Uskladitev računov je pomemben korak za zagotovitev popolnosti in točnosti računovodskih izkazov. Natančneje, podjetja se morajo uskladiti bilanco stanja računov, ki bi lahko vsebovali pomembne ali pomembne napačne navedbe. Računovodje pregledajo vsak račun v glavni knjigi računov in preverijo, ali je navedeno stanje popolno in pravilno. Ko se odkrijejo neskladja, računovodje raziščejo in sprejmejo ustrezne korektivne ukrepe.

Kot del Amazonove organizacije FinTech ponujamo programsko platformo, ki notranjim računovodskim ekipam v Amazonu omogoča izvajanje usklajevanja računov. Za optimizacijo postopka usklajevanja ti uporabniki potrebujejo visoko zmogljivo transformacijo z možnostjo prilagajanja na zahtevo, pa tudi zmožnostjo obdelave spremenljivih velikosti datotek, ki segajo od nekaj MB do več kot 100 GB. Podatkov ni vedno mogoče namestiti na en stroj ali jih obdelati z enim samim programom v razumnem časovnem okviru. Ta izračun mora biti opravljen dovolj hitro, da se zagotovijo praktične storitve, pri katerih je mogoče ločiti logiko programiranja in osnovne podrobnosti (razporeditev podatkov, odpornost na napake in razporejanje).

Te hkratne izračune lahko dosežemo na več strojih ali nitih iste funkcije v skupinah elementov nabora podatkov z uporabo porazdeljenih rešitev za obdelavo podatkov. To nas je spodbudilo, da smo ponovno izumili našo storitev usklajevanja, ki jo poganjajo storitve AWS, vključno z Amazonski EMR in Apache Spark ogrodje porazdeljene obdelave, ki uporablja PySpark. Ta storitev uporabnikom omogoča obdelavo datotek nad 100 GB, ki vsebujejo do 100 milijonov transakcij v manj kot 30 minutah. Storitev usklajevanja je postala elektrarna za obdelavo podatkov in zdaj lahko uporabniki nemoteno izvajajo različne operacije, kot je npr. pivot, PRIDRUŽITE (kot operacija Excel VLOOKUP), aritmetika operacije, in več, ki zagotavlja vsestransko in učinkovito rešitev za usklajevanje velikih naborov podatkov. Ta izboljšava je dokaz razširljivosti in hitrosti, doseženi s sprejetjem porazdeljenih rešitev za obdelavo podatkov.

V tej objavi pojasnjujemo, kako smo integrirali Amazon EMR, da bi zgradili zelo razpoložljiv in razširljiv sistem, ki nam je omogočil izvajanje obsežnega postopka finančne uskladitve.

Arhitektura pred selitvijo

Naslednji diagram ponazarja našo prejšnjo arhitekturo.

Naša stara storitev je bila zgrajena z Amazonska storitev za kontejnerje z elastiko (Amazon ECS) vklopljen AWS Fargate. Podatke smo obdelali zaporedno z uporabo Pythona. Vendar pa smo morali zaradi pomanjkanja zmožnosti vzporedne obdelave pogosto povečati velikost gruče navpično, da bi podprli večje nabore podatkov. Za kontekst je obdelava 5 GB podatkov s 50 operacijami trajala približno 3 ure. Ta storitev je bila konfigurirana za vodoravno skaliranje na pet primerkov ECS, ki so anketirali sporočila Storitev Amazon Simple Queue Service (Amazon SQS), ki je hranil zahteve za preoblikovanje. Vsaka instanca je bila konfigurirana s 4 vCPU-ji in 30 GB pomnilnika, da se omogoči vodoravno skaliranje. Vendar njegove zmogljivosti nismo mogli povečati glede zmogljivosti, ker se je postopek odvijal zaporedno in je izbiral dele podatkov iz Preprosta storitev shranjevanja Amazon (Amazon S3) za obdelavo. Na primer, operacija VLOOKUP, kjer je treba združiti dve datoteki, je zahtevala, da se obe datoteki prebereta v pomnilniku del za delom, da se pridobi izhod. To je postalo ovira za uporabnike, saj so morali dolgo čakati na obdelavo svojih podatkovnih nizov.

V okviru naše prenove in modernizacije smo želeli doseči naslednje:

• Visoka razpoložljivost – Grozdi za obdelavo podatkov morajo biti visoko razpoložljivi, kar zagotavlja tri 9-ke razpoložljivosti (99.9 %).
• Pretočnost – Storitev naj bi opravila 1,500 voženj na dan
• Latenca – Zmožen naj bi bil obdelati 100 GB podatkov v 30 minutah
• Heterogenost – Grozd bi moral podpirati široko paleto delovnih obremenitev z datotekami, velikimi od nekaj MB do več sto GB
• Sočasnost poizvedbe – Implementacija zahteva sposobnost podpore najmanj 10 stopenj sočasnosti
• Zanesljivost delovnih mest in konsistentnost podatkov – Dela morajo delovati zanesljivo in dosledno, da se izognete kršitvam sporazumov o ravni storitev (SLA)
• Stroškovno učinkovit in prilagodljiv – Biti mora razširljiv glede na delovno obremenitev, zaradi česar je stroškovno učinkovit
• Varnost in skladnost – Glede na občutljivost podatkov mora podpirati natančen nadzor dostopa in ustrezne varnostne izvedbe
• Spremljanje – Rešitev mora nuditi celovito spremljanje grozdov in opravil

Zakaj Amazon EMR

Amazon EMR je vodilna rešitev za velike podatke v oblaku za obdelavo petabajtnih podatkov, interaktivno analitiko in strojno učenje (ML) z uporabo odprtokodnih okvirov, kot je npr. Apache Spark, Apache panjin Presto. S temi okviri in povezanimi odprtokodnimi projekti lahko obdelujete podatke za analitične namene in delovne obremenitve poslovne inteligence. Amazon EMR vam omogoča preoblikovanje in premikanje velikih količin podatkov v in iz drugih podatkovnih shramb in baz podatkov AWS, kot sta Amazon S3 in Amazon DynamoDB.

Pomembna prednost Amazon EMR je njegova učinkovita uporaba vzporedne obdelave s PySparkom, kar pomeni znatno izboljšanje v primerjavi s tradicionalno zaporedno kodo Python. Ta inovativni pristop poenostavlja uvajanje in skaliranje gruč Apache Spark, kar omogoča učinkovito paralelizacijo velikih naborov podatkov. Porazdeljena računalniška infrastruktura ne le izboljša zmogljivost, temveč omogoča tudi obdelavo ogromnih količin podatkov pri hitrostih brez primere. PySpark, opremljen s knjižnicami, olajša operacije, podobne Excelu Podatkovni okvirji, visokonivojska abstrakcija DataFrames pa poenostavlja zapletene manipulacije podatkov in zmanjšuje kompleksnost kode. V kombinaciji s samodejnim zagotavljanjem gruče, dinamičnim dodeljevanjem virov in integracijo z drugimi storitvami AWS se Amazon EMR izkaže za vsestransko rešitev, primerno za različne delovne obremenitve, od paketne obdelave do ML. Vgrajena toleranca napak v PySpark in Amazon EMR spodbuja robustnost tudi v primeru okvar vozlišč, zaradi česar je razširljiva, stroškovno učinkovita in visoko zmogljiva izbira za vzporedno obdelavo podatkov na AWS.

Amazon EMR razširja svoje zmožnosti onkraj osnov in ponuja različne možnosti uvajanja za različne potrebe. Ali je Amazon EMR na EC2, Amazon EMR na EKS, Amazon EMR brez strežnikaali Amazon EMR na AWS Outposts, lahko svoj pristop prilagodite posebnim zahtevam. Za tiste, ki iščejo okolje brez strežnikov za delovna mesta Spark, integracija AWS lepilo je tudi izvedljiva možnost. Poleg podpore različnim odprtokodnim okvirom, vključno s Sparkom, Amazon EMR zagotavlja prilagodljivost pri izbiri načinov uvajanja, Amazonski elastični računalniški oblak (Amazon EC2) vrste instanc, mehanizmi skaliranja in številne tehnike optimizacije, ki prihranijo stroške.

Amazon EMR je dinamična sila v oblaku, ki zagotavlja neprimerljive zmogljivosti za organizacije, ki iščejo robustne rešitve za velike količine podatkov. Zaradi brezhibne integracije, zmogljivih funkcij in prilagodljivosti je nepogrešljivo orodje za krmarjenje po kompleksnosti podatkovne analitike in strojnega učenja na AWS.

Prenovljena arhitektura

Naslednji diagram ponazarja našo prenovljeno arhitekturo.

Rešitev deluje v skladu s pogodbo API, kjer lahko odjemalci predložijo transformacijske konfiguracije, ki definirajo nabor operacij poleg lokacije nabora podatkov S3 za obdelavo. Zahteva se postavi v čakalno vrsto prek Amazon SQS, nato pa se prek funkcije Lambda usmeri v Amazon EMR. Ta postopek sproži ustvarjanje koraka Amazon EMR za implementacijo ogrodja Spark v namenski gruči EMR. Čeprav Amazon EMR omogoča neomejeno število korakov v dolgotrajni življenjski dobi gruče, se lahko hkrati izvaja ali čaka le 256 korakov. Za optimalno paralelizacijo je sočasnost korakov nastavljena na 10, kar omogoča hkratno izvajanje 10 korakov. V primeru neuspešne zahteve Amazon SQS vrsta mrtvih pisem (DLQ) obdrži dogodek. Spark obdela zahtevo in prevede operacije, podobne Excelu, v kodo PySpark za učinkovit načrt poizvedbe. Odporni DataFrames shranjujejo vhodne, izhodne in vmesne podatke v pomnilniku, optimizirajo hitrost obdelave, zmanjšajo stroške V/I diska, izboljšajo zmogljivost delovne obremenitve in dostavijo končni izhod na določeno lokacijo Amazon S3.

SLA definiramo v dveh dimenzijah: zakasnitev in prepustnost. Zakasnitev je opredeljena kot čas, potreben za izvedbo enega opravila glede na deterministično velikost nabora podatkov in število operacij, izvedenih na naboru podatkov. Prepustnost je opredeljena kot največje število sočasnih opravil, ki jih lahko storitev izvede, ne da bi pri tem kršila zakasnitev SLA enega opravila. Celotna razširljivost SLA storitve je odvisna od ravnovesja horizontalnega skaliranja elastičnih računalniških virov in vertikalnega skaliranja posameznih strežnikov.

Ker smo morali izvajati 1,500 procesov na dan z minimalno zakasnitvijo in visoko zmogljivostjo, smo se odločili integrirati Amazon EMR v način uvajanja EC2 z omogočenim upravljanim skaliranjem za podporo obdelave spremenljivih velikosti datotek.

Konfiguracija gruče EMR omogoča veliko različnih izbir:

• Vrste vozlišč EMR – Primarna, jedrna ali opravilna vozlišča
• Možnosti nakupa primerkov – Primerki na zahtevo, rezervirani primerki ali promptni primerki
• Možnosti konfiguracije – Flota primerkov EMR ali enotna skupina primerkov
• Možnosti skaliranja - Samodejno skaliranje ali upravljano skaliranje Amazon EMR

Na podlagi naše spremenljive delovne obremenitve smo konfigurirali floto primerkov EMR (za najboljše prakse glejte Zanesljivost). Odločili smo se tudi, da uporabimo skaliranje, ki ga upravlja Amazon EMR, za skaliranje vozlišč jedra in opravil (za scenarije skaliranja glejte Scenariji dodeljevanja vozlišč). Nazadnje smo izbrali pomnilniško optimizirano AWS Graviton primerki, ki zagotavljajo do 30 % nižji stroški in do 15 % izboljšana zmogljivost za delovne obremenitve Spark.

Naslednja koda ponuja posnetek naše konfiguracije gruče:

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

Uspešnost

Z našo migracijo na Amazon EMR smo lahko dosegli sistemsko zmogljivost, ki je zmožna obravnavati različne nabore podatkov, od samo 273 B do 88.5 GB z p99 491 sekund (približno 8 minut).

Naslednja slika prikazuje različne velikosti obdelanih datotek.

Naslednja slika prikazuje našo zakasnitev.

Za primerjavo z zaporedno obdelavo smo vzeli dva nabora podatkov, ki vsebujeta 53 milijonov zapisov, in drug proti drugemu zagnali operacijo VLOOKUP, skupaj z 49 drugimi operacijami, podobnimi Excelu. To je v novi storitvi trajalo 26 minut za obdelavo v primerjavi s 5 dnevi za obdelavo v stari storitvi. Ta izboljšava je skoraj 300-krat večja od prejšnje arhitekture v smislu zmogljivosti.

Premisleki

Ko razmišljate o tej rešitvi, upoštevajte naslednje:

• Grozdi prave velikosti – Čeprav je Amazon EMR mogoče spremeniti velikost, je pomembno, da izberete pravo velikost gruče. Pravilna velikost zmanjša počasno gručo, če je premajhna, ali višje stroške, če je gruča prevelika. Če želite predvideti te težave, lahko izračunate število in vrsto vozlišč, ki bodo potrebna za delovne obremenitve.
• Vzporedni koraki – Vzporedno izvajanje korakov vam omogoča izvajanje naprednejših delovnih obremenitev, povečanje izkoriščenosti virov gruče in zmanjšanje količine časa, ki je potreben za dokončanje delovne obremenitve. Število korakov, dovoljenih za izvajanje naenkrat, je nastavljivo in ga je mogoče nastaviti ob zagonu gruče in kadar koli po zagonu gruče. Če se v eni gruči v skupni rabi izvaja več opravil, morate upoštevati in optimizirati porabo procesorja/pomnilnika na opravilo.
• Prehodni EMR grozdi na podlagi delovnih mest – Če je primerno, je priporočljiva uporaba prehodne gruče EMR na podlagi opravila, ki zagotavlja vrhunsko izolacijo in preverja, ali vsaka naloga deluje v svojem namenskem okolju. Ta pristop optimizira uporabo virov, pomaga preprečevati motnje med opravili in izboljša splošno zmogljivost in zanesljivost. Prehodna narava omogoča učinkovito skaliranje ter zagotavlja robustno in izolirano rešitev za različne potrebe obdelave podatkov.
• EMR brez strežnika – EMR Serverless je idealna izbira, če se ne želite ukvarjati z upravljanjem in delovanjem gruč. Omogoča vam enostavno zagon aplikacij z uporabo odprtokodnih ogrodij, ki so na voljo znotraj EMR Serverless, in ponuja preprosto izkušnjo brez težav.
• Amazon EMR na EKS – Amazon EMR na EKS ponuja izrazite prednosti, kot so hitrejši zagonski časi in izboljšana razširljivost, ki rešuje izzive računalniške zmogljivosti – kar je še posebej koristno za uporabnike Gravitona in Spot Instance. Vključitev širšega nabora vrst računalništva povečuje stroškovno učinkovitost in omogoča prilagojeno dodeljevanje virov. Poleg tega podpora Multi-AZ zagotavlja večjo razpoložljivost. Te prepričljive funkcije zagotavljajo robustno rešitev za upravljanje velikih podatkovnih delovnih obremenitev z izboljšano zmogljivostjo, optimizacijo stroškov in zanesljivostjo v različnih računalniških scenarijih.

zaključek

V tej objavi smo razložili, kako je Amazon optimiziral svoj proces finančnega usklajevanja velikih količin z Amazon EMR za večjo razširljivost in zmogljivost. Če imate monolitno aplikacijo, ki je odvisna od navpičnega skaliranja za obdelavo dodatnih zahtev ali naborov podatkov, potem lahko njena selitev v ogrodje porazdeljene obdelave, kot je Apache Spark, in izbira upravljane storitve, kot je Amazon EMR za računanje, pomaga skrajšati čas izvajanja in zmanjšati vašo dostavo SLA in lahko tudi pomaga zmanjšati skupne stroške lastništva (TCO).

Ker sprejemamo Amazon EMR za ta poseben primer uporabe, vas spodbujamo, da raziščete nadaljnje možnosti na vaši poti inovacij podatkov. Razmislite o oceni AWS Glue skupaj z drugimi dinamičnimi možnostmi uvedbe Amazon EMR, kot sta EMR Serverless ali Amazon EMR na EKS, da odkrijete najboljšo storitev AWS, prilagojeno vašemu edinstvenemu primeru uporabe. Prihodnost potovanja podatkovnih inovacij ponuja vznemirljive možnosti in napredke, ki jih je treba še raziskati.

O avtorjih

Jeeshan Khetrapal je višji inženir za razvoj programske opreme pri Amazonu, kjer razvija fintech produkte, ki temeljijo na brezstrežniških arhitekturah računalništva v oblaku, ki so odgovorni za splošne IT kontrole podjetij, finančno poročanje in nadzor nad upravljanjem, tveganjem in skladnostjo.

Šakti Mišra je glavni arhitekt rešitev pri AWS, kjer strankam pomaga posodobiti njihovo podatkovno arhitekturo in opredeliti njihovo strategijo podatkov od konca do konca, vključno z varnostjo podatkov, dostopnostjo, upravljanjem in še več. Je tudi avtor knjige Poenostavite analizo velikih podatkov z Amazon EMR. Zunaj dela Sakti uživa v učenju novih tehnologij, gledanju filmov in obiskovanju krajev z družino.

• Distribucija vsebine in PR s pomočjo SEO. Okrepite se še danes.
• PlatoData.Network Vertical Generative Ai. Opolnomočite se. Dostopite tukaj.
• PlatoAiStream. Web3 Intelligence. Razširjeno znanje. Dostopite tukaj.
• PlatoESG. Ogljik, CleanTech, Energija, Okolje, sončna energija, Ravnanje z odpadki. Dostopite tukaj.
• PlatoHealth. Obveščanje o biotehnologiji in kliničnih preskušanjih. Dostopite tukaj.
• vir: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/