Datamodellering

Den här artikeln beskriver överväganden, varningar och rekommendationer för datamodellering i Azure Databricks. Den riktar sig till användare som konfigurerar nya tabeller eller redigerar ETL-arbetsbelastningar, med tonvikt på att förstå Azure Databricks-beteenden som påverkar omvandling av rådata till en ny datamodell. Beslut om datamodellering beror på hur din organisation och dina arbetsbelastningar använder tabeller. Den datamodell du väljer påverkar frågeprestanda, beräkningskostnader och lagringskostnader. Detta inkluderar en introduktion till grundläggande begrepp inom databasdesign med Azure Databricks.

Viktigt!

Den här artikeln gäller uteslutande för tabeller som backas upp av Delta Lake, som innehåller alla hanterade Unity Catalog-tabeller.

Du kan använda Azure Databricks för att fråga andra externa datakällor, inklusive tabeller som registrerats med Lakehouse Federation. Varje extern datakälla har olika begränsningar, semantik och transaktionsgarantier. Se Frågedata.

Begrepp för databashantering

Ett lakehouse byggt med Azure Databricks delar många komponenter och begrepp med andra system för informationslager för företag. Tänk på följande begrepp och funktioner när du utformar din datamodell.

Transaktioner i Azure Databricks

Azure Databricks avgränsar transaktioner till enskilda tabeller. Det innebär att Azure Databricks inte stöder flera tabellinstruktioner (kallas även transaktioner med flera instruktioner).

För datamodelleringsarbetsbelastning innebär detta att flera oberoende transaktioner måste utföras när en källpost kräver att rader infogas eller uppdateras i två eller flera tabeller. Var och en av dessa transaktioner kan lyckas eller misslyckas oberoende av andra transaktioner, och efterföljande frågor måste vara toleranta mot skillnad i tillstånd på grund av misslyckade eller försenade transaktioner.

Primära och externa nycklar i Azure Databricks

Primära och externa nycklar är informationsbaserade och tillämpas inte. Den här modellen är vanlig i många molnbaserade databassystem för företag, men skiljer sig från många traditionella relationsdatabassystem. Se Begränsningar för Azure Databricks.

Ansluter till Azure Databricks

Kopplingar kan introducera flaskhalsar för bearbetning i valfri databasdesign. När du bearbetar data i Azure Databricks försöker frågeoptimeraren optimera planen för kopplingar, men kan kämpa när en enskild fråga måste koppla resultat från många tabeller. Optimeraren kan också misslyckas med att hoppa över poster i en tabell när filterparametrar finns på ett fält i en annan tabell, vilket kan resultera i en fullständig tabellgenomsökning.

Se Arbeta med kopplingar i Azure Databricks.

Kommentar

Du kan använda materialiserade vyer för att stegvis beräkna resultatet för vissa kopplingsåtgärder, men andra kopplingar är inte kompatibla med materialiserade vyer. Se även Materialiserade vyer.

Arbeta med kapslade och komplexa datatyper

Azure Databricks stöder arbete med halvstrukturerade datakällor, inklusive JSON, Avro och ProtoBuff, och lagring av komplexa data som structs, JSON-strängar och kartor och matriser. Se Modellera halvstrukturerade data.

Normaliserade datamodeller

Azure Databricks kan fungera bra med alla datamodeller. Om du har en befintlig datamodell som du behöver för att köra frågor på eller migrera till Azure Databricks bör du utvärdera prestanda innan du omstrukturerar dina data.

Om du utformar ett nytt lakehouse eller lägger till datauppsättningar i en befintlig miljö rekommenderar Azure Databricks att du inte använder en kraftigt normaliserad modell, till exempel tredje normal form (3NF).

Modeller som star-schemat eller snowflake-schemat fungerar bra på Azure Databricks, eftersom det finns färre kopplingar i standardfrågor och färre nycklar att hålla synkroniserade. Om du har fler datafält i en enda tabell kan frågeoptimeraren dessutom hoppa över stora mängder data med hjälp av statistik på filnivå. Mer information om datahopp finns i Datahopp för Delta Lake.