A Databricks fejlesztői ajánlott eljárásai

Ez az oldal ajánlott eljárásokat kínál az adatelemzéshez és a fejlesztési életciklushoz, beleértve a verziókövetést, a környezetkezelést, a fejlesztői eszközöket és a felügyelt üzembe helyezéseket.

Forrásvezérlő

Az összes fájl verziókövetése

A deklaratív automatizálás arra az elképzelésre épül, hogy ha valami nincs verziókövetésben, az nem létezik. Ezért a Databricks azt javasolja, hogy szinte minden fájlt vonjon verziókezelés alá, beleértve a következőket:

• Minden jegyzetfüzet és forrásfájl (.py, .sql)
• Csomagkonfigurációs fájlok (databricks.yml és környezetspecifikus YAML-felülbírálások)

Ne véglegesítse azonban a következőt:

• Összetevők, például .jar fájlok létrehozása .whl . Ehelyett töltse fel a lefordított bináris fájlokat a Unity Catalog-kötetekbe a CI-folyamat során. Lásd a jar feltöltését.
• Tokenek vagy hitelesítő adatok. Használjon egy felhőalapú titokkezelőre (például az AWS Secrets Managerre vagy az Azure Key Vaultra) épülő, munkaterületszintű titokkezelést, és szinkronizálja az értékeket a Databricks titokkörökbe. Lásd: Titkos kódok kezelése.
• Helyi adat példák és fájlok PII-vel. A kizárásukhoz használható .gitignore .

Önálló adattár

A Databricks azt javasolja, hogy egyetlen adattárat használjon az összes kódhoz (forráskódhoz és konfigurációs fájlokhoz), mivel megkönnyíti az együttműködést, valamint a kód- és ajánlott eljárások megosztását mind az emberek, mind az AI számára. Ha több csomaggal rendelkezik a különálló üzembehelyezési életciklusokhoz, tartsa őket egyetlen adattárban.

Az egyetlen adattárra vonatkozó javaslat alól kivételt képeznek a szabályozott iparágak, ahol több adattárra van szükség bizalmassági célokból.

Trunk-alapú elágaztatási stratégia

Az egyesítési ütközések minimalizálása és annak biztosítása érdekében, hogy a főág mindig telepíthető állapotban legyen, használjon trunk-alapú elágaztatási stratégiát.

Egy egyszerű munkafolyamat a következő:

1. Fejlessze helyileg vagy a munkaterületen, és helyezzen üzembe egy Databricks fejlesztői munkaterületen a módosítások teszteléséhez.
2. Hozzon létre egy rövid élettartamú funkcióágat a verziókövetési frissítésekhez, és rendszeresen szinkronizálja a helyi vagy a munkaterület módosításait.
3. Ha a tesztelés befejeződött, egyesítse a funkcióágat a fő ágba.
4. A CI/CD automatikusan üzembe helyezi a fő ágat egy átmeneti munkaterületen, és automatikus tesztek aktiválódnak.
5. Amikor az előkészítési tesztek és az ellenőrzések sikeresek, a CI/CD üzembe helyezi a fő ágat egy éles munkaterületen.

Ezeket a lépéseket az alábbi diagram ismerteti:

Munkaterület konfigurálása

Munkaterületi környezetek elkülönítése

A munkaterületi környezetek elkülönítése a sikertelen üzembe helyezés hatásának minimalizálása érdekében. Például:

• Kis csapatok (legfeljebb 5 adatmérnök): Induljon két munkaterülettel (fejlesztési és produkciós) egy felhőfiókon belül.
• Növekvő csapatok (legalább 5 adatmérnök): Térjenek át három munkaterületre (fejlesztési, tesztelési és éles). Az előkészítésnek funkcionálisan reprezentatívnak kell lennie az éles környezetre – ugyanazzal a csomagkonfigurációval, sémával és kritikus integrációval –, még akkor is, ha le van skálázva.
• Szabályozott iparágak (banki, egészségügyi, védelmi): Fizikailag elkülönítheti a munkaterületeket és a felhőfiókokat az adatszivárgás megelőzése érdekében. Az IAM- és Unity-katalógushatárokon keresztüli elkülönítés kezelése egyetlen fiókon belül lehetséges, de kevésbé robusztus biztonsági helyzetet biztosít.

Éles munkaterületekhez használjon szerver nélküli számítási kapacitást hálózati szabályzatok mellett, amikor csak lehetséges. Ellenkező esetben konfigurálja úgy a felhőfiókokat, hogy privát alhálózatokat vagy virtuális hálózatokat (VNeteket) használjanak szigorúan szabályozott kimenő forgalommal és hálózati biztonsági szabályozással.

További információ: Környezetalapú hálózati szabályzatok.

Adattárolás elkülönítése

• Használjon egyetlen Unity Catalog metastore-t, és hozzon létre külön katalógusokat a fejlesztői, az előkészítő (ha van ilyen) és az éles környezethez, a munkaterület felépítését tükrözve.
• Az egyes fejlesztők személyes sémáit használja a fejlesztési és tesztelési (nem éles) katalógusokhoz.
• Az éles katalógust ISOLATED módban csak az éles munkaterülethez kösse. A katalógus elkülönítési módjának ISOLATED értékre állítása biztosítja, hogy az éles adatok ne legyenek elérhetők a fejlesztési vagy stagingkörnyezetekből, még akkor sem, ha egy identitás hibásan van konfigurálva.
• Külön metaadattárakat, fiókokat vagy régiókat csak olyan szabályozási, adatelkülönítési vagy többrégiós követelményekkel rendelkező szervezetek számára foglaljon le, amelyeknek a katalógusszintű elkülönítés nem felel meg.

Tábla- és oszlop metaadatainak kezelése kódként

A tábla- és oszlopbejegyzéseket a kód részeként kezelheti. Tartsa őket fájlokban .sql a Deklaratív Automation-csomagok definíciói mellett, és helyezze üzembe őket egy metaadat-feladaton keresztül, hogy a pontos, üzleti szempontból elérhető definíciók mindig elérhetők legyenek. Írjon olyan megjegyzéseket, amelyek az oszlopnév ismétlése helyett egyszerű nyelven írják le a sorokat, az egységeket és az érvényes értékeket.

Személyes sémák konfigurálása

A fejlesztés során konfigurálja a csomagokat úgy, hogy felhasználónként személyes sémát használjanak, például dev_${user_name}. Ez megakadályozza, hogy a fejlesztők felülírják egymás tábláit egy megosztott munkaterületen.

Kiszolgáló nélküli számítás használata

Használjon kiszolgáló nélküli számítási megoldásokat a fürtkezelés egyszerűsítéséhez és a költségek optimalizálásához. Lásd: Csatlakozás kiszolgáló nélküli számításhoz.

CI/CD-re vonatkozó javaslatok

Deklaratív automatizálási csomagok CI/CD-hez

A Deklaratív Automation-csomagok (korábbi nevén Databricks Asset Bundles) hatékony, egységes megközelítést kínálnak a kód, munkafolyamatok és infrastruktúra Databricks-ökoszisztémán belüli kezeléséhez, és a CI/CD-folyamatokhoz ajánlottak.

A csomagok CI/CD-munkafolyamatokhoz való használatáról további információt a Databricks CI-/CD-munkafolyamatai című témakörben talál.

A deklaratív automatizálási csomagokról további információt a Deklaratív automatizálási csomagok című témakörben talál.

A Terraform használata csak külső erőforrásokhoz

A Terraform használatával definiálja a következő erőforrásokat:

• Felhőszintű és külső erőforrások
• Olyan rendszergazdai műveletek, amelyeket a nem kiemelt felhasználók nem hajtanak végre, például a munkaterület kiépítése vagy a felhőbeli hálózatkezelés konfigurálása

Deklaratív automation-csomagokat használhat az összes többi Databricks-erőforráshoz.

Csomagkezelés

Kis csomagok létrehozása

A Databricks kis, koncentrált csomagokat javasol egyetlen nagy csomagon keresztül.

• Helyezzen egy csomagba mindent, ami egy csapat tulajdonában van.
• Tesztelje és telepítse ugyanazon a CI/CD-folyamaton keresztül, amely ugyanazt az életciklust és kiadási ütemet használja.
• Minden csomagnak egy adott projekt összes környezetére (fejlesztés, előkészítés, éles környezet) kell kiterjednie, nem pedig külön kötegeket kell használnia környezetenként.

Hozzon létre külön csomagokat a következőhöz:

• Különböző termékek vagy tartományok, például "Számlázási elemzés" és "Csalásészlelés"
• Eltérő tulajdonosi vagy engedélyhatárok
• Egyértelműen eltérő életciklusú számítási feladatok
• Olyan esetek, amikor független előléptetésre vagy visszaállításra van szükség

Megosztott mappák szinkronizálása a sync.paths használatával

Ha több csomagot kezel egy adattárban, a sync.paths megosztott mappákat a csomag gyökerén kívülről szinkronizálhatja. Ez lehetővé teszi, hogy a különböző projektek közös tármappát osszanak meg, például ../commonkülönálló üzembehelyezési identitásokat fenntartva.

Csomagközi függőségek modellezése a CI/CD-ben

Ha a B csomag az A csomag által közzétett erőforrásoktól függ, akkor ezt a függőséget a CI/CD-folyamatban vagy az orchestration rétegben modellezd, ahelyett hogy mindkettőt egyetlen csomagba vonnád össze.

• Az A köteg üzembe helyezési és közzétételi munkafolyamata legyen a B köteg kifejezett előfeltétele. Állítsa be úgy a folyamatcsatornát, hogy a B köteg csak akkor induljon el, ha az A köteg üzembe helyezése sikeresen befejeződött, és az összes szükséges érvényesítési ellenőrzés megfelelt.
• Adja át a közzétett eszközazonosítókat vagy helyeket folyamatbemenetként, és gyorsan meghiúsul, ha hiányzik a felsőbb rétegbeli objektumok. Ez biztosítja, hogy a B csomag soha ne helyezzen üzembe részlegesen közzétett állapotban.

A csomagmegosztásról további információt a csomagok és a kötegfájlok megosztása című témakörben talál.

Egyéni csomagsablonok

Használja az egyéni deklaratív automatizálásicsomag-sablonokat az új projektek alapértelmezett kiindulópontjaként, hogy minden projekt ugyanazokat a korlátokat örökölje – az engedélyeket, a címkézést, a fürtszabályzatokat, a CI/CD-integrációt és a példányok alapkonfigurációit –, anélkül hogy ezt minden csapatnak a nulláról kellene megoldania.

A sablonoknak olyan megosztott, hosszú élettartamú konvenciókat kell kódolniuk, mint a szabályozás, a teljesítmény alapértelmezései, a környezet elrendezése és a kvótakorlátok. Kerülje az alkalmazásspecifikus üzleti logikát, titkos kulcsokat vagy egyszeri konfigurációt a sablonokban.

Csak olyan bemenetek paraméterezése, amelyek várhatóan csapat, projekt vagy környezet szerint változnak:

• Project vagy alkalmazás neve
• Cél-munkaterület beállításai
• Katalógus- vagy sémanevek
• Szolgáltatásnév-azonosítók
• Ütemezések és értesítési beállítások

A platformőrzőket és a megosztott alapértelmezett értékeket a sablonban kell rögzíteni a paraméterezés helyett.

Az egyéni csomagsablonokról és azok létrehozásáról a Deklaratív Automation Bundles projektsablonok című témakörben olvashat.

Visszaállítások és gyorsjavítások tervezése

Tartsa a csomagokat elég kicsinek ahhoz, hogy célzott visszaállítást hajtson végre egyetlen csomagon ahelyett, hogy összehangolja a visszaállítást számos nem kapcsolódó számítási feladat között.

Incidens során:

1. Állítsa vissza vagy görgesse vissza az érintett csomagot az utolsó ismerten jól működő verzióra.
2. Gyorsjavítást csak olyan sürgős, szűk hatókörű javításokhoz használjon, amelyek nem várhatják meg a normál promóciós folyamatot.
3. Az ellenőrzés után minden gyorsjavítást azonnal egyesítsen vissza a főágba, hogy a főág maradjon az egyetlen hiteles forrás.

Általános fejlesztés

Szolgáltatásnevek vagy OIDC használata

Az összes nem fejlesztési automatizáláshoz használjon egyszerű szolgáltatásneveket az automatizált munkafolyamatok leválasztásához az egyes felhasználói fiókoktól, és győződjön meg arról, hogy a belső felhasználók elhagyásakor a feladatok továbbra is futnak. Lásd Szolgáltatásfelelősök.

• Az üzembe helyezéshez és a futtatókörnyezethez használjon külön szolgáltatásneveket. A csomagtelepítésekhez szükséges dedikált üzembehelyezési szolgáltatásnévnek minimális adathozzáférésnek kell lennie. Minden produkciós feladatnak vagy folyamatnak saját, a futtatáshoz használt szolgáltatásazonosítóval kell rendelkeznie, amelynek hatóköre kizárólag az adott munkaterheléshez szükséges adatokra és erőforrásokra terjed ki. Ez a szétválasztás biztosítja, hogy a telepítések biztonságosak maradjanak az adathozzáférési jogosultságok rotálásakor vagy szigorításakor, és elkerülhetővé teszi, hogy az infrastruktúra módosításai az éles adatokhoz való hozzáféréshez legyenek kötve.
• Szabályozott iparágak: Használja a Workload Identity Federationt (OIDC) a CI/CD-hez. Ez kiküszöböli GitHub Actions vagy Azure DevOps hosszú életű titkos kulcsait. Lásd: Számítási feladatok identitás-összevonásának engedélyezése a CI/CD-ben.

A Databricks fejlesztői eszközeinek használata

Fejlesztés a Databricks-munkaterület felhasználói felületén a Git-mappák vagy egy helyi IDE használatával. Ha a Visual Studio Code-ot vagy annak egy kompatibilis változatát használja, telepítse a hivatalos Databricks-bővítményt az alábbiakhoz:

• Databricks-specifikus ügynökkészségek
• Unity-katalógus és fájlrendszer-hozzáférés
• Távoli fejlesztési képességek számítási feladatok Databricks-számításon való futtatásához

További információkért lásd: Databricks-bővítmény a Visual Studio Code-hoz.

Üzleti logika minimalizálása jegyzetfüzetekben

Ne kezelje a jegyzetfüzeteket az üzleti logika elsődleges tárolójaként. Csak feltáráshoz és vizualizációhoz használja őket.

• Python: Helyezze az alapvető logikát importálható .py modulokbasrc/, vagy src/py/hívja meg ezeket a függvényeket a jegyzetfüzetekből.
• SQL: A lekérdezéseket tartsa a(z) .sql vagy src/ helyen található src/sql/ fájlokban, és ezekre a fájlokra a feladatokból és a folyamatokból hivatkozzon ahelyett, hogy a jegyzetfüzetekbe foglalná bele az SQL-kódot.

A jegyzetfüzeteket csak olyan vékony vezénylési és vizualizációs rétegekként használja, amelyek a mögöttes kódot hívják. Ez a megközelítés megkönnyíti a tesztelést és az újbóli felhasználást.

A jegyzetfüzet-nehéz projektek migrálása során végezze el fokozatosan. Egyszerre egy újrafelhasználható modult vagy SQL-fájlt nyerhet ki, és deklaratív Automation-csomagok használatával a migrált eszközöket ugyanabban az üzembehelyezési és tesztelési munkafolyamatban hozhatja létre, mint a projekt többi része.

Kontextus dinamikus átadása

Kerülje a tevékenységfüggőségek statikus változóit. Használjon dinamikus értékhivatkozásokat, például {{tasks.<task_key>.values.<value_key>}} elemet, a futásidejű kontextus átadására a többszakaszos feladaton belüli feladatok között.

Tesztelés és megfigyelhetőség

Tesztelési rétegek implementálása

Használjon három tesztelési réteget, amelyek megfelelnek a csomagok éles környezetbe való áthelyezésének:

1. Egységtesztek: Tartsa meg az üzleti logikát importálható src/ modulokban, és fedje le vagy azzal egyenértékű keretrendszerrel pytest . Futtasd ezeket minden pull request esetén, hogy hiba esetén ne lehessen merge-elni.
2. Csomag ellenőrzése: Futtassa helyben a(z) bundle validate parancsot. A CI-ben inkább bundle deploy használjon, mint egy nem éles munkaterületet, hogy az éles telepítés előtt kiszűrje a YAML- és erőforrás-leképezési problémákat.
3. Integrációs tesztek staging környezetben: A staging környezetbe történő telepítés után futtasson end-to-end feladatokat lefutásellenőrzésekkel és kritikus adatminőségi ellenőrzésekkel, például a sorok számára vagy a sémára vonatkozó elvárásokkal.

A "minden teszt áthalad a fő ágon és az előkészítésben", mint az összetevők termelésre való előmozdításának kapuja.

A Lakeflow-folyamatok esetében a beépített fejlesztési és érvényesítési funkciókat használja az alkalmi jegyzetfüzet-futtatások helyett. Tesztelje a folyamat logikáját a hibákat tartalmazó rekordokat tartalmazó, kisméretű, reprezentatív adatkészleteken, és fejlesztési móddal ellenőrizze a változásokat az éles táblák frissítése előtt.

Tekintse a naplózást az üzembe helyezés részének

A deklaratív automation-csomagokban üzembe helyezett számítási feladatok esetében a metrikákat és a naplózást az üzembe helyezési szerződés részeként kell kezelnie, nem pedig az egyes projektek egymástól függetlenül definiált feladatait.

• Következetesen használ strukturált naplózást a feladatok, folyamatok és részfeladatok során. Adja meg a csomag nevét, a célkörnyezetet, a számítási feladat nevét, a futtatási azonosítót és a hibák nyomon követéséhez szükséges üzleti azonosítót.
• Minden éles számítási feladathoz tartozó működési metrikák standard készletének nyomon követése: futtatási állapot, időtartam, újrapróbálkozások száma, valamint átviteli sebesség- vagy frissességmutatók, ahol releváns.
• Ezeket az egyezményeket megosztott kódtárakban, újrafelhasználható számítási feladatok definícióiban vagy csomagsablonokban kódolja, hogy a csapatoknak ne kelljen újra létrehozniuk a megfigyelhetőségi mintákat az egyes projektekhez.