Elke dag verwerken en analyseren Amazon-apparaten miljarden transacties van wereldwijde verzending, voorraad, capaciteit, levering, verkoop, marketing, producenten en klantenserviceteams. Deze gegevens worden gebruikt bij het aanschaffen van de inventaris van apparaten om aan de eisen van Amazon-klanten te voldoen. Met datavolumes die jaar op jaar een dubbelcijferig groeipercentage vertoonden en de COVID-pandemie die de wereldwijde logistiek in 2021 verstoorde, werd het belangrijker om te schalen en near-real-time data te genereren.

Dit bericht laat zien hoe we zijn gemigreerd naar een serverloos datameer gebouwd op AWS dat automatisch gegevens uit meerdere bronnen en verschillende indelingen verbruikt. Bovendien creëerde het verdere mogelijkheden voor onze datawetenschappers en ingenieurs om AI en machine learning (ML)-services te gebruiken om continu gegevens te voeden en te analyseren.

Uitdagingen en ontwerpproblemen

Onze legacy-architectuur wordt voornamelijk gebruikt Amazon Elastic Compute-cloud (Amazon EC2) om de gegevens te extraheren uit verschillende interne heterogene gegevensbronnen en REST API's met de combinatie van Amazon eenvoudige opslagservice (Amazon S3) om de gegevens te laden en Amazon roodverschuiving voor verdere analyse en het genereren van de inkooporders.

We ontdekten dat deze aanpak enkele tekortkomingen opleverde en daarom verbeteringen aanbracht op de volgende gebieden:

• Snelheid van de ontwikkelaar – Vanwege het gebrek aan unificatie en ontdekking van schema's, die de belangrijkste redenen zijn voor runtime-fouten, besteedden ontwikkelaars vaak tijd aan het oplossen van operationele en onderhoudsproblemen.
• Schaalbaarheid – De meeste van deze datasets worden over de hele wereld gedeeld. Daarom moeten we bij het opvragen van de gegevens aan de schaallimieten voldoen.
• Minimaal onderhoud van de infrastructuur – Het huidige proces omvat meerdere berekeningen, afhankelijk van de gegevensbron. Daarom is het verminderen van het onderhoud van de infrastructuur van cruciaal belang.
• Responsiviteit op wijzigingen in de gegevensbron – Ons huidige systeem haalt data uit verschillende heterogene datastores en services. Elke update van die services kost maanden aan ontwikkelingscycli. De reactietijden voor deze gegevensbronnen zijn van cruciaal belang voor onze belangrijkste belanghebbenden. Daarom moeten we een datagestuurde aanpak volgen om een ​​krachtige architectuur te selecteren.
• Opslag en redundantie – Vanwege de heterogene datastores en -modellen was het een uitdaging om de verschillende datasets van verschillende zakelijke stakeholderteams op te slaan. Daarom zal het hebben van versiebeheer samen met incrementele en differentiële gegevens om te vergelijken een opmerkelijke mogelijkheid bieden om meer geoptimaliseerde plannen te genereren
• Voortvluchtig en bereikbaarheid – Vanwege de volatiele aard van logistiek hebben enkele teams van belanghebbenden de behoefte om de gegevens op aanvraag te analyseren en het bijna realtime optimale plan voor de inkooporders te genereren. Dit introduceert de noodzaak van zowel polling als het pushen van de gegevens om toegang te krijgen tot en te analyseren in bijna realtime.

Implementatiestrategie

Op basis van deze vereisten veranderden we van strategie en begonnen we elk probleem te analyseren om de oplossing te vinden. Architectonisch hebben we gekozen voor een serverloos model en de actielijn voor data lake-architectuur verwijst naar alle architectonische hiaten en uitdagende functies waarvan we hebben vastgesteld dat ze deel uitmaakten van de verbeteringen. Vanuit operationeel oogpunt hebben we een nieuw model voor gedeelde verantwoordelijkheid ontworpen voor het gebruik van gegevensopname AWS lijm in plaats van interne services (REST API's) die zijn ontworpen op Amazon EC2 om de gegevens te extraheren. Wij gebruikten ook AWS Lambda voor gegevensverwerking. Toen hebben wij gekozen Amazone Athene als onze vraagservice. Om de snelheid van ontwikkelaars voor onze dataconsumenten verder te optimaliseren en te verbeteren, hebben we toegevoegd Amazon DynamoDB als een metadataopslag voor verschillende gegevensbronnen die in het datameer terechtkomen. Deze twee beslissingen hebben geleid tot elke ontwerp- en implementatiebeslissing die we hebben genomen.

Het volgende diagram illustreert de architectuur

In de volgende secties bekijken we elk onderdeel in de architectuur in meer detail terwijl we door de processtroom gaan.

AWS-lijm voor ETL

Om aan de vraag van de klant te voldoen en tegelijkertijd de schaal van de gegevensbronnen van nieuwe bedrijven te ondersteunen, was het voor ons van cruciaal belang om een ​​hoge mate van flexibiliteit, schaalbaarheid en reactievermogen te hebben bij het doorzoeken van verschillende gegevensbronnen.

AWS Glue is een serverloze data-integratieservice die het voor analysegebruikers gemakkelijk maakt om data uit meerdere bronnen te ontdekken, voor te bereiden, te verplaatsen en te integreren. U kunt het gebruiken voor analyse, ML en applicatie-ontwikkeling. Het bevat ook extra productiviteit en DataOps-tooling voor het schrijven, uitvoeren van taken en het implementeren van zakelijke workflows.

Met AWS Glue kunt u meer dan 70 verschillende gegevensbronnen ontdekken en er verbinding mee maken, en uw gegevens beheren in een gecentraliseerde gegevenscatalogus. U kunt ETL-pijplijnen (extraheren, transformeren en laden) visueel maken, uitvoeren en bewaken om gegevens in uw datalakes te laden. U kunt ook direct gecatalogiseerde gegevens zoeken en doorzoeken met behulp van Athena, Amazon EMR en Amazon Roodverschuivingsspectrum.

AWS Glue heeft het voor ons gemakkelijk gemaakt om verbinding te maken met de gegevens in verschillende gegevensarchieven, de gegevens naar behoefte te bewerken en op te schonen, en de gegevens in een door AWS ingerichte opslag te laden voor een uniforme weergave. AWS Glue-taken kunnen op verzoek worden gepland of opgeroepen om gegevens uit de bron van de klant en uit het datameer te extraheren.

Enkele verantwoordelijkheden van deze banen zijn als volgt:

• Een bronentiteit extraheren en converteren naar gegevensentiteit
• Verrijk de gegevens met jaar, maand en dag voor betere catalogisering en voeg een momentopname-ID toe voor betere query's
• Voer invoervalidatie en padgeneratie uit voor Amazon S3
• Koppel de geaccrediteerde metadata op basis van het bronsysteem

Het opvragen van REST API's van interne services is een van onze kernuitdagingen, en gezien de minimale infrastructuur wilden we ze in dit project gebruiken. AWS Glue-connectoren hielpen ons bij het naleven van de vereiste en het doel. Om gegevens uit REST API's en andere gegevensbronnen op te vragen, gebruikten we PySpark- en JDBC-modules.

AWS Glue ondersteunt een breed scala aan verbindingstypen. Voor meer details, zie Verbindingstypen en opties voor ETL in AWS Glue.

S3 bucket als landingszone

We gebruikten een S3-bucket als directe landingszone van de geëxtraheerde gegevens, die verder worden verwerkt en geoptimaliseerd.

Lambda als AWS Glue ETL-trigger

We hebben S3-gebeurtenismeldingen op de S3-bucket ingeschakeld om Lambda te activeren, waardoor onze gegevens verder worden gepartitioneerd. De gegevens zijn gepartitioneerd op InputDataSetName, Year, Month en Date. Elke queryprocessor die bovenop deze gegevens draait, scant slechts een subset van gegevens voor betere kosten- en prestatie-optimalisatie. Onze gegevens kunnen in verschillende formaten worden opgeslagen, zoals CSV, JSON en Parquet.

De onbewerkte gegevens zijn niet ideaal voor de meeste van onze use-cases om het optimale plan te genereren, omdat deze vaak duplicaten of onjuiste gegevenstypen bevatten. Het belangrijkste is dat de gegevens in meerdere indelingen zijn, maar we hebben de gegevens snel aangepast en hebben aanzienlijke prestatieverbeteringen voor query's waargenomen door het gebruik van de Parquet-indeling. Hier hebben we een van de prestatietips in gebruikt Top 10 tips voor het afstemmen van prestaties voor Amazon Athena.

AWS Glue-taken voor ETL

We wilden betere gegevensscheiding en toegankelijkheid, dus kozen we voor een andere S3-bucket om de prestaties verder te verbeteren. We hebben dezelfde AWS Glue-taken gebruikt om de gegevens verder te transformeren en te laden in de vereiste S3-bucket en een deel van de geëxtraheerde metadata in DynamoDB.

DynamoDB als metadataopslag

Nu we de gegevens hebben, gebruiken verschillende zakelijke belanghebbenden deze verder. Dit laat ons met twee vragen: welke brongegevens bevinden zich op het datameer en welke versie. We kozen DynamoDB als onze metadata-opslag, die de consumenten de laatste details biedt om de gegevens effectief op te vragen. Elke dataset in ons systeem wordt uniek geïdentificeerd door snapshot-ID, die we kunnen doorzoeken in onze metadata-opslag. Klanten hebben toegang tot deze data store met een API's.

Amazon S3 als datameer

Voor een betere gegevenskwaliteit hebben we de verrijkte gegevens geëxtraheerd naar een andere S3-bucket met dezelfde AWS Glue-taak.

AWS lijmcrawler

Crawlers zijn de 'geheime saus' waarmee we kunnen reageren op schemawijzigingen. Gedurende het hele proces hebben we ervoor gekozen om elke stap zo schema-agnostisch mogelijk te maken, waardoor schemawijzigingen kunnen worden doorgevoerd totdat ze AWS Glue bereiken. Met een crawler konden we de agnostische wijzigingen in het schema handhaven. Dit hielp ons om automatisch de gegevens van Amazon S3 te crawlen en het schema en de tabellen te genereren.

AWS-lijmgegevenscatalogus

De gegevenscatalogus hielp ons de catalogus te onderhouden als een index voor de locatie, het schema en de looptijdstatistieken van de gegevens in Amazon S3. Informatie in de gegevenscatalogus wordt opgeslagen als metadatatabellen, waarbij elke tabel een enkele gegevensopslag specificeert.

Athena voor SQL-query's

Athena is een interactieve queryservice die het eenvoudig maakt om gegevens in Amazon S3 te analyseren met behulp van standaard SQL. Athena is serverloos, dus er is geen infrastructuur om te beheren en u betaalt alleen voor de query's die u uitvoert. We beschouwden operationele stabiliteit en toenemende snelheid van ontwikkelaars als onze belangrijkste verbeterfactoren.

We hebben het proces om Athena te bevragen verder geoptimaliseerd, zodat gebruikers de waarden en query's kunnen invoeren om gegevens uit Athena te halen door het volgende te maken:

• An AWS Cloud-ontwikkelingskit (AWS CDK) sjabloon om Athena-infrastructuur te creëren en AWS Identiteits- en toegangsbeheer (IAM)-rollen voor toegang tot data lake S3-buckets en de datacatalogus vanuit elk account
• Een bibliotheek zodat de klant een IAM-rol, query, gegevensindeling en uitvoerlocatie kan bieden om een ​​Athena-query te starten en de status en het resultaat van de queryrun in de bucket van hun keuze te krijgen.

Athena opvragen is een proces in twee stappen:

• StartQueryUitvoering – Hiermee wordt de queryrun gestart en wordt de run-ID opgehaald. Gebruikers kunnen de uitvoerlocatie opgeven waar de uitvoer van de query wordt opgeslagen.
• GetQueryExecution - Dit krijgt de querystatus omdat de run asynchroon is. Als dit lukt, kunt u de uitvoer opvragen in een S3-bestand of via API.

De helpermethode voor het starten van de queryrun en het verkrijgen van het resultaat bevindt zich in de bibliotheek.

Metadataservice van Data Lake

Deze service is op maat ontwikkeld en communiceert met DynamoDB om de metadata (datasetnaam, snapshot-ID, partitietekenreeks, tijdstempel en S3-link van de data) in de vorm van een REST API te krijgen. Wanneer het schema wordt ontdekt, gebruiken clients Athena als hun queryprocessor om de gegevens op te vragen.

Omdat alle datasets een snapshot-ID hebben en zijn gepartitioneerd, resulteert de join-query niet in een volledige tabelscan, maar alleen in een partitiescan op Amazon S3. We gebruikten Athena als onze query-processor vanwege het gemak waarmee we onze query-infrastructuur niet konden beheren. Als we later het gevoel hebben dat we iets meer nodig hebben, kunnen we Redshift Spectrum of Amazon EMR gebruiken.

Conclusie

Amazon Devices-teams ontdekten aanzienlijke waarde door over te stappen op een data lake-architectuur met behulp van AWS Glue, waardoor meerdere wereldwijde zakelijke belanghebbenden gegevens op productievere manieren konden opnemen. Hierdoor konden de teams het optimale plan genereren om inkooporders voor apparaten te plaatsen door de verschillende datasets in bijna realtime te analyseren met de juiste bedrijfslogica om de problemen van de toeleveringsketen, vraag en prognose op te lossen.

Vanuit operationeel oogpunt begint de investering zich al terug te betalen:

• Het standaardiseerde onze opname-, opslag- en ophaalmechanismen, waardoor onboarding-tijd werd bespaard. Vóór de implementatie van dit systeem duurde het 1 maand om één dataset aan boord te krijgen. Dankzij onze nieuwe architectuur konden we 15 nieuwe datasets in minder dan 2 maanden onboarden, wat onze flexibiliteit met 70% verbeterde.
• Het verwijderde schaalknelpunten, waardoor een homogeen systeem ontstond dat snel kan worden opgeschaald naar duizenden runs.
• De oplossing voegde schema- en gegevenskwaliteitsvalidatie toe voordat invoer werd geaccepteerd en afgewezen als er schendingen van de gegevenskwaliteit werden ontdekt.
• Het maakte het gemakkelijk om datasets op te halen en tegelijkertijd toekomstige simulaties en back-tester use cases te ondersteunen die versie-invoer vereisen. Dit maakt het lanceren en testen van modellen eenvoudiger.
• De oplossing creëerde een gemeenschappelijke infrastructuur die gemakkelijk kan worden uitgebreid naar andere teams binnen DIAL die soortgelijke problemen hebben met gebruiksscenario's voor gegevensopname, opslag en ophalen.
• Onze bedrijfskosten zijn met bijna 90% gedaald.
• Dit datameer is efficiënt toegankelijk voor onze datawetenschappers en ingenieurs om andere analyses uit te voeren en een voorspellende benadering te hebben als een toekomstige mogelijkheid om nauwkeurige plannen voor de inkooporders te genereren.

De stappen in dit bericht kunnen u helpen bij het plannen van een vergelijkbare moderne gegevensstrategie met behulp van door AWS beheerde services om gegevens uit verschillende bronnen op te nemen, automatisch metagegevenscatalogi te maken, gegevens naadloos te delen tussen het datameer en het datawarehouse en waarschuwingen te creëren in het geval van een georkestreerde dataworkflowfout.

Over de auteurs

Avinash Kolluri is Senior Solutions Architect bij AWS. Hij werkt voor Amazon Alexa en Devices om moderne gedistribueerde oplossingen te ontwerpen en te ontwerpen. Zijn passie is het bouwen van kosteneffectieve en zeer schaalbare oplossingen op AWS. In zijn vrije tijd kookt hij graag fusionrecepten en reist hij graag.

Vipul Verma is Sr.Software Engineer bij Amazon.com. Hij werkt sinds 2015 bij Amazon en lost echte uitdagingen op door middel van technologie die het leven van Amazon-klanten rechtstreeks beïnvloedt en verbetert. In zijn vrije tijd wandelt hij graag.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. Toegang hier.
• Bron: https://aws.amazon.com/blogs/big-data/how-amazon-devices-scaled-and-optimized-real-time-demand-and-supply-forecasts-using-serverless-analytics/