DLS-lagret

DLS-lagret hanterar hur data flödar genom lagringszonerna — från rå landning till standardiserade, frågeklara tabeller. Det sköter arkivering, bearbetning, profilering och publicering.

Avvikelser mot datakontraktet registreras här, de blockeras inte. Se Vad plattformen registrerar, och vad den stoppar.

För den skärmvisa guiden till att konfigurera en källfil, se Data Lake Service.

DLS-lagret hanterar hur data flödar genom lagringszoner — från rå landing till validerade, fråge-redo tabeller. Det hanterar arkivering, bearbetning, validering och publicering.

Zonarkitektur

┌──────────┐    ┌──────────────┐    ┌─────────────┐    ┌───────────────┐
│ Landing  │ ──►│ Raw Archive  │ ──►│  Trusted    │ ──►│  Published    │
│ Zone     │    │ Zone         │    │  Zone       │    │  Zone         │
└──────────┘    └──────────────┘    └─────────────┘    └───────────────┘

Landing Zone

• Syfte: Temporärt stagingområde där exporterad data först anländer
• Livscykel: Filer bearbetas och flyttas till Raw Archive — behålls inte långsiktigt
• Sökvägsformat: [landingZoneName]/[system]/[filename]/
• Inga datumtoken — landing är en övergående buffert

Raw Archive Zone

• Syfte: Oföränderlig, permanent post av varje fil som ingesterades
• Livscykel: Skriv en gång, ändra aldrig — fungerar som revisionsspår
• Sökvägsformat: [rawZoneName]/[system]/[filename]/[YYYY]/[MM]/[DD]/
• Datumpartitionerad för effektiva historiska frågor

Trusted Zone

• Syfte: Validerad, rensad och standardiserad data redo för modellering
• Livscykel: Skrivs av DLS Workers medan varje leverans bearbetas
• Sökvägsformat: [trustedZoneName]/[system]/[filename]/[YYYY]/[MM]/[DD]/
• Avvikelser mot datakontraktet registreras här, de blockeras inte — se Arkitektur

Published Zone

• Syfte: SQL-optimerade tabeller redo för direkt frågning och lagerkonsumtion
• Livscykel: Synkroniseras från Trusted via Publish-steget
• Styrs av: publishedZoneName och publishedModelSchema i Settings

Zonkonfiguration

Alla zonnamn är konfigurerbara i Settings → Data Lake Settings:

Inställning	Beskrivning	Exempel
landingZoneName	Landing zone-etikett	landing
rawZoneName	Raw archive-etikett	raw
trustedZoneName	Trusted zone-etikett	trusted
publishedZoneName	Published zone-etikett	published

Lagringsinställningar

Inställning	Beskrivning
storageIntegration	Snowflake storage integration-namn (krävs för externa steg)
externalVolume	Extern volym för datastaging
formatFile	Formatdefinitionsfil (JSON/text)
tableCatalog	Snowflake-katalogspecifikation
publishedModelSchema	Målschema för publicerade modeller

DLS-pipelinen

Landing ──► Raw Archive ──► DLS Workers ──► Trusted + Profile
                                                       │
                                                       ▼
                                                  Sync/Publish
                                                       │
                                                       ▼
                                                  Published Zone

DLS Workers — parallella arbetarprocesser (minst sex containrar) hanterar datatransformation och validering:

• Parsa inkommande filformat (CSV, JSON, XML)
• Tillämpa datatypstvång och normalisering
• Köra profileringskontroller när enableProfiler är aktivt
• Skriva data till Trusted Zone och registrera varje avvikelse mot kontraktet
• Skriva profilstatistik till Profile Zone

Sync/Publish-steget — överbryggar gapet mellan DLS (Trusted Zone) och DWA (Published Zone):

• Genererar laddnings-SQL för målformatet (TABLE eller ICEBERG)
• Tillämpar den konfigurerade targetMethod (TRANSACTION, APPEND, CHANGES ONLY, LATEST VERSION eller OVERWRITE)
• Skapar eller uppdaterar tabeller i Published-schemat

Publiceringsmönster

Målmetoder

targetMethod på en sourcefile styr hur data laddas i publicerade tabeller:

Metod	Beteende	När den ska användas
replace	Radera och återskapa måltabellen med ny data	Små tabeller, fullständiga uppdateringar, referensdata
append	Lägg till nya rader i befintlig tabell	Händelse-/loggdata, append-only-mönster
upsert	Infoga nya rader, uppdatera befintliga rader efter nyckel	Dimensionstabeller med SCD-spårning, masterdata

Målformat

Format	Beskrivning	Överväganden
TABLE	Måldatabasens eget tabellformat	Bäst för de flesta användningsfall, fullt SQL-stöd
ICEBERG	Apache Iceberg-tabellformat	Bättre för multimotor-åtkomst, tidsresor, schemaevolution
JSON	Semi-strukturerad lagring	När strukturen är okänd eller mycket variabel

SQL-generering

PDQ genererar laddnings-SQL automatiskt baserat på din konfiguration:

1. Sourcefile-struktur definierar kolumner och typer
2. Målmetod bestämmer INSERT/MERGE/CREATE OR REPLACE-beteende
3. Mappningar styr vilka fält som mappar till vilka modellattribut
4. Settings ger schema-, katalog- och lagringsintegrationsdetaljer

Du kan förhandsgranska den genererade SQL:en innan körning för att verifiera att den matchar din avsikt.

Publiceringsöverväganden

Datanormalisering

targetNormalization-inställningen styr hur nästlad/hierarkisk data plattas ut:

Läge	Beteende	Exempel
NONE	En tabell per källfil	Platt CSV → enskild måltabell
LISTS	Dela arrayer i separata tabeller	JSON med nästlade arrayer → förälder + barntabeller
LISTS AND OBJECTS	Dela arrayer och nästlade objekt	Djupt nästlad JSON → helt normaliserat tabellset

Sökvägstokenstöd

Zonsökvägar stöder datumtoken för tidsbaserad partitionering:

Token	Värde
[YYYY]	Fyrsiffrigt år
[MM]	Tvåsiffrig månad
[DD]	Tvåsiffrig dag
[HH]	Tvåsiffrig timme

Exempel: trusted/SAP/customers/[YYYY]/[MM]/[DD]/

note

Landing Zone-sökvägar stöder inte datumtoken — de använder en platt sökväg.

Komprimering och kryptering

Inställning	Alternativ
fileCompressionType	Ingen, eller gzip
fileCompressionLevel	1 (snabbast) till 9 (minst)
enableEncryption	Aktivera/inaktivera kryptering vid vila

Stödda filkodningar: UTF-8 (standard, rekommenderad), UTF-16, Windows-1252

Bästa praxis

Zondesign

• Håll Raw Archive oföränderligt — ändra eller radera aldrig filer i Raw Zone. Det är din återställningsväg.
• Använd datumpartitionering — inkludera alltid [YYYY]/[MM]/[DD] i Raw- och Trusted-sökvägar för effektiv frågning och livscykelhantering.
• Namnge zoner tydligt — använd beskrivande namn som gör det uppenbart var data befinner sig i sin livscykel.

Publiceringsstrategi

Scenario	Rekommenderat tillvägagångssätt
Liten referenstabell (<100K rader)	OVERWRITE-metod, TABLE-format
Stor faktatabell (miljontals rader)	append-metod med CDC uppströms
Långsamt förändrande dimension	LATEST VERSION-metod med affärsnycklar
Multimotor-analys (Spark + Snowflake)	ICEBERG-format
Okänt/evolverande schema	JSON-format initialt, migrera till TABLE när stabilt

Prestandaöverväganden

• Profilering ökar beräkningskostnaden — aktivera enableProfiler för kritisk data, överväg att inaktivera för högvolym, välförstådda källor
• Komprimering sparar lagring — använd gzip nivå 6 som en bra balans mellan hastighet och storlek
• Välj LATEST VERSION noggrant — det kräver väldefinierade affärsnycklar och är långsammare än APPEND för stora volymer
• Partitionera efter datum — det möjliggör effektiv pruning och gör rensnings-/bevarandepolicyer enklare att implementera

Datastyrning

• Markera PII-fält som sensitive: 1 i sourcefile-strukturen
• Använd excludeFromProfiling: 1 för fält som inte ska analyseras
• Tilldela fieldDomain-klassificeringar för efterlevnadsspårning
• Exkludera interna/felsökningsfält med excludeField: 1 för att hålla publicerad data ren

---

Nästa steg

• DWA-lagret — att göra en modell av en publicerad leverans
• Data Lake Service — konfigurationsguiden fält för fält
• Arkitektur — modellkedjan och dess synonymer