Data Lake-zones en -containers
Het is belangrijk om uw gegevensstructuur te plannen voordat u deze in een data lake terechtkomt. Wanneer u een plan hebt, kunt u effectief gebruikmaken van beveiliging, partitionering en verwerking.
Zie Overzicht van Azure Data Lake Storage voor analyses op cloudschaal voor een overzicht van data lakes.
Overzicht
Uw drie Data Lake-accounts moeten zijn afgestemd op de typische Data Lake-lagen.
| Lakenummer | Lagen | Containernummer | Containernaam |
|---|---|---|---|
| 1 | Onbewerkt | 1 | Landing |
| 1 | Onbewerkt | 2 | Conformiteit |
| 2 | Verrijkt | 1 | Gestandaardiseerde |
| 2 | Gecureerd | 2 | Gegevensproducten |
| 3 | Ontwikkeling | 1 | Analytics-sandbox |
| 3 | Ontwikkeling | # | Primaire opslagnummer van Synapse |
In de vorige tabel ziet u het standaardaantal containers dat per datalandingszone wordt aanbevolen. De uitzondering op deze aanbeveling is als er verschillende beleidsregels voor voorlopig verwijderen vereist zijn voor de gegevens in een container. Deze vereisten bepalen uw behoefte aan meer containers.
Notitie
In elke datalandingszone worden drie data lakes geïllustreerd. De data lake bevindt zich tussen drie data lake-accounts, meerdere containers en mappen, maar het vertegenwoordigt één logische data lake voor uw datalandingszone.
Afhankelijk van uw vereisten wilt u mogelijk onbewerkte, verrijkte en gecureerde lagen samenvoegen in één opslagaccount. Bewaar een ander opslagaccount met de naam 'ontwikkeling' voor gegevensgebruikers om andere nuttige gegevensproducten mee te nemen.
Zie Storage-accounts in een logische data lake voor meer informatie over het scheiden van Data Lake-accounts.
Schakel Azure Storage in met de hiërarchische functie voor naamruimte, waarmee u bestanden efficiënt kunt beheren. Met de hiërarchische naamruimtefunctie worden objecten en bestanden binnen een account ingedeeld in een hiërarchie van mappen en geneste submappen. Deze hiërarchie is op dezelfde manier georganiseerd als het bestandssysteem op uw computer.
Wanneer uw gegevensagnostische opname-engine of onboarding-toepassing een nieuw recordsysteem registreert, worden vereiste mappen gemaakt in containers in de onbewerkte, verrijkte en gestandaardiseerde gegevenslagen. Als een gegevenstoepassing die is afgestemd op een bron de gegevens opneemt, heeft uw gegevenstoepassingsteam uw team voor gegevenslandingszones nodig om de mappen en beveiligingsgroepen te maken. Plaats een service-principalnaam of beheerde identiteit in de juiste groep en wijs een machtigingsniveau toe. Documenteer dit proces voor uw datalandingszone en gegevenstoepassingsteams.
Zie Rollen en teams begrijpen voor analyses op cloudschaal in Azure voor meer informatie over teams.
Elk gegevensproduct moet twee mappen bevatten in de container met gegevensproducten die eigendom is van uw gegevensproductteam.
In de verrijkte laag van een gestandaardiseerde container zijn er twee mappen per bronsysteem, gedeeld door classificatie. Met deze structuur kan uw team gegevens met verschillende beveiligings- en gegevensclassificaties afzonderlijk opslaan en ze verschillende beveiligingstoegang toewijzen.
Uw gestandaardiseerde container heeft een algemene map nodig voor vertrouwelijke of onderliggende gegevens en een gevoelige map voor persoonlijke gegevens. Toegang tot deze mappen beheren met behulp van toegangsbeheerlijsten (ACL's). U kunt een gegevensset maken waarin alle persoonlijke gegevens zijn verwijderd en deze opslaan in uw algemene map. U kunt een andere gegevensset hebben die alle persoonlijke gegevens in uw map met gevoelige persoonlijke gegevens bevat.
Een combinatie van ACL's en Microsoft Entra-groepen beperken de toegang tot gegevens. Deze lijsten en groepen bepalen wat andere groepen wel en niet kunnen openen. Gegevenseigenaren en datatoepassingsteams kunnen de toegang tot hun gegevensassets goedkeuren of afwijzen.
Zie Gegevenstoegangsbeheer en beperkte gegevens voor meer informatie.
Waarschuwing
Sommige softwareproducten bieden geen ondersteuning voor het koppelen van de hoofdmap van een Data Lake-container. Vanwege deze beperking moet elke Data Lake-container in onbewerkte, gecureerde, verrijkte en ontwikkelingslagen één map bevatten die vertakt naar meerdere mappen. Stel uw mapmachtigingen zorgvuldig in. Wanneer u een nieuwe map maakt vanuit de hoofdmap, bepaalt de standaard-ACL in de bovenliggende map de standaard-ACL en toegangs-ACL van een onderliggende map. De ACL van een onderliggend bestand heeft geen standaard-ACL.
Zie Toegangsbeheerlijsten (ACL's) in Azure Data Lake Storage Gen2 voor meer informatie.
Onbewerkte laag of data lake één
Denk aan de onbewerkte laag als een reservoir waarin gegevens in de natuurlijke en oorspronkelijke staat worden opgeslagen. Het is niet gefilterd en niet-gepurificeerd. U kunt de gegevens opslaan in de oorspronkelijke indeling, zoals JSON of CSV. Of het kan rendabel zijn om de bestandsinhoud op te slaan als een kolom in een gecomprimeerde bestandsindeling, zoals Avro, Parquet of Databricks Delta Lake.
Deze onbewerkte gegevens zijn onveranderbaar. Houd uw onbewerkte gegevens vergrendeld en als u machtigingen geeft aan alle consumenten, geautomatiseerd of menselijk, moet u ervoor zorgen dat ze alleen-lezen zijn. U kunt deze laag organiseren met behulp van één map per bronsysteem. Geef elk opnameproces schrijftoegang tot alleen de bijbehorende map.
Wanneer u gegevens uit bronsystemen in de onbewerkte zone laadt, kunt u ervoor kiezen om het volgende te doen:
- Volledige laadt om een volledige gegevensset te extraheren.
- Delta wordt geladen om alleen gewijzigde gegevens te laden.
Geef het gekozen laadpatroon in uw mapstructuur aan om het gebruik voor uw gegevensgebruikers te vereenvoudigen.
Onbewerkte gegevens uit bronsystemen voor elke op de bron afgestemde gegevenstoepassing of geautomatiseerde opname-enginebron komt terecht in de volledige map of de deltamap. Elk opnameproces moet schrijftoegang hebben tot alleen de bijbehorende map.
De verschillen tussen volledige belastingen en deltabelastingen zijn:
Volledige belasting : volledige gegevens uit de bron kunnen worden ge onboardd als:
- Het gegevensvolume bij de bron is klein.
- Het bronsysteem onderhoudt geen tijdstempelveld dat aangeeft of gegevens zijn toegevoegd, bijgewerkt of verwijderd.
- Het bronsysteem overschrijft de volledige gegevens telkens.
Deltabelasting : incrementele gegevens uit de bron kunnen worden ge onboardd als:
- Het gegevensvolume bij de bron is groot.
- Het bronsysteem onderhoudt een tijdstempelveld dat aangeeft of gegevens zijn toegevoegd, bijgewerkt of verwijderd.
- Het bronsysteem maakt en werkt bestanden bij op gegevenswijzigingen.
Uw onbewerkte data lake bestaat uit uw landings- en conformheidscontainers. Elke container maakt gebruik van een verplichte mapstructuur van 100% die specifiek is voor het doel ervan.
Indeling van landingscontainer
Uw landingscontainer is gereserveerd voor onbewerkte gegevens die afkomstig zijn van een herkend bronsysteem. Uw gegevensagnostische opname-engine of een op de bron afgestemde gegevenstoepassing laadt de gegevens, wat ongewijzigd is en in de oorspronkelijke ondersteunde indeling.
.
|-Landing
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------{date (ex. rundate=2019-08-22)}
|------Full
Container voor conformheid van onbewerkte lagen
De onbewerkte laag bevat gegevenskwaliteit die aan de gegevens voldoet. Wanneer gegevens naar een landingscontainer worden gekopieerd, worden gegevensverwerking en computing geactiveerd om de gegevens van de landingscontainer naar de conforme container te kopiëren. In deze eerste fase worden gegevens geconverteerd naar de Delta Lake-indeling en terechtkomen ze in een invoermap. Wanneer de gegevenskwaliteit wordt uitgevoerd, worden records die worden gekopieerd naar de uitvoermap gekopieerd. Records die niet in een foutmap terechtkomen.
.
|-Conformance
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------Delta
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
|------Full
|-------Input
|--------{date (ex. rundate=2019-08-22)}
|-------Output
|--------{date (ex. rundate=2019-08-22)}
|-------Error
|--------{date (ex. rundate=2019-08-22)}
Fooi
Denk na over scenario's waarin u mogelijk een volledig nieuw analyseplatform moet bouwen. Houd rekening met de meest gedetailleerde gegevens die u nodig hebt om downstream-leesgegevensarchieven opnieuw op te bouwen. Zorg ervoor dat u een plan voor bedrijfscontinuïteit en herstel na noodgevallen hebt voor uw belangrijkste onderdelen.
Verrijkte laag of data lake twee
Denk aan de verrijkte laag als een filtratielaag. Het verwijdert onzuiverheden en kan ook verrijking omvatten.
Uw standaardisatiecontainer bevat systemen met records en masters. Mappen worden eerst gesegmenteerd op onderwerpgebied en vervolgens op entiteit. Gegevens zijn beschikbaar in samengevoegde, gepartitioneerde tabellen die zijn geoptimaliseerd voor analyseverbruik.
Gestandaardiseerde container
.
|-Standardized
|--Log
|---{Application Name}
|--Master and Reference
|---{Source System}
|--Telemetry
|---{Source System}
|----{Application}
|--Transactional
|---{Source System}
|----{Entity}
|-----{Version}
|------General
|--------{date (ex. rundate=2019-08-22)}
|-------Sensitive
|--------{date (ex. rundate=2019-08-22)}
Notitie
Deze gegevenslaag wordt beschouwd als de zilveren laag of leesgegevensbron. Gegevens binnen deze laag hebben geen andere transformaties toegepast dan gegevenskwaliteit, delta lake-conversie en uitlijning van gegevenstypen.
In het volgende diagram ziet u de stroom van data lakes en containers van brongegevens naar een gestandaardiseerde container.
Gecureerde laag of data lake twee
Uw gecureerde laag is uw verbruikslaag. Het is geoptimaliseerd voor analyses in plaats van gegevensopname of -verwerking. De gecureerde laag kan gegevens opslaan in gedenormaliseerde datamarts of sterschema's.
Gegevens uit uw gestandaardiseerde container worden omgezet in hoogwaardige gegevensproducten die worden geleverd aan uw gegevensgebruikers. Deze gegevens hebben structuur. Het kan worden geleverd aan de consumenten, zoals data science-notebooks, of via een ander leesgegevensarchief, zoals Azure SQL Database.
Gebruik hulpprogramma's, zoals Spark of Data Factory, om dimensionale modellering uit te voeren in plaats van dit te doen in uw database-engine. Dit gebruik van hulpprogramma's wordt een belangrijk punt als u uw meer de enige bron van waarheid wilt maken.
Als u dimensionale modellering buiten uw lake uitvoert, wilt u mogelijk modellen weer naar uw lake publiceren voor consistentie. Deze laag is geen vervanging voor een datawarehouse. De prestaties zijn doorgaans niet voldoende voor responsieve dashboards of interactieve analyses van eindgebruikers en consumenten. Deze laag is het meest geschikt voor interne analisten en gegevenswetenschappers die grootschalige, geïmproviseerde query's of analyses uitvoeren, of voor geavanceerde analisten die geen tijdgevoelige rapportagebehoeften hebben. Omdat de opslagkosten lager zijn in uw data lake dan uw datawarehouse, kan het kosteneffectief zijn om gedetailleerde, lage gegevens in uw lake te bewaren. Sla geaggregeerde gegevens op in uw magazijn. Genereer deze aggregaties met behulp van Spark of Azure Data Factory. Sla ze op in uw data lake voordat u ze in uw datawarehouse laadt.
Gegevensassets in deze zone zijn doorgaans zeer beheerd en goed gedocumenteerd. Wijs machtigingen toe per afdeling of per functie en organiseer machtigingen per consumentengroep of datamart.
Container voor gegevensproducten
.
|-{Data Product}
|---{Entity}
|----{Version}
|-----General
|-------{date (ex. rundate=2019-08-22)}
|------Sensitive
|-------{date (ex. rundate=2019-08-22)}
Fooi
Wanneer u gegevens in een ander leesgegevensarchief terechtkomt, zoals Azure SQL Database, moet u ervoor zorgen dat u een kopie van die gegevens hebt die zich in uw gecureerde gegevens bevinden. Gebruikers van uw gegevensproduct worden begeleid bij uw belangrijkste leesgegevensarchief of Azure SQL Database-exemplaar, maar ze kunnen ook gegevens verkennen met extra hulpprogramma's als u de gegevens beschikbaar maakt in uw Data Lake.
Ontwikkelingslaag of data lake drie
Uw gegevensgebruikers kunnen andere nuttige gegevensproducten meenemen, samen met de gegevens die zijn opgenomen in uw gestandaardiseerde container.
In dit scenario kan uw gegevensplatform een sandbox-gebied voor analyses toewijzen aan deze consumenten. In de sandbox kunnen ze waardevolle inzichten genereren met behulp van de gecureerde gegevens en gegevensproducten die ze meenemen. Als een data science-team bijvoorbeeld de beste productplaatsingsstrategie voor een nieuwe regio wil bepalen, kunnen ze andere gegevensproducten, zoals demografische gegevens van klanten en gebruiksgegevens, van vergelijkbare producten in die regio meenemen. Het team kan de hoogwaardige verkoopinzichten van deze gegevens gebruiken om de productmarkt passend en aanbiedingsstrategie te analyseren.
Notitie
Het gebied voor de analyse-sandbox is een werkgebied voor een persoon of een kleine groep medewerkers. De mappen van het sandboxgebied hebben een speciale set beleidsregels die voorkomen dat dit gebied wordt gebruikt als onderdeel van een productieoplossing. Deze beleidsregels beperken de totale beschikbare opslag en hoe lang gegevens kunnen worden opgeslagen.
Deze gegevensproducten hebben meestal een onbekende kwaliteit en nauwkeurigheid. Ze worden nog steeds gecategoriseerd als gegevensproducten, maar zijn tijdelijk en alleen relevant voor de gebruikersgroep die de gegevens gebruikt.
Wanneer deze gegevensproducten volwassen worden, kan uw bedrijf deze gegevensproducten promoveren naar uw gecureerde gegevenslaag. Als u uw gegevensproductteams verantwoordelijk wilt houden voor nieuwe gegevensproducten, geeft u de teams een speciale map op uw gecureerde gegevenszone. Ze kunnen nieuwe resultaten opslaan in de map en ze delen met andere teams in uw organisatie.
Notitie
Voor elke Azure Synapse-werkruimte die u maakt, gebruikt u data lake drie om een container te maken die als primaire opslag moet worden gebruikt. Deze container voorkomt dat Azure Synapse-werkruimten de doorvoerlimieten van uw gecureerde en verrijkte zones verstoren.
Voorbeeld van gegevensstroom naar producten en analyse-sandbox
Het volgende diagram compileert de informatie in dit artikel en laat zien hoe gegevens stromen naar een gegevensproducten en analyse-sandbox.
