Megosztás a következőn keresztül:


Részben strukturált adatok modellezése

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 számítási feladatokat írásokhoz vagy olvasásokhoz?

A Databricks azt javasolja, hogy deltatáblákként tárolja az adatokat az alsóbb rétegbeli lekérdezésekhez.

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:

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őket.

Számos rendszer sztring- vagy bájtkódolt JSON-rekordként adja ki a rekordokat. A rekordok betöltése és tárolása, mivel a sztringek feldolgozási terhelése nagyon alacsony. A függvény használatával to_json bármilyen adatstruktúrát JSON-sztringgé 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:

  • Streamelési adatok betöltése egy üzenetsor-szolgáltatásból, például a Kafkából.
  • Válaszok rögzítése REST API-lekérdezések.
  • Nyers rekordok tárolása olyan felsőbb rétegbeli adatforrásból, amelyet nem a csapata irányít.

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 ugyanúgy kezeli a tárolt adatokat, mint bármely más oszlopot, ami azt jelenti, hogy nincs funkcionális különbség a szerkezetektől és az oszlopoktól. A Delta Lake által használt Parquet-adatfájlok létrehoznak egy oszlopot a szerkezet minden mezőjéhez. A strukturált mezőket fürtözési vagy particionálási oszlopokként használhatja, és statisztikákat gyűjthet az adatkiugráshoz szükséges szerkezetekről.

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. A teljesítmény akkor szenvedhet, ha a jelen lévő oszlopok száma több százba kerül.

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 is be van adva, így az adatok előre fel vannak dolgozva, és a séma íráskor lesz kényszerítve.

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: