Datasjözoner och -containrar
Det är viktigt att planera datastrukturen innan du landar den i en datasjö. När du har en plan kan du använda säkerhet, partitionering och bearbetning effektivt.
En översikt över datasjöar finns i Översikt över Azure Data Lake Storage för analys i molnskala.
Översikt
Dina tre datasjökonton bör anpassas till de typiska datasjölagren.
| Sjönummer | Skikt | Containernummer | Containerns namn |
|---|---|---|---|
| 1 | Raw | 1 | Landning |
| 1 | Raw | 2 | Överensstämmelse |
| 2 | Berikad | 1 | Standardiserade |
| 2 | Modererad | 2 | Dataprodukter |
| 3 | Utveckling | 1 | Sandbox-miljö för analys |
| 3 | Utveckling | # | Primärt Synapse-lagringsnummer |
I den föregående tabellen visas standardantalet containrar som vi rekommenderar per datalandningszon. Undantaget till den här rekommendationen är om olika principer för mjuk borttagning krävs för data i en container. Dessa krav avgör ditt behov av fler containrar.
Kommentar
Tre datasjöar illustreras i varje datalandningszon. Datasjön finns i tre datasjökonton, flera containrar och mappar, men den representerar en logisk datasjö för din datalandningszon.
Beroende på dina krav kanske du vill konsolidera råa, berikade och kuraterade lager till ett lagringskonto. Behåll ett annat lagringskonto med namnet "utveckling" för datakonsumenter för att ta med andra användbara dataprodukter.
Mer information om hur du separerar data lake-konton finns i Lagringskonton i en logisk datasjö.
Aktivera Azure Storage med den hierarkiska namnutrymmesfunktionen, som gör att du effektivt kan hantera filer. Den hierarkiska namnrymdsfunktionen organiserar objekt och filer i ett konto i en hierarki med kataloger och kapslade underkataloger. Den här hierarkin är ordnad på samma sätt som filsystemet på datorn.
När din dataagnostiska inmatningsmotor eller registreringsprogram registrerar ett nytt postsystem skapas nödvändiga mappar i containrar i de råa, berikade och standardiserade dataskikten. Om ett källjusterat dataprogram matar in data behöver ditt dataprogramteam ditt team för datalandningszoner för att skapa mappar och säkerhetsgrupper. Placera ett tjänstprincipnamn eller en hanterad identitet i rätt grupp och tilldela en behörighetsnivå. Dokumentera den här processen för dina team för datalandningszoner och dataprogram.
Mer information om team finns i Förstå roller och team för analys i molnskala i Azure.
Varje dataprodukt bör ha två mappar i containern för dataprodukter som ditt dataproduktteam äger.
I en standardiserad containers berikade lager finns det två mappar per källsystem, dividerat med klassificering. Med den här strukturen kan ditt team separat lagra data som har olika säkerhets- och dataklassificeringar och tilldela dem olika säkerhetsåtkomst.
Din standardiserade container behöver en allmän mapp för konfidentiella eller nedanstående data och en känslig mapp för personliga data. Kontrollera åtkomsten till dessa mappar med hjälp av åtkomstkontrollistor (ACL: er). Du kan skapa en datauppsättning med alla personliga data borttagna och lagra dem i den allmänna mappen. Du kan ha en annan datauppsättning som innehåller alla personuppgifter i din känsliga personliga datamapp.
En kombination av ACL:er och Microsoft Entra-grupper begränsar dataåtkomsten. Dessa listor och grupper styr vad andra grupper kan och inte kan komma åt. Dataägare och dataprogramteam kan godkänna eller avvisa åtkomst till sina datatillgångar.
Mer information finns i Dataåtkomsthantering och Begränsade data.
Varning
Vissa programvaruprodukter stöder inte montering av roten för en datasjöcontainer. På grund av den här begränsningen bör varje datasjöcontainer i råa, kurerade, berikade och utvecklingslager innehålla en enda mapp som förgrenas till flera mappar. Konfigurera dina mappbehörigheter noggrant. När du skapar en ny mapp från roten avgör standard-ACL på den överordnade katalogen en underordnad katalogs standard-ACL och åtkomst-ACL. En underordnad fils ACL har ingen standard-ACL.
Mer information finns i Åtkomstkontrollistor (ACL: er) i Azure Data Lake Storage Gen2.
Rådataskikt eller datasjö ett
Tänk på det råa lagret som en reservoar som lagrar data i sitt naturliga och ursprungliga tillstånd. Den är ofiltrerad och opurifierad. Du kan lagra data i dess ursprungliga format, till exempel JSON eller CSV. Eller så kan det vara kostnadseffektivt att lagra filinnehållet som en kolumn i ett komprimerat filformat, till exempel Avro, Parquet eller Databricks Delta Lake.
Dessa rådata är oföränderliga. Håll rådata låsta och om du ger behörighet till konsumenter, automatiserade eller mänskliga, ser du till att de är skrivskyddade. Du kan ordna det här lagret med hjälp av en mapp per källsystem. Ge varje inmatningsprocess skrivåtkomst till endast dess associerade mapp.
När du läser in data från källsystem till råzonen kan du välja att göra:
- Fullständig inläsning för att extrahera en fullständig datauppsättning.
- Delta läses in för att endast läsa in ändrade data.
Ange ditt valda inläsningsmönster i mappstrukturen för att förenkla användningen för dina datakonsumenter.
Rådata från källsystem för varje källjusterat dataprogram eller automatisk inmatningsmotor hamnar i den fullständiga mappen eller deltamappen. Varje inmatningsprocess ska endast ha skrivåtkomst till den associerade mappen.
Skillnaderna mellan fullständiga belastningar och deltabelastningar är:
Fullständig belastning – Fullständiga data från källan kan registreras om:
- Datavolymen vid källan är liten.
- Källsystemet har inte ett tidsstämpelfält som identifierar om data har lagts till, uppdaterats eller tagits bort.
- Källsystemet skriver över fullständiga data varje gång.
Deltainläsning – Inkrementella data från källan kan registreras om:
- Datavolymen vid källan är stor.
- Källsystemet har ett tidsstämpelfält som identifierar om data har lagts till, uppdaterats eller tagits bort.
- Källsystemet skapar och uppdaterar filer om dataändringar.
Din rådatasjö består av dina landnings- och efterlevnadscontainrar. Varje container använder en 100 % obligatorisk mappstruktur som är specifik för dess syfte.
Layout för landningscontainer
Din landningscontainer är reserverad för rådata som kommer från ett känt källsystem. Din dataagnostiska inmatningsmotor eller ett källjusterat dataprogram läser in data, som är oförändrade och i sitt ursprungliga format som stöds.
.
|-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 för överensstämmelse med råskikt
Ditt rådatalager innehåller datakvalitetskonforma data. När data kopieras till en landningscontainer utlöses databehandling och databehandling för att kopiera data från landningscontainern till överensstämmelsecontainern. I den första fasen konverteras data till delta lake-format och hamnar i en indatamapp. När datakvaliteten körs kopieras poster som skickas till utdatamappen. Poster som misslyckas hamnar i en felmapp.
.
|-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)}
Dricks
Tänk på scenarier där du kan behöva återskapa en analysplattform från grunden. Tänk på de mest detaljerade data som du behöver för att återskapa nedströmsläst datalager. Kontrollera att du har en plan för affärskontinuitet och haveriberedskap för dina nyckelkomponenter.
Berikat lager eller datasjö två
Tänk på det berikade lagret som ett filtreringslager. Det tar bort orenheter och kan också innebära berikande.
Standardiseringscontainern innehåller system med poster och original. Mappar segmenteras först efter ämnesområde, sedan efter entitet. Data är tillgängliga i sammanfogade, partitionerade tabeller som är optimerade för analysförbrukning.
Standardiserad 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)}
Kommentar
Det här datalagret anses vara silverskiktet eller läsa datakällan. Data i det här lagret har inte tillämpat några transformeringar förutom datakvalitet, delta lake-konvertering och datatypjustering.
Följande diagram visar flödet av datasjöar och containrar från källdata till en standardiserad container.
Kuraterat lager eller datasjö två
Det kurerade lagret är ditt förbrukningslager. Den är optimerad för analys snarare än datainmatning eller bearbetning. Det kurerade lagret kan lagra data i avnormaliserade data marts eller star-scheman.
Data från din standardiserade container omvandlas till dataprodukter med högt värde som hanteras av dina datakonsumenter. Dessa data har struktur. Det kan hanteras till konsumenterna i den mån det är, till exempel datavetenskapsanteckningsböcker eller via ett annat läsdatalager, till exempel Azure SQL Database.
Använd verktyg som Spark eller Data Factory för att utföra dimensionsmodellering i stället för att göra det i databasmotorn. Den här användningen av verktyg blir en viktig punkt om du vill göra din sjö till den enda sanningskällan.
Om du utför dimensionsmodellering utanför din sjö kanske du vill publicera modeller tillbaka till din sjö för konsekvens. Det här lagret ersätter inte ett informationslager. Dess prestanda är vanligtvis inte tillräcklig för dynamiska instrumentpaneler eller slutanvändare och interaktiva konsumentanalyser. Det här lagret passar bäst för interna analytiker och dataforskare som kör storskaliga, improviserade frågor eller analyser, eller för avancerade analytiker som inte har tidskänsliga rapporteringsbehov. Eftersom lagringskostnaderna är lägre i din datasjö än ditt informationslager kan det vara kostnadseffektivt att behålla detaljerade data på låg nivå i din sjö. Lagra aggregerade data i ditt lager. Generera dessa aggregeringar med hjälp av Spark eller Azure Data Factory. Spara dem i datasjön innan du läser in dem i informationslagret.
Datatillgångar i den här zonen är vanligtvis mycket reglerade och väldokumenterade. Tilldela behörigheter efter avdelning eller funktion och organisera behörigheter efter konsumentgrupp eller data mart.
Container för dataprodukter
.
|-{Data Product}
|---{Entity}
|----{Version}
|-----General
|-------{date (ex. rundate=2019-08-22)}
|------Sensitive
|-------{date (ex. rundate=2019-08-22)}
Dricks
När du landar data i ett annat läsdatalager, till exempel Azure SQL Database, kontrollerar du att du har en kopia av dessa data i dina kurerade data. Dina dataproduktanvändare vägleds till ditt huvudsakliga läsdatalager eller Azure SQL Database-instans, men de kan också utforska data med extra verktyg om du gör data tillgängliga i din datasjö.
Utvecklingslagret eller datasjön tre
Dina datakonsumenter kan ta med andra användbara dataprodukter tillsammans med data som matas in i din standardiserade container.
I det här scenariot kan din dataplattform allokera ett sandbox-analysområde för dessa konsumenter. I sandbox-miljön kan de generera värdefulla insikter med hjälp av de utvalda data- och dataprodukter som de tar med sig. Om ett datavetenskapsteam till exempel vill fastställa den bästa produktplaceringsstrategin för en ny region kan de ta med sig andra dataprodukter, till exempel kunddemografi och användningsdata, från liknande produkter i den regionen. Teamet kan använda värdefulla försäljningsinsikter från dessa data för att analysera produktmarknadens anpassning och erbjudandestrategi.
Kommentar
Sandbox-analysområdet är ett arbetsområde för en enskild person eller en liten grupp medarbetare. Sandbox-områdets mappar har en särskild uppsättning principer som förhindrar försök att använda det här området som en del av en produktionslösning. Dessa principer begränsar den totala tillgängliga lagringen och hur länge data kan lagras.
Dessa dataprodukter är vanligtvis av okänd kvalitet och noggrannhet. De kategoriseras fortfarande som dataprodukter, men är tillfälliga och endast relevanta för den användargrupp som använder data.
När dessa dataprodukter mognar kan företaget höja upp dessa dataprodukter till det kurerade dataskiktet. För att hålla dina dataproduktteam ansvariga för nya dataprodukter kan du ge teamen en dedikerad mapp i din kurerade datazon. De kan lagra nya resultat i mappen och dela dem med andra team i organisationen.
Kommentar
För varje Azure Synapse-arbetsyta som du skapar använder du data lake three för att skapa en container som ska användas som primär lagring. Den här containern hindrar Azure Synapse-arbetsytor från att störa dina utvalda och berikade zoners dataflödesgränser.
Exempel på dataflöde till produkter och sandbox-analys
Följande diagram sammanställer informationen i den här artikeln och visar hur data flödar till en sandbox-miljö för dataprodukter och analys.
