Der Kontoabgleich ist ein wichtiger Schritt, um die Vollständigkeit und Richtigkeit der Finanzberichte sicherzustellen. Konkret müssen sich Unternehmen versöhnen Bilanz Konten, die erhebliche oder wesentliche Falschangaben enthalten könnten. Buchhalter gehen jedes Konto im Hauptbuch durch und überprüfen, ob der aufgeführte Saldo vollständig und korrekt ist. Wenn Unstimmigkeiten festgestellt werden, untersuchen Buchhalter diese und ergreifen entsprechende Korrekturmaßnahmen.

Als Teil der FinTech-Organisation von Amazon bieten wir eine Softwareplattform an, die es den internen Buchhaltungsteams bei Amazon ermöglicht, Kontoabstimmungen durchzuführen. Um den Abstimmungsprozess zu optimieren, benötigen diese Benutzer eine leistungsstarke Transformation mit der Möglichkeit zur Skalierung bei Bedarf sowie der Fähigkeit, variable Dateigrößen von wenigen MB bis zu mehr als 100 GB zu verarbeiten. Es ist nicht immer möglich, Daten auf einer einzigen Maschine unterzubringen oder sie mit einem einzigen Programm in einem angemessenen Zeitrahmen zu verarbeiten. Diese Berechnung muss schnell genug durchgeführt werden, um praktische Dienste bereitzustellen, bei denen Programmierlogik und zugrunde liegende Details (Datenverteilung, Fehlertoleranz und Planung) getrennt werden können.

Mithilfe verteilter Datenverarbeitungslösungen können wir diese gleichzeitigen Berechnungen auf mehreren Maschinen oder Threads derselben Funktion über Gruppen von Elementen eines Datensatzes hinweg durchführen. Dies hat uns dazu ermutigt, unseren auf AWS-Diensten basierenden Abgleichsdienst neu zu erfinden Amazon EMR und dem Apache Funken verteiltes Verarbeitungsframework, das verwendet PySpark. Mit diesem Dienst können Benutzer Dateien über 100 GB mit bis zu 100 Millionen Transaktionen in weniger als 30 Minuten verarbeiten. Der Abgleichsdienst hat sich zu einem Kraftpaket für die Datenverarbeitung entwickelt, und jetzt können Benutzer nahtlos eine Vielzahl von Vorgängen durchführen, wie z Drehpunkt, JOIN (wie eine Excel-SVERWEIS-Operation), Arithmetik Operationen und mehrund bietet eine vielseitige und effiziente Lösung für den Abgleich großer Datensätze. Diese Verbesserung ist ein Beweis für die Skalierbarkeit und Geschwindigkeit, die durch die Einführung verteilter Datenverarbeitungslösungen erreicht wird.

In diesem Beitrag erklären wir, wie wir Amazon EMR integriert haben, um ein hochverfügbares und skalierbares System aufzubauen, das es uns ermöglichte, einen großvolumigen Finanzabstimmungsprozess durchzuführen.

Architektur vor der Migration

Das folgende Diagramm veranschaulicht unsere bisherige Architektur.

Unser Legacy-Service wurde mit aufgebaut Amazon Elastic Container-Service (Amazon ECS) auf AWS Fargate. Wir haben die Daten sequentiell mit Python verarbeitet. Aufgrund der fehlenden Parallelverarbeitungsfähigkeit mussten wir jedoch häufig die Clustergröße vertikal erhöhen, um größere Datensätze zu unterstützen. Zum Vergleich: Die Verarbeitung von 5 GB Daten mit 50 Vorgängen dauerte etwa 3 Stunden. Dieser Dienst wurde für die horizontale Skalierung auf fünf ECS-Instanzen konfiguriert, von denen Nachrichten abgefragt wurden Amazon Simple Queue-Dienst (Amazon SQS), das die Transformationsanfragen gespeist hat. Jede Instanz wurde mit 4 vCPUs und 30 GB Arbeitsspeicher konfiguriert, um eine horizontale Skalierung zu ermöglichen. Allerdings konnten wir die Leistungskapazität nicht erweitern, da der Prozess sequentiell ablief und Datenblöcke auswählte Amazon Simple Storage-Service (Amazon S3) zur Bearbeitung. Beispielsweise erforderte ein VLOOKUP-Vorgang, bei dem zwei Dateien zusammengefügt werden sollen, das Lesen beider Dateien im Speicher Stück für Stück, um die Ausgabe zu erhalten. Dies wurde zu einem Hindernis für Benutzer, da sie lange auf die Verarbeitung ihrer Datensätze warten mussten.

Im Rahmen unserer Neuarchitektur und Modernisierung wollten wir Folgendes erreichen:

• Hohe Verfügbarkeit – Die Datenverarbeitungscluster sollten hochverfügbar sein und eine Verfügbarkeit von drei Neunen (9 %) bieten.
• Durchsatz – Der Dienst soll 1,500 Fahrten pro Tag abwickeln
• Latency – Es sollte in der Lage sein, 100 GB Daten innerhalb von 30 Minuten zu verarbeiten
• Heterogenität – Der Cluster sollte in der Lage sein, eine Vielzahl von Arbeitslasten zu unterstützen, wobei die Dateigröße zwischen einigen MB und Hunderten von GB liegt
• Parallelität abfragen – Die Implementierung erfordert die Fähigkeit, mindestens 10 Grade der Parallelität zu unterstützen
• Zuverlässigkeit der Jobs und Datenkonsistenz – Jobs müssen zuverlässig und konsistent ausgeführt werden, um eine Verletzung von Service Level Agreements (SLAs) zu vermeiden.
• Kostengünstig und skalierbar – Es muss je nach Arbeitslast skalierbar und damit kosteneffizient sein
• Sicherheit und Compliance – Angesichts der Sensibilität der Daten müssen sie eine differenzierte Zugriffskontrolle und geeignete Sicherheitsimplementierungen unterstützen
• Netzwerk Performance – Die Lösung muss eine End-to-End-Überwachung der Cluster und Jobs bieten

Warum Amazon EMR

Amazon EMR ist die branchenführende Cloud-Big-Data-Lösung für Datenverarbeitung im Petabyte-Bereich, interaktive Analysen und maschinelles Lernen (ML) unter Verwendung von Open-Source-Frameworks wie Apache Funken, Apache Hive und Presto. Mit diesen Frameworks und zugehörigen Open-Source-Projekten können Sie Daten für Analysezwecke und BI-Workloads verarbeiten. Mit Amazon EMR können Sie große Datenmengen in und aus anderen AWS-Datenspeichern und -Datenbanken wie Amazon S3 umwandeln und verschieben Amazon DynamoDB.

Ein bemerkenswerter Vorteil von Amazon EMR liegt in der effektiven Nutzung der Parallelverarbeitung mit PySpark, was eine deutliche Verbesserung gegenüber herkömmlichem sequentiellem Python-Code darstellt. Dieser innovative Ansatz optimiert die Bereitstellung und Skalierung von Apache Spark-Clustern und ermöglicht eine effiziente Parallelisierung großer Datenmengen. Die verteilte Computerinfrastruktur steigert nicht nur die Leistung, sondern ermöglicht auch die Verarbeitung großer Datenmengen mit beispielloser Geschwindigkeit. Ausgestattet mit Bibliotheken erleichtert PySpark Excel-ähnliche Vorgänge Datenrahmen, und die Abstraktion von DataFrames auf höherer Ebene vereinfacht komplizierte Datenmanipulationen und reduziert so die Codekomplexität. In Kombination mit automatischer Cluster-Bereitstellung, dynamischer Ressourcenzuweisung und Integration mit anderen AWS-Diensten erweist sich Amazon EMR als vielseitige Lösung, die für unterschiedliche Arbeitslasten geeignet ist, von der Stapelverarbeitung bis hin zu ML. Die inhärente Fehlertoleranz von PySpark und Amazon EMR fördert die Robustheit auch bei Knotenausfällen und macht es zu einer skalierbaren, kostengünstigen und leistungsstarken Wahl für die parallele Datenverarbeitung auf AWS.

Amazon EMR erweitert seine Funktionen über die Grundlagen hinaus und bietet eine Vielzahl von Bereitstellungsoptionen, um den unterschiedlichen Anforderungen gerecht zu werden. Ob es Amazon EMR auf EC2, Amazon EMR auf EKS, Amazon EMR ohne Server, oder Amazon EMR auf AWS Outpostskönnen Sie Ihren Ansatz an spezifische Anforderungen anpassen. Für diejenigen, die eine serverlose Umgebung für Spark-Jobs suchen, ist die Integration AWS-Kleber ist auch eine praktikable Option. Amazon EMR unterstützt nicht nur verschiedene Open-Source-Frameworks, einschließlich Spark, sondern bietet auch Flexibilität bei der Auswahl der Bereitstellungsmodi. Amazon Elastic Compute-Cloud (Amazon EC2) Instanztypen, Skalierungsmechanismen und zahlreiche kostensparende Optimierungstechniken.

Amazon EMR ist eine dynamische Kraft in der Cloud und bietet unübertroffene Funktionen für Unternehmen, die robuste Big-Data-Lösungen suchen. Seine nahtlose Integration, leistungsstarke Funktionen und Anpassungsfähigkeit machen es zu einem unverzichtbaren Werkzeug für die Bewältigung der Komplexität von Datenanalysen und ML auf AWS.

Neu gestaltete Architektur

Das folgende Diagramm veranschaulicht unsere neu gestaltete Architektur.

Die Lösung arbeitet im Rahmen eines API-Vertrags, bei dem Kunden Transformationskonfigurationen übermitteln können, die neben dem Speicherort des S3-Datensatzes auch eine Reihe von Vorgängen für die Verarbeitung definieren. Die Anfrage wird über Amazon SQS in die Warteschlange gestellt und dann über eine Lambda-Funktion an Amazon EMR weitergeleitet. Dieser Prozess initiiert die Erstellung eines Amazon EMR-Schritts für die Spark-Framework-Implementierung auf einem dedizierten EMR-Cluster. Obwohl Amazon EMR über die Lebensdauer eines Clusters mit langer Laufzeit eine unbegrenzte Anzahl von Schritten unterstützt, können nur 256 Schritte gleichzeitig ausgeführt werden oder ausstehen. Für eine optimale Parallelisierung ist die Schrittgleichzeitigkeit auf 10 eingestellt, sodass 10 Schritte gleichzeitig ausgeführt werden können. Bei fehlgeschlagenen Anfragen wird Amazon SQS Warteschlange für unzustellbare Nachrichten (DLQ) behält das Ereignis. Spark verarbeitet die Anfrage und übersetzt Excel-ähnliche Vorgänge in PySpark-Code für einen effizienten Abfrageplan. Resilient DataFrames speichern Eingabe-, Ausgabe- und Zwischendaten im Speicher, optimieren die Verarbeitungsgeschwindigkeit, reduzieren die Festplatten-E/A-Kosten, verbessern die Workload-Leistung und liefern die endgültige Ausgabe an den angegebenen Amazon S3-Speicherort.

Wir definieren unser SLA in zwei Dimensionen: Latenz und Durchsatz. Die Latenz ist definiert als die Zeit, die für die Ausführung eines Auftrags bei einer deterministischen Datensatzgröße und der Anzahl der am Datensatz ausgeführten Vorgänge benötigt wird. Der Durchsatz ist definiert als die maximale Anzahl gleichzeitiger Jobs, die der Dienst ausführen kann, ohne das Latenz-SLA eines Jobs zu verletzen. Das Gesamtskalierbarkeits-SLA des Dienstes hängt vom Gleichgewicht zwischen horizontaler Skalierung elastischer Rechenressourcen und vertikaler Skalierung einzelner Server ab.

Da wir 1,500 Prozesse pro Tag mit minimaler Latenz und hoher Leistung ausführen mussten, haben wir uns für die Integration von Amazon EMR im EC2-Bereitstellungsmodus mit aktivierter verwalteter Skalierung entschieden, um die Verarbeitung variabler Dateigrößen zu unterstützen.

Die EMR-Clusterkonfiguration bietet viele verschiedene Auswahlmöglichkeiten:

• EMR-Knotentypen – Primär-, Kern- oder Aufgabenknoten
• Kaufoptionen für Instanzen – On-Demand-Instanzen, reservierte Instanzen oder Spot-Instanzen
• Konfigurationsoptionen – EMR-Instanzflotte oder einheitliche Instanzgruppe
• Skalierungsoptionen - Automatische Skalierung oder von Amazon EMR verwaltete Skalierung

Basierend auf unserer variablen Arbeitslast haben wir eine EMR-Instanzflotte konfiguriert (Best Practices finden Sie unter Zuverlässigkeit). Wir haben uns auch entschieden, die verwaltete Skalierung von Amazon EMR zu verwenden, um die Kern- und Aufgabenknoten zu skalieren (Informationen zu Skalierungsszenarien finden Sie unter Knotenzuteilungsszenarien). Schließlich haben wir uns für speicheroptimiert entschieden AWS Graviton Instanzen, die bis zu bieten 30 % geringere Kosten und bis zu 15 % verbesserte Leistung für Spark-Workloads.

Der folgende Code bietet eine Momentaufnahme unserer Clusterkonfiguration:

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

Leistung

Mit unserer Migration zu Amazon EMR konnten wir eine Systemleistung erreichen, die in der Lage ist, eine Vielzahl von Datensätzen zu verarbeiten, die von nur 273 GB bis zu 88.5 GB reichen p99 von 491 Sekunden (ca. 8 Minuten).

Die folgende Abbildung veranschaulicht die Vielfalt der verarbeiteten Dateigrößen.

Die folgende Abbildung zeigt unsere Latenz.

Zum Vergleich mit der sequentiellen Verarbeitung haben wir zwei Datensätze mit 53 Millionen Datensätzen genommen und einen VLOOKUP-Vorgang gegeneinander ausgeführt, zusammen mit 49 anderen Excel-ähnlichen Vorgängen. Die Verarbeitung im neuen Dienst dauerte 26 Minuten, im Vergleich zu 5 Tagen im alten Dienst. Diese Verbesserung ist im Hinblick auf die Leistung fast 300-mal größer als bei der vorherigen Architektur.

Überlegungen

Beachten Sie Folgendes, wenn Sie diese Lösung in Betracht ziehen:

• Cluster mit der richtigen Größe – Obwohl die Größe von Amazon EMR geändert werden kann, ist es wichtig, die richtige Größe der Cluster zu wählen. Durch die richtige Dimensionierung wird ein langsamer Cluster bei Unterdimensionierung oder höhere Kosten bei Überdimensionierung des Clusters abgemildert. Um diese Probleme zu antizipieren, können Sie die Anzahl und Art der Knoten berechnen, die für die Arbeitslasten benötigt werden.
• Parallele Schritte – Durch die parallele Ausführung von Schritten können Sie komplexere Arbeitslasten ausführen, die Cluster-Ressourcenauslastung erhöhen und die Zeit reduzieren, die für die Erledigung Ihrer Arbeitslast benötigt wird. Die Anzahl der Schritte, die gleichzeitig ausgeführt werden dürfen, ist konfigurierbar und kann beim Start eines Clusters und jederzeit nach dem Start des Clusters festgelegt werden. Sie müssen die CPU-/Speichernutzung pro Job berücksichtigen und optimieren, wenn mehrere Jobs in einem einzigen gemeinsam genutzten Cluster ausgeführt werden.
• Jobbasierte transiente EMR-Cluster – Gegebenenfalls wird die Verwendung eines auftragsbasierten transienten EMR-Clusters empfohlen, der eine hervorragende Isolierung bietet und überprüft, ob jede Aufgabe in ihrer dedizierten Umgebung ausgeführt wird. Dieser Ansatz optimiert die Ressourcennutzung, hilft, Interferenzen zwischen Jobs zu vermeiden und verbessert die Gesamtleistung und Zuverlässigkeit. Die transiente Natur ermöglicht eine effiziente Skalierung und bietet eine robuste und isolierte Lösung für verschiedene Datenverarbeitungsanforderungen.
• EMR Serverlos – EMR Serverless ist die ideale Wahl, wenn Sie sich lieber nicht um die Verwaltung und den Betrieb von Clustern kümmern möchten. Es ermöglicht Ihnen die mühelose Ausführung von Anwendungen mithilfe der in EMR Serverless verfügbaren Open-Source-Frameworks und bietet so ein unkompliziertes und problemloses Erlebnis.
• Amazon EMR auf EKS – Amazon EMR auf EKS bietet deutliche Vorteile, wie z. B. schnellere Startzeiten und verbesserte Skalierbarkeit zur Lösung von Rechenkapazitätsproblemen – was besonders für Graviton- und Spot-Instance-Benutzer von Vorteil ist. Die Einbeziehung einer breiteren Palette von Rechentypen erhöht die Kosteneffizienz und ermöglicht eine maßgeschneiderte Ressourcenzuweisung. Darüber hinaus sorgt die Multi-AZ-Unterstützung für eine erhöhte Verfügbarkeit. Diese überzeugenden Funktionen bieten eine robuste Lösung für die Verwaltung großer Datenmengen mit verbesserter Leistung, Kostenoptimierung und Zuverlässigkeit in verschiedenen Computerszenarien.

Zusammenfassung

In diesem Beitrag haben wir erklärt, wie Amazon seinen großvolumigen Finanzabstimmungsprozess mit Amazon EMR für eine höhere Skalierbarkeit und Leistung optimiert hat. Wenn Sie über eine monolithische Anwendung verfügen, die auf vertikale Skalierung angewiesen ist, um zusätzliche Anforderungen oder Datensätze zu verarbeiten, kann die Migration auf ein verteiltes Verarbeitungsframework wie Apache Spark und die Auswahl eines verwalteten Dienstes wie Amazon EMR für die Datenverarbeitung dazu beitragen, die Laufzeit zu verkürzen und Ihre Bereitstellung zu senken SLA und kann auch dazu beitragen, die Gesamtbetriebskosten (TCO) zu senken.

Da wir Amazon EMR für diesen speziellen Anwendungsfall nutzen, ermutigen wir Sie, weitere Möglichkeiten auf Ihrem Weg zur Dateninnovation zu erkunden. Erwägen Sie die Evaluierung von AWS Glue zusammen mit anderen dynamischen Amazon EMR-Bereitstellungsoptionen wie EMR Serverless oder Amazon EMR auf EKS, um den besten AWS-Service zu finden, der auf Ihren individuellen Anwendungsfall zugeschnitten ist. Die Zukunft der Dateninnovation birgt spannende Möglichkeiten und Fortschritte, die weiter erforscht werden müssen.

Über die Autoren

Jeeshan Khetrapal ist Senior Software Development Engineer bei Amazon, wo er Fintech-Produkte auf Basis serverloser Cloud-Computing-Architekturen entwickelt, die für die allgemeinen IT-Kontrollen, die Finanzberichterstattung und die Steuerung von Governance, Risiko und Compliance von Unternehmen verantwortlich sind.

Shakti Mishra ist Principal Solutions Architect bei AWS, wo er Kunden dabei hilft, ihre Datenarchitektur zu modernisieren und ihre End-to-End-Datenstrategie zu definieren, einschließlich Datensicherheit, Zugänglichkeit, Governance und mehr. Er ist auch der Autor des Buches Vereinfachen Sie Big-Data-Analysen mit Amazon EMR. Außerhalb der Arbeit lernt Sakti gerne neue Technologien, schaut sich Filme an und besucht Orte mit der Familie.

• SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
• PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
• PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
• PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
• PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
• Quelle: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/