Kapabiliteter för datahantering
En samlad lista över vad PDQ gör inom datahantering, grupperad efter uppgiften snarare än efter komponenten som utför den. Använd den för att kontrollera om en kapabilitet finns, och följ länken till där den beskrivs i detalj.
Varje kapabilitet anger vilket lager som äger den — INGEST, DLS, DWA, QPI, AME (Active Metadata Engine) eller DataOps-konsolen.
1. Datainhämtning
Att få ut data ur källsystemen och in i plattformen, enligt schema, utan handskriven extraktionskod.
| Kapabilitet | Vad det innebär | Ägare |
|---|---|---|
| Databasextraktion | SQL-källor hämtas via direktanslutning — PostgreSQL, SQL Server, Oracle och MySQL | INGEST |
| API-extraktion | REST-endpoints konfigurerade som källexporter | INGEST |
| Filextraktion | Filer hämtas från objektlagring och nätverksutdelningar — S3, Azure Blob, monterade sökvägar | INGEST |
| Custom- och manuella källor | Egna kopplingar, och källor som levereras för hand där automatik saknas | INGEST |
| Full export | Hela datamängden extraheras om vid varje körning, för små referens- och dimensionstabeller | INGEST |
| Change data capture | Endast nya, ändrade och borttagna poster sedan föregående körning | INGEST |
| Glidande fönster | Ett rullande tidsfönster som extraheras om vid varje körning, för sent anländande data | INGEST |
| Schemaläggning | Frekvens, intervallmultiplikator och tidigaste tillåtna starttid, per export | INGEST |
| Kolumnurval | Inkluderingslistor, exkluderingslistor eller allt — bestäms per export | INGEST |
| Substitutioner vid export | Strängsubstitutioner som appliceras under extraktionen | INGEST |
| Oförändrad landning | Det som anländer skrivs orört och stämplas med tidpunkt och ursprung, så leveransen går att skilja från det vi gjorde med den | INGEST |
→ INGEST-lagret · Konfigurera inhämtning
2. Lagring och livscykel
Var data bor mellan ankomst och konsumtion, och vad varje lager garanterar.
| Kapabilitet | Vad det innebär | Ägare |
|---|---|---|
| Landing | Ingångspunkten — tillfällig uppställning för anländande leveranser | DLS |
| Raw Archive | Ett oföränderligt revisionsspår, bevarat på obestämd tid, organiserat och märkt | DLS |
| Trusted | Data i standardiserat format. Avvikelser mot datakontraktet registreras, de blockeras inte — se Arkitektur | DLS |
| Omkörbart fönster på Trusted | KEEPDATAINTRUSTEDFORDAYS, standard 3 dagar — hur långt bakåt Published kan köras om från utan att processa om från Raw | DLS |
| Profile | Profileringsstatistik skrivs vid sidan om flödet, utan att störa laddningen | DLS |
| Published | Frågeklara tabeller i överenskommet format, öppna för SQL-åtkomst | DLS → DWA |
| Konfigurerbara lagernamn och sökvägar | Lagernamn sätts centralt; sökvägar följer konventionen [ZoneName]/[System]/[Filename]/[YYYY]/[MM]/[DD]/; Landing tar inga datumtoken | DLS |
| Datumtoken för partitionering | [YYYY], [MM], [DD] och [HH] för tidsbaserad partitionering av lagersökvägar | DLS |
| Komprimering | Valfri gzip, nivå 1–9, per källfil | DLS |
| Kryptering i vila | Aktiveras eller avaktiveras per källfil | DLS |
| Teckenkodning | UTF-8 (rekommenderas), UTF-16 och Windows-1252 | DLS |
→ DLS-lagret · Data Lake Service
3. Datakontrakt och profilering
Att veta hur en leverans ska se ut, och märka när den slutar se ut så.
| Kapabilitet | Vad det innebär | Ägare |
|---|---|---|
| Källfilsdefinitioner | Strukturen på en inhämtad fil — fält, typer, nycklar och styrningsflaggor | DLS |
| Automatisk profilering | Löpande kontroller mot datakontraktet, aktiveras per källfil | DLS / QPI |
| Typkontroll | Verifiering att värden stämmer med sin deklarerade typ | DLS |
| Andel null och tomma värden | Hur mycket av varje fält som faktiskt är ifyllt | DLS |
| Värdefördelning | Fördelningsmönster per fält, används för att upptäcka tysta för ändringar | DLS |
| Upptäckt av schemadrift | Nya eller saknade kolumner flaggas när källan förändras | DLS |
| Kontraktsvalidering | Var en källa har glidit från sitt överenskomna kontrakt: Data Type Mismatch, Missing In Contract (källan började skicka något nytt) och Missing In Delta (källan slutade skicka något). Jämför dagens profildata mot kontraktet. | DataOps-konsolen |
| Undantag per fält | Enskilda fält hoppas över där profilering inte är önskvärd | DLS |
→ Dataprofilering · Kontraktsvalidering
4. Modellering och warehouse-automation
Från källdata till modell — och koden som laddar den genereras.
| Kapabilitet | Vad det innebär | Ägare |
|---|---|---|
| Modellkedjan | Published → Base (integrera) → Core (konsumera) → Business | DWA |
| Datamart-modeller | Ytterligare modeller för specifika analytiska användningsfall | DWA |
| Modelldefinitioner | Måltabeller med typade attribut, affärsnycklar, relationer och affärsbeskrivning | DWA |
| Specifika och kombinerade modeller | En källa per modell, eller flera källor integrerade i en | DWA |
| Laddningsmönster | full, incremental, transaction, dayspan eller none, valfritt per modell | DWA |
| Affärsnycklar | Enkla eller sammansatta nycklar med uttalad prioritetsordning, som styr deduplicering och upsert | DWA |
| Relationer | Främmande nycklar mellan modeller, inklusive 1:N och M:M | DWA |
| Tidigt anländande data | En post vars masterkälla ännu inte laddats behåller sin relation. När mastern anländer kompletterar dess attribut samma post — inga uppehållna laddningar, ingen omkörning, ingen manuell lagning | DWA |
| Historisering | En normaliserad, historiserad kärna där varje värde har en giltighetsperiod — frågan "vad visste vi då?" förblir besvarbar | DWA |
| SCD Type 2 | Långsamt föränderliga dimensioner spåras via validFrom-fält | DWA |
| Kodgenerering | Laddningslogik, historisering och strukturer genereras ur modellen i stället för att skrivas för hand | DWA |
| Förhandsgranskning av SQL | Den genererade laddnings-SQL:en granskas innan den körs | DWA |
| Målmetoder | TRANSACTION, APPEND, CHANGES ONLY, LATEST VERSION eller OVERWRITE, per källfil | DLS → DWA |
| Målformat | Standardtabeller, Apache Iceberg eller semistrukturerad JSON | DLS → DWA |
| Normalisering av hierarkier | Nästlad data platt i en tabell, uppdelad per lista, eller fullt normaliserad till en tabelluppsättning | DLS |
→ DWA-lagret · Data Warehouse Automation
5. Transformation och mappning
Reglerna som kopplar ett källfält till ett modellattribut.
| Kapabilitet | Vad det innebär | Ägare |
|---|---|---|
| Fält-till-attribut-mappningar | Kärnmekanismen som kopplar källfilens fält till modellens attribut | DWA |
| Nyckelmappningar | Mappningar markerade som affärsnycklar, med uttalad nyckelordning | DWA |
| Valfria beräkningar | SQL-uttryck per mappning, för härledda och beräknade värden | DWA |
| Filter på mappning | Ett WHERE-villkor som gäller en enskild mappning | DWA |
| Sorteringsordning | Sorteringsprioritet per mappning, stigande eller fallande | DWA |
| Massredigering | Mappningar redigeras i grupp i stället för en i taget | DWA |
| Mappningsdiagram | En visuell vy över hur källor når modeller | DWA |
→ Mappningar och transformationer
6. Kvalitetsövervakning
Löpande mätning av om plattformen är komplett, sammankopplad och frisk.
| Kapabilitet | Vad det innebär | Ägare |
|---|---|---|
| Plattformsräknare | System, källfiler, fält, mappningar och modeller, följda över tid | DataOps-konsolen |
| Mappningstäckning | Andelen av en källfils fält som når en modell, graderad grön / gul / röd | DataOps-konsolen |
| Anslutningshälsa | Anslutningstyp, om ett system har exporter och hur många | DataOps-konsolen |
| QPI-kontroller | Kvalitetskontroller skapas, redigeras, avvecklas och triggas manuellt | DataOps-konsolen |
| Kvalitetsdashboards | Arkitekturdiagram, härkomstflöde och detaljpaneler per källa | DataOps-konsolen |
→ Kvalitetsövervakning (QPI) · Datakvalitetssidorna
7. Styrning, säkerhet och regelefterlevnad
Klassificering och kontroll som faller ut ur flödet i stället för att ligga vid sidan om.
| Kapabilitet | Vad det innebär | Ägare |
|---|---|---|
| Märkning av känsliga data | Fält märkta som PII eller på annat sätt känsliga | DLS |
| Fältdomäner | Styrningsklassificering per fält | DLS |
| Uteslutning av fält | Fält tas bort ur flödet helt | DLS |
| Nyckelfältsindikatorer | Uttalad märkning av primär- och affärsnycklar | DLS |
| Genererade villkor | Unika villkor ur affärsnycklar, främmande nycklar ur relationer, primärnycklar på publiceringstabeller — genererade som databasobjekt, på som standard | DWA |
| Genererade kommentarer | Tabell- och kolumnkommentarer genererade inuti CREATE TABLE, ur beskrivningarna i modellen och datakontraktet | DWA |
| Klassificeringstaggar i målet | fieldDomain och sensitive genereras som taggar på målkolumnerna, med varje plattforms egen taggningsfunktion | DWA |
| Kolumnmaskering | Maskeringspolicy på Snowflake, dynamisk datamaskering i T-SQL-familjen, SECURITY LABEL på PostgreSQL — Databricks genererar bara en tagg, ingen mask | DWA |
| Arv av klassificering | Domäntaggar följer ärvda affärsnycklar till normaliserade barntabeller — klassificera en gång, förbli klassificerad | DWA |
| Frågetaggning | Varje sats bär sitt jobb, steg och sin körning in i målets egen frågehistorik | DWA |
| Härkomst | Var en kolumn kommer ifrån och var den hamnar, härlett ur metadata | AME / DataOps-konsolen |
| Oföränderligt revisionsspår | Rådata bevaras oförändrad för revision och avstämning | DLS |
| Rollbaserad åtkomst i konsolen | Rollerna admin, developer och reader, där varje förändrande åtgärd kräver admin | DataOps-konsolen |
| Åtgärdslogg | En strukturerad loggrad per användaråtgärd — vem, roll, sida, åtgärd, mål, tidpunkt | DataOps-konsolen |
| Kryptering och komprimering | Tillämpas per källfil, i vila | DLS |
→ Vad som landar i målmiljön · Styrning på fältnivå · Roller och åtgärdslogg
8. Orkestrering och drift
Att köra plattformen dag för dag, och rätta till det som inte gick igenom.
| Kapabilitet | Vad det innebär | Ägare |
|---|---|---|
| Central orkestrering | Beroenden, körordning och omkörningar hanteras centralt i stället för per pipeline | AME |
| Schemaläggning av uppgifter | Ett schema per källfil, med hälsan synlig | DWA |
| För- och efterbehandling | Ytterligare uppgifter kedjade till laddningarna | DWA |
| Spårning av körningar | Varje leverans följs genom Landing → Raw → Trusted → Published | DataOps-konsolen |
| Spårning av publicering | Bekräftelse på att varje publicering landade i sin måltabell | DataOps-konsolen |
| Laddningsstatistik | Rader stagade och infogade, per källfil och per objekt | DataOps-konsolen |
| Hälsostatus för plattformen | En indikator för valt tidsfönster: frisk, varningar, degraderad eller otillgänglig | DataOps-konsolen |
| Korrigerande åtgärder | Starta om, hoppa över och trigga om det som fallerade | DataOps-konsolen |
| Tjänstehälsa och loggar | Om tjänsterna själva kör, och vad de loggade | DataOps-konsolen |
| Tidsfönstrade vyer | Varje driftsida avgränsas av ett gemensamt datumintervall | DataOps-konsolen |
→ Daglig drift · DataOps-konsolen
9. Metadata och dokumentation
Metadatan beskriver inte bara plattformen — den kör den.
| Kapabilitet | Vad det innebär | Ägare |
|---|---|---|
| Centralt metadataregister | All logik, varje körd operation och varje planerad operation, på ett ställe | AME |
| Metadatastyrd exekvering | Varje komponent läser sin konfiguration ur registret | AME |
| API-åtkomst till metadata | REST-API:et som konsolen och integrationer läser | AME |
| OpenLineage-export | Start- och sluthändelser för varje exekvering, föräldrajobbhändelser från kvalitetskontroller och härkomst på attributnivå som alternativ — härkomsten landar i katalogen du redan kör | AME / DWA |
| Definitionsexport | Den genererade DDL:en returnerad från SQL Generator-API:et, så att en definition kan diffas i CI innan den driftsätts | AME |
| Genererad dokumentation | Hela konfigurationen och datakontraktet bakom en källfil, renderat ur metadata | DataOps-konsolen |
| Datamodellvyer | Hur målmodellen hänger ihop, ritad ur modellen själv | DataOps-konsolen |
| Live-arkitekturvy | Det konfigurerade flödet ritat ur de system, källfiler och modeller som faktiskt finns | DataOps-konsolen |
| Versionering och härkomst som biprodukter | Skapas av körningen i stället för att underhållas som ett separat projekt | AME |
→ Referensvyer · Att få ut metadata — API:er och OpenLineage · Arkitektur
10. Portabilitet
Plattformen sitter ovanpå din stack — inte tvärtom.
| Kapabilitet | Vad det innebär |
|---|---|
| Valfri databas | Snowflake, Databricks, SQL Server, Synapse, Fabric, PostgreSQL |
| Valfri lagring | Azure Blob, Amazon S3, CEPH, Swift, MinIO |
| Valfritt moln | Azure, AWS, Cleura |
| Oberoende lager | Byte av databas eller lagring är en konfigurationsändring; byte av moln en migrering |
| Portabel modell och logik | Modellen, logiken och metadatan följer med när den underliggande tekniken byts |
Nästa steg
- Arkitektur — hur lagren hänger ihop
- Plattformsguide — hur lagren hänger ihop, och vägen in i fördjupningarna för INGEST, DLS och DWA
- Vad som landar i målmiljön — villkoren, kommentarerna, taggarna och maskeringen plattformen genererar in i din databas
- Ditt första flöde — kapabiliteterna tillämpade hela vägen