Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
Ez a cikk a részben strukturált adatok tárolására vonatkozó mintákat javasolja attól függően, hogy a szervezet hogyan használja fel az adatokat. Az Azure Databricks függvényeket, natív adattípusokat és lekérdezési szintaxist biztosít a félig strukturált, beágyazott és összetett adatok kezeléséhez.
A következő szempontok befolyásolják a használni kívánt mintát:
- Gyakran változnak az adatforrás mezői vagy típusai?
- Hány egyedi mező található az adatforrásban?
- Optimalizálnia kell a munkafolyamatokat az írási vagy olvasási műveletekhez?
Az alábbi táblázat összefoglalja a rendelkezésre álló megközelítéseket. Bármelyik mintát is választod, a Databricks azt javasolja, hogy az adatokat Delta táblázatként tárold a későbbi lekérdezésekhez.
| Approach | Legjobb a számára | Sémakezelés | Performance |
|---|---|---|---|
| Változat | Félig strukturált JSON, amely optimalizált tárolásból profitál | Rugalmas, hasonló alkalmazásokkal a JSON húrokhoz | Optimalizált kódolás, amely felülmúlja a JSON szövegeket olvasásban és írásban |
| JSON húrok | A nyers forrásadatok teljes, pontos ábrázolása | Nincs típusinformáció, és előfeldolgozás nem szükséges | Olvasás esetén ez a legrosszabb, mert a teljes karakterlánc minden lekérdezésnél feldolgozásra kerül |
| Szerkezetek | Olyan adat, amelyen jól ismert sémák vannak, ahol validált adatokat szeretnél | Írásra kényszerítve; előfeldolgozást igényel; kevésbé rugalmas a séma fejlődéséhez | Olvasásnál a legjobb, de több száz oszlop felett romlik a teljesítménye |
| Térképek és tömbök | Félig strukturált adathalmazok körülbelül 500 mezővel | A kulcsokat és értékeket íráskor gépeljük és érvényesítik | Kiegyensúlyozott az olvasás és írás terén, de a statisztikákat nem lehet gyűjteni |
Változat használata
A Databricks Runtime 15.3-ban és újabb verziókban a VARIANT típussal félig strukturált JSON-adatokat tárolhat optimalizált kódolással, amely felülmúlja az olvasási és írási JSON-sztringeket.
A VARIANT típus jSON-sztringekhez hasonló alkalmazásokat tartalmaz. Egyes számítási feladatok továbbra is kihasználják a szerkezetek, térképek és tömbök használatát, különösen olyan jól ismert sémákkal rendelkező adatok esetében, amelyek kihasználnák az optimalizált adatelrendezést és a statisztikák gyűjtését.
További részletekért tekintse meg az alábbi cikkeket:
- Variánsadatok lekérdezése
- Miben különbözik a változat a JSON-sztringekétól?
- Adatok betöltése félig strukturált változattípusként
JSON-sztringek használata
Az adatokat egyetlen sztringoszlopban tárolhatja szabványos JSON-formázással, majd : jelöléssel lekérdezheti a JSON mezőit.
Számos rendszer sztring- vagy bájtkódolt JSON-rekordként adja ki a rekordokat. E rekordok karakterláncként való beolvasása és tárolása nagyon alacsony feldolgozási többletterheléssel jár. A(z) to_json függvénnyel bármely adatszerkezetet JSON-karakterlánccá is alakíthat.
Az adatok JSON-sztringként való tárolásakor vegye figyelembe az alábbi erősségeket és gyengeségeket:
- Minden érték sztringként van tárolva, típusinformációk nélkül.
- A JSON támogatja az összes olyan adattípust, amely szöveg használatával jeleníthető meg.
- A JSON tetszőleges hosszúságú sztringeket támogat.
- Az egyetlen JSON-adatoszlopban megjeleníthető mezők száma nincs korlátozva.
- Az adatok nem igényelnek előzetes feldolgozást, mielőtt a táblába írnak.
- Az alsóbb rétegbeli számítási feladatokban található adatokban előforduló típusproblémákat megoldhatja.
- A JSON a legrosszabb teljesítményt nyújtja az olvasáshoz, mivel minden lekérdezéshez elemeznie kell a teljes sztringet.
A JSON-sztringek nagy rugalmasságot és könnyen implementálható megoldást biztosítanak a nyers adatok lakehouse-táblákba való beolvasásához. Számos alkalmazáshoz használhat JSON-sztringeket, de különösen akkor hasznosak, ha egy számítási feladat legfontosabb eredménye egy adatforrás teljes és pontos ábrázolása az alsóbb rétegbeli feldolgozáshoz. Néhány használati eset a következők lehetnek:
- Folyamatosan beérkező adatok betöltése egy üzenetsorkezelő szolgáltatásból, például a Kafkából.
- Válaszok rögzítése REST API lekérdezésekre.
- Nyers rekordok tárolása olyan forrásoldali adatforrásból, amelyet nem az Ön csapata felügyel.
Feltételezve, hogy a betöltési logika rugalmas, az adatok JSON-sztringként való tárolásának akkor is rugalmasnak kell lennie, ha új mezőket, adatszerkezeti változásokat vagy adatváltozásokat tapasztal az adatforrásban. Bár a lefelé irányuló számítási feladatok a módosítások miatt meghiúsulhatnak, a táblázat a forrásadatok teljes előzményeit tartalmazza, ami azt jelenti, hogy a problémákat anélkül orvosolhatja, hogy vissza kellene lépnie az adatforráshoz.
Szerkezetek használata
A részben strukturált adatokat strukturált szerkezetekkel tárolhatja, és engedélyezheti az oszlopok összes natív funkcióját, miközben fenntartja az adatforrás beágyazott struktúráját.
A Delta Lake lehetővé teszi az oszlopokhoz hasonló szerkezetek használatát. Egy Delta Lake-táblában a Parquet-adatfájlok létrehoznak egy oszlopot a szerkezet minden mezőjéhez. A struktúramezőket klaszterezési kulcsként használhatja, és statisztikákat gyűjthet a struktúrákról az adatátugrás támogatásához. A táblák strukturált mezővel nem particionálhatók. Használja helyette a liquid clusteringet. Lásd: Táblákhoz folyékony klaszterezés használata.
A szerkezetek általában a legjobb teljesítményt nyújtják az olvasáshoz, mivel támogatják az összes adatkiugrási optimalizálást, és az egyes mezőket oszlopként tárolják. Problémák merülhetnek fel a teljesítményben, amikor a jelen lévő oszlopok száma több százra növekszik.
A szerkezet minden mezője adattípussal rendelkezik, amelyet az oszlopokhoz hasonlóan íráskor kell kikényszeríteni. A szerkezetek így az adatok teljes előzetes feldolgozását igénylik. Ez akkor lehet hasznos, ha csak egy táblára vonatkozó érvényesített adatokat szeretne véglegesíteni, de a hibásan formázott rekordok felsőbb rétegbeli rendszerekből történő feldolgozásakor elvetett adatokhoz vagy sikertelen feladatokhoz vezethet.
A szerkezetek kevésbé rugalmasak, mint a JSON-adatfolyamok a sémafejlődéshez, legyen szó a változó adattípusokról vagy új mezők hozzáadásáról.
Térképek és tömbök használata
Térképek és tömbök kombinációjával natív módon replikálhatja a részben strukturált adatformátumokat a Delta Lake-ben. Az ilyen típusú mezőkön nem lehet statisztikákat gyűjteni, de kiegyensúlyozott teljesítményt nyújtanak az 500 mező körül lévő félig strukturált adathalmazok olvasása és írása terén is.
A térképek kulcsa és értéke tipizált, ezért az adatokat előre feldolgozzák, és a sémát íráskor érvényesítik.
A lekérdezések felgyorsítása érdekében a Databricks azt javasolja, hogy olyan mezőket tároljon, amelyeket gyakran használnak az adatok külön oszlopként való szűrésére.
Össze kell simítanom az adataimat?
Ha JSON vagy térképek használatával tárolja az adatokat, fontolja meg a lekérdezések oszlopként való szűréséhez gyakran használt mezők tárolását. A statisztikagyűjtés, particionálás és fürtözés nem érhető el JSON-sztringek vagy térképek mezőihez. Ezt nem kell elvégeznie a strukturáltként tárolt adatok esetében.
Szintaxis beágyazott adatokkal való munkavégzéshez
A beágyazott adatokkal kapcsolatos információkért tekintse át a következő erőforrásokat: