Dit is een gastpost van Kanti Chalasani, Division Director bij Georgia Data Analytics Center (GDAC). GDAC is ondergebracht bij het Georgia Office of Planning and Budget om het delen van gereguleerde gegevens tussen verschillende overheidsinstanties en -afdelingen te vergemakkelijken.

Het Office of Planning and Budget (OPB) heeft de Gegevensanalysecentrum in Georgië (GDAC) met de bedoeling om gegevensverantwoordelijkheid en transparantie in Georgië te bieden. GDAC streeft ernaar de overheidsinstanties, academische instellingen, onderzoekers en belastingbetalers van de staat te ondersteunen bij hun gegevensbehoeften. Het moderne data-analysecentrum van Georgia helpt bij het veilig verzamelen, integreren, anonimiseren en aggregeren van gegevens.

In dit bericht delen we hoe GDAC vanaf het begin een analyseplatform creëerde met behulp van AWS-services en hoe GDAC samenwerkte met de AWS-datalab om dit project van ontwerp tot bouw in recordtijd te versnellen. De pre-planningsessies, technische onderdompelingen, pre-build-sessies en post-build-sessies hielpen ons ons te concentreren op onze doelstellingen en tastbare resultaten. We bouwden een prototype met een moderne data-architectuur en namen snel extra data op in het datameer en het datawarehouse. Dankzij de speciaal gebouwde gegevens- en analyseservices konden we snel aanvullende gegevens opnemen en dashboards voor gegevensanalyse leveren. Het was buitengewoon de moeite waard om de openbare website van GDAC binnen slechts 4 maanden officieel te lanceren.

Een combinatie van duidelijke aanwijzingen van de uitvoerende belanghebbenden van OPB, input van het deskundige en gedreven AWS-team en de gedrevenheid en toewijding van het GDAC-team om te leren, speelden een grote rol in dit succesverhaal. De partnerbureaus van GDAC hebben enorm geholpen door tijdige gegevenslevering, gegevensvalidatie en beoordeling.

We hadden een tweeledige samenwerking met het AWS Data Lab. In het eerste niveau namen we deel aan een Design Lab om onze vereisten voor de korte tot lange termijn te bespreken en een best passende architectuur te creëren. We hebben de voor- en nadelen besproken van verschillende diensten die ons kunnen helpen aan die vereisten te voldoen. We hadden ook een zinvolle samenwerking met AWS-experts van verschillende AWS-services om dieper in de best practices te duiken.

Het Design Lab werd gevolgd door een Build Lab, waar we een kleinere dwarsdoorsnede van de grotere architectuur hebben genomen en een prototype in 4 dagen hebben geïmplementeerd. Tijdens het Build Lab werkten we in GDAC AWS-accounts, met behulp van GDAC-gegevens en GDAC-bronnen. Dit hielp ons niet alleen om het prototype te bouwen, maar hielp ons ook om praktische ervaring op te doen bij het bouwen ervan. Deze ervaring hielp ons ook om het product beter te onderhouden nadat we live gingen. We konden voortdurend voortbouwen op deze praktische ervaring en de kennis delen met andere bureaus in Georgië.

Onze Design and Build Lab-ervaringen worden hieronder beschreven.

Stap 1: Ontwerplab

We wilden een platform opzetten dat kan voldoen aan de gegevens- en analysebehoeften van het Georgia Data Analytics Center (GDAC) en mogelijk als gouden standaard kan dienen voor andere overheidsinstanties in Georgië. Ons doel met het AWS Data Design Lab was om een ​​architectuur te bedenken die voldoet aan de initiële databehoeften en voldoende ruimte biedt voor toekomstige uitbreiding, naarmate ons gebruikersbestand en datavolume toenam. We wilden dat elk onderdeel van de architectuur onafhankelijk zou kunnen schalen, met strengere controles op gegevenstoegang. Ons doel was om eenvoudig gegevens te kunnen verkennen met snellere responstijden met behulp van Tableau-gegevensanalyse en om gegevenskapitaal voor Georgië op te bouwen. Dit zou ons in staat stellen onze beleidsmakers in staat te stellen tijdig gegevensgestuurde beslissingen te nemen en overheidsinstanties in staat te stellen gegevens en definities binnen en tussen instanties te delen via gegevensbeheer. We hebben ook de nadruk gelegd op gegevensbeveiliging, classificatie, verduistering, auditing, monitoring, logboekregistratie en nalevingsbehoeften. We wilden speciaal gebouwde tools gebruiken die bedoeld waren voor gespecialiseerde doelen.

In de loop van het tweedaagse Design Lab hebben we onze algemene architectuur gedefinieerd en een verkleinde versie gekozen om te verkennen. Het volgende diagram illustreert de architectuur van ons prototype.

De architectuur bevat de volgende hoofdcomponenten:

• Amazon eenvoudige opslagservice (Amazon S3) voor het landen van onbewerkte gegevens en beheerde gegevensstaging.
• AWS lijm voor extraheren, transformeren en laden (ETL)-taken om gegevens in optimale indeling en lay-out van de Amazon S3-landingszone naar de door Amazon S3 beheerde zone te verplaatsen. We hebben een AWS Glue-crawler gebruikt om de AWS Glue-gegevenscatalogus bij te werken.
• AWS Stap Functies voor AWS Glue-taakorkestratie.
• Amazone Athene als een krachtige tool voor een snelle en uitgebreide SQL data-analyse en om een ​​logische laag op de landingszone te bouwen.
• Amazon roodverschuiving om een ​​federatief datawarehouse te creëren met conforme afmetingen en sterschema's voor gebruik door Tableau-gegevensanalyse.

Stap 2: Pre-Build Lab

We zijn begonnen met planningssessies om fundamentele componenten van onze infrastructuur te bouwen: AWS-accounts, Amazon Elastic Compute-cloud (Amazon EC2) instances, een Amazon Redshift-cluster, een virtual private cloud (VPC), routetabellen, beveiligingsgroepen, encryptiesleutels, toegangsregels, internetgateways, een bastionhost en meer. Daarnaast zetten we AWS Identiteits- en toegangsbeheer (IAM)-rollen en -beleid, AWS Glue-verbindingen, dev-eindpunten en notebooks. Bestanden zijn opgenomen via beveiligde FTP of vanuit een database naar Amazon S3 met behulp van AWS-opdrachtregelinterface (AWS CLI). We hebben Amazon S3 gecrawld via AWS Glue-crawlers om Data Catalog-schema's en tabellen te bouwen voor snelle SQL-toegang in Athena.

Het GDAC-team nam deel aan Immersion Days voor training in AWS Glue, AWS Lake-formatie, en Amazon Redshift ter voorbereiding op het Build Lab.

We hebben het volgende gedefinieerd als de succescriteria voor het Build Lab:

• Maak ETL-pijplijnen van bron (Amazon S3 raw) naar doel (Amazon Redshift). Deze ETL-pijplijnen moeten dimensies en feiten creëren en laden in Amazon Redshift.
• Zorg voor een mechanisme om de nauwkeurigheid te testen van de gegevens die via onze pijplijnen worden geladen.
• Stel Amazon Redshift in een privé-subnet van een VPC in, met de juiste gebruikers en rollen geïdentificeerd.
• Maak verbinding van AWS Glue naar Amazon S3 naar Amazon Redshift zonder via internet te gaan.
• Stel filtering op rijniveau in Amazon Redshift in op basis van gebruikersaanmelding.
• De indeling van gegevenspijplijnen met behulp van Step Functions.
• Bouw en publiceer Tableau-analyses met verbindingen met ons sterschema in Amazon Redshift.
• Automatiseer de implementatie met behulp van AWS CloudFormatie.
• Stel beveiliging op kolomniveau in voor de gegevens in Amazon S3 met behulp van Lake Formation. Dit maakt differentiële toegang tot gegevens op basis van gebruikersrollen mogelijk voor gebruikers die zowel Athena als Amazon Roodverschuivingsspectrum.

Stap 3: Vierdaags bouwlab

Na een reeks implementatiesessies met onze architect, vormden we het GDAC-datameer en organiseerden we downstream data pulls voor het datawarehouse met gereguleerde datatoegang. Gegevens werden opgenomen in het onbewerkte data-landingsmeer en vervolgens samengesteld in een stagingmeer, waar gegevens werden gecomprimeerd en gepartitioneerd in Parquet-indeling.

Het gaf ons de kracht om PySpark Extract Transform Loads (ETL) AWS Glue-taken te bouwen met onze nauwgezette AWS Data Lab-architect. We hebben herbruikbare lijmtaken gebouwd voor de gegevensopname en -beheer met behulp van de meegeleverde codefragmenten. De dagen waren zwaar en lang, maar we waren verheugd om te zien dat onze gecentraliseerde gegevensopslag zo snel tot wasdom kwam. Het catalogiseren van gegevens en het gebruik van Athena-query's bleek een snelle en kosteneffectieve manier te zijn voor gegevensverkenning en gegevensruzie.

Dankzij de serverloze orkestratie met Step Functions konden we AWS Glue-taken in een eenvoudig leesbare gegevensworkflow plaatsen. We hebben tijd besteed aan het ontwerpen voor prestaties en het partitioneren van gegevens om de kosten te minimaliseren en de efficiëntie te verhogen.

Databasetoegang vanuit Tableau en SQL Workbench/J werden opgezet voor mijn team. Onze opwinding werd alleen maar groter toen we begonnen met het bouwen van data-analyses en dashboards met behulp van onze dimensionale datamodellen.

Stap 4: Post-Build Lab

Tijdens onze post-Build Lab-sessie hebben we verschillende losse eindjes gesloten en extra AWS Glue-taken gebouwd voor initiële en historische belastingen en strategieën voor toevoegen versus overschrijven. Deze strategieën zijn gekozen op basis van de aard van de gegevens in verschillende tabellen. We keerden terug voor een tweede Build Lab om te werken aan het bouwen van gegevensmigratietaken vanuit Oracle Database via VPC-peering, bestandsverwerking met behulp van AWS lijm DataBrewen AWS CloudFormation voor het automatisch genereren van AWS Glue-taken. Als je een team van 4-8 bouwers hebt die op zoek zijn naar een snelle en gemakkelijke basis voor een compleet data-analysesysteem, zou ik het AWS Data Lab ten zeerste aanbevelen.

Conclusie

Al met al hebben we met een heel klein team een ​​duurzaam raamwerk op AWS-infrastructuur kunnen opzetten met elastische schaalbaarheid om toekomstige capaciteit aan te kunnen zonder afbreuk te doen aan de kwaliteit. Met dit raamwerk zijn we snel bezig met nieuwe datafeeds. Dit zou niet mogelijk zijn geweest zonder de hulp van het AWS Data Lab-team gedurende de hele levenscyclus van het project. Met deze snelle overwinning hebben we besloten om verder te gaan en te bouwen AWS-verkeerstoren met meerdere accounts in onze landingszone. We hebben professionals ingeschakeld om te helpen bij het opzetten van vangrails en beveiligingsbeleid voor infrastructuur en gegevenscompliance. We zijn verheugd om onze cloudinfrastructuur, services en data-engineeringprocessen voortdurend te verbeteren. Deze sterke initiële basis heeft de weg vrijgemaakt voor eindeloze dataprojecten in Georgië.

Over de auteur

Kanti Chalasani fungeert als divisiedirecteur voor het Georgia Data Analytics Center (GDAC) bij het Office of Planning and Budget (OPB). Kanti is verantwoordelijk voor de activiteiten op het gebied van gegevensbeheer, analyse, beveiliging, naleving en governance van GDAC. Ze streeft ernaar om samen te werken met overheidsinstanties om het delen van gegevens, datageletterdheid en gegevenskwaliteit te verbeteren via dit moderne data-engineeringplatform. Met meer dan 26 jaar ervaring in IT-beheer, hands-on datawarehousing en analyse-ervaring, gedijt ze op uitmuntendheid.

Vishal Pathak is een AWS Data Lab Solutions Architect. Vishal werkt met klanten aan hun gebruiksscenario's, ontwerpt oplossingen om hun zakelijke problemen op te lossen en helpt hen schaalbare prototypen te bouwen. Voorafgaand aan zijn reis bij AWS hielp Vishal klanten bij het implementeren van BI-, datawarehousing- en datameerprojecten in de VS en Australië.

• Coinsmart. Europa's beste Bitcoin- en crypto-uitwisseling.
• Platoblockchain. Web3 Metaverse Intelligentie. Kennis versterkt. GRATIS TOEGANG.
• CryptoHawk. Altcoin-radar. Gratis proefversie.
• Bron: https://aws.amazon.com/blogs/big-data/how-the-georgia-data-analytics-center-built-a-cloud-analytics-solution-from-scratch-with-the-aws- datalab/