Adatobjektumok a Databricks lakehouse-ban

A Databricks lakehouse rendszerezi a Delta Lake-ben tárolt adatokat a felhőobjektum-tárolóban, olyan ismerős kapcsolatokkal, mint az adatbázis, a táblák és a nézetek. Ez a modell egyesíti a vállalati adattárház számos előnyét a data lake méretezhetőségével és rugalmasságával. Tudjon meg többet a modell működéséről, valamint az objektumadatok és a metaadatok közötti kapcsolatról, hogy a Databricks lakehouse tervezésekor és implementálásánál gyakorlati tanácsokat alkalmazzon a szervezet számára.

Milyen adatobjektumok találhatók a Databricks lakehouse-ban?

A Databricks lakehouse architektúra a Delta Lake protokollal a felhőbeli objektumtárban tárolt adatokat kombinálja a metaadattárban regisztrált metaadatokkal. A Databricks-tóházban öt elsődleges objektum található:

• Katalógus: adatbázisok csoportosítása.
• Adatbázis vagy séma: objektumok csoportosítása egy katalógusban. Az adatbázisok táblákat, nézeteket és függvényeket tartalmaznak.
• Táblázat: az objektumtárolóban adatfájlként tárolt sorok és oszlopok gyűjteménye.
• Nézet: Egy mentett lekérdezés általában egy vagy több táblán vagy adatforráson.
• Függvény: mentett logika, amely skaláris értéket vagy sorkészletet ad vissza.

Az objektumok Unity Catalogban való védelméről további információt a biztonságos objektummodellben talál.

Mi az a metaadattár?

A metaadattár tartalmazza a tóházban található adatobjektumokat meghatározó összes metaadatot. Az Azure Databricks a következő metaadattár-beállításokat biztosítja:

• Unity Catalog metaadattár: A Unity Catalog központosított hozzáférés-vezérlési, naplózási, életút- és adatfelderítési képességeket biztosít. Unity Catalog-metaadattárakat az Azure Databricks-fiók szintjén hozhat létre, és egyetlen metaadattár több munkaterületen is használható.

  Minden Unity Catalog-metaadattár egy gyökértárolóval van konfigurálva egy Azure Data Lake Storage Gen2-tárolóban az Azure-fiókban. Ez a tárolási hely alapértelmezés szerint a felügyelt táblák adatainak tárolására szolgál.

  A Unity Catalogban az adatok alapértelmezés szerint biztonságosak. A felhasználók kezdetben nem férnek hozzá a metaadattárban lévő adatokhoz. A hozzáférést egy metaadattár rendszergazdája vagy egy objektum tulajdonosa adhatja meg. Securable objects in Unity Catalog are hierarchical and privileges are inherited downward. A Unity Catalog egyetlen helyet kínál az adatelérési szabályzatok felügyeletéhez. A felhasználók a Unity Katalógusban lévő adatokat bármely olyan munkaterületről elérhetik, amelyhez a metaadattár csatolva van. További információ: Jogosultságok kezelése a Unity Katalógusban.

• Beépített Hive metaadattár (örökölt): Minden Azure Databricks-munkaterület tartalmaz egy beépített Hive metaadattárat felügyelt szolgáltatásként. A metaadattár egy példánya minden fürtön üzembe helyezve biztonságosan hozzáfér a metaadatokhoz az egyes ügyfél-munkaterületek központi adattárából.

  A Hive metaadattár kevésbé központosított adatszabályozási modellt biztosít, mint a Unity Catalog. A fürtök alapértelmezés szerint lehetővé teszik, hogy minden felhasználó hozzáférjen a munkaterület beépített Hive metaadattára által kezelt összes adathoz, kivéve, ha a táblahozzáférés-vezérlés engedélyezve van az adott fürthöz. További információ: Hive metaadattár táblahozzáférés-vezérlés (örökölt).

  A táblahozzáférés-vezérlők nem fiókszinten vannak tárolva, ezért ezeket külön kell konfigurálni az egyes munkaterületekhez. A Unity Catalog által biztosított központosított és egyszerűsített adatszabályozási modell előnyeinek kihasználásához a Databricks azt javasolja, hogy frissítse a munkaterület Hive-metaadattára által kezelt táblákat a Unity Catalog metaadattárra.

• Külső Hive metaadattár (örökölt): Saját metaadattárat is használhat az Azure Databricksben. Az Azure Databricks-fürtök csatlakozhatnak a meglévő külső Apache Hive-metaadattárakhoz. A táblahozzáférés-vezérléssel kezelheti egy külső metaadattár engedélyeit. A táblahozzáférés-vezérlők nincsenek tárolva a külső metaadattárban, ezért ezeket külön kell konfigurálni az egyes munkaterületekhez. A Databricks azt javasolja, hogy az egyszerűség és a fiókközpontú szabályozási modell helyett a Unity Catalogot használja.

A használt metaadattártól függetlenül az Azure Databricks az összes táblaadatot objektumtárolóban tárolja a felhőfiókjában.

Mi az a katalógus?

A katalógus a Databricks lakehouse-relációs modell legmagasabb absztrakciója (vagy durvaszemcséje). Minden adatbázis katalógushoz lesz társítva. A katalógusok objektumként léteznek egy metaadattárban.

A Unity Catalog bevezetése előtt az Azure Databricks kétrétegű névteret használt. A katalógusok a Unity Catalog névkészítési modelljének harmadik szintje:

catalog_name.database_name.table_name

A beépített Hive metaadattár csak egyetlen katalógust támogat. hive_metastore

Mi az az adatbázis?

Az adatbázisok adatobjektumok, például táblák vagy nézetek (más néven "kapcsolatok") és függvények gyűjteményei. Az Azure Databricksben a "séma" és az "adatbázis" kifejezések felcserélhetők (míg számos relációs rendszerben az adatbázis sémák gyűjteménye).

Az adatbázisok mindig a felhőobjektum-tároló helyéhez lesznek társítva. Az adatbázis regisztrálásakor megadhat egy LOCATION értéket, és ne feledje, hogy:

• Az LOCATION adatbázishoz társított hely mindig felügyelt helynek minősül.
• Az adatbázis létrehozása nem hoz létre fájlokat a célhelyen.
• Az LOCATION adatbázis határozza meg az adatbázishoz regisztrált összes tábla adatainak alapértelmezett helyét.
• Az adatbázis sikeres elvetése rekurzív módon elveti a felügyelt helyen tárolt összes adatot és fájlt.

Az adatbázis és az adatfájlok által felügyelt helyek közötti interakció nagyon fontos. Az adatok véletlen törlésének elkerülése érdekében:

• Ne ossza meg az adatbázis-helyeket több adatbázis-definíció között.
• Ne regisztráljon adatbázist olyan helyre, amely már tartalmaz adatokat.
• Ha adatbázistól függetlenül szeretné kezelni az adatok életciklusát, mentse az adatokat olyan helyre, amely nincs beágyazva egyetlen adatbázis-helyre sem.

Mi az a tábla?

Az Azure Databricks-táblák strukturált adatok gyűjteményei. A Delta-táblák fájlkönyvtárként tárolják az adatokat a felhőobjektum-tárolóban, és regisztrálják a tábla metaadatait a katalógusban és a sémában lévő metaadattárba. Mivel a Delta Lake az Azure Databricksben létrehozott táblák alapértelmezett tárolási szolgáltatója, a Databricksben létrehozott táblák alapértelmezés szerint Delta-táblák. Mivel a Delta-táblák a felhőalapú objektumtárban tárolják az adatokat, és metaadattáron keresztül nyújtanak hivatkozásokat az adatokra, a szervezet felhasználói az előnyben részesített API-k használatával férhetnek hozzá az adatokhoz; a Databricksen ez az SQL, a Python, a PySpark, a Scala és az R.

Vegye figyelembe, hogy a Databricksen olyan táblák hozhatók létre, amelyek nem Delta-táblák. Ezek a táblák nem a Delta Lake által támogatottak, és nem biztosítják az ACID-tranzakciókat és a Delta-táblák optimalizált teljesítményét. Az ebbe a kategóriába tartozó táblák közé tartoznak a külső rendszerekben lévő adatokon regisztrált táblák, valamint a data lake más fájlformátumaiban regisztrált táblák. Lásd az adatforrások Csatlakozás.

A Databricksben kétféle tábla található, felügyelt és nem felügyelt (vagy külső) táblák.

Megjegyzés:

Az élő és streamelt élő táblák közötti Delta Élő táblázatok különbséget nem kényszeríti ki a táblázat szempontjából.

Mi az a felügyelt tábla?

Az Azure Databricks kezeli a felügyelt táblák metaadatait és adatait is; amikor elvet egy táblát, a mögöttes adatokat is törli. Ezt a viselkedést az adatelemzők és más, többnyire SQL-ben dolgozó felhasználók is előnyben részesíthetik. Tábla létrehozásakor a felügyelt táblák az alapértelmezettek. A felügyelt táblák adatai abban az LOCATION adatbázisban találhatók, amelyben regisztrálva van. Az adathely és az adatbázis közötti felügyelt kapcsolat azt jelenti, hogy egy felügyelt tábla új adatbázisba való áthelyezéséhez minden adatot át kell írnia az új helyre.

A felügyelt táblák számos módon hozhatók létre, például:

CREATE TABLE table_name AS SELECT * FROM another_table

CREATE TABLE table_name (field_name1 INT, field_name2 STRING)

df.write.saveAsTable("table_name")

Mi az a nem felügyelt tábla?

Az Azure Databricks csak a nem felügyelt (külső) táblák metaadatait kezeli; tábla elvetésekor nincs hatással a mögöttes adatokra. A nem felügyelt táblák mindig megadnak egy táblát LOCATION a tábla létrehozásakor. Regisztrálhat egy meglévő adatfájl-könyvtárat táblaként, vagy megadhat egy elérési utat a táblák első definiálásakor. Mivel az adatok és a metaadatok egymástól függetlenül vannak kezelve, átnevezhet vagy regisztrálhat egy új adatbázisba anélkül, hogy adatokat kellene áthelyeznie. Az adatmérnökök gyakran előnyben részesítik a nem felügyelt táblákat és az éles adatokhoz biztosított rugalmasságot.

A nem felügyelt táblák számos módon hozhatók létre, például:

CREATE TABLE table_name
USING DELTA
LOCATION '/path/to/existing/data'

CREATE TABLE table_name
(field_name1 INT, field_name2 STRING)
LOCATION '/path/to/empty/directory'

df.write.option("path", "/path/to/empty/directory").saveAsTable("table_name")

Mi az a nézet?

A nézet általában egy lekérdezés szövegét tárolja egy vagy több adatforráson vagy táblán a metaadattárban. A Databricksben a nézet egyenértékű az adatbázisban objektumként tárolt Spark DataFrame-ekkel. A DataFrame-ekkel ellentétben a Databricks-termék bármely részéből lekérdezheti a nézeteket, feltéve, hogy rendelkezik erre vonatkozó engedéllyel. A nézet létrehozása nem dolgoz fel és nem ír adatokat; csak a lekérdezési szöveg van regisztrálva a társított adatbázis metaadattárában.

Mi az az ideiglenes nézet?

Az ideiglenes nézet hatóköre és megőrzése korlátozott, és nincs regisztrálva sémában vagy katalógusban. Az ideiglenes nézet élettartama a használt környezettől függően eltérő:

• A jegyzetfüzetekben és a feladatokban az ideiglenes nézetek hatóköre a jegyzetfüzet vagy a szkript szintjére terjed ki. Nem hivatkozhatnak rájuk azon a jegyzetfüzeten kívül, amelyben deklarálva vannak, és a továbbiakban nem léteznek, amikor a jegyzetfüzet leválasztja őket a fürtről.
• A Databricks SQL-ben az ideiglenes nézetek hatóköre a lekérdezési szintre terjed ki. Az ugyanabban a lekérdezésben több utasítás is használhatja az ideiglenes nézetet, de más lekérdezésekben nem hivatkozhat rá, még ugyanazon az irányítópulton belül sem.
• A globális ideiglenes nézetek hatóköre a fürt szintjére terjed ki, és megoszthatók a számítási erőforrásokat használó jegyzetfüzetek vagy feladatok között. A Databricks a globális ideiglenes nézetek helyett a megfelelő tábla ACL-ekkel rendelkező nézeteket javasolja.

Mi az a függvény?

A függvényekkel felhasználó által definiált logikát társíthat egy adatbázishoz. A függvények skaláris értékeket vagy sorhalmazokat is visszaadhatnak. A függvények az adatok összesítésére szolgálnak. Az Azure Databricks lehetővé teszi, hogy a végrehajtási környezettől függően különböző nyelveken mentse a függvényeket, és az SQL széles körben támogatott. Függvényekkel felügyelt hozzáférést biztosíthat az egyéni logikához a Databricks-termék számos környezetében.

Hogyan működnek a relációs objektumok a Delta Live Tablesben?

A Delta Live Tables deklaratív szintaxist használ a DDL, a DML és az infrastruktúra üzembe helyezésének definiálásához és kezeléséhez. A Delta Live Tables a "virtuális séma" fogalmát használja a logikai tervezés és végrehajtás során. A Delta Live Tables a Databricks-környezetben más adatbázisokkal is kommunikálhat, a Delta Live Tables pedig közzéteheti és megőrizheti a táblákat máshol történő lekérdezéshez egy céladatbázis megadásával a folyamatkonfigurációs beállításokban.

A Delta Live-táblákban létrehozott táblák mindegyike Delta-táblák. Ha a Unity Katalógust Delta Live-táblákkal használja, az összes tábla Unity Catalog által felügyelt táblák. Ha a Unity Katalógus nem aktív, a táblák felügyelt vagy nem felügyelt táblákként deklarálhatók.

Bár a nézetek deklarálhatók a Delta Live Táblákban, ezeket a folyamatra vonatkozó ideiglenes nézeteknek kell tekinteni. A Delta Live Tables ideiglenes táblái egyedi fogalomnak számítanak: ezek a táblák megőrzik az adatokat a tárolóban, de nem tesznek közzé adatokat a céladatbázisban.

Egyes műveletek, például APPLY CHANGES INTOegy tábla és egy nézet is regisztrálva lesznek az adatbázisba; a tábla neve aláhúzással (_) kezdődik, a nézetben pedig a tábla neve lesz deklarálva a APPLY CHANGES INTO művelet céljaként. A nézet lekérdezi a megfelelő rejtett táblát az eredmények materializálásához.