Dit is een gastpost van Diego Benavides en Luis Bendezú, Senior Data Architects, Data Architecture Direction bij Belcorp.

Belcorp is een van de belangrijkste bedrijven voor verpakte consumentengoederen (CPG) die al meer dan 50 jaar cosmeticaproducten in de regio leveren, verdeeld over ongeveer 13 landen in Noord-, Midden- en Zuid-Amerika (AMER). Belcorp, geboren in Peru en met een eigen productfabriek in Colombia, bleef altijd voorop lopen en paste zijn bedrijfsmodel aan volgens de behoeften van de klant en versterkte zijn strategie met technologische trends, waardoor elke keer een betere klantervaring werd geboden. Hierop gericht begon Belcorp zijn eigen datastrategie te implementeren om het gebruik van data voor besluitvorming aan te moedigen. Op basis van deze strategie ontwierp en implementeerde het data-architectuurteam van Belcorp een data-ecosysteem dat bedrijfs- en analyseteams in staat stelt functionele data te gebruiken die ze gebruiken om hypothesen en inzichten te genereren die gematerialiseerd worden in betere marketingstrategieën of nieuwe producten. Dit bericht is bedoeld om een ​​reeks continue verbeteringen te beschrijven die in 2021 zijn uitgevoerd om het aantal platformincidenten dat eind 2020 wordt gemeld te verminderen, de door het bedrijf vereiste SLA's te optimaliseren en kostenefficiënter te zijn bij het gebruik van Amazon EMR, wat resulteert in tot 30% besparing voor het bedrijf.

Om voorop te blijven lopen, hebben sterkere bedrijven een datastrategie ontwikkeld waarmee ze de belangrijkste bedrijfsstrategieën kunnen verbeteren, of zelfs nieuwe kunnen creëren, met data als belangrijkste drijfveer. Als een van de belangrijkste bedrijven in verpakte consumentengoederen (CPG) in de regio, is Belcorp geen uitzondering - de afgelopen jaren hebben we gewerkt aan het implementeren van datagestuurde besluitvorming.

We weten dat alle goede datastrategieën zijn afgestemd op bedrijfsdoelstellingen en gebaseerd zijn op de belangrijkste zakelijke use-cases. Momenteel zijn al onze teaminspanningen gericht op de eindconsumenten, en bijna alle zakelijke initiatieven zijn gerelateerd aan hyperpersonalisatie, prijsstelling en klantbetrokkenheid.

Om deze initiatieven te ondersteunen, biedt de afdeling data-architectuur datadiensten zoals data-integratie, slechts één bron van waarheid, datagovernance en datakwaliteitskaders, databeschikbaarheid, datatoegankelijkheid en geoptimaliseerde time-to-market, in overeenstemming met zakelijke vereisten zoals andere grote bedrijven. Om minimale mogelijkheden te bieden om al deze services te ondersteunen, hadden we een schaalbaar, flexibel en kostenefficiënt data-ecosysteem nodig. Belcorp begon dit avontuur een paar jaar geleden met behulp van AWS-services zoals Amazon Elastic Compute-cloud (Amazone EC2), AWS Lambda, AWS Fargate, Amazon EMR, Amazon DynamoDB en Amazon roodverschuiving, die momenteel onze belangrijkste analytische oplossingen met gegevens voeden.

Naarmate we groeiden, moesten we ons architectuurontwerp en -verwerkingskader voortdurend verbeteren met betrekking tot gegevensvolume en complexere vereisten voor gegevensoplossingen. We moesten ook kwaliteits- en monitoringkaders aannemen om de data-integriteit, datakwaliteit en service level agreements (SLA's) te garanderen. Zoals je kunt verwachten, is het geen gemakkelijke taak en vereist het zijn eigen strategie. Begin 2021 en als gevolg van kritieke incidenten die we ontdekten, werd de operationele stabiliteit aangetast, wat een directe impact had op de bedrijfsresultaten. De facturering werd ook beïnvloed, omdat er meer nieuwe complexe workloads werden opgenomen, wat zorgde voor een onverwachte stijging van de platformkosten. Als reactie hierop hebben we besloten ons te concentreren op drie uitdagingen:

• Operationele stabiliteit
• Kost efficiëntie
• Service level agreements

In dit bericht worden enkele actiepunten beschreven die we in 2021 hebben uitgevoerd via het gegevensverwerkingsraamwerk van Belcorp op basis van Amazon EMR. We bespreken ook hoe deze acties ons hebben geholpen de eerder genoemde uitdagingen het hoofd te bieden en ook economische besparingen opleverden voor Belcorp, wat de belangrijkste bijdrage van het data-architectuurteam aan het bedrijf was.

Overzicht van de oplossing

Het data-ecosysteem van Belcorp bestaat uit zeven belangrijke capaciteitspijlers (zoals weergegeven in het volgende diagram) die ons architectonisch ontwerp definiëren en ons min of meer technologische flexibele opties bieden. Ons dataplatform kan worden geclassificeerd als een onderdeel van de tweede generatie dataplatforms, zoals vermeld door Zhamak Dehghani in Hoe verder te gaan dan een monolithisch datameer naar een gedistribueerd datamesh. In feite heeft het alle beperkingen en beperkingen van een Lakehouse-aanpak zoals vermeld in de krant Lakehouse: een nieuwe generatie open platforms die datawarehousing en geavanceerde analyses verenigen .

Het dataplatform van Belcorp ondersteunt twee belangrijke use-cases. Aan de ene kant biedt het gegevens die kunnen worden geconsumeerd met behulp van visualisatietools, waardoor zelfbediening wordt aangemoedigd. Aan de andere kant biedt het functionele gegevens aan eindgebruikers, zoals datawetenschappers of data-analisten, via gedistribueerde datawarehouses en objectopslag die meer geschikt zijn voor geavanceerde analytische praktijken.

In het volgende referentieontwerp worden de twee belangrijkste lagen uitgelegd die verantwoordelijk zijn voor het leveren van functionele gegevens voor deze gebruiksscenario's. De gegevensverwerkingslaag bestaat uit twee sublagen. De eerste is Belcorp's Data Lake Integrator, een ingebouwde, interne Python-oplossing met een set API REST-services die verantwoordelijk zijn voor het organiseren van alle dataworkloads en datafasen in de analyserepositories. Het werkt ook als een controlepunt voor het distribueren van middelen die moeten worden toegewezen voor elke Amazon EMR Spark-taak. De verwerkingssublaag bestaat voornamelijk uit het EMR-cluster, dat verantwoordelijk is voor het orkestreren, volgen en onderhouden van alle Spark-taken die zijn ontwikkeld met behulp van een Scala-framework.

Voor de persistente repository-laag gebruiken we Amazon eenvoudige opslagservice (Amazon S3) objectopslag als gegevensopslag voor analyseworkloads, waarbij we een reeks gegevensstadia hebben ontworpen met operationele en functionele doeleinden op basis van het ontwerp van de referentiearchitectuur. Het valt buiten het bestek van dit artikel om het ontwerp van de repository nader te bespreken, maar we moeten er rekening mee houden dat het alle veelvoorkomende uitdagingen behandelt met betrekking tot gegevensbeschikbaarheid, gegevenstoegankelijkheid, gegevensconsistentie en gegevenskwaliteit. Bovendien voldoet het aan alle behoeften van Belcorp die vereist zijn door zijn bedrijfsmodel, ondanks alle beperkingen en beperkingen die we erven door het eerder genoemde ontwerp.

We kunnen nu onze aandacht richten op het hoofddoel van dit bericht.

Zoals we al zeiden, kregen we begin 2021 te maken met kritieke incidenten (waarvan sommige al bestonden) en onverwachte kostenstijgingen, wat ons motiveerde om actie te ondernemen. In de volgende tabel staan ​​enkele van de belangrijkste problemen die onze aandacht hebben getrokken.

Om deze problemen het hoofd te bieden, hebben we besloten om van strategie te veranderen en begonnen we elk probleem te analyseren om de oorzaak te achterhalen. We hebben twee actielijnen gedefinieerd op basis van drie uitdagingen waaraan de leiders wilden dat we werkten. De volgende afbeelding vat deze lijnen en uitdagingen samen.

De actielijn voor data lake-architectuur verwijst naar alle architecturale hiaten en verouderde functies die we hebben vastgesteld als onderdeel van de belangrijkste problemen die de incidenten veroorzaakten. De actielijn voor best practices voor Spark-ontwikkeling is gerelateerd aan de ontwikkelde Spark-gegevensoplossing die tijdens de ontwikkelingslevenscyclus instabiliteit veroorzaakte als gevolg van slechte praktijken. Gefocust op deze actielijnen, hebben onze leiders drie uitdagingen gedefinieerd om het aantal incidenten te verminderen en de kwaliteit van de service die we leveren te garanderen: operationele stabiliteit, kostenefficiëntie en SLA's.

Op basis van deze uitdagingen hebben we drie KPI's gedefinieerd om het succes van het project te meten. Jira-incidenten stellen ons in staat te valideren dat onze wijzigingen een positieve impact hebben; facturering per week laat de leiders zien dat een deel van de wijzigingen die we hebben doorgevoerd de kosten geleidelijk zullen optimaliseren; en runtime biedt de zakelijke gebruikers een betere time-to-market.

Vervolgens definieerden we de volgende stappen en hoe de voortgang te meten. Op basis van ons monitoringraamwerk hebben we vastgesteld dat bijna alle incidenten die zich voordeden gerelateerd waren aan de dataverwerkings- en persistente repository-lagen. Toen moesten we beslissen hoe we ze zouden oplossen. We kunnen reactieve oplossingen maken om operationele stabiliteit te bereiken en geen impact hebben op het bedrijf, of we kunnen onze gebruikelijke manier van werken veranderen, elk probleem analyseren en een definitieve oplossing bieden om ons raamwerk te optimaliseren. Zoals je kunt raden, hebben we besloten om onze manier van werken te veranderen.

We hebben een voorlopige analyse uitgevoerd om de belangrijkste effecten en uitdagingen te bepalen. Op basis van onze actielijnen hebben we vervolgens de volgende acties en verbeteringen voorgesteld:

• Data lake-architectuur – We hebben het EMR-cluster opnieuw ontworpen; we gebruiken nu kern- en taakknooppunten
• Best practices voor Spark-ontwikkeling - We hebben Spark-parameters geoptimaliseerd (RAM-geheugen, cores, CPU's en uitvoerdernummer)

In de volgende sectie lichten we in detail de acties en verbeteringen toe die worden voorgesteld om onze doelen te bereiken.

Acties en verbeteringen

Zoals we in de vorige sectie vermeldden, resulteerde de analyse van het architectuurteam in een lijst met acties en verbeteringen die ons zouden helpen om drie uitdagingen het hoofd te bieden: operationele stabiliteit, een kostenefficiënt data-ecosysteem en SLA's.

Voordat we verder gaan, is het een goed moment om meer details te geven over het Belcorp-raamwerk voor gegevensverwerking. We hebben het gebouwd op basis van Apache Spark met behulp van de programmeertaal Scala. Ons raamwerk voor gegevensverwerking is een reeks schaalbare, parametreerbare en herbruikbare Scala-artefacten die ontwikkelingsteams een krachtig hulpmiddel bieden om complexe gegevenspijplijnen te implementeren, waarbij de meest complexe zakelijke vereisten worden bereikt met behulp van Apache Spark-technologie. Via het Belcorp DevOps-framework implementeren we elk artefact in verschillende niet-productieomgevingen. Daarna promoveren we naar productie, waar het EMR-cluster alle routines lanceert met behulp van de Scala-artefacten die verwijzen naar elk conceptueel gebied binnen het analytische platform. Dit deel van de cyclus geeft de teams een zekere mate van flexibiliteit en wendbaarheid. We vergaten echter even de kwaliteit van de software die we ontwikkelden met behulp van Apache Spark-technologie.

In deze sectie duiken we in de acties en verbeteringen die we hebben toegepast om het Belcorp-raamwerk voor gegevensverwerking te optimaliseren en de architectuur te verbeteren.

Het EPD-cluster opnieuw ontwerpen

Het huidige ontwerp en de implementatie van het Belcorp data lake is niet de eerste versie. We zijn momenteel in versie 2.0 en vanaf het begin van de eerste implementatie tot nu toe hebben we verschillende EMR-clusterontwerpen geprobeerd om de gegevensverwerkingslaag te implementeren. Aanvankelijk gebruikten we een vast cluster met vier knooppunten (zoals weergegeven in de volgende afbeelding), maar toen de mogelijkheid voor automatisch schalen werd gelanceerd en de gegevensworkloads van Belcorp toenam, besloten we het daarheen te verplaatsen om het gebruik van hulpbronnen en de kosten te optimaliseren. Een automatisch geschaald EMR-cluster heeft echter ook verschillende opties. U kunt kiezen tussen kern- en taakknooppunten met een minimaal en maximaal aantal van elk. Daarnaast kunt u On-Demand of Spot Instances selecteren. U kunt ook een geoptimaliseerde toewijzingsstrategie implementeren met behulp van EMR-instantievloten om de kans op verlies van Spot Instance te verkleinen. Zie voor meer informatie over Amazon EMR-middelentoewijzingsstrategieën: Spark-verbeteringen voor elasticiteit en veerkracht op Amazon EMR en Amazon EMR optimaliseren voor veerkracht en kosten met voor capaciteit geoptimaliseerde Spot Instances.

We hebben al deze mogelijkheden getest, maar we hebben enkele problemen geconstateerd.

Ten eerste, hoewel AWS veel mogelijkheden en functionaliteiten biedt rond Amazon EMR, kun je, als je geen enkele mate van kennis hebt over de technologie die je wilt gebruiken, veel problemen tegenkomen als de use-cases zich voordoen. Zoals we al zeiden, hebben we besloten om de Apache Spark-gegevensverwerkingsengine via Amazon EMR te gebruiken als onderdeel van het gegevensecosysteem van Belcorp, maar we hadden te maken met veel problemen. Telkens wanneer zich een incident voordeed, motiveerde dit het verantwoordelijke team van data-architecten om het op te lossen, als onderdeel van de operationele en ondersteunende taken. Bijna al deze reactieve oplossingen hadden betrekking op het wijzigen van de Amazon EMR-configuratie om verschillende alternatieven uit te proberen om deze incidenten efficiënt op te lossen.

We kwamen erachter dat bijna alle incidenten verband hielden met de toewijzing van middelen, dus hebben we veel configuratie-opties getest, zoals instantietypen, het vergroten van het aantal knooppunten, aangepaste regels voor automatisch schalen en vlootstrategieën. Deze laatste optie werd gebruikt om het verlies van knooppunten te verminderen. Eind 2020 hebben we gevalideerd dat een EMR-cluster met automatische schaling ingeschakeld met een minimumcapaciteit van drie on-demand core nodes 24/7 en de mogelijkheid om tot 25 on-demand core nodes op te schalen, ons een stabiele gegevensverwerking opleverde. platform. Begin 2021 werden complexere Spark-taken ingezet als onderdeel van de gegevensverwerkingsroutines binnen het EMR-cluster, waardoor er opnieuw operationele instabiliteit ontstond. Bovendien nam de facturering onverwacht toe, wat leiders waarschuwde wiens team het EMR-cluster moest herontwerpen om een ​​gezonde operationele stabiliteit te behouden en de kosten te optimaliseren.

We realiseerden ons al snel dat het mogelijk was om tot 40% van de huidige facturering te verminderen met behulp van Spot Instances, in plaats van alle kernknooppunten in On-Demand-consumptie te houden. Een andere infrastructuuroptimalisatie die we wilden toepassen, was het vervangen van een aantal kernknooppunten door taakknooppunten, omdat bijna alle Belcorp-gegevensworkloads geheugenintensief zijn en Amazon S3 gebruiken om de brongegevens te lezen en de resultaatgegevensset te schrijven. De vraag was hier hoe dat te doen zonder de voordelen van het huidige ontwerp te verliezen. Om deze vraag te beantwoorden, hadden we de begeleiding van het AWS Account Team en onze AWS Analytics en Big Data Specialist SA, om vragen over het volgende te verduidelijken:

• Apache Spark-implementatie in Amazon EMR
• Best practices voor kern- en taakknooppunten voor productieomgevingen
• Gedrag van instanties in Amazon EMR

We raden zeker aan om deze drie hoofdpunten aan te pakken voordat u wijzigingen aanbrengt, omdat, volgens onze eerdere ervaring, wijzigingen in het donker kunnen leiden tot dure en slecht presterende Amazon EMR-implementatie. Met dat in gedachten hebben we het EMR-cluster opnieuw ontworpen om te gebruiken EMR beheerde schaling, waarmee het formaat van uw cluster automatisch wordt aangepast voor de beste prestaties tegen de laagst mogelijke kosten. We hebben een maximum van 28 capaciteitseenheden gedefinieerd met drie on-demand core nodes die altijd aan staan ​​(24/7) om dataworkloads gedurende de dag te ondersteunen. Vervolgens hebben we een limiet voor automatisch schalen ingesteld van zes On-Demand-kernen om minimale HDFS-mogelijkheden te bieden ter ondersteuning van de resterende 22 taakknooppunten die zijn samengesteld uit Spot Instances. Deze definitieve configuratie is gebaseerd op het advies van AWS-experts dat we ten minste één kernknooppunt hebben om zes taakknooppunten te ondersteunen, waarbij een verhouding van 1:6 behouden blijft. De volgende tabel vat ons clusterontwerp samen.

De volgende afbeelding illustreert ons bijgewerkte en huidige clusterontwerp.

Spark-parameters afstemmen

Zoals elk goed boek over Apache Spark kan u vertellen dat het afstemmen van Spark-parameters het belangrijkste onderwerp is waar u naar moet kijken voordat u een Spark-toepassing in productie implementeert.

Het aanpassen van Spark-parameters is de taak van het instellen van de resources (CPU's, geheugen en het aantal uitvoerders) voor elke Spark-toepassing. In dit bericht richten we ons niet op bronnen voor stuurprogramma-instanties; we richten ons op de uitvoerders, want dat is het belangrijkste probleem dat we hebben gevonden in de implementatie van Belcorp.

Nadat we verbeteringen hadden aangebracht rond join-bewerkingen en cachestrategieën in de ontwikkeling van Spark-applicaties, realiseerden we ons dat aan sommige van die applicaties overschatte resources in het EMR-cluster waren toegewezen. Dat betekent dat Spark-applicaties resources toegewezen kregen, maar dat slechts 30% van de resources werd gebruikt. Het volgende Ganglia-rapport illustreert de overschatting van de toewijzing van middelen voor één Spark-toepassingstaak, die we tijdens een van onze tests hebben vastgelegd.

Een groot gevolg van dit gedrag was de massale inzet van EMR-knooppunten die niet goed werden gebruikt. Dat betekent dat er tal van nodes zijn ingericht vanwege de functie voor automatisch schalen die vereist is voor het indienen van een Spark-toepassing, maar veel van de bronnen van deze nodes zijn vrijgehouden. Een basisvoorbeeld hiervan laten we verderop in deze paragraaf zien.

Met dit bewijs begonnen we te vermoeden dat we de Spark-parameters van sommige van onze Spark-applicaties moesten aanpassen.

Zoals we in eerdere secties vermeldden, hebben we als onderdeel van het data-ecosysteem van Belcorp een Data Pipelines Integrator gebouwd, die de hoofdverantwoordelijkheid heeft voor het handhaven van gecentraliseerde controle over de uitvoeringen van elke Spark-applicatie. Om dat te doen, gebruikt het een JSON-bestand dat de Spark-parameterconfiguratie bevat en voert elk uit spark-submit met behulp van Livy-service, zoals weergegeven in de volgende voorbeeldcode:

'/usr/lib/spark/bin/spark-submit' '--class' 'LoadToFunctional' '--conf' 'spark.executor.instances=62' '--conf' 'spark.executor.memory=17g' '--conf' 'spark.yarn.maxAppAttempts=2' '--conf' 'spark.submit.deployMode=cluster' '--conf' 'spark.master=yarn' '--conf' 'spark.executor.cores=5' 's3://<bucket-name>/FunctionalLayer.jar' '--system' 'CM' '--country' 'PE' '--current_step' 'functional' '--attempts' '1' '--ingest_attributes' '{"FileFormat": "zip", "environment": "PRD", "request_origin": "datalake_integrator", "next_step": "load-redshift"}' '--fileFormat' 'zip' '--next_step' 'load-redshift'

Dit JSON-bestand bevat de Spark-parameterconfiguratie van elke Spark-toepassing met betrekking tot een intern systeem en land dat we indienen bij het EMR-cluster. In het volgende voorbeeld, CM is de naam van het systeem en PE is de landcode waar de gegevens vandaan komen:

"systems" : { "CM" : { "PE" : { "params" : {"executorCores": 15, "executorMemory": "45g", "numExecutors": 50 }, "conf" : { "spark.sql.shuffle.partitions" :120 } }
}

Het probleem met deze aanpak is dat naarmate we meer applicaties toevoegen, het beheer van deze configuratiebestanden complexer wordt. Daarnaast hadden we veel Spark-applicaties opgezet met een standaardconfiguratie die lang geleden was gedefinieerd toen workloads goedkoper waren. Het was dus te verwachten dat er een en ander zou veranderen. Een voorbeeld van een Spark-toepassing met niet-gekalibreerde parameters wordt weergegeven in de volgende afbeelding (we gebruiken alleen vier executor-instanties voor het voorbeeld). In dit voorbeeld realiseerden we ons dat we uitvoerders met veel middelen toewijsden zonder een van de best practices van Spark te volgen. Dit veroorzaakte de bevoorrading van dikke uitvoerders (met behulp van Spark-jargon) waarbij elk van deze in ten minste één knooppunt wordt toegewezen. Dat betekent dat als we een Spark-toepassing definiëren die moet worden ingediend met 10 uitvoerders, we minimaal 10 knooppunten van het cluster nodig hebben en 10 knooppunten gebruiken voor slechts één run, wat erg duur voor ons was.

Wanneer u met Spark-parameterafstemmingsuitdagingen omgaat, is het altijd een goed idee om deskundig advies op te volgen. Misschien is een van de belangrijkste adviezen gerelateerd aan het aantal uitvoerende kernen dat u in één Spark-toepassing moet gebruiken. Experts suggereren dat een uitvoerder maximaal vier of vijf kernen moet hebben. We waren bekend met deze beperking omdat we voorheen Spark-applicaties in het Hadoop-ecosysteem ontwikkelden vanwege Hadoop File Systems I/O-beperkingen. Dat wil zeggen, als we meer kernen hebben geconfigureerd voor één uitvoerder, voeren we meer I/O-bewerkingen uit in een enkel HDFS-gegevensknooppunt, en het is algemeen bekend dat HDFS degradeert als gevolg van hoge gelijktijdigheid. Deze beperking is geen probleem als we Amazon S3 als opslag gebruiken, maar de suggestie blijft vanwege de overbelasting van de JVM. Onthoud dat terwijl u meer operationele taken hebt, zoals I/O-bewerkingen, de JVM van elke uitvoerder meer werk te doen heeft, dus de JVM wordt gedegradeerd.

Met deze feiten en eerdere bevindingen realiseerden we ons dat we voor sommige van onze Spark-applicaties slechts 30% van de toegewezen resources gebruikten. We moesten de Spark-taakparameters opnieuw kalibreren om alleen de meest geschikte resources toe te wijzen en het overmatig gebruik van EMR-knooppunten aanzienlijk te verminderen. De volgende afbeelding geeft een voorbeeld van de voordelen van deze verbetering, waarbij we een knooppuntreductie van 50% kunnen waarnemen op basis van onze eerdere configuratie.

We hebben de volgende geoptimaliseerde parameters gebruikt om de Spark-toepassing met betrekking tot het CM-systeem te optimaliseren:

"systems" : { "CM" : { "PE" : { "params" : {"executorCores": 5, "executorMemory": "17g", "numExecutors": 62 }, "conf" : { "spark.sql.shuffle.partitions" :120 } }
}

Resultaten

In dit bericht wilden we het succesverhaal delen van ons project om het data-ecosysteem van Belcorp te verbeteren, gebaseerd op twee actielijnen en drie uitdagingen die zijn gedefinieerd door leiders met behulp van AWS-datatechnologieën en interne platforms.

We waren vanaf het begin duidelijk over onze doelstellingen op basis van de gedefinieerde KPI's, dus we hebben kunnen valideren dat het aantal JIRA-incidenten dat eind mei 2021 werd gemeld, een opmerkelijke daling kende. De volgende cijfers laten een daling tot 75% zien ten opzichte van voorgaande maanden, waarbij maart als kritieke piek wordt gemarkeerd.

Op basis van deze incidentreductie kwamen we erachter dat bijna alle Spark-taakroutines die in het EMR-cluster worden uitgevoerd, profiteerden van een runtime-optimalisatie, inclusief de twee meest complexe Spark-taken, met een reductie tot 60%, zoals weergegeven in de volgende afbeelding.

Misschien wel de belangrijkste bijdrage van de verbeteringen die het team heeft aangebracht, is direct gerelateerd aan de facturering per week. Het herontwerp van Amazon EMR, de verbeteringen van de join-operatie, de toegepaste best practices voor de cache en het afstemmen van Spark-parameters hebben allemaal geleid tot een opmerkelijke vermindering van het gebruik van clusterresources. Zoals we weten, berekent Amazon EMR de facturering op basis van de tijd dat de clusterknooppunten zijn ingeschakeld, ongeacht of ze enig werk doen. Dus toen we het gebruik van EMR-clusters optimaliseerden, optimaliseerden we ook de kosten die we genereerden. Zoals weergegeven in de volgende afbeelding:, alleen in 2 maanden, tussen maart en mei, hebben we een factuurvermindering tot 40% bereikt. We schatten dat we tot 26% besparen op de jaarlijkse facturering die zou zijn gegenereerd zonder de verbeteringen.

Conclusie en volgende stappen

Het data-architectuurteam is verantwoordelijk voor de voortdurende verbeteringen van het data-ecosysteem van Belcorp, en we worden altijd uitgedaagd om een ​​best-in-class architectuur te bereiken, betere ontwerpen voor architecturale oplossingen te maken, de kosten te optimaliseren en de meest geautomatiseerde, flexibele en schaalbare kaders.

Tegelijkertijd denken we na over de toekomst van dit data-ecosysteem: hoe we ons kunnen aanpassen aan nieuwe zakelijke behoeften, nieuwe bedrijfsmodellen kunnen genereren en de huidige architecturale lacunes kunnen dichten. We werken nu aan de volgende generatie van het Belcorp-dataplatform, gebaseerd op nieuwe benaderingen zoals dataproducten, datamesh en meerhuizen. We geloven dat deze nieuwe benaderingen en concepten ons zullen helpen om onze huidige architecturale hiaten in de tweede generatie van ons dataplatformontwerp te dichten. Bovendien gaat het ons helpen om de business- en ontwikkelingsteams beter te organiseren om meer wendbaarheid te krijgen tijdens de ontwikkelingscyclus. We zien dataoplossingen als een dataproduct en bieden teams een reeks technologische componenten en geautomatiseerde frameworks die ze als bouwstenen kunnen gebruiken.

Dankwoord

We willen onze leiders bedanken, in het bijzonder Jose Israel Rico, Corporate Data Architecture Director, en Venkat Gopalan, Chief Technology, Data and Digital Officer, die ons inspireren om klantgericht te zijn, aan te dringen op de hoogste normen en elke technische beslissing te ondersteunen op basis van op een sterkere kennis van de stand van de techniek.

Over de auteurs

Diego Benavides is de Senior Data Architect van Belcorp die verantwoordelijk is voor het ontwerp, de implementatie en de continue verbetering van de wereldwijde en zakelijke data-ecosysteemarchitectuur. Hij heeft ervaring met het werken met big data en geavanceerde analysetechnologieën in vele bedrijfstakken, zoals telecommunicatie, bankieren en detailhandel.

Luis Bendezu werkt als Senior Data Engineer bij Belcorp. Hij is verantwoordelijk voor continue verbeteringen en het implementeren van nieuwe data lake-functies met behulp van een aantal AWS-services. Hij heeft ook ervaring als software-engineer, het ontwerpen van API's, het integreren van veel platforms, het ontkoppelen van applicaties en het automatiseren van handmatige taken.

Maart Ortiz is een bio-ingenieur die werkt als Solutions Architect Associate bij AWS. Ze heeft ervaring met het werken met cloudcomputing en diverse technologieën zoals media, databases, compute en gedistribueerd architectuurontwerp.

Raul Hugo is een AWS Sr. Solutions Architect met meer dan 12 jaar ervaring in LATAM financiële bedrijven en wereldwijde telecombedrijven als SysAdmin, DevOps-engineer en cloudspecialist.

Bron: https://aws.amazon.com/blogs/big-data/how-belcorp-decreased-cost-and-improved-reliability-in-its-big-data-processing-framework-using-amazon-emr- beheerde schaling/