Osvědčené postupy pro vývojáře v Databricks

Tato stránka obsahuje osvědčené postupy pro váš životní cyklus přípravy a vývoje dat, včetně správy verzí, správy prostředí, nástrojů pro vývojáře a spravovaných nasazení.

Správa zdrojového kódu

Správa verzí – všechny soubory

Deklarativní automatizace je založená na myšlence, že pokud něco není ve správě verzí, neexistuje. Databricks proto doporučuje spravovat ve správě verzí téměř všechny soubory, včetně:

• Všechny poznámkové bloky a zdrojové soubory (.py, .sql)
• Konfigurační soubory balíčku (databricks.yml a přepisující soubory YAML specifické pro dané prostředí)

Neprovádějte však commit:

• Vytváření artefaktů, jako .jar jsou soubory nebo .whl artefakty Místo toho nahrajte kompilované binární soubory do svazků katalogu Unity během CI. Viz nahraj JAR.
• Tokeny nebo přihlašovací údaje. Používejte správu tajných kódů na úrovni pracovního prostoru založené na správci cloudových tajných kódů (například AWS Secrets Manager nebo Azure Key Vault) a synchronizujte hodnoty do rozsahů tajných kódů Databricks. Viz správa tajemství.
• Příklady místních dat a soubory s PII Slouží .gitignore k jejich vyloučení.

Jedno úložiště

Databricks doporučuje používat jedno úložiště pro všechny vaše kódy (zdrojový kód a konfigurační soubory), protože usnadňuje spolupráci a sdílení kódu a osvědčených postupů pro lidi i AI. Pokud máte více sad pro samostatné životní cyklus nasazení, ponechte je v jednom úložišti.

Jedinou výjimkou doporučení pro jedno úložiště je v regulovaných odvětvích, kde je pro účely důvěrnosti nezbytné více úložišť.

Strategie větvení založené na kmenech

Pokud chcete minimalizovat konflikty při slučování a zajistit, aby hlavní větev byla vždy v nasaditelném stavu, použijte strategii větvení na základě kmene.

Jednoduchý pracovní postup by byl:

1. Vývoj místně nebo v pracovním prostoru a nasazení do vývojového pracovního prostoru Databricks za účelem testování změn
2. Vytvořte krátkodobou větev funkcí pro aktualizace správy verzí a pravidelně synchronizujte místní změny nebo změny pracovního prostoru.
3. Po dokončení testování sloučíte větev funkce do hlavní větve.
4. CI/CD automaticky nasadí hlavní větev do přípravného pracovního prostoru a spustí se automatizované testy.
5. Když přípravné testy a kontroly projdou, CI/CD nasadí hlavní větev do produkčního pracovního prostoru.

Tyto kroky jsou popsány v následujícím diagramu:

Konfigurace pracovního prostoru

Izolace prostředí pracovního prostoru

Izolujte prostředí pracovního prostoru, abyste minimalizovali dopad neúspěšného nasazení. Příklad:

• Malé týmy (až 5 datových inženýrů): Začněte se dvěma pracovními prostory (vývoj a produkce) v jednom cloudovém účtu.
• Rostoucí týmy (5+ datoví inženýři):: Přechod do tří pracovních prostorů (vývoj, příprava a produkce). Stagingové prostředí by mělo funkčně odpovídat produkčnímu prostředí – mít stejnou konfiguraci balíčků, schéma a kritické integrace – i když je v menším měřítku.
• Regulovaná odvětví (bankovnictví, zdravotnictví, obrana): Fyzicky izolují pracovní prostory a cloudové účty, aby se zabránilo úniku dat. Správa izolace prostřednictvím hranic katalogu IAM a Unity v rámci jednoho účtu je možná, ale poskytuje méně robustní stav zabezpečení.

V případě produkčních pracovních prostorů používejte bezserverové výpočetní prostředky se zásadami sítě, pokud je to možné. V opačném případě nakonfigurujte cloudové účty tak, aby používaly privátní podsítě nebo virtuální sítě s úzce řízenými výstupními a síťovými bezpečnostními prvky.

Další informace naleznete v tématu Kontextové zásady sítě.

Izolace úložiště dat

• Použijte jediný metastore služby Unity Catalog a vytvořte samostatné katalogy pro vývoj, staging (pokud je relevantní) a produkci tak, aby odpovídaly uspořádání vašich pracovních prostorů.
• Používejte osobní schémata pro jednotlivé vývojáře pro vývojové a přípravné (neprodukční) katalogy.
• Připojte produkční katalog v režimu ISOLATED pouze k produkčnímu pracovnímu prostoru. Nastavením režimu izolace katalogu na ISOLATED zajistíte, že produkční data budou nedostupná z vývojových nebo testovacích prostředí, i když je některá identita chybně nakonfigurovaná.
• Vyhraďte si samostatné metastory, účty nebo oblasti pouze pro organizace s zákonnými požadavky, suverenitou dat nebo více oblastmi, které izolace na úrovni katalogu nesplňuje.

Zacházení s metadaty tabulek a sloupců jako s kódem

Zacházet s komentáři tabulek a sloupců jako součástí kódu Udržujte je v souborech .sql společně s definicemi Declarative Automation Bundles a nasaďte je pomocí úlohy metadat, aby byly vždy k dispozici přesné a srozumitelné definice pro obchodní uživatele. Napište komentáře, které popisují, co řádek představuje, jednotky a platné hodnoty v prostém jazyce, a neopakujte název sloupce.

Konfigurace osobních schémat

Během vývoje nakonfigurujte sady pro použití osobního schématu pro jednotlivé uživatele, například dev_${user_name}. To vývojářům brání v přepsání tabulek mezi sebou ve sdíleném pracovním prostoru.

Použití bezserverového výpočetního prostředí

Použití bezserverového výpočetního prostředí ke zjednodušení správy clusteru a optimalizaci nákladů Viz Připojení k výpočetním prostředkům bez serveru.

Doporučení CI/CD

Deklarativní balíčky automatizace pro CI/CD

Deklarativní balíčky automatizace (dříve Označované jako Sady prostředků Databricks) nabízejí výkonný, jednotný přístup ke správě kódu, pracovních postupů a infrastruktury v ekosystému Databricks a doporučuje se pro vaše kanály CI/CD.

Další podrobnosti o používání sad pro pracovní postupy CI/CD najdete v pracovních postupech CI/CD v Databricks.

Další informace o deklarativních balíčcích automatizace naleznete v tématu Co jsou deklarativní automatizační sady?.

Používejte Terraform pouze pro externí zdroje

Pomocí Terraformu definujte následující prostředky:

• Cloudové a externí prostředky
• Akce správce, které by uživatelé bez oprávnění neměli provádět, jako je zřizování pracovních prostorů nebo konfigurace cloudových sítí

Pro všechny ostatní prostředky Databricks použijte balíčky deklarativní automatizace.

Správa balíčků

Vytvořte malé balíčky

Databricks doporučuje vytvářet malé, zaměřené balíčky namísto jednoho velkého balíčku.

• Dejte všechno, co jeden tým vlastní, do jedné sady.
• Testujte a nasazujte prostřednictvím stejného kanálu CI/CD, který má stejný životní cyklus a frekvenci vydávání.
• Každá sada by měla zahrnovat všechna prostředí pro daný projekt (vývoj, příprava, produkční prostředí) místo použití samostatných sad pro každé prostředí.

Vytvořte samostatné sady pro:

• Různé produkty nebo domény, například Analýza fakturace a Detekce podvodů
• Různé hranice vlastnictví nebo oprávnění
• Úlohy s jasně odlišnými životními cykly
• Případy, kdy potřebujete nezávislé povýšení nebo vrácení zpět

Synchronizace sdílených složek pomocí sync.paths

Při správě více sad v jednom úložišti použijte sync.paths k synchronizaci sdílených složek mimo kořenový adresář sady. To umožňuje různým projektům sdílet společnou složku knihovny, například ../common, při zachování samostatných identit nasazení.

Modelovat závislosti mezi balíčky v CI/CD

Pokud sada B závisí na artefaktech publikovaných sadou A, namodelujte tuto závislost ve vrstvě CI/CD nebo orchestrace namísto sloučení obou do jedné sady.

• Nastavte workflow nasazení a publikování sady A jako výslovnou podmínku pro sadu B. Nakonfigurujte pipeline tak, aby se sada B spustila až po úspěšném nasazení sady A a po splnění všech požadovaných ověřovacích kontrol.
• Předejte publikované identifikátory prostředků nebo umístění vpřed jako vstupy kanálu a pokud chybí nadřazené prostředky, rychle selžou. Tím se zajistí, že se Bundle B nikdy nenasadí vůči částečně publikovanému stavu.

Další informace o sdílení sad najdete v tématu Sdílení sad a souborů sad.

Vlastní šablony balíčků

Jako výchozí výchozí bod pro nové projekty použijte vlastní šablony Deklarativní automatizace, aby každý projekt zdědil stejné mantinely – oprávnění, označování, zásady clusteru, zapojení CI/CD a směrné plány instancí – bez nutnosti řešení od začátku každého týmu.

Šablony by měly kódovat sdílené dlouhodobé konvence, jako jsou zásady správného řízení, výchozí hodnoty výkonu, rozložení prostředí a limity kvót. V šablonách se vyhněte obchodní logice, tajným kódům nebo jednorázové konfiguraci specifické pro aplikace.

Parametrizovat pouze vstupy, které se mají lišit podle týmu, projektu nebo prostředí:

• Project nebo název aplikace
• Nastavení cílového pracovního prostoru
• Názvy katalogů nebo schémat
• Identifikátory instančního objektu
• Plány a nastavení oznámení

Zachovejte ochranné mantinely platformy a sdílené výchozí hodnoty pevně nastavené v šabloně, nikoli jejich parametrizaci.

Informace o vlastních šablonách balíčků a o tom, jak je vytvořit, najdete v části Šablony projektů Declarative Automation Bundles.

Plánujte návrat k předchozí verzi a rychlé opravy

Udržujte balíčky dostatečně malé, abyste mohli cíleně vrátit změny u jednoho balíčku, místo abyste museli koordinovat vrácení změn napříč mnoha nesouvisejícími pracovními zátěžemi.

Během incidentu:

1. Vraťte dotčený balíček na poslední známou funkční verzi.
2. Hotfix používejte pouze pro naléhavé opravy s úzce vymezeným rozsahem, které nemohou čekat na běžný proces nasazení.
3. Každý hotfix po ověření ihned slučte zpět do hlavní větve, aby hlavní větev zůstala jediným zdrojem pravdy.

Obecný vývoj

Použití instančních objektů nebo OIDC

Instanční objekty můžete použít pro všechny automatizace nesouvisecí s vývojem k oddělení automatizovaných pracovních postupů od jednotlivých uživatelských účtů a zajištění toho, aby úlohy pokračovaly v provozu, když odcházejí interní uživatelé. Viz principály služeb.

• Pro nasazení i za běhu použijte samostatné instanční objekty služby. Vyhrazený instanční objekt služby pro nasazení balíčků by měl mít minimální přístup k datům. Každá produkční úloha nebo pipeline by měla mít svůj vlastní instanční objekt služby používaný ke spouštění s oprávněními omezenými pouze na data a prostředky, které daná úloha nebo pipeline vyžaduje. Toto oddělení zajišťuje, že nasazení zůstanou bezpečná, když měníte nebo zpřísňujete oprávnění k přístupu k datům, a zabraňuje provázání změn infrastruktury s přístupem k produkčním datům.
• Regulovaná odvětví: Pro CI/CD použijte federaci identit úloh (OIDC). Tím se eliminují dlouhodobé tajné kódy v GitHub Actions nebo Azure DevOps. Viz Jak povolit federaci identit úloh v CI/CD.

Použití vývojářských nástrojů Databricks

Vyvíjejte v uživatelském rozhraní pracovního prostoru Databricks pomocí složek Git nebo v místním integrovaném vývojovém prostředí (IDE). Pokud používáte Visual Studio Code nebo kompatibilní fork, nainstalujte oficiální rozšíření Databricks pro:

• Dovednosti agenta specifické pro Databricks
• Katalog Unity a přístup k systému souborů
• Možnosti vzdáleného vývoje pro spouštění úloh na výpočetních prostředcích Databricks

Další informace najdete v tématu Rozšíření Databricks pro Visual Studio Code.

Minimalizujte obchodní logiku v poznámkových blocích

Nezacházejte s poznámkovými bloky jako s primárním kontejnerem pro obchodní logiku. Používejte je jenom pro zkoumání a vizualizaci.

• Python: Umístěte základní logiku do importovatelných .py modulů v src/ nebo src/py/ a tyto funkce volejte z notebooků.
• SQL: Uchovávejte dotazy v .sql souborech v umístěních src/ nebo src/sql/ a odkazujte na tyto soubory z úloh a pipelineů namísto vkládání SQL do poznámkových bloků.

Poznámkové bloky používejte pouze jako odlehčené vrstvy orchestrace a vizualizace, které volají podkladový kód. Tento přístup usnadňuje testování a opakované použití.

Při migraci projektu náročného na poznámkový blok to udělejte postupně. Extrahujte jeden opakovaně použitelný modul nebo soubor SQL a pomocí deklarativních automatizačních sad přineste migrované prostředky do stejného pracovního postupu nasazení a testování jako zbytek projektu.

Dynamické předávání kontextu

Vyhněte se statickým proměnným pro závislosti úkolů. Použijte odkazy na dynamické hodnoty, jako je {{tasks.<task_key>.values.<value_key>}}, k předávání kontextu za běhu mezi úkoly ve vícefázové úloze.

Testování a pozorovatelnost

Implementace testovacích vrstev

Použijte tři vrstvy testování, které odpovídají způsobu, jakým se vaše sady pohybují k produkčnímu prostředí:

1. Jednotkové testy: Udržujte byznys logiku v importovatelných modulech src/ a pokryjte ji pomocí pytest nebo ekvivalentního frameworku. Spouštějte je u každého pull requestu, aby případná selhání zablokovala sloučení.
2. Ověření balíčku: Spusťte bundle validate lokálně. V CI preferujte bundle deploy neprodukční pracovní prostor, abyste před nasazením do produkčního prostředí zachytili problémy s YAML a mapováním prostředků.
3. Integrační testy ve stagingu: Po nasazení do staging prostředí spusťte end-to-end úlohy s kontrolami dokončení a kritickými ověřeními kvality dat, jako je ověření počtu řádků nebo očekávaného schématu.

Považujte „že všechny testy projdou v hlavní větvi i ve stagingu“ za podmínku pro povýšení artefaktů do produkce.

Pro Lakeflow Spark Declarative Pipelines používejte integrované funkce pro vývoj a ověřování namísto ad hoc spouštění notebooků. Otestujte logiku kanálu s malými reprezentativními datovými sadami, které obsahují záznamy s chybami, a pomocí vývojového režimu ověřte změny před aktualizací produkčních tabulek.

Považujte protokolování za součást nasazení

Pro úlohy nasazené deklarativní automatizací zacházejte s metrikami a protokolováním jako součást kontraktu nasazení, nikoli s tím, co každý projekt definuje nezávisle.

• Generujte strukturované logy konzistentně napříč joby, pipelinemi a úkoly. Zahrňte název sady prostředků, cílové prostředí, název úlohy, identifikátor spuštění a jakýkoli obchodní identifikátor potřebný k trasování selhání.
• Sledujte standardní sadu provozních metrik pro každou produkční úlohu: stav spuštění, dobu trvání, počet opakování a indikátory propustnosti nebo aktuálnosti, pokud jsou relevantní.
• Kódujte tyto konvence ve sdílených knihovnách, opakovaně použitelných definicích úloh nebo šablonách sad, aby týmy nemusely pro každý projekt znovu vytvářet vzory pozorovatelnosti.