Uzgodnienie kont jest ważnym krokiem zapewniającym kompletność i dokładność sprawozdań finansowych. W szczególności firmy muszą się pogodzić bilans sprawozdania finansowe, które mogą zawierać znaczące lub istotne zniekształcenia. Księgowi przeglądają każde konto w księdze głównej kont i sprawdzają, czy podane saldo jest kompletne i dokładne. W przypadku wykrycia rozbieżności księgowi badają je i podejmują odpowiednie działania korygujące.

Jako część organizacji FinTech firmy Amazon oferujemy platformę oprogramowania, która umożliwia wewnętrznym zespołom księgowym Amazon przeprowadzanie uzgadniania kont. Aby zoptymalizować proces uzgadniania, użytkownicy ci wymagają transformacji o wysokiej wydajności z możliwością skalowania na żądanie, a także możliwością przetwarzania plików o zmiennym rozmiarze od kilku MB do ponad 100 GB. Nie zawsze możliwe jest umieszczenie danych na jednej maszynie lub przetworzenie ich za pomocą jednego programu w rozsądnym czasie. Obliczenia te należy wykonać wystarczająco szybko, aby zapewnić praktyczne usługi, w których można oddzielić logikę programowania i leżące u jej podstaw szczegóły (dystrybucja danych, odporność na błędy i planowanie).

Możemy osiągnąć te jednoczesne obliczenia na wielu maszynach lub wątkach o tej samej funkcji w grupach elementów zbioru danych, korzystając z rozwiązań do rozproszonego przetwarzania danych. Zachęciło nas to do ponownego opracowania naszej usługi uzgadniania opartej na usługach AWS, w tym Amazon EMR oraz Apache Spark rozproszona platforma przetwarzania, która wykorzystuje PySpark. Usługa ta pozwala użytkownikom przetwarzać pliki powyżej 100 GB zawierające do 100 milionów transakcji w czasie krótszym niż 30 minut. Usługa uzgadniania stała się potęgą w przetwarzaniu danych, a teraz użytkownicy mogą bezproblemowo wykonywać różnorodne operacje, takie jak Pivot, DOŁĄCZ (jak operacja Excel VLOOKUP), arytmetyka operacje i jeszcze, zapewniając wszechstronne i wydajne rozwiązanie do uzgadniania dużych zbiorów danych. To ulepszenie jest dowodem skalowalności i szybkości osiągniętej dzięki przyjęciu rozwiązań do rozproszonego przetwarzania danych.

W tym poście wyjaśniamy, jak zintegrowaliśmy Amazon EMR, aby zbudować wysoce dostępny i skalowalny system, który umożliwił nam przeprowadzenie masowego procesu uzgadniania finansowego.

Architektura przed migracją

Poniższy diagram ilustruje naszą poprzednią architekturę.

Nasza dotychczasowa usługa została zbudowana w oparciu o Usługa Amazon Elastic Container Service (Amazon ECS) włączony AWS-Fargate. Dane przetwarzaliśmy sekwencyjnie przy użyciu języka Python. Jednak ze względu na brak możliwości przetwarzania równoległego często musieliśmy zwiększać rozmiar klastra w pionie, aby obsługiwać większe zbiory danych. Dla kontekstu: przetworzenie 5 GB danych z 50 operacjami zajęło około 3 godzin. Usługę tę skonfigurowano tak, aby skalowała się poziomo do pięciu instancji ECS, z których odpytywano wiadomości Usługa Amazon Simple Queue (Amazon SQS), która przekazała żądania transformacji. Każda instancja została skonfigurowana z 4 procesorami vCPU i 30 GB pamięci, aby umożliwić skalowanie poziome. Nie mogliśmy jednak zwiększyć jego wydajności, ponieważ proces odbywał się sekwencyjnie, zbierając fragmenty danych Usługa Amazon Simple Storage (Amazon S3) do przetworzenia. Na przykład operacja WYSZUKAJ.PIONOWO, podczas której dwa pliki mają zostać połączone, wymagała odczytania obu plików fragment po fragmencie pamięci w celu uzyskania wyniku. Stało się to przeszkodą dla użytkowników, ponieważ musieli długo czekać na przetworzenie swoich zbiorów danych.

W ramach naszej rearchitektury i modernizacji chcieliśmy osiągnąć:

• Duża dostępność – Klastry przetwarzania danych powinny charakteryzować się wysoką dostępnością, zapewniającą dostępność na poziomie trzech dziewiątek (9%)
• Wydajność – Serwis powinien obsłużyć 1,500 kursów dziennie
• Utajenie – Powinien być w stanie przetworzyć 100 GB danych w ciągu 30 minut
• Niejednorodność – Klaster powinien być w stanie obsłużyć szeroką gamę obciążeń, z plikami o wielkości od kilku MB do setek GB
• Zapytanie o współbieżność – Wdrożenie wymaga możliwości obsługi minimum 10 stopni współbieżności
• Niezawodność zadań i spójność danych – Zadania muszą działać niezawodnie i konsekwentnie, aby uniknąć zerwania umów o gwarantowanym poziomie usług (SLA)
• Ekonomiczne i skalowalne – Musi być skalowalny w zależności od obciążenia, dzięki czemu jest opłacalny
• Bezpieczeństwo i zgodność – Biorąc pod uwagę wrażliwość danych, muszą one obsługiwać precyzyjną kontrolę dostępu i odpowiednie wdrożenia zabezpieczeń
• Monitorowanie – Rozwiązanie musi oferować kompleksowe monitorowanie klastrów i zadań

Dlaczego Amazon EMR

Amazon EMR to wiodące w branży rozwiązanie Big Data w chmurze do przetwarzania danych w skali petabajtowej, interaktywnej analizy i uczenia maszynowego (ML) przy użyciu platform open source, takich jak Apache Spark, Ula Apache, presto. Dzięki tym frameworkom i powiązanym projektom typu open source możesz przetwarzać dane do celów analitycznych i obciążeń BI. Amazon EMR umożliwia przekształcanie i przenoszenie dużych ilości danych do i z innych magazynów danych i baz danych AWS, takich jak Amazon S3 i Amazon DynamoDB.

Godną uwagi zaletą Amazon EMR jest efektywne wykorzystanie przetwarzania równoległego za pomocą PySpark, co stanowi znaczną poprawę w porównaniu z tradycyjnym sekwencyjnym kodem Pythona. To innowacyjne podejście usprawnia wdrażanie i skalowanie klastrów Apache Spark, umożliwiając wydajną pracę równoległą na dużych zbiorach danych. Rozproszona infrastruktura obliczeniowa nie tylko zwiększa wydajność, ale także umożliwia przetwarzanie ogromnych ilości danych z niespotykaną dotąd szybkością. Wyposażony w biblioteki, PySpark ułatwia operacje na plikach Excel Ramki danych, a abstrakcja wyższego poziomu DataFrames upraszcza skomplikowane manipulacje danymi, zmniejszając złożoność kodu. W połączeniu z automatycznym udostępnianiem klastrów, dynamiczną alokacją zasobów i integracją z innymi usługami AWS, Amazon EMR okazuje się wszechstronnym rozwiązaniem odpowiednim do różnorodnych obciążeń, od przetwarzania wsadowego po ML. Wrodzona odporność na błędy w PySpark i Amazon EMR zapewnia niezawodność nawet w przypadku awarii węzła, co czyni go skalowalnym, opłacalnym i wydajnym wyborem do równoległego przetwarzania danych w AWS.

Amazon EMR rozszerza swoje możliwości poza podstawy, oferując różnorodne opcje wdrażania w celu zaspokojenia różnorodnych potrzeb. Czy to jest Amazon EMR na EC2, Amazon EMR na EKS, Bezserwerowe Amazon EMRlub Amazon EMR w placówkach AWSmożesz dostosować swoje podejście do konkretnych wymagań. Dla tych, którzy szukają środowiska bezserwerowego dla zadań Spark, integracja Klej AWS jest również realną opcją. Oprócz obsługi różnych frameworków open source, w tym Spark, Amazon EMR zapewnia elastyczność w wyborze trybów wdrażania, Elastyczna chmura obliczeniowa Amazon (Amazon EC2), typy instancji, mechanizmy skalowania i liczne techniki optymalizacji oszczędzające koszty.

Amazon EMR to dynamiczna siła w chmurze, zapewniająca niezrównane możliwości organizacjom poszukującym solidnych rozwiązań Big Data. Jego bezproblemowa integracja, zaawansowane funkcje i możliwości adaptacji sprawiają, że jest to niezbędne narzędzie do poruszania się po złożoności analityki danych i uczenia maszynowego w AWS.

Przeprojektowana architektura

Poniższy diagram ilustruje naszą przeprojektowaną architekturę.

Rozwiązanie działa w ramach kontraktu API, w ramach którego klienci mogą przesyłać konfiguracje transformacji, definiując zestaw operacji wraz z lokalizacją zbioru danych S3 do przetworzenia. Żądanie jest umieszczane w kolejce przez Amazon SQS, a następnie kierowane do Amazon EMR za pośrednictwem funkcji Lambda. Proces ten inicjuje utworzenie kroku Amazon EMR w celu wdrożenia frameworku Spark w dedykowanym klastrze EMR. Chociaż Amazon EMR obsługuje nieograniczoną liczbę kroków w ciągu całego życia klastra, jednocześnie uruchomionych lub oczekujących może być tylko 256 kroków. Aby zapewnić optymalną równoległość, współbieżność kroków jest ustawiona na 10, co pozwala na jednoczesne działanie 10 kroków. W przypadku niepowodzenia żądań Amazon SQS kolejka utraconych wiadomości (DLQ) zachowuje wydarzenie. Spark przetwarza żądanie, tłumacząc operacje podobne do programu Excel na kod PySpark w celu uzyskania wydajnego planu zapytań. Odporne ramki DataFrames przechowują dane wejściowe, wyjściowe i pośrednie w pamięci, optymalizując prędkość przetwarzania, redukując koszty operacji we/wy dysku, zwiększając wydajność obciążeń i dostarczając ostateczne dane wyjściowe do określonej lokalizacji Amazon S3.

Naszą umowę SLA definiujemy w dwóch wymiarach: opóźnienia i przepustowości. Opóźnienie definiuje się jako czas potrzebny na wykonanie jednego zadania w odniesieniu do deterministycznego rozmiaru zbioru danych oraz liczbę operacji wykonanych na zbiorze danych. Przepustowość definiuje się jako maksymalną liczbę jednoczesnych zadań, które usługa może wykonać bez naruszenia umowy SLA dotyczącej opóźnienia jednego zadania. Ogólna umowa SLA dotycząca skalowalności usługi zależy od równowagi między skalowaniem poziomym elastycznych zasobów obliczeniowych i skalowaniem pionowym poszczególnych serwerów.

Ponieważ musieliśmy uruchamiać 1,500 procesów dziennie przy minimalnych opóźnieniach i wysokiej wydajności, zdecydowaliśmy się zintegrować Amazon EMR w trybie wdrażania EC2 z włączoną funkcją zarządzanego skalowania w celu obsługi przetwarzania plików o zmiennych rozmiarach.

Konfiguracja klastra EMR zapewnia wiele różnych opcji:

• Typy węzłów EMR – Węzły podstawowe, podstawowe lub zadaniowe
• Opcje zakupu instancji – Instancje na żądanie, Instancje zarezerwowane lub Instancje typu Spot
• Opcje konfiguracji – Flota instancji EMR lub jednolita grupa instancji
• Opcje skalowania - Automatyczne skalowanie lub skalowanie zarządzane przez Amazon EMR

W oparciu o nasze zmienne obciążenie pracą skonfigurowaliśmy flotę instancji EMR (najlepsze praktyki można znaleźć w artykule Niezawodność). Zdecydowaliśmy się również użyć skalowania zarządzanego przez Amazon EMR do skalowania węzłów rdzenia i zadań (scenariusze skalowania można znaleźć w artykule Scenariusze alokacji węzłów). Na koniec wybraliśmy zoptymalizowaną pod kątem pamięci Grawiton AWS przypadki, które zapewniają do Koszt niższy o 30% i wydajność zwiększona nawet o 15% w przypadku obciążeń Spark.

Poniższy kod zawiera migawkę konfiguracji naszego klastra:

Concurrent steps:10

EMR Managed Scaling:
minimumCapacityUnits: 64
maximumCapacityUnits: 512
maximumOnDemandCapacityUnits: 512
maximumCoreCapacityUnits: 512

Master Instance Fleet:
r6g.xlarge
- 4 vCore, 30.5 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units

Core Instance Fleet:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Task Instances:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Wydajność

Dzięki naszej migracji do Amazon EMR udało nam się osiągnąć wydajność systemu zdolną do obsługi różnych zestawów danych, od tak małych jak 273 B do nawet 88.5 GB przy p99 491 sekund (około 8 minut).

Poniższy rysunek ilustruje różne rozmiary przetwarzanych plików.

Poniższy rysunek pokazuje nasze opóźnienie.

Aby porównać z przetwarzaniem sekwencyjnym, wzięliśmy dwa zbiory danych zawierające 53 miliony rekordów i przeprowadziliśmy względem siebie operację WYSZUKAJ.PIONOWO oraz 49 innych operacji przypominających program Excel. Przetworzenie tego w nowej usłudze zajęło 26 minut, w porównaniu do 5 dni w starszej usłudze. Ta poprawa jest prawie 300 razy większa w porównaniu z poprzednią architekturą pod względem wydajności.

rozważania

Rozważając to rozwiązanie, należy pamiętać o następujących kwestiach:

• Klastry o odpowiedniej wielkości – Chociaż rozmiar Amazon EMR można zmieniać, ważne jest, aby dostosować rozmiar klastrów. Właściwy rozmiar pozwala uniknąć powolnego klastra, jeśli jest on zbyt mały, lub wyższych kosztów, jeśli klaster jest zbyt duży. Aby przewidzieć te problemy, można obliczyć liczbę i typ węzłów potrzebnych do obsługi obciążeń.
• Kroki równoległe – Równoległe wykonywanie kroków umożliwia uruchamianie bardziej zaawansowanych obciążeń, zwiększa wykorzystanie zasobów klastra i skraca czas potrzebny na wykonanie zadania. Liczbę kroków, które można wykonać jednocześnie, można skonfigurować podczas uruchamiania klastra i w dowolnym momencie po jego uruchomieniu. Należy rozważyć i zoptymalizować użycie procesora/pamięci na zadanie, gdy w jednym udostępnionym klastrze działa wiele zadań.
• Oparte na zadaniach przejściowe klastry EMR – W stosownych przypadkach zaleca się użycie klastra EMR opartego na zadaniach, który zapewnia doskonałą izolację i sprawdza, czy każde zadanie działa w dedykowanym środowisku. Takie podejście optymalizuje wykorzystanie zasobów, pomaga zapobiegać zakłóceniom między zadaniami oraz zwiększa ogólną wydajność i niezawodność. Przejściowy charakter umożliwia wydajne skalowanie, zapewniając solidne i izolowane rozwiązanie dla różnorodnych potrzeb w zakresie przetwarzania danych.
• EMR bez serwera – EMR Serverless to idealny wybór, jeśli nie chcesz zajmować się zarządzaniem i obsługą klastrów. Umożliwia bezproblemowe uruchamianie aplikacji przy użyciu platform open source dostępnych w ramach EMR Serverless, oferując proste i bezproblemowe działanie.
• Amazonka EMR na EKS – Amazon EMR na platformie EKS oferuje wyraźne korzyści, takie jak krótszy czas uruchamiania i poprawiona skalowalność w rozwiązywaniu problemów związanych z wydajnością obliczeniową – co jest szczególnie korzystne dla użytkowników Graviton i Spot Instance. Włączenie szerszego zakresu typów obliczeń zwiększa efektywność kosztową, umożliwiając dostosowaną alokację zasobów. Co więcej, obsługa Multi-AZ zapewnia zwiększoną dostępność. Te atrakcyjne funkcje zapewniają solidne rozwiązanie do zarządzania obciążeniami big data z lepszą wydajnością, optymalizacją kosztów i niezawodnością w różnych scenariuszach obliczeniowych.

Wnioski

W tym poście wyjaśniliśmy, jak Amazon zoptymalizował swój masowy proces uzgadniania finansowego za pomocą Amazon EMR w celu uzyskania wyższej skalowalności i wydajności. Jeśli masz aplikację monolityczną, która jest zależna od skalowania pionowego w celu przetwarzania dodatkowych żądań lub zestawów danych, migracja jej do platformy przetwarzania rozproszonego, takiej jak Apache Spark i wybranie usługi zarządzanej, takiej jak Amazon EMR do obliczeń, może pomóc w skróceniu czasu działania i zmniejszeniu wydajności SLA, a także może pomóc w obniżeniu całkowitego kosztu posiadania (TCO).

Ponieważ uwzględniamy Amazon EMR w tym konkretnym przypadku, zachęcamy Cię do zbadania dalszych możliwości w Twojej podróży do innowacji w zakresie danych. Rozważ ocenę AWS Glue wraz z innymi dynamicznymi opcjami wdrażania Amazon EMR, takimi jak EMR Serverless lub Amazon EMR na EKS, aby odkryć najlepszą usługę AWS dostosowaną do Twojego unikalnego przypadku użycia. Przyszłość innowacji w zakresie danych kryje w sobie ekscytujące możliwości i postępy, które należy zbadać dalej.

O autorach

Jeeshan Khetrapal jest starszym inżynierem ds. rozwoju oprogramowania w firmie Amazon, gdzie opracowuje produkty fintech oparte na bezserwerowych architekturach przetwarzania w chmurze, które są odpowiedzialne za ogólną kontrolę IT w firmach, raportowanie finansowe i kontrolę w zakresie zarządzania, ryzyka i zgodności.

Sakti Misra jest głównym architektem rozwiązań w AWS, gdzie pomaga klientom modernizować architekturę danych i definiować kompleksową strategię dotyczącą danych, w tym bezpieczeństwo danych, dostępność, zarządzanie i nie tylko. Jest także autorem książki Uprość analizę Big Data dzięki Amazon EMR. Poza pracą Sakti lubi uczyć się nowych technologii, oglądać filmy i odwiedzać miejsca z rodziną.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• PlatoData.Network Pionowe generatywne AI. Wzmocnij się. Dostęp tutaj.
• PlatoAiStream. Inteligencja Web3. Wiedza wzmocniona. Dostęp tutaj.
• PlatonESG. Węgiel Czysta technologia, Energia, Środowisko, Słoneczny, Gospodarowanie odpadami. Dostęp tutaj.
• Platon Zdrowie. Inteligencja w zakresie biotechnologii i badań klinicznych. Dostęp tutaj.
• Źródło: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/