Nejčastější dotazy k deklarativním balíčkům automatizace

Tento článek obsahuje nejčastější dotazy týkající se deklarativních automatizačních sad (dříve označovaných jako Sady prostředků Databricks).

Proč byly sady prostředků Databricks přejmenovány na deklarativní automatizační sady?

Nový název Deklarativní automatizační sady přesněji odráží využití a možnosti sad. Kromě toho termín aktiva způsobil určité nejasnosti, protože v Databricks má více než jeden význam. Tato změna názvu není zásadní. Příkaz bundle rozhraní příkazového řádku a vaše stávající konfigurace není třeba upravovat.

Jak můžu jako součást svého kanálu CI/CD v Azure Databricks používat balíčky deklarativní automatizace?

Balíčky deklarativní automatizace můžete použít k definování a programové správě prostředků v implementaci CI/CD v Azure Databricks, které obvykle zahrnují:

  • Poznámkové bloky: Poznámkové bloky Azure Databricks jsou často klíčovou součástí pracovních postupů datového inženýrství a datové vědy. Pro notebooky můžete použít verzování a také je ověřit a otestovat jako součást CI/CD pipeline. U poznámkových bloků můžete spustit automatizované testy a zkontrolovat, jestli fungují podle očekávání.
  • Knihovny: Spravujte závislosti knihovny potřebné ke spuštění nasazeného kódu. Používejte správu verzí u knihoven a zahrňte je do automatizovaného testování a ověřování.
  • Pracovní postupy: Úlohy Lakeflow se skládají z úloh, které umožňují plánovat a spouštět automatizované úlohy pomocí poznámkových bloků nebo úloh Sparku.
  • Datové kanály: Datové kanály můžete také zahrnout do automatizace CI/CD pomocí kanálů Lakeflow k deklaraci datových kanálů.
  • Infrastruktura: Konfigurace infrastruktury zahrnuje definice a informace o zřizování pro clustery, pracovní prostory a úložiště pro cílová prostředí. Změny infrastruktury je možné ověřit a testovat jako součást kanálu CI/CD a zajistit tak, aby byly konzistentní a bez chyb.

Proč musím mít samostatná vývojová a produkční cílová prostředí?

Samostatná vývojová a produktová prostředí umožňují:

  • Bezpečně izolujte změny vývoje, aby nechtěně neovlivnily produkční prostředí.
  • Zabránit duplikaci kódu přizpůsobením prostředků, které se mají použít na konkrétní cílové prostředí.
  • Zjednodušte a optimalizujte CI/CD pomocí konfigurace specifické pro prostředí, jako jsou cesty k databázi, výstrahy a řízení přístupu.
  • Opakovaně používejte pracovní postupy napříč týmy a prostředími.

Použijte cíle k definování prostředí nasazení sady prostředků. Podívejte se na cíle.

Jak učiním své svazky konzistentními v rámci své organizace?

Šablony sad slouží k konzistentní struktuře, k omezení chyb nastavení a k propagaci osvědčených postupů. Můžete použít výchozí šablony sad nebo můžete vytvořit vlastní šablony sad. Viz Šablony projektů balíčků deklarativní automatizace.

Ve svých balíčcích je mnoho opakování, jako jsou stejné definice clusteru. Jaký je nejlepší způsob, jak to zvládnout?

Vlastní proměnné představují nejlepší způsob zpracování opakování a také nastavení, která jsou specifická pro kontext. Viz Vlastní proměnné.

Jaké jsou osvědčené postupy při používání balíčků v rámci procesu nasazení?

Databricks doporučuje:

  • Přechod z ručních nasazení do spolehlivé automatizace pomocí pracovních postupů integrovaných v Gitu
  • Před nasazením balíčku ověřte v kanálu CI/CD použití databricks bundle validate.
  • Oddělování kroků nasazení k zajištění, že změny jsou prověřené a záměrné.
  • Parametrizujte prostředí (vývoj, příprava, produkce) s možností přepsání pro izolaci změn.
  • Spusťte testy integrace po nasazení a zachyťte problémy včas.
  • Aktivujte nasazení aplikace pomocí GitHub Actions, Azure DevOps nebo GitLab CI při commitu nebo sloučení pull requestu.
  • Sledujte, co je nasazeno, kde a kdy, aby se každé nasazení mapovalo na commit a verzi balíčku.

Jak přesunu nasazení balíčku z /Workspace/Shared?

Nasazujte balíčky na místo, které vlastníte vy nebo váš tým, místo /Workspace/Shared, které je přístupné všem uživatelům pracovního prostoru, abyste mohli aplikovat práva s nejmenšími oprávněními. Pro přesun existujícího nasazení:

  1. Změňte umístění cíle root_path z /Workspace/Shared/... do samostatného umístění, například do /Workspace/Users/${workspace.current_user.userName}/.bundle/${bundle.name}/${bundle.target} nebo do složky vlastněné týmem. Toto pole je v cíli nastaveno v části workspace, například workspace.root_path.
  2. Potvrďte, že balíček definuje sekci permissions, aby si správné identity zachovaly přístup v novém umístění. Pokud ne, přidejte takové nastavení, které udělí vlastnícímu týmu CAN_MANAGE a CAN_VIEW skupině users, pokud mají zdroje zůstat viditelné pro všechny.
  3. Znovu nasaďte pomocí databricks bundle deploy -t <target>, nebo nechte změnu nasadit svým CI/CD pipeline. Pro náhled změny nejprve spusťte databricks bundle plan -t <target>.

Pro produkční nasazení nasazujte jako servisní principal na týmově vlastněnou cestu. Viz Specifikovat běžnou identitu pro workflow Declarative Automation Bundles a Declarative Automation Bundles – režimy nasazení.

Můžu do sady přenést existující úlohy, kanály, řídicí panely a další objekty Databricks?

Ano. Použijte příkaz databricks bundle generate k vygenerování konfiguračního souboru pro existující úlohu, pipeline nebo řídicí panel ve vaší místní sadě a poté použijte databricks bundle deployment bind k navázání prostředku sady na odpovídající prostředek v pracovním prostoru. To je ideální pro začlenění stávajících pracovních postupů do strukturovaného, verzovaného vývoje. Vazba také řeší relativní cesty k absolutním odkazům na pracovní prostor, což předchází chybám v cestách.

Viz Migrace existujících prostředků do sady.

Jak můžu iterativně testovat můj balík?

S iterativními nasazeními a spuštěními můžete vyvíjet rychleji:

  • Ověření před nasazením
  • Nasazujte postupně
  • Spustit jenom to, co je potřeba
  • Upravit a opakovat

To zrychluje testování a ladění, snižuje přepínání kontextu, umožňuje bezpečnější a rychlejší iteraci bez úplného opětovného nasazení a při přechodu k produkčnímu prostředí vynucuje disciplínu.