A számlaegyeztetés fontos lépés a pénzügyi kimutatások teljességének és pontosságának biztosításához. Konkrétan a cégeknek kell egyeztetniük mérleg olyan beszámolókat, amelyek jelentős vagy lényeges hibás állításokat tartalmazhatnak. A könyvelők átnézik a főkönyvi számlákat, és ellenőrzik, hogy a felsorolt ​​egyenleg teljes és pontos. Ha eltéréseket találnak, a könyvelők kivizsgálják és megteszik a megfelelő korrekciós intézkedéseket.

Az Amazon FinTech szervezetének részeként olyan szoftverplatformot kínálunk, amely felhatalmazza az Amazon belső számviteli csapatait a számlaegyeztetések elvégzésére. Az egyeztetési folyamat optimalizálása érdekében ezeknek a felhasználóknak nagy teljesítményű átalakításra van szükségük az igény szerinti méretezés lehetőségével, valamint a néhány MB-tól a 100 GB-nál nagyobb méretű változó fájlméretek feldolgozására. Nem mindig lehetséges ésszerű időn belül egyetlen gépre illeszteni vagy egyetlen programmal feldolgozni az adatokat. Ezt a számítást elég gyorsan kell elvégezni ahhoz, hogy olyan gyakorlati szolgáltatásokat nyújtsunk, ahol a programozási logika és a mögöttes részletek (adatelosztás, hibatűrés és ütemezés) elkülöníthetők.

Ezeket az egyidejű számításokat több gépen vagy ugyanazon funkciójú szálon is megvalósíthatjuk egy adathalmaz elemcsoportjai között elosztott adatfeldolgozási megoldásokkal. Ez arra ösztönzött bennünket, hogy újra feltaláljuk az AWS-szolgáltatásokon alapuló egyeztetési szolgáltatásunkat, beleértve a következőket: Amazon EMR és a Apache Spark elosztott feldolgozási keretrendszer, amely használ PySpark. Ez a szolgáltatás lehetővé teszi a felhasználók számára, hogy kevesebb mint 100 perc alatt feldolgozzák a 100 GB-nál nagyobb fájlokat, amelyek akár 30 millió tranzakciót is tartalmazhatnak. Az egyeztető szolgáltatás az adatfeldolgozás erőgépévé vált, és mára a felhasználók zökkenőmentesen hajthatnak végre különféle műveleteket, mint pl. tengely, JOIN (mint egy Excel VLOOKUP művelet), számtan műveletek, és több, amely sokoldalú és hatékony megoldást kínál hatalmas adatkészletek egyeztetésére. Ez a továbbfejlesztés az elosztott adatfeldolgozási megoldások alkalmazása révén elért skálázhatóságot és sebességet bizonyítja.

Ebben a bejegyzésben elmagyarázzuk, hogyan integráltuk az Amazon EMR-t egy rendkívül elérhető és méretezhető rendszer felépítéséhez, amely lehetővé tette számunkra egy nagy volumenű pénzügyi egyeztetési folyamat futtatását.

Építészet a migráció előtt

Az alábbi ábra szemlélteti korábbi architektúránkat.

Örökös szolgáltatásunk a Amazon Elastic Container Service (Amazon ECS) bekapcsolva AWS Fargate. Az adatokat Python segítségével szekvenciálisan dolgoztuk fel. A párhuzamos feldolgozási képesség hiánya miatt azonban gyakran meg kellett növelnünk a fürt méretét függőlegesen a nagyobb adatkészletek támogatása érdekében. Kontextusban 5 GB adat 50 művelettel történő feldolgozása körülbelül 3 órát vett igénybe. Ez a szolgáltatás úgy lett konfigurálva, hogy vízszintesen méretezhető legyen öt olyan ECS-példányra, amelyek lekérdezték az üzeneteket Amazon Simple Queue Service (Amazon SQS), amely táplálta az átalakítási kéréseket. Mindegyik példány 4 vCPU-val és 30 GB memóriával lett konfigurálva, hogy lehetővé tegye a vízszintes skálázást. A teljesítményt azonban nem tudtuk bővíteni, mert a folyamat szekvenciálisan zajlott, és az adattömböket gyűjtötte Amazon egyszerű tárolási szolgáltatás (Amazon S3) feldolgozásra. Például egy VLOOKUP művelethez, amelyben két fájlt össze kell kapcsolni, mindkét fájlt darabonként be kellett olvasni a memóriában a kimenet eléréséhez. Ez akadályt jelentett a felhasználók számára, mert hosszú ideig kellett várniuk az adatkészleteik feldolgozására.

Újraépítésünk és korszerűsítésünk részeként a következőket szerettük volna elérni:

• Magas rendelkezésre állás – Az adatfeldolgozó klasztereknek magasan elérhetőnek kell lenniük, három 9%-os rendelkezésre állást biztosítva (99.9%)
• áteresztőképesség – A szolgáltatásnak napi 1,500 futtatást kellene kezelnie
• Késleltetés – 100 GB adatot kell 30 percen belül feldolgoznia
• heterogenitás – A fürtnek képesnek kell lennie a munkaterhelések széles skálájának támogatására, néhány MB-tól több száz GB-ig terjedő fájlokkal.
• Egyidejű lekérdezés – A megvalósítás legalább 10 fokos párhuzamosság támogatását igényli
• A feladatok megbízhatósága és az adatok konzisztenciája – A munkáknak megbízhatóan és következetesen kell futniuk, hogy elkerüljék a szolgáltatási szint megállapodások (SLA) megszegését.
• Költséghatékony és skálázható – A terhelés alapján skálázhatónak kell lennie, így költséghatékony
• Biztonság és megfelelés – Tekintettel az adatok érzékenységére, támogatnia kell a részletes hozzáférés-szabályozást és a megfelelő biztonsági megvalósításokat
• megfigyelés – A megoldásnak biztosítania kell a klaszterek és a munkahelyek végpontok közötti felügyeletét

Miért az Amazon EMR

Az Amazon EMR az iparágban vezető felhőalapú big data megoldás a petabájtos méretű adatfeldolgozáshoz, interaktív elemzéshez és gépi tanuláshoz (ML) olyan nyílt forráskódú keretrendszerekkel, mint pl. Apache Spark, Apache Hiveés Gyors. Ezekkel a keretrendszerekkel és a kapcsolódó nyílt forráskódú projektekkel adatokat dolgozhat fel elemzési célokra és BI-munkaterhelésekhez. Az Amazon EMR lehetővé teszi nagy mennyiségű adat átalakítását és áthelyezését más AWS adattárakba és adatbázisokba, például az Amazon S3-ba és azokból. Amazon DynamoDB.

Az Amazon EMR jelentős előnye abban rejlik, hogy hatékonyan használja a párhuzamos feldolgozást a PySparkkal, ami jelentős előrelépést jelent a hagyományos szekvenciális Python kódhoz képest. Ez az innovatív megközelítés leegyszerűsíti az Apache Spark-fürtök telepítését és méretezését, lehetővé téve a nagy adatkészletek hatékony párhuzamosítását. Az elosztott számítási infrastruktúra nemcsak a teljesítményt növeli, hanem hatalmas mennyiségű adat feldolgozását is lehetővé teszi soha nem látott sebességgel. A könyvtárakkal felszerelt PySpark megkönnyíti az Excel-szerű műveleteket DataFrames, és a DataFrames magasabb szintű absztrakciója leegyszerűsíti a bonyolult adatkezeléseket, csökkentve a kód bonyolultságát. Az automatikus fürtkiépítéssel, a dinamikus erőforrás-allokációval és az egyéb AWS-szolgáltatásokkal való integrációval kombinálva az Amazon EMR sokoldalú megoldásnak bizonyult, amely sokféle munkaterheléshez alkalmas, a kötegelt feldolgozástól az ML-ig. A PySparkban és az Amazon EMR-ben rejlő hibatűrés növeli a robusztusságot, még csomóponthiba esetén is, így skálázható, költséghatékony és nagy teljesítményű választás az AWS párhuzamos adatfeldolgozásához.

Az Amazon EMR az alapokon túl bővíti képességeit, és számos telepítési lehetőséget kínál a különféle igények kielégítésére. Akár az Amazon EMR az EC2-n, Amazon EMR az EKS-en, Amazon EMR szerver nélkülivagy Amazon EMR az AWS Outposts-on, akkor egyedi igényekhez igazíthatja megközelítését. Azok számára, akik szerver nélküli környezetet keresnek a Spark-feladatokhoz, az integrációhoz AWS ragasztó is járható lehetőség. A különféle nyílt forráskódú keretrendszerek, köztük a Spark támogatása mellett az Amazon EMR rugalmasságot biztosít a telepítési módok kiválasztásában, Amazon rugalmas számítási felhő (Amazon EC2) példánytípusok, skálázási mechanizmusok és számos költségkímélő optimalizálási technika.

Az Amazon EMR dinamikus erő a felhőben, és páratlan képességeket biztosít a robusztus big data megoldásokat kereső szervezetek számára. Zökkenőmentes integrációja, hatékony funkciói és alkalmazkodóképessége nélkülözhetetlen eszközzé teszik az adatelemzés és az ML bonyolultságában az AWS-en való navigáláshoz.

Újratervezett architektúra

Az alábbi ábra szemlélteti az újratervezett architektúránkat.

A megoldás API-szerződés alapján működik, ahol a kliensek transzformációs konfigurációkat küldhetnek be, meghatározva a műveletek halmazát az S3 adatkészlet helye mellett feldolgozásra. A kérést az Amazon SQS-en keresztül sorba állítják, majd egy Lambda funkción keresztül az Amazon EMR-hez irányítják. Ez a folyamat elindítja egy Amazon EMR lépés létrehozását a Spark keretrendszer megvalósításához egy dedikált EMR-fürtön. Bár az Amazon EMR korlátlan számú lépést tesz lehetővé egy régóta működő fürt élettartama alatt, egyszerre csak 256 lépés futhat vagy függőben van. Az optimális párhuzamosítás érdekében a lépések párhuzamosságát 10-re állítjuk, így 10 lépés párhuzamosan futhat. Kérelemhiba esetén az Amazon SQS holtbetűs sor (DLQ) megtartja az eseményt. A Spark feldolgozza a kérést, és az Excel-szerű műveleteket PySpark-kódba fordítja le a hatékony lekérdezési terv érdekében. A rugalmas DataFrame-ek a bemeneti, kimeneti és közbenső adatokat a memóriában tárolják, optimalizálják a feldolgozási sebességet, csökkentik a lemez I/O költségeit, javítják a terhelési teljesítményt, és a végső kimenetet a megadott Amazon S3 helyre szállítják.

SLA-nkat két dimenzióban határozzuk meg: késleltetés és átviteli sebesség. A késleltetést úgy definiáljuk, mint egy feladat végrehajtásához szükséges időt egy determinisztikus adatkészlet méretéhez képest, valamint az adatkészleten végrehajtott műveletek számát. Az átviteli sebesség az egyidejű jobok maximális száma, amelyet a szolgáltatás egy job késleltetési SLA-jának megsértése nélkül tud végrehajtani. A szolgáltatás általános skálázhatósági SLA-ja a rugalmas számítási erőforrások vízszintes skálázásának és az egyes kiszolgálók függőleges skálázásának egyensúlyától függ.

Mivel napi 1,500 folyamatot kellett lefuttatnunk minimális késleltetéssel és nagy teljesítménnyel, úgy döntöttünk, hogy az Amazon EMR-t EC2 telepítési módba integráljuk, és a felügyelt méretezéssel támogatjuk a változó fájlméretek feldolgozását.

Az EMR-fürt konfigurációja számos különböző lehetőséget kínál:

• EMR csomópontok típusai – Elsődleges, mag- vagy feladatcsomópontok
• Példányvásárlási lehetőségek – Igény szerinti példányok, lefoglalt példányok vagy azonnali példányok
• Konfigurációs beállítások – EMR példányflotta vagy egységes példánycsoport
• Méretezési lehetőségek - Automatikus méretezés vagy Amazon EMR menedzselt skálázás

Változó munkaterhelésünk alapján konfiguráltunk egy EMR-példányflottát (a legjobb gyakorlatokért lásd: Megbízhatóság). Úgy döntöttünk, hogy az Amazon EMR által felügyelt skálázást használjuk a mag- és feladatcsomópontok méretezéséhez (a skálázási forgatókönyveket lásd: Csomópont-kiosztási forgatókönyvek). Végül a memóriaoptimalizálást választottuk AWS Graviton példányok, amelyek akár 30%-kal alacsonyabb költség és akár 15%-kal jobb teljesítmény a Spark-terheléseknél.

A következő kód pillanatképet nyújt a fürt konfigurációjáról:

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

teljesítmény

Az Amazon EMR-re való átállásunkkal olyan rendszerteljesítményt tudtunk elérni, amely képes különféle adatkészletek kezelésére, a 273 B-tól egészen a 88.5 GB-ig terjedő adatkészletekig. p99 491 másodperc (körülbelül 8 perc).

A következő ábra a feldolgozott fájlméretek sokféleségét szemlélteti.

A következő ábra a késleltetésünket mutatja.

A szekvenciális feldolgozással való összehasonlításhoz két, 53 millió rekordot tartalmazó adatkészletet vettünk, és egy VLOOKUP műveletet futtattunk egymás ellen, valamint 49 másik Excel-szerű műveletet. Ennek feldolgozása az új szolgáltatásban 26 percet vett igénybe, szemben a korábbi szolgáltatásban 5 napig. Ez a javulás a teljesítmény tekintetében közel 300-szor nagyobb az előző architektúrához képest.

Szempontok

A megoldás mérlegelésekor tartsa szem előtt a következőket:

• Megfelelő méretű klaszterek – Bár az Amazon EMR átméretezhető, fontos a klaszterek megfelelő mérete. A megfelelő méretezés csökkenti a lassú fürt méretét, ha alulméretezett, vagy a magasabb költségeket, ha a fürt túlméretezett. A problémák előrejelzéséhez kiszámíthatja a munkaterhelésekhez szükséges csomópontok számát és típusát.
• Párhuzamos lépések – A lépések párhuzamos futtatása lehetővé teszi a fejlettebb munkaterhelések futtatását, növeli a fürt erőforrás-kihasználását, és csökkenti a munkaterhelés befejezéséhez szükséges időt. Az egyszerre futtatható lépések száma konfigurálható, és beállítható a fürt indításakor és bármikor a fürt elindítása után. Figyelembe kell vennie és optimalizálnia kell a CPU/memóriahasználatot jobonként, ha több job fut egyetlen megosztott fürtben.
• Munka alapú tranziens EMR klaszterek – Adott esetben ajánlatos munkaalapú tranziens EMR-fürt használata, amely kiváló izolációt biztosít, és ellenőrzi, hogy minden feladat a dedikált környezetben működik-e. Ez a megközelítés optimalizálja az erőforrás-kihasználást, segít megelőzni a feladatok közötti interferenciát, és javítja az általános teljesítményt és megbízhatóságot. Az átmeneti jelleg hatékony skálázást tesz lehetővé, robusztus és elszigetelt megoldást biztosítva a különféle adatfeldolgozási igényekre.
• EMR szerver nélküli – Az EMR Serverless ideális választás, ha nem szeretné kezelni a fürtök kezelését és üzemeltetését. Lehetővé teszi az alkalmazások könnyű futtatását az EMR Serverlessben elérhető nyílt forráskódú keretrendszerek használatával, egyszerű és problémamentes élményt kínálva.
• amazon EMR az EKS-en – Az EKS-en futó Amazon EMR határozott előnyöket kínál, például gyorsabb indítási időt és jobb skálázhatóságot, amely megoldja a számítási kapacitással kapcsolatos kihívásokat – ami különösen előnyös a Graviton és Spot Instance felhasználók számára. A számítási típusok szélesebb körének bevonása növeli a költséghatékonyságot, lehetővé téve a személyre szabott erőforrás-elosztást. Ezenkívül a Multi-AZ támogatás megnövelt elérhetőséget biztosít. Ezek a lenyűgöző szolgáltatások robusztus megoldást kínálnak a nagy adatmennyiségek kezelésére, javított teljesítménnyel, költségoptimalizálással és megbízhatósággal a különféle számítási forgatókönyvekben.

Következtetés

Ebben a bejegyzésben elmagyaráztuk, hogyan optimalizálta az Amazon nagy volumenű pénzügyi egyeztetési folyamatát az Amazon EMR-rel a nagyobb méretezhetőség és teljesítmény érdekében. Ha van egy monolitikus alkalmazása, amely függőleges skálázástól függ további kérések vagy adatkészletek feldolgozásához, akkor az elosztott feldolgozási keretrendszerre, például az Apache Sparkra való migrálása és egy felügyelt szolgáltatás, például az Amazon EMR választása a számításokhoz, csökkentheti a futási időt, és csökkentheti a kézbesítést. SLA, és segíthet csökkenteni a teljes tulajdonlási költséget (TCO).

Mivel ebben a konkrét felhasználási esetben elfogadjuk az Amazon EMR-t, arra biztatjuk, hogy fedezze fel a további lehetőségeket adatinnovációs útja során. Fontolja meg az AWS Glue és más dinamikus Amazon EMR-telepítési lehetőségek, például az EMR Serverless vagy az Amazon EMR on EKS értékelését, hogy megtalálja az Ön egyedi használati esetére szabott legjobb AWS-szolgáltatást. Az adatinnovációs út jövője izgalmas lehetőségeket és fejlesztéseket rejt magában, amelyeket tovább kell vizsgálni.

A szerzőkről

Jeeshan Khetrapal Sr. Software Development Engineer az Amazonnál, ahol felhőalapú számítástechnikai szerver nélküli architektúrákon alapuló fintech termékeket fejleszt, amelyek felelősek a vállalatok általános informatikai ellenőrzéséért, a pénzügyi jelentéskészítésért és az irányításért, a kockázatokért és a megfelelőségért.

Sakti Mishra az AWS vezető megoldások építésze, ahol segít az ügyfeleknek adatarchitektúrájuk korszerűsítésében és a végpontok közötti adatstratégiájuk meghatározásában, beleértve az adatbiztonságot, a hozzáférhetőséget, az irányítást és még sok mást. Ő a könyv szerzője is Egyszerűsítse Big Data Analytics az Amazon EMR segítségével. A munkán kívül Sakti szeret új technológiákat tanulni, filmeket nézni és helyeket látogatni családjával.

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• PlatoData.Network Vertical Generative Ai. Erősítse meg magát. Hozzáférés itt.
• PlatoAiStream. Web3 Intelligence. Felerősített tudás. Hozzáférés itt.
• PlatoESG. Carbon, CleanTech, Energia, Környezet, Nap, Hulladékgazdálkodás. Hozzáférés itt.
• PlatoHealth. Biotechnológiai és klinikai vizsgálatok intelligencia. Hozzáférés itt.
• Forrás: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/