Modellera halvstrukturerade data
Den här artikeln rekommenderar mönster för lagring av halvstrukturerade data beroende på hur din organisation använder data. Azure Databricks tillhandahåller funktioner, interna datatyper och frågesyntax för att arbeta med halvstrukturerade, kapslade och komplexa data.
Följande överväganden påverkar vilket mönster du bör använda:
- Ändras fälten eller typerna i datakällan ofta?
- Hur många totala unika fält finns i datakällan?
- Behöver du optimera dina arbetsbelastningar för skrivningar eller läsningar?
Databricks rekommenderar att du lagrar data som Delta-tabeller för underordnade frågor.
Använda variant
I Databricks Runtime 15.3 och senare kan du använda VARIANT typen för att lagra halvstrukturerade JSON-data med en optimerad kodning som överträffar JSON-strängar för läsningar och skrivningar.
Typen VARIANT har liknande program som JSON-strängar. Vissa arbetsbelastningar drar fortfarande nytta av att använda structs, kartor och matriser, särskilt för data med välkända scheman som skulle dra nytta av optimerad datalayout och statistikinsamling.
Mer information finns i följande artiklar:
- Frågevariantdata
- Hur skiljer sig varianten från JSON-strängar?
- Mata in data som halvstrukturerad varianttyp
Använda JSON-strängar
Du kan lagra data i en enskild strängkolumn med JSON-standardformatering och sedan fråga efter fält i JSON med : notation.
Många system matar ut poster som sträng- eller bytekodade JSON-poster. Inmatning och lagring av dessa poster som strängar har mycket låg bearbetningskostnad. Du kan också använda to_json funktionen för att omvandla en struct av data till en JSON-sträng.
Tänk på följande styrkor och svagheter när du väljer att lagra data som JSON-strängar:
- Alla värden lagras som strängar utan typinformation.
- JSON stöder alla datatyper som kan representeras med hjälp av text.
- JSON stöder strängar med godtycklig längd.
- Det finns inga gränser för antalet fält som kan representeras i en enda JSON-datakolumn.
- Data kräver ingen förbearbetning innan de skrivs till tabellen.
- Du kan lösa typproblem som finns i data i underordnade arbetsbelastningar.
- JSON ger den sämsta prestandan vid läsning, eftersom du måste parsa hela strängen för varje fråga.
JSON-strängar ger stor flexibilitet och en lättimplementerad lösning för att få rådata till en lakehouse-tabell. Du kan välja att använda JSON-strängar för många program, men de är särskilt användbara när det viktigaste resultatet av en arbetsbelastning är att lagra en fullständig och korrekt representation av en datakälla för nedströmsbearbetning. Några användningsfall kan vara:
- Mata in strömmande data från en kötjänst, till exempel Kafka.
- Spela in svar på REST API-frågor.
- Lagra rådata från en överordnad datakälla som inte kontrolleras av ditt team.
Förutsatt att inmatningslogiken är flexibel bör lagring av data som en JSON-sträng vara motståndskraftig även om du stöter på nya fält, ändringar i datastrukturen eller typändringar i datakällan. Även om underordnade arbetsbelastningar kan misslyckas på grund av dessa ändringar innehåller tabellen en fullständig historik över källdata, vilket innebär att du kan åtgärda problem utan att behöva gå tillbaka till datakällan.
Använda structs
Du kan lagra halvstrukturerade data med structs och aktivera alla interna funktioner i kolumner samtidigt som datakällans kapslade struktur bibehålls.
Delta Lake behandlar data som lagras som structs på samma sätt som andra kolumner, vilket innebär att det inte finns någon funktionell skillnad från structs och kolumner. Parquet-datafilerna som används av Delta Lake skapar en kolumn för varje fält i en struct. Du kan använda strukturfält som klusterkolumner eller partitionkolumner, och du kan samla in statistik om strukturer för att hoppa över data.
Structs ger vanligtvis bästa prestanda vid läsoperationer, eftersom de stöder alla optimeringar för datasprång och lagrar enskilda fält som kolumner. Prestanda kan börja påverkas negativt när antalet kolumner når upp till hundratals.
Varje fält i en struct har en datatyp som framtvingas vid skrivning på samma sätt som kolumner. Därför kräver structs fullständig förbearbetning av data. Detta kan vara fördelaktigt när du bara vill att verifierade data ska checkas in i en tabell, men kan leda till borttagna data eller misslyckade jobb vid bearbetning av felaktiga poster från överordnade system.
Structs är mindre flexibla än JSON-strömmar för schemautveckling, oavsett om det är för att utveckla datatyper eller lägga till nya fält.
Använda kartor och matriser
Du kan använda en kombination av kartor och matriser för att replikera halvstrukturerade dataformat internt i Delta Lake. Det går inte att samla in statistik för fält som definierats med dessa typer, men de ger balanserade prestanda för både läsning och skrivning för halvstrukturerade datauppsättningar med cirka 500 fält.
Både nyckeln och värdet för kartor skrivs, så data bearbetas i förväg och schemat tillämpas vid skrivning.
För att påskynda frågor rekommenderar Databricks att du lagrar fält som ofta används för att filtrera data som separata kolumner.
Behöver jag platta ut mina data?
Om du lagrar dina data med JSON eller kartor bör du överväga att lagra fält som ofta används för att filtrera frågor som kolumner. Statistiksamling, partitionering och klustring är inte tillgängliga för fält i JSON-strängar eller kartor. Du behöver inte göra detta för data som lagras som structs.
Syntax för att arbeta med kapslade data
Granska följande resurser för information om hur du arbetar med kapslade data: