Vad är arkitekturen i medallion lakehouse?

Arkitekturen medallion beskriver en serie datalager som anger kvaliteten på data som lagras i lakehouse. Azure Databricks rekommenderar att du använder en metod med flera lager för att skapa en enda sanningskälla för företagets dataprodukter.

Den här arkitekturen garanterar atomitet, konsekvens, isolering och hållbarhet när data passerar genom flera lager av valideringar och transformeringar innan de lagras i en layout som är optimerad för effektiv analys. Termerna brons (rå), silver (validerad) och guld (berikad) beskriver kvaliteten på data i vart och ett av dessa lager.

Medallion-arkitektur som ett mönster för datadesign

En medaljongarkitektur är ett datadesignmönster som används för att organisera data logiskt. Dess mål är att stegvis och progressivt förbättra strukturen och kvaliteten på data när de flödar genom varje skikt i arkitekturen (från Brons ⇒ Silver ⇒ Guldskikttabeller). Medallion-arkitekturer kallas ibland även för arkitekturer med flera hopp.

Genom att gå vidare med data genom dessa lager kan organisationer stegvis förbättra datakvaliteten och tillförlitligheten, vilket gör den mer lämplig för business intelligence- och maskininlärningsprogram.

Att följa medaljongarkitekturen är en rekommenderad metod, men inte ett krav.

Fråga	Brons	Silver	Guld
Vad händer i det här lagret?	Rådatainmatning	Datarensning och validering	Dimensionsmodellering och sammansättning
Vem är den avsedda användaren?	– Datatekniker – Dataåtgärder – Efterlevnads- och granskningsteam	– Datatekniker – Dataanalytiker (använd Silver-lagret för en mer förfinad datamängd som fortfarande behåller detaljerad information som krävs för djupgående analys) – Dataforskare (skapa modeller och utföra avancerad analys)	- Affärsanalytiker och BI-utvecklare – Dataforskare och maskininlärningstekniker (ML) - Chefer och beslutsfattare – Operativa team

Exempel på medaljongarkitektur

Det här exemplet på en medaljongarkitektur visar brons-, silver- och guldskikt för användning av ett affärsdriftsteam. Varje lager lagras i ett annat schema i ops-katalogen.

• Bronsskikt (ops.bronze): Matar in rådata från molnlagring, Kafka och Salesforce. Ingen datarensning eller verifiering utförs här.
• Silverskikt (ops.silver): Datarensning och validering utförs i det här lagret.
  • Data om kunder och transaktioner rensas genom att null-värden tas bort och ogiltiga poster tas bort. Dessa datauppsättningar är anslutna till en ny datauppsättning med namnet customer_transactions. Dataexperter kan använda den här datamängden för förutsägelseanalys.
  • På samma sätt kopplas konton och affärsmöjlighetsdatauppsättningar från Salesforce till att skapa account_opportunities, vilket utökas med kontoinformation.
  • Data leads_raw rensas i en datauppsättning med namnet leads_cleaned.
• Guldskikt (ops.gold): Det här lagret är utformat för företagsanvändare. Den innehåller färre datamängder än silver och guld.
  • customer_spending: Genomsnittliga och totala utgifter för varje kund.
  • account_performance: Dagliga prestanda för varje konto.
  • sales_pipeline_summary: Information om försäljningspipelinen från slutpunkt till slutpunkt.
  • business_summary: Mycket aggregerad information för den verkställande personalen.

Mata in rådata till bronsskiktet

Bronsskiktet innehåller råa, ovaliderade data. Data som matas in i bronsskiktet har vanligtvis följande egenskaper:

• Innehåller och underhåller datakällans råtillstånd i sina ursprungliga format.
• Läggs till stegvis och växer med tiden.
• Är avsedd för förbrukning av arbetsbelastningar som berikar data för silvertabeller, inte för åtkomst av analytiker och dataforskare.
• Fungerar som en enda sanningskälla och bevarar datans återgivning.
• Möjliggör upparbetning och granskning genom att behålla alla historiska data.
• Kan vara valfri kombination av strömnings- och batchtransaktioner från källor, inklusive molnobjektlagring (till exempel S3, GCS, ADLS), meddelandebussar (till exempel Kafka, Kinesis osv.) och federerade system (till exempel Lakehouse Federation).

Begränsa rensning eller validering av data

Minimal dataverifiering utförs i bronsskiktet. För att säkerställa mot borttagna data rekommenderar Azure Databricks att du lagrar de flesta fält som sträng, VARIANT eller binärt för att skydda mot oväntade schemaändringar. Metadatakolumner kan läggas till, till exempel härkomsten eller datakällan (till exempel _metadata.file_name ).

Verifiera och deduplicera data i silverskiktet

Datarensning och validering utförs i silverlager.

Skapa silvertabeller från bronsskiktet

Om du vill skapa silverskiktet läser du data från en eller flera brons- eller silvertabeller och skriver data till silvertabeller.

Azure Databricks rekommenderar inte att du skriver till silvertabeller direkt från inmatning. Om du skriver direkt från inmatningen kommer du att introducera fel på grund av schemaändringar eller skadade poster i datakällor. Förutsatt att alla källor endast är tillägg konfigurerar du de flesta läsningar från brons som direktuppspelningsläsningar. Batchläsningar bör reserveras för små datamängder (till exempel små dimensionstabeller).

Silverskiktet representerar verifierade, rensade och berikade versioner av data. Silverskiktet:

• Bör alltid innehålla minst en validerad, icke-aggregerad representation av varje post. Om aggregerade representationer driver många underordnade arbetsbelastningar kan dessa representationer finnas i silverskiktet, men vanligtvis är de i guldskiktet.
• Här utför du datarensning, deduplicering och normalisering.
• Förbättrar datakvaliteten genom att korrigera fel och inkonsekvenser.
• Strukturerar data till ett mer förbrukningsbart format för nedströmsbearbetning.

Framtvinga datakvalitet

Följande åtgärder utförs i silvertabeller:

• Schematillämpning
• Hantering av null- och saknade värden
• Datadeduplicering
• Lösning på problem med oordnade och försenade data
• Kontroller och tillämpning av datakvalitet
• Schemautveckling
• Typgjutning
• Kopplingar

Starta modelleringsdata

Det är vanligt att börja utföra datamodellering i silverskiktet, inklusive att välja hur du ska representera kraftigt kapslade eller halvstrukturerade data:

• Använd VARIANT datatyp.
• Använd JSON strängar.
• Skapa structs, kartor och matriser.
• Platta ut schema eller normalisera data till flera tabeller.

Power Analytics med guldskiktet

Det guldfärgade lagret representerar mycket förfinade vyer av data som driver nedströmsanalys, instrumentpaneler, ML och program. Guldlagerdata är ofta mycket aggregerade och filtrerade för specifika tidsperioder eller geografiska regioner. Den innehåller semantiskt meningsfulla datauppsättningar som mappar till affärsfunktioner och behov.

Guldskiktet:

• Består av aggregerade data som är skräddarsydda för analys och rapportering.
• Överensstämmer med affärslogik och krav.
• Är optimerad för prestanda i frågor och instrumentpaneler.

Anpassa till affärslogik och krav

Det guldfärgade lagret är där du ska modellera dina data för rapportering och analys med hjälp av en dimensionsmodell genom att upprätta relationer och definiera mått. Analytiker med åtkomst till data i guld bör kunna hitta domänspecifika data och svara på frågor.

Eftersom guldskiktet modellerar en affärsdomän skapar vissa kunder flera guldskikt för att uppfylla olika affärsbehov, till exempel HR, ekonomi och IT.

Skapa aggregeringar som är skräddarsydda för analys och rapportering

Organisationer behöver ofta skapa aggregerade funktioner för mått som medelvärden, antal, max och minimum. Om ditt företag till exempel behöver svara på frågor om den totala veckoförsäljningen kan du skapa en materialiserad vy med namnet weekly_sales som föraggregerar dessa data så att analytiker och andra inte behöver återskapa ofta använda materialiserade vyer.

CREATE OR REPLACE MATERIALIZED VIEW weekly_sales AS
SELECT week,
       prod_id,
       region,
       SUM(units) AS total_units,
       SUM(units * rate) AS total_sales
FROM orders
GROUP BY week, prod_id, region

Optimera för prestanda i frågor och instrumentpaneler

Det är bra att optimera tabeller med guldlager för prestanda eftersom dessa datauppsättningar ofta efterfrågas. Stora mängder historiska data används vanligtvis i sliver-lagret och materialiseras inte i guldskiktet.

Kontrollera kostnaderna genom att justera datainmatningsfrekvensen

Kontrollera kostnaderna genom att bestämma hur ofta data ska matas in.

Datainmatningsfrekvens	Kostnad	Svarstid	Deklarativa exempel	Procedurexempel
Kontinuerlig inkrementell inmatning	Högre	Lower	– Strömmande tabell som använder spark.readStream för att mata in från molnlagring eller meddelandebuss. – Delta Live Tables-pipelinen som uppdaterar den här strömningstabellen körs kontinuerligt. – Strukturerad strömningskod som använder spark.readStream i en notebook-fil för att mata in från molnlagring eller meddelandebuss till en Delta-tabell. – Anteckningsboken dirigeras med hjälp av ett Azure Databricks-jobb med en kontinuerlig jobbutlösare.
Utlöst inkrementell inmatning	Lower	Högre	– Strömmande tabell som matas in från molnlagring eller meddelandebuss med .spark.readStream – Pipelinen som uppdaterar den här strömningstabellen utlöses av jobbets schemalagda utlösare eller en utlösare för filinkomst. – Strukturerad direktuppspelningskod i en notebook-fil med en Trigger.Available utlösare. – Den här notebook-filen utlöses av jobbets schemalagda utlösare eller en utlösare för filinkomst.
Batchinmatning med manuell inkrementell inmatning	Lower	Högsta, på grund av ovanliga körningar.	– Inmatning av strömmande tabell från molnlagring med hjälp av spark.read. – Använder inte strukturerad direktuppspelning. Använd i stället primitiver som partitionsöverskrivning för att uppdatera en hel partition samtidigt. – Kräver omfattande uppströmsarkitektur för att konfigurera inkrementell bearbetning, vilket möjliggör en kostnad som liknar structured streaming reads/writes. – Kräver också partitionering av källdata efter ett datetime fält och sedan bearbetning av alla poster från partitionen till målet.