Inzicht in bestandsindelingen en structuur voor een modern datawarehouse

Voltooid

Wanneer u gegevens in uw datawarehouse laadt, variëren de bestandstypen en methoden voor het opnemen van de gegevens per bron. Het laden van gegevens uit on-premises bestandssystemen, relationele gegevensarchieven of streaminggegevensbronnen vereisen bijvoorbeeld verschillende benaderingen van opname in het data lake of tussenliggende gegevensarchief, om verfijnde gegevens in de ondersteunende laag te plaatsen. Het is belangrijk om inzicht te hebben in de verschillende bestandstypen en welke u moet gebruiken voor onbewerkte opslag versus verfijnde versies voor analytische query's. Andere ontwerpoverwegingen zijn hiërarchische structuren voor het optimaliseren van query's en activiteiten voor het laden van gegevens. In deze les worden de bestandstypen en hun optimale gebruiksvoorbeelden beschreven en hoe u ze het beste in uw Data Lake kunt ordenen.

Ondersteunde bestandsindelingen voor het opnemen van onbewerkte gegevens in batch

In data engineering beschrijven we de snelheid van het laden van gegevens meestal als een van de drie latenties:

• Batch: Query's of programma's die tientallen minuten, uren of dagen in beslag nemen. Activiteiten kunnen bestaan uit initiële gegevens wrangling, volledige ETL-pijplijn of voorbereiding voor downstreamanalyses.
• Interactieve query: Query's uitvoeren op batchgegevens op 'menselijke' interactieve snelheden, wat met de huidige generatie technologieën betekent dat resultaten gereed zijn in tijdsbestekken die in seconden tot minuten worden gemeten.
• Realtime/bijna realtime: Verwerking van een doorgaans oneindige stroom invoergegevens (stroom), waarvan de tijd totdat de resultaten gereed zijn kort is, gemeten in milliseconden of seconden in de langste gevallen.

Als het gaat om het opnemen van onbewerkte gegevens in batch vanuit nieuwe gegevensbronnen, worden deze gegevensindelingen systeemeigen ondersteund door Synapse:

• CSV
• Parquet
• ORC
• JSON

Als u Echter Apache Spark gebruikt met Synapse Notebooks, kunt u meer bestandstypen voor uw onbewerkte gegevens verkennen en verwerken.

Streaminggegevens opnemen in toegewezen SQL-pools van Synapse

Het verwerken van gegevens die binnenkomen bij de derde latentie (realtime/bijna realtime) wordt ook wel streaminggegevensverwerking genoemd. Streaminggegevensbronnen kunnen IoT-apparaten en -sensoren, financiële transacties, gegevens van webklikken, factory's en medische apparaten zijn, om er enkele te noemen.

Azure biedt speciaal gebouwde stroomopnameservices zoals Azure IoT Hub en Azure Event Hubs (met of zonder Kafka-ondersteuning) die robuust, bewezen en performant zijn. In uw gegevenspijplijn moet u berichten van deze of vergelijkbare services verzamelen en verwerken met behulp van Azure Stream Analytics, Azure Functions, Azure Databricks of andere services waarmee u streaminggegevens kunt opnemen en verwerken.

Het is mogelijk uw doel om deze gegevens in uw Data Lake te zetten, zoals het Azure Data Lake Storage Gen2-account dat is gekoppeld aan uw Synapse Analytics-werkruimte, en vervolgens Synapse Spark-notebooks of T-SQL-query's te gebruiken met een serverloze SQL-pool om de gegevens te verkennen en te transformeren. In dit geval slaat u die gegevens waarschijnlijk op in een van de onbewerkte indelingen, zoals CSV of JSON. Azure Stream Analytics vereenvoudigt deze taak door verbinding te maken met IoT Hub of Event Hubs als invoerbron en bestanden uit te voeren naar het ADLS Gen2-opslagaccount als uitvoer. U kunt een padpatroon opgeven waarmee u uw gegevens kunt structuren voor optimale analytische workloads door op pad gebaseerde gegevens te verwijderen. U kunt bijvoorbeeld het volgende padpatroon instellen voor de ADLS Gen2-uitvoer: tran/sensor/{datetime:yyyy}/{datetime:MM}/{datetime:dd}. Met verdere opties kunt u de serialisatie instellen, zoals JSON, codering, zoals UTF-8, minimumaantal rijen per bestand, zoals 100, enzovoort.

Als u echter de streaminggegevens in een toegewezen SQL-pool wilt landen, kunt u een aantal opties gebruiken om de gegevens eerst te verwerken en op te slaan in uw Data Lake, zoals hierboven beschreven. Laad de gegevens vervolgens in een toegewezen SQL-pool via een van de verschillende technieken voor het laden van gegevens, zoals Synapse Pipelines, Synapse Spark-pools of COPY-instructies. Hiermee kunt u de data lake gebruiken als faseringsgebied of de onbewerkte indeling in de data lake behouden, naast een meer verfijnde versie van de gegevens in de toegewezen SQL-pool.

Een andere optie is om Azure Stream Analytics te gebruiken met een Azure Synapse Analytics (toegewezen SQL-pool) als uitvoersink voor gegevensopname met hoge doorvoer met Azure Stream Analytics-taken.

Zodra u de Synapse Analytics-uitvoer hebt gemaakt, kunt u deze instellen als het doel in de Stream Analytics-query. In het onderstaande voorbeeld hebben we een Event Hubs-invoer met de naam CallStreamen een Synapse Analytics-uitvoer met de naam sqlpool-demo-asaoutput. Met de SQL-query worden alle binnenkomende gegevens rechtstreeks naar de toegewezen SQL-pool geschreven. U kunt ook alleen specifieke eigenschappen selecteren en de gegevenstypen uit de binnenkomende stroom transformeren en een van de vensterfuncties gebruiken om gegevens samen te voegen voordat u deze naar de toegewezen SQL-pool schrijft.

Met Stream Analytics met Synapse Analytics kunt u op deze manier uw toegewezen SQL-pooldatabase en -tabel selecteren waarin de Stream Analytics-query de streaminggegevens schrijft. Deze systeemeigen stroomopname is geoptimaliseerd om de gegevens snel rechtstreeks naar de toegewezen SQL-pool te schrijven zonder eerst de gegevens ergens anders te hoeven landen.

Aanbevolen bestandstypen

Onbewerkte gegevens

Voor onbewerkte gegevens wordt aanbevolen dat gegevens worden opgeslagen in de systeemeigen indeling. Gegevens uit relationele databases moeten doorgaans worden opgeslagen in CSV-indeling. Dit is de indeling die wordt ondersteund door de meeste systemen, dus het biedt de grootste flexibiliteit.

Voor gegevens uit web-API's en NoSQL-databases is JSON de aanbevolen indeling.

Verfijnde versies voor gegevens

Als het gaat om het opslaan van verfijnde versies van de gegevens voor mogelijke query's, is Parquet de aanbevolen gegevensindeling.

Er is afstemming in de branche rond de Parquet-indeling voor het delen van gegevens op de opslaglaag (bijvoorbeeld in hadoop-, Databricks- en SQL-enginescenario's). Parquet is een hoogwaardige, kolomgeoriënteerde indeling die is geoptimaliseerd voor big data-scenario's.

Kolomindelingen zoals Parquet hebben voordelen voor opslag en prestaties. De waarden worden gegroepeerd op kolom, zodat de compressie efficiënter is (om de opslagvoetafdruk te verkleinen), en een query-engine kan kolomprojecties omlaag pushen (om lees-I/O van het netwerk en schijf te verminderen door ongewenste kolommen over te slaan), ook wel kolomsnoeien genoemd. Vergelijkbare gegevenstypen (voor een kolom) worden samen opgeslagen in Parquet-bestanden, wat leidt tot efficiënte gegevenscompressie- en coderingsschema's.

Parquet slaat het bestandsschema op in de metagegevens van het bestand. CSV-bestanden slaan geen metagegevens van bestanden op, dus lezers moeten worden opgegeven met het schema of het schema moet worden afgeleid. Het leveren van een schema is tijdrovend en het uitstellen van een schema is foutgevoelig/duur.

Bestandsstructuur organiseren voor analytische query's

Het eerste wat u moet overwegen bij het opnemen van gegevens in de data lake, is het structureren of organiseren van gegevens in de data lake. U moet Azure Data Lake Storage (ADLS) Gen2 (in Azure Portal) gebruiken. Dit is een Azure Storage-account waarvoor een hiërarchische naamruimte is ingeschakeld.

Een belangrijk mechanisme dat ADLS Gen2 biedt voor de prestaties van het bestandssysteem op het gebied van objectopslag en prijzen, naast een hiërarchische naamruimte. Hierdoor kan de verzameling objecten/bestanden binnen een account worden ingedeeld in een hiërarchie van mappen en geneste submappen op dezelfde manier als het bestandssysteem op uw computer is georganiseerd. Als een hiërarchische naamruimte is ingeschakeld, kan een opslagaccount de schaalbaarheid en kosteneffectiviteit van objectopslag bieden, met semantiek van het bestandssysteem die bekend zijn met analyse-engines en frameworks.

In ADLS Gen2 is het een best practice om een toegewezen opslagaccount te hebben voor productie en een afzonderlijk opslagaccount voor ontwikkel- en testworkloads. Dit zorgt ervoor dat ontwikkel- of testworkloads nooit de productie verstoren.

Een veelgebruikte methode voor het structureren van mappen in een data lake is het ordenen van gegevens in afzonderlijke mappen door de mate van verfijning. Een bronsmap kan bijvoorbeeld onbewerkte gegevens bevatten, zilver bevat de opgeschoonde, voorbereide en geïntegreerde gegevens, en goud bevat gegevens die gereed zijn om analyses te ondersteunen, waaronder uiteindelijke verfijningen, zoals vooraf berekende aggregaties. Als er meer verfijningsniveaus vereist zijn, kan deze structuur indien nodig worden gewijzigd om meer mappen op te nemen.

Wanneer u met Data Lake Storage Gen2 werkt, moet het volgende worden overwogen:

• Wanneer gegevens worden opgeslagen in Data Lake Storage Gen2, hebben de bestandsgrootte, het aantal bestanden en de mapstructuur invloed op de prestaties.
• Als u uw gegevens zo veel kleine bestanden opslaat, kan dit de prestaties negatief beïnvloeden. In het algemeen kunt u uw gegevens ordenen in grotere bestanden voor betere prestaties (256 MB tot 100 GB).
• Sommige engines en toepassingen kunnen problemen hebben bij het efficiënt verwerken van bestanden die groter zijn dan 100 GB.
• Soms hebben gegevenspijplijnen beperkte controle over de onbewerkte gegevens, die veel kleine bestanden bevatten. Het wordt aanbevolen om een 'kookproces' te hebben waarmee grotere bestanden worden gegenereerd die moeten worden gebruikt voor downstreamtoepassingen.