Zephyrnet-logo

Migreer een bestaand datameer naar een transactioneel datameer met Apache Iceberg | Amazon-webservices

Datum:

A data lake is een gecentraliseerde opslagplaats die u kunt gebruiken om al uw gestructureerde en ongestructureerde gegevens op elke schaal op te slaan. U kunt uw gegevens opslaan zoals ze zijn, zonder dat u eerst de gegevens hoeft te structureren en vervolgens verschillende soorten analyses moet uitvoeren voor betere zakelijke inzichten. In de loop der jaren zijn er datameren ontstaan Eenvoudige opslagservice van Amazon (Amazon S3) zijn de standaardopslagplaats voor bedrijfsgegevens geworden en zijn een gebruikelijke keuze voor een grote groep gebruikers die gegevens opvragen voor een verscheidenheid aan analyses en machine-leunende gebruiksscenario's. Met Amazon S3 heb je toegang tot diverse datasets, kun je business intelligence-dashboards bouwen en het dataverbruik versnellen door een moderne data-architectuur or gegevensgaas patroon aan Amazon Web Services (AWS).

Analytics-gebruiksscenario's op datameren zijn voortdurend in ontwikkeling. Vaak wilt u voortdurend gegevens uit verschillende bronnen in een datameer opnemen en de gegevens tegelijkertijd opvragen via meerdere analysetools met transactionele mogelijkheden. Maar traditioneel zijn datameren die op Amazon S3 zijn gebouwd onveranderlijk en bieden ze niet de transactionele mogelijkheden die nodig zijn om veranderende gebruiksscenario's te ondersteunen. Met veranderende gebruiksscenario's zoeken klanten naar manieren om niet alleen nieuwe of incrementele gegevens als transacties naar datameren te verplaatsen, maar ook om bestaande gegevens te converteren op basis van Apache Parket naar een transactioneel formaat. Open tabelformaten, zoals Apache-ijsberg, een oplossing bieden voor dit probleem. Apache Iceberg maakt transacties op datameren mogelijk en kan de opslag, het beheer, de opname en de verwerking van gegevens vereenvoudigen.

In dit bericht laten we u zien hoe u bestaande gegevens in een Amazon S3-datameer in Apache Parquet-indeling naar Apache Iceberg-indeling kunt converteren om transacties op de gegevens te ondersteunen met behulp van Op Jupyter Notebook gebaseerde interactieve sessies over AWS-lijm 4.0.

Bestaande migratie van Parquet naar Ijsberg

Er zijn twee brede methoden om de bestaande gegevens in een data lake in Apache Parquet-indeling naar Apache Iceberg-indeling te migreren om het datameer naar een transactionele tabelindeling te converteren.

Gegevensupgrade ter plaatse

Bij een interne datamigratiestrategie worden bestaande datasets geüpgraded naar het Apache Iceberg-formaat zonder eerst de bestaande data opnieuw te verwerken of opnieuw te formuleren. Dit betekent dat de gegevensbestanden in het datameer niet worden gewijzigd tijdens de migratie en dat alle metagegevensbestanden van Apache Iceberg (manifesten, manifestbestanden en tabelmetagegevensbestanden) buiten het bereik van de gegevens worden gegenereerd. Bij deze methode worden de metadata opnieuw aangemaakt in een geïsoleerde omgeving en op dezelfde locatie geplaatst als de bestaande gegevensbestanden. Dit kan een veel goedkopere operatie zijn vergeleken met het herschrijven van alle gegevensbestanden. De bestaande gegevensbestandsindeling moet Apache Parquet, Apache ORC of Apache Avro zijn. Een in-place migratie kan op twee manieren worden uitgevoerd:

  1. gebruik bestanden toevoegen: deze procedure voegt bestaande gegevensbestanden toe aan een bestaande ijsbergtabel met een nieuwe momentopname die de bestanden bevat. In tegenstelling tot migreren of momentopnamen, add_files kan bestanden importeren van een specifieke partitie of partities en maakt geen nieuwe ijsbergtabel. Met deze procedure wordt het schema van de bestanden niet geanalyseerd om te bepalen of ze overeenkomen met het schema van de ijsbergtabel. Na voltooiing behandelt de Iceberg-tabel deze bestanden alsof ze deel uitmaken van de set bestanden die eigendom zijn van Apache Iceberg.
  2. gebruik trekken: deze procedure vervangt een tabel door een Apache Iceberg-tabel die is geladen met de gegevensbestanden van de bron. Het schema, de partities, de eigenschappen en de locatie van de tabel worden gekopieerd uit de brontabel. Ondersteunde formaten zijn Avro, Parquet en ORC. Standaard blijft de oorspronkelijke tabel behouden met de naam table_BACKUP_. Om de oorspronkelijke tabel tijdens het proces echter intact te laten, moet u momentopname gebruiken om een ​​nieuwe tijdelijke tabel te maken die dezelfde brongegevensbestanden en hetzelfde schema heeft.

In dit bericht laten we je zien hoe je de Iceberg kunt gebruiken add_files procedure voor een interne data-upgrade. Merk op dat de migrate procedure wordt niet ondersteund in AWS Glue Data Catalog.

Het volgende diagram toont een weergave op hoog niveau.

CTAS-migratie van gegevens

De CTAS-migratieaanpak (create table as select) is een techniek waarbij alle metadata-informatie voor Iceberg wordt gegenereerd samen met het opnieuw samenstellen van alle gegevensbestanden. Deze methode schaduwt de brongegevensset in batches. Wanneer de schaduw is ingehaald, kunt u de geschaduwde gegevensset verwisselen met de bron.

Het volgende diagram toont de stroom op hoog niveau.

Voorwaarden

Om de walkthrough te volgen, moet u over het volgende beschikken:

U kunt de gegevensgrootte controleren met behulp van de volgende code in de AWS CLI of AWS-cloudshell:

//Run this command to check the data size aws s3 ls --summarize --human-readable --recursive s3://noaa-ghcn-pds/parquet/by_year/YEAR=2023

Op het moment dat dit bericht wordt geschreven, bevinden zich 107 objecten met een totale grootte van 70 MB voor het jaar 2023 in het Amazon S3-pad.

Houd er rekening mee dat u, om de oplossing te implementeren, een aantal voorbereidende stappen moet voltooien.

Resources implementeren met AWS CloudFormation

Voer de volgende stappen uit om de S3-bucket en de AWS IAM-rol en het beleid voor de oplossing te maken:

  1. Meld u aan bij uw AWS-account en kies vervolgens Launch Stack om de CloudFormation-sjabloon te starten.

  1. Voor Stack naam, voer een naam in.
  2. Laat de parameters op de standaardwaarden staan. Houd er rekening mee dat als de standaardwaarden worden gewijzigd, u tijdens de volgende stappen overeenkomstige wijzigingen moet aanbrengen.
  3. Kies Volgende om uw stapel te creëren.

Deze AWS CloudFormatie sjabloon implementeert de volgende bronnen:

  • Een S3-bucket met de naam demo-blog-post-XXXXXXXX (XXXXXXXX vertegenwoordigt de gebruikte AWS-account-ID).
  • Twee mappen met de naam parquet en iceberg onder de emmer.
  • Een IAM-rol en een benoemd beleid demoblogpostrole en demoblogpostscoped respectievelijk.
  • An AWS Glue-database genoemd ghcn_db.
  • An AWS lijmcrawler genoemd demopostcrawlerparquet.

Nadat de AWS CloudFormation-sjabloon succesvol is geïmplementeerd:

  1. Kopieer de gegevens in de gemaakte S3-bucket met behulp van de volgende opdracht in AWS CLI of AWS-cloudshell. Vervangen XXXXXXXX op de juiste manier in de doel-S3-bucketnaam.
    Opmerking: In het voorbeeld kopiëren we alleen gegevens voor het jaar 2023. U kunt echter met de gehele dataset werken, waarbij u dezelfde instructies volgt.
    aws s3 sync s3://noaa-ghcn-pds/parquet/by_year/YEAR=2023/ s3://demo-blog-post-XXXXXXXX/parquet/year=2023

  2. Open de AWS Management Console en ga naar de AWS Glue-console.
  3. Selecteer in het navigatievenster crawlers.
  4. Voer de crawler met de naam uit demopostcrawlerparquet.
  5. Na de AWS Glue-crawler demopostcrawlerparquet succesvol is uitgevoerd, wordt de metagegevensinformatie van de Apache Parquet-gegevens gecatalogiseerd onder de ghcn_db AWS Glue-database met de tabelnaam source_parquet. Merk op dat de tabel is gepartitioneerd year en element kolommen (zoals in de S3-bucket).

  1. Gebruik de volgende query om de gegevens uit het Amazone Athene troosten. Als u Amazon Athena voor het eerst gebruikt in uw AWS-account, stelt u een locatie van queryresultaat in Amazon S3.
    SELECT * FROM ghcn_db.source_parquet limit 10;

Start een AWS Glue Studio-notebook voor verwerking

Voor dit bericht gebruiken we een AWS Glue Studio-notebook. Volg de stappen binnen Aan de slag met notebooks in AWS Glue Studio om de notebookomgeving in te stellen. Start de notebooks die hieronder worden gehost link en pak ze uit op een lokaal werkstation.

  1. Open AWS-lijmstudio.
  2. Kies ETL-banen.
  3. Kies Jupyter notitieboek en kies dan Upload en bewerk een bestaand notitieboek. Van Kies bestand, selecteer vereist ipynb bestand en kies Openen, kies dan creëren.
  4. Op de Notebook instellen pagina, voor Taaknaam, voer een logische naam in.
  5. Voor IAM-rolselecteer demoblogpostrole. Kiezen Baan creëren. Na een minuut verschijnt de Jupyter-notitieboekjeeditor. Wis alle standaardcellen.

Met de voorgaande stappen wordt een AWS Glue Studio-notebookomgeving gestart. Zorg ervoor dat je Bespaar de notebook telkens wanneer deze wordt gebruikt.

Gegevensupgrade ter plaatse

In deze sectie laten we u zien hoe u de add_files procedure om een ​​interne data-upgrade te realiseren. In deze sectie wordt gebruik gemaakt van de ipynb bestand met de naam demo-in-place-upgrade-addfiles.ipynb. Te gebruiken met de add_files procedure, voert u het volgende uit:

  1. Op de Notebook instellen pagina, voor Taaknaam, ga naar binnen demo-in-place-upgrade voor de notebooksessie zoals uitgelegd in Lanceer Glue-notitieboekje voor verwerking.
  2. Voer de cellen onder de sectie uit Configuraties van lijmsessies. Geef de S3-bucketnaam op uit de vereisten voor het bucket_name variabel door te vervangen XXXXXXXX.
  3. Voer de volgende cellen in het notitieblok uit.

Merk op dat de cel eronder Voer de add_files-procedure uit sectie voert de creatie van metagegevens uit in het genoemde pad.

Bekijk de gegevensbestandspaden voor de nieuwe Iceberg-tabel. Om een ​​te tonen De huidige gegevensbestanden van de ijsbergtabel, .files kan worden gebruikt om details te verkrijgen, zoals file_path, partition, en anderen. Opnieuw gemaakte bestanden verwijzen naar het bronpad onder Amazon S3.

Noteer de locatie van het metadatabestand na transformatie. Het verwijst naar de nieuwe map met de naam iceberg onder Amazon S3. Dit kun je controleren met behulp van .snapshots om te controleren Locatie van het momentopnamebestand van ijsbergtabellen. Controleer hetzelfde ook in de Amazon S3 URI s3://demo-blog-post-XXXXXXXX/iceberg/ghcn_db.db/target_iceberg_add_files/metadata/. Merk ook op dat er twee versies van de manifestlijst zijn gemaakt na de add_files procedure is gelopen. De eerste is een lege tabel met het gegevensschema en de tweede is het toevoegen van de bestanden.

De tabel is gecatalogiseerd in AWS Glue onder de database ghcn_db met het tabeltype als ICEBERG.

Vergelijk het aantal records met Amazon Athena tussen de bron- en doeltabel. Ze zijn hetzelfde.

Kortom, u kunt gebruik maken van de add_files procedure om bestaande gegevensbestanden in Apache Parquet-indeling in een datameer naar Apache Iceberg-indeling te converteren door de metagegevensbestanden toe te voegen en zonder de tabel helemaal opnieuw te maken. Hieronder volgen enkele voor- en nadelen van deze methode.

VOORDELEN

  • Vermijdt volledige tabelscans om de gegevens te lezen, omdat er geen herformulering is. Dit kan tijd besparen.
  • Als er fouten optreden tijdens het schrijven van de metagegevens, is alleen het herschrijven van de metagegevens vereist en niet de volledige gegevens.
  • De lijn van de bestaande banen blijft behouden omdat de bestaande catalogus nog steeds bestaat.

NADELEN

  • Als gegevens in de gegevensset worden verwerkt (invoegingen, updates en verwijderingen) tijdens het schrijfproces van de metagegevens, moet het proces opnieuw worden uitgevoerd om de nieuwe gegevens op te nemen.
  • Er moet sprake zijn van schrijfuitval om te voorkomen dat het proces een tweede keer moet worden uitgevoerd.
  • Als een herformulering van de gegevens vereist is, werkt deze workflow niet omdat de brongegevensbestanden niet worden gewijzigd.

CTAS-migratie van gegevens

Dit gedeelte maakt gebruik van de ipynb bestand met de naam demo-ctas-upgrade.ipynb. Voltooi het volgende:

  1. Op de Notebook instellen pagina, voor Taaknaam, ga naar binnen demo-ctas-upgrade voor de notebooksessie zoals uitgelegd onder Lanceer Glue-notitieboekje voor verwerking.
  2. Voer de cellen onder de sectie uit Configuraties van lijmsessies. Geef de S3-bucketnaam op uit de vereisten voor het bucket_name variabel door te vervangen XXXXXXXX.
  3. Voer de volgende cellen in het notitieblok uit.

Merk op dat de cel eronder Maak een ijsbergtafel van parket sectie voert de schaduwupgrade naar Iceberg-formaat uit. Houd er rekening mee dat Iceberg vereist dat de gegevens worden gesorteerd op basis van tabelpartities voordat ze naar de Iceberg-tabel worden geschreven. Verdere details zijn te vinden in Distributiemodi schrijven.

Let op de gegevens- en metadatabestandspaden voor de nieuwe Iceberg-tabel. Het wijst naar het nieuwe pad onder Amazon S3. Controleer ook onder de Amazon S3 URI s3://demo-blog-post-XXXXXXXX/iceberg/ghcn_db.db/target_iceberg_ctas/ gebruikt voor dit bericht.

De tabel is gecatalogiseerd onder AWS Glue onder de database ghcn_db met het tabeltype als ICEBERG.

Vergelijk het aantal records met Amazon Athena tussen de bron- en doeltabel. Ze zijn hetzelfde.

Samengevat, de CTAS methode maakt een nieuwe tabel door alle metadatabestanden te genereren en de feitelijke gegevens opnieuw te formuleren. Hieronder volgen enkele voor- en nadelen van deze methode:

VOORDELEN

  • Hiermee kunt u de gegevens tijdens het proces controleren en valideren, omdat de gegevens opnieuw worden geformuleerd.
  • Als er runtimeproblemen optreden tijdens het migratieproces, kunnen rollback en herstel eenvoudig worden uitgevoerd door de Apache Iceberg-tabel te verwijderen.
  • Bij het migreren van een bron kunt u verschillende configuraties testen. U kunt voor elke configuratie een nieuwe tabel maken en de impact evalueren.
  • Schaduwgegevens worden hernoemd naar een andere map in de bron (zodat deze niet botsen met oude Apache Parquet-gegevens).

NADELEN

  • De opslag van de dataset wordt tijdens het proces verdubbeld, omdat zowel de originele Apache Parquet als de nieuwe Apache Iceberg-tabellen aanwezig zijn tijdens de migratie- en testfase. Hiermee moet rekening worden gehouden bij de kostenraming.
  • De migratie kan veel langer duren (afhankelijk van de hoeveelheid data) omdat zowel data als metadata worden geschreven.
  • Het is moeilijk om tabellen gesynchroniseerd te houden als er tijdens het proces wijzigingen in de brontabel optreden.

Opruimen

Om toekomstige kosten te voorkomen en om ongebruikte rollen en beleidsregels op te schonen, verwijdert u de bronnen die u hebt gemaakt: de datasets, CloudFormation-stack, S3-bucket, AWS Glue-taak, AWS Glue-database en AWS Glue-tabel.

Conclusie

In dit bericht heb je strategieën geleerd voor het migreren van bestaande Apache Parquet-geformatteerde gegevens naar Apache Iceberg in Amazon S3 om ze te converteren naar een transactioneel datameer met behulp van interactieve sessies in AWS Glue 4.0 om de processen te voltooien. Als u een evoluerend gebruiksscenario heeft waarbij een bestaand datameer moet worden geconverteerd naar een transactioneel datameer op basis van de Apache Iceberg-tabelindeling, volgt u de richtlijnen in dit bericht.

Het pad dat u kiest voor deze upgrade, een in-place upgrade of CTAS-migratie, of een combinatie van beide, zal afhangen van een zorgvuldige analyse van de data-architectuur en de data-integratiepijplijn. Beide trajecten hebben voor- en nadelen, zoals besproken. Op een hoog niveau zou dit upgradeproces meerdere goed gedefinieerde fasen moeten doorlopen om de patronen van data-integratie en gebruiksscenario's te identificeren. Het kiezen van de juiste strategie hangt af van uw vereisten, zoals prestaties, kosten, recentheid van de gegevens, aanvaardbare downtime tijdens de migratie, enzovoort.


Over de auteur

Rajdip Chaudhuri is een Senior Solutions Architect bij Amazon Web Services, gespecialiseerd in data en analyse. Hij werkt graag samen met AWS-klanten en -partners aan data- en analysevereisten. In zijn vrije tijd houdt hij van voetbal en films.

spot_img

Laatste intelligentie

spot_img