Tilin täsmäytys on tärkeä askel tilinpäätösten täydellisyyden ja oikeellisuuden varmistamiseksi. Erityisesti yritysten on sovittava yhteen tase tilit, jotka voivat sisältää merkittäviä tai olennaisia ​​virheellisyyksiä. Kirjanpitäjät käyvät läpi jokaisen pääkirjanpidon tilin ja varmistavat, että listattu saldo on täydellinen ja tarkka. Kun poikkeavuuksia havaitaan, kirjanpitäjät tutkivat asian ja ryhtyvät tarvittaviin korjaaviin toimenpiteisiin.

Osana Amazonin FinTech-organisaatiota tarjoamme ohjelmistoalustan, jonka avulla Amazonin sisäiset kirjanpitotiimit voivat suorittaa tilien täsmäytyksiä. Täsmäytysprosessin optimoimiseksi nämä käyttäjät tarvitsevat korkean suorituskyvyn muunnoksen, joka mahdollistaa skaalauksen tarpeen mukaan, sekä kyvyn käsitellä vaihtelevia tiedostokokoja, jotka vaihtelevat muutamasta megatavusta yli 100 gigatavuun. Aina ei ole mahdollista sovittaa tietoja yhdelle koneelle tai käsitellä sitä yhdellä ohjelmalla kohtuullisessa ajassa. Tämä laskenta on suoritettava riittävän nopeasti, jotta voidaan tarjota käytännön palveluita, joissa ohjelmointilogiikka ja taustalla olevat yksityiskohdat (tietojen jakelu, vikasietoisuus ja ajoitus) voidaan erottaa toisistaan.

Voimme saavuttaa nämä samanaikaiset laskennat useilla koneilla tai saman toiminnon säikeillä tietojoukon elementtiryhmissä käyttämällä hajautettuja tietojenkäsittelyratkaisuja. Tämä rohkaisi meitä keksimään uudelleen AWS-palveluilla toimivan täsmäytyspalvelumme, mukaan lukien Amazonin EMR ja Apache Spark hajautettu käsittelykehys, joka käyttää PySpark. Tämän palvelun avulla käyttäjät voivat käsitellä yli 100 Gt:n tiedostoja, jotka sisältävät jopa 100 miljoonaa tapahtumaa alle 30 minuutissa. Täsmäytyspalvelusta on tullut tiedonkäsittelyn voimavara, ja nyt käyttäjät voivat suorittaa saumattomasti erilaisia ​​toimintoja, kuten esim. Tappi, LIITY (kuten Excelin VLOOKUP-toiminto), aritmeettinen operaatiot ja lisää, joka tarjoaa monipuolisen ja tehokkaan ratkaisun laajojen tietojoukkojen täsmäyttämiseen. Tämä parannus on osoitus hajautettujen tietojenkäsittelyratkaisujen skaalautumisesta ja nopeudesta.

Tässä viestissä selitämme, kuinka integroimme Amazon EMR:n rakentaaksemme erittäin saatavilla olevan ja skaalautuvan järjestelmän, jonka avulla pystyimme suorittamaan suuria määriä taloudellista sovitteluprosessia.

Arkkitehtuuri ennen muuttoa

Seuraava kaavio havainnollistaa aikaisempaa arkkitehtuuriamme.

Vanha palvelumme on rakennettu Amazonin elastisten säiliöiden palvelu (Amazon ECS) päällä AWS-veljeskunta. Käsittelimme tiedot peräkkäin Pythonilla. Rinnakkaisen käsittelykapasiteetin puutteen vuoksi jouduimme kuitenkin usein kasvattamaan klusterin kokoa pystysuunnassa tukeaksemme suurempia tietojoukkoja. Kontekstin vuoksi 5 Gt:n datan ja 50 toiminnon käsittely kesti noin 3 tuntia. Tämä palvelu on määritetty skaalautumaan vaakasuunnassa viiteen ECS-instanssiin, jotka poisivat viestejä Amazonin yksinkertainen jonopalvelu (Amazon SQS), joka syötti muunnospyynnöt. Jokaiseen esiintymään konfiguroitiin 4 vCPU:ta ja 30 Gt muistia vaakasuuntaisen skaalauksen mahdollistamiseksi. Emme kuitenkaan voineet laajentaa sen suorituskyvyn kapasiteettia, koska prosessi tapahtui peräkkäin ja keräsi datapaloja Amazonin yksinkertainen tallennuspalvelu (Amazon S3) käsittelyyn. Esimerkiksi VLOOKUP-toiminto, jossa kaksi tiedostoa yhdistetään, edellytti molempien tiedostojen lukemista muistissa kappaleittain tulosteen saamiseksi. Tästä tuli esteenä käyttäjille, koska he joutuivat odottamaan pitkiä aikoja tietojensa käsittelyä.

Osana uudelleenarkkitehtuuriamme ja modernisointiamme halusimme saavuttaa seuraavat:

• Korkea saatavuus – Tietojenkäsittelyklusterien tulee olla erittäin saatavilla ja tarjota kolme 9s käytettävyyttä (99.9 %)
• suoritusteho – Palvelun tulisi hoitaa 1,500 ajoa päivässä
• Viive – Sen pitäisi pystyä käsittelemään 100 Gt dataa 30 minuutissa
• Heterogeenisuus – Klusterin pitäisi pystyä tukemaan monenlaisia ​​työkuormia, joiden tiedostot vaihtelevat muutamasta megatavusta satoihin gigatavuihin
• Kyselyn samanaikaisuus – Toteutus vaatii kykyä tukea vähintään 10 astetta samanaikaisuutta
• Töiden luotettavuus ja tietojen johdonmukaisuus – Työt on suoritettava luotettavasti ja johdonmukaisesti, jotta vältytään palvelutasosopimusten (SLA) rikkomisesta.
• Kustannustehokas ja skaalautuva – Sen on oltava työmäärän mukaan skaalautuva, mikä tekee siitä kustannustehokasta
• Turvallisuus ja vaatimustenmukaisuus – Tietojen herkkyys huomioon ottaen sen on tuettava tarkkaa kulunhallintaa ja asianmukaisia ​​suojaustoteutuksia
• Seuranta – Ratkaisun on tarjottava klustereiden ja työpaikkojen seurantaa päästä päähän

Miksi Amazon EMR

Amazon EMR on alan johtava pilvibig data -ratkaisu petatavun mittakaavan tiedonkäsittelyyn, interaktiiviseen analytiikkaan ja koneoppimiseen (ML) käyttämällä avoimen lähdekoodin kehyksiä, kuten esim. Apache Spark, Apache Hiveja Presto. Näiden viitekehysten ja niihin liittyvien avoimen lähdekoodin projektien avulla voit käsitellä tietoja analytiikkatarkoituksiin ja BI-työkuormiin. Amazon EMR:n avulla voit muuntaa ja siirtää suuria tietomääriä muihin AWS-tietovarastoihin ja -tietokantoihin, kuten Amazon S3 ja Amazon DynamoDB.

Amazon EMR:n merkittävä etu on sen tehokas rinnakkaiskäsittelyn käyttö PySparkin kanssa, mikä merkitsee merkittävää parannusta perinteiseen peräkkäiseen Python-koodiin verrattuna. Tämä innovatiivinen lähestymistapa virtaviivaistaa Apache Spark -klusterien käyttöönottoa ja skaalausta, mikä mahdollistaa tehokkaan rinnakkaisuuden suurissa tietojoukoissa. Hajautettu laskentainfrastruktuuri ei vain lisää suorituskykyä, vaan mahdollistaa myös valtavien tietomäärien käsittelyn ennennäkemättömällä nopeudella. Kirjastoilla varustettu PySpark mahdollistaa Excelin kaltaisen toiminnan DataFrames, ja DataFrame-kehysten korkeamman tason abstraktio yksinkertaistaa monimutkaista tietojen käsittelyä ja vähentää koodin monimutkaisuutta. Yhdessä automaattisen klusterin provisioinnin, dynaamisen resurssien allokoinnin ja muiden AWS-palvelujen kanssa integroinnin kanssa Amazon EMR osoittautuu monipuoliseksi ratkaisuksi, joka soveltuu erilaisiin työkuormiin, eräkäsittelystä ML:ään. PySparkin ja Amazon EMR:n luontainen vikasietoisuus edistää kestävyyttä jopa solmuvikojen sattuessa, mikä tekee siitä skaalautuvan, kustannustehokkaan ja tehokkaan valinnan rinnakkaiseen tietojenkäsittelyyn AWS:ssä.

Amazon EMR laajentaa kykyjään perusasioiden lisäksi tarjoamalla erilaisia ​​käyttöönottovaihtoehtoja erilaisiin tarpeisiin. Onko se Amazon EMR EC2:ssa, Amazon EMR EKS:ssä, Amazon EMR-palvelimetontai Amazon EMR AWS Outpostsissa, voit räätälöidä lähestymistapasi tiettyjen vaatimusten mukaan. Niille, jotka etsivät palvelimetonta ympäristöä Spark-töitä varten, integrointi AWS-liima on myös varteenotettava vaihtoehto. Sen lisäksi, että Amazon EMR tukee useita avoimen lähdekoodin kehyksiä, mukaan lukien Spark, se tarjoaa joustavuutta käyttöönottotilojen valinnassa, Amazonin elastinen laskentapilvi (Amazon EC2) ilmentymätyypit, skaalausmekanismit ja lukuisat kustannuksia säästävät optimointitekniikat.

Amazon EMR on pilven dynaaminen voima, joka tarjoaa vertaansa vailla olevia ominaisuuksia organisaatioille, jotka etsivät kestäviä big data -ratkaisuja. Sen saumaton integrointi, tehokkaat ominaisuudet ja mukautuvuus tekevät siitä välttämättömän työkalun data-analytiikan ja ML:n monimutkaisten navigointiin AWS:ssä.

Uudelleen suunniteltu arkkitehtuuri

Seuraava kaavio havainnollistaa uudelleen suunniteltua arkkitehtuuriamme.

Ratkaisu toimii API-sopimuksella, jossa asiakkaat voivat lähettää muunnoskonfiguraatioita, jotka määrittelevät operaatiot S3-tietojoukon sijainnin rinnalla prosessoitavaksi. Pyyntö asetetaan jonoon Amazon SQS:n kautta ja ohjataan sitten Amazon EMR:ään Lambda-toiminnon kautta. Tämä prosessi käynnistää Amazon EMR -vaiheen luomisen Spark-kehyksen toteuttamista varten erillisessä EMR-klusterissa. Vaikka Amazon EMR mahdollistaa rajoittamattoman määrän vaiheita pitkän klusterin käyttöiän aikana, vain 256 vaihetta voi olla käynnissä tai vireillä samanaikaisesti. Optimaalista rinnakkaisuutta varten vaiheiden samanaikaisuus on asetettu arvoon 10, jolloin 10 vaihetta voidaan suorittaa samanaikaisesti. Jos pyyntö epäonnistuu, Amazon SQS kuolleiden kirjeiden jono (DLQ) säilyttää tapahtuman. Spark käsittelee pyynnön ja kääntää Excelin kaltaiset toiminnot PySpark-koodiksi tehokkaan kyselysuunnitelman saavuttamiseksi. Kimmoisat DataFrame-kehykset tallentavat syöte-, lähtö- ja välitiedot muistiin, optimoiden käsittelynopeuden, vähentävät levyn I/O-kustannuksia, parantavat työkuorman suorituskykyä ja toimittavat lopullisen lähdön määritettyyn Amazon S3 -sijaintiin.

Määrittelemme SLA:mme kahdessa ulottuvuudessa: latenssissa ja suorituskyvyssä. Latenssi määritellään ajanjaksoksi, joka kuluu yhden työn suorittamiseen deterministisen tietojoukon koon ja tietojoukolle suoritettujen toimintojen lukumäärän perusteella. Suorituskyky määritellään samanaikaisten töiden enimmäismääräksi, jonka palvelu voi suorittaa rikkomatta yhden työn latenssipalvelusopimusta. Palvelun yleinen skaalautuvuus SLA riippuu elastisten laskentaresurssien vaakaskaalauksen ja yksittäisten palvelimien vertikaalisen skaalauksen tasapainosta.

Koska meidän täytyi ajaa 1,500 2 prosessia päivässä minimaalisella viiveellä ja korkealla suorituskyvyllä, päätimme integroida Amazon EMR:n ECXNUMX-käyttöönottotilaan, jossa hallittu skaalaus on käytössä muuttuvien tiedostokokojen käsittelyn tukemiseksi.

EMR-klusterin kokoonpano tarjoaa monia erilaisia ​​valintoja:

• EMR-solmutyypit – Ensisijaiset, ydin- tai tehtäväsolmut
• Esimerkki ostovaihtoehdot – On-demand-esiintymät, varatut ilmentymät tai spot-instanssit
• Määritysvaihtoehdot – EMR-instanssikalusto tai yhtenäinen ilmentymäryhmä
• Skaalausvaihtoehdot - Automaattinen skaalaus tai Amazon EMR -hallittu skaalaus

Muuttuvan työmäärämme perusteella määritimme EMR-instanssikaluston (katso parhaat käytännöt, katso Luotettavuus). Päätimme myös käyttää Amazon EMR:n hallittua skaalausta ydin- ja tehtäväsolmujen skaalaamiseen (katso skaalausskenaariot Solmun allokointiskenaariot). Lopuksi valitsimme muistioptimoidun AWS Graviton tapauksia, jotka tarjoavat jopa 30 % pienemmät kustannukset ja jopa 15 % parempi suorituskyky Spark-työkuormilla.

Seuraava koodi tarjoaa tilannekuvan klusterikokoonpanostamme:

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

Suorituskyky

Siirtyessämme Amazon EMR:ään pystyimme saavuttamaan järjestelmän suorituskyvyn, joka pystyy käsittelemään erilaisia ​​tietojoukkoja, aina 273 B:stä jopa 88.5 Gt:iin. p99 491 sekuntia (noin 8 minuuttia).

Seuraava kuva havainnollistaa käsiteltyjen tiedostojen kokoja.

Seuraava kuva näyttää latenssimme.

Vertataksemme peräkkäistä käsittelyä otimme kaksi tietojoukkoa, jotka sisälsivät 53 miljoonaa tietuetta, ja suoritimme VLOOKUP-operaation toisiaan vastaan ​​sekä 49 muuta Excelin kaltaista toimintoa. Tämän käsittely kesti uudessa palvelussa 26 minuuttia verrattuna 5 päivään vanhan palvelun käsittelyyn. Tämä suorituskyvyn parannus on lähes 300 kertaa suurempi kuin edellisessä arkkitehtuurissa.

Huomioita

Muista seuraavat seikat, kun harkitset tätä ratkaisua:

• Oikean kokoiset klusterit – Vaikka Amazon EMR:n kokoa voi muuttaa, on tärkeää, että klusterit on mitoitettu oikeaan kokoon. Oikea koko vähentää hidasta klusteria, jos se on alikokoinen, tai korkeampia kustannuksia, jos klusteri on ylisuuri. Ennakoidaksesi nämä ongelmat, voit laskea työkuormiin tarvittavien solmujen määrän ja tyypin.
• Rinnakkaiset askeleet – Askeleiden suorittaminen rinnakkain mahdollistaa edistyneempien työkuormien suorittamisen, lisää klusterin resurssien käyttöä ja vähentää työkuorman suorittamiseen kuluvaa aikaa. Kerralla suoritettavien vaiheiden määrä on konfiguroitavissa ja voidaan asettaa klusterin käynnistyessä ja milloin tahansa klusterin käynnistymisen jälkeen. Sinun on harkittava ja optimoitava suorittimen/muistin käyttö työkohtaisesti, kun useita töitä on käynnissä yhdessä jaetussa klusterissa.
• Työpohjaiset ohimenevät EMR-klusterit – Jos mahdollista, on suositeltavaa käyttää työhön perustuvaa ohimenevää EMR-klusteria, joka tarjoaa erinomaisen eristyksen ja varmistaa, että jokainen tehtävä toimii sille tarkoitetussa ympäristössä. Tämä lähestymistapa optimoi resurssien käytön, auttaa estämään häiriöitä töiden välillä ja parantaa yleistä suorituskykyä ja luotettavuutta. Ohimenevä luonne mahdollistaa tehokkaan skaalauksen ja tarjoaa vankan ja erillisen ratkaisun erilaisiin tietojenkäsittelytarpeisiin.
• EMR-palvelimeton – EMR Serverless on ihanteellinen valinta, jos et halua hoitaa klusterien hallintaa ja toimintaa. Sen avulla voit vaivattomasti ajaa sovelluksia käyttämällä avoimen lähdekoodin kehyksiä, jotka ovat saatavilla EMR Serverlessissä, mikä tarjoaa suoraviivaisen ja vaivattoman kokemuksen.
• Amazon EMR EKS:ssä – EKS:n Amazon EMR tarjoaa selkeitä etuja, kuten nopeammat käynnistysajat ja parannetun skaalautuvuuden, mikä ratkaisee laskentakapasiteetin haasteita – mikä on erityisen hyödyllistä Graviton- ja Spot Instance -käyttäjille. Laajemman valikoiman laskentatyyppejä lisääminen parantaa kustannustehokkuutta, mikä mahdollistaa räätälöidyn resurssien allokoinnin. Lisäksi Multi-AZ-tuki lisää käytettävyyttä. Nämä houkuttelevat ominaisuudet tarjoavat vankan ratkaisun suurten datakuormien hallintaan parantamalla suorituskykyä, kustannusten optimointia ja luotettavuutta erilaisissa laskentaskenaarioissa.

Yhteenveto

Tässä viestissä selitimme, kuinka Amazon optimoi suuren volyymin taloudellisen täsmäytysprosessinsa Amazon EMR:n kanssa parantaakseen skaalautuvuutta ja suorituskykyä. Jos sinulla on monoliittinen sovellus, joka on riippuvainen vertikaalisesta skaalauksesta lisäpyyntöjen tai tietojoukkojen käsittelyssä, sen siirtäminen hajautettuun käsittelykehykseen, kuten Apache Spark, ja hallitun palvelun, kuten Amazon EMR:n, valitseminen laskemiseen voi auttaa lyhentämään toimitusaikaa. Palvelutasosopimus, ja se voi myös auttaa vähentämään kokonaiskustannuksia (TCO).

Koska omaksumme Amazon EMR:n tässä erityisessä käyttötapauksessa, kehotamme sinua tutkimaan muita mahdollisuuksia datainnovaatiomatkallasi. Harkitse AWS Gluen ja muiden dynaamisten Amazon EMR -käyttöönottovaihtoehtojen, kuten EMR Serverless tai Amazon EMR EKS:n, arvioimista löytääksesi parhaan AWS-palvelun, joka on räätälöity ainutlaatuiseen käyttötapauksiisi. Datainnovaatiomatkan tulevaisuus sisältää jännittäviä mahdollisuuksia ja edistysaskeleita, joita on tutkittava edelleen.

Tietoja Tekijät

Jeeshan Khetrapal on vanhempi ohjelmistokehitysinsinööri Amazonilla, jossa hän kehittää fintech-tuotteita, jotka perustuvat pilvipalveluiden palvelimettomiin arkkitehtuureihin, jotka vastaavat yritysten IT-yleisohjauksista, taloudellisesta raportoinnista ja hallinnasta hallinnon, riskien ja vaatimustenmukaisuuden osalta.

Sakti Mishra on AWS:n pääratkaisuarkkitehti, jossa hän auttaa asiakkaita modernisoimaan tietoarkkitehtuuriaan ja määrittelemään kokonaisvaltaisen datastrategiansa, mukaan lukien tietoturva, saavutettavuus, hallinto ja paljon muuta. Hän on myös kirjan kirjoittaja Yksinkertaista Big Data Analytics Amazon EMR:llä. Työn ulkopuolella Sakti nauttii uusien teknologioiden opiskelusta, elokuvien katselusta ja vierailusta perheen kanssa.

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• PlatoData.Network Vertical Generatiivinen Ai. Vahvista itseäsi. Pääsy tästä.
• PlatoAiStream. Web3 Intelligence. Tietoa laajennettu. Pääsy tästä.
• PlatoESG. hiili, CleanTech, energia, ympäristö, Aurinko, Jätehuolto. Pääsy tästä.
• PlatonHealth. Biotekniikan ja kliinisten kokeiden älykkyys. Pääsy tästä.
• Lähde: https://aws.amazon.com/blogs/big-data/how-amazon-optimized-its-high-volume-financial-reconciliation-process-with-amazon-emr-for-higher-scalability-and-performance/