Databricks-Governance ohne Copy-Paste: YAML Anchors für Admins

In unserem Artikel „Azure Databricks Governance mit Terraform und Databricks-Bundles“ haben wir die Governance von Azure Databricks in drei Phasen unterteilt: Terraform stellt die Cloud-Infrastruktur bereit, Databricks Declarative-Automation-Bundles (DAB) konfigurieren die Berechtigungen der Plattform und das Python-SDK übernimmt die Aufgaben, die die Bundles nicht deklarativ abbilden können. 

Die Governance in Databricks erstreckt sich über drei Berechtigungsebenen: Konto, Arbeitsbereich und Unity Catalog. Dieser Artikel befasst sich insbesondere mit der letzten Ebene (Unity Catalog), auf der der Großteil der täglichen Arbeit zur Vergabe von Berechtigungen stattfindet.

Diese Konfiguration funktioniert gut, solange Ihre Plattform nicht wächst. Sobald Ihre Medaillon-Architektur Bronze-, Silber- und Gold-Kataloge mit jeweils mehreren Schemata umfasst, vervielfacht sich eine Sache schnell: die Berechtigungen (Blöcke). Die gleichen READ-Berechtigungen für Workspace-Benutzer oder WRITE-Berechtigungen für Job-Runner werden in jeden Katalog und jedes Schema kopiert. Und genau beim Kopieren und Einfügen bricht die Governance still und leise zusammen. Ändern Sie eine Berechtigung, müssen Sie diese an einem Dutzend Stellen suchen und aktualisieren.

Dieser Artikel stellt eine kleine, native YAML-Funktion vor, die diese Wiederholungen vollständig beseitigt: Anchors. (Anker)
(Kurz zur Erinnerung: YAML ist die menschenlesbare Konfigurationssprache, in der Databricks Asset Bundles geschrieben werden. Jede databricks.yml und jede Ressourcen-Datei im Bundle ist YAML.)

Was sind YAML Anchors and Aliases?

Bevor man etwas auf Databricks anwendet, ist es hilfreich, sich zunächst den Mechanismus an sich anzusehen. YAML verfügt über miteinander verbundene Funktionen zur Wiederverwendung von Inhalten innerhalb einer Datei.
Ein Anchor (&name) markiert einen Knoten, sodass man später darauf verweisen kann. Ein Alias (*name) verwendet dann genau diesen Knoten an einer anderen Stelle wieder. Ein einfaches Beispiel:

default_grant: &read_access
  principal: workspace_users
  privileges: [USE_CATALOG, SELECT]

catalog_a:
  grants: *read_access
catalog_b:
  grants: *read_access

Hier verweisen sowohl catalog_a als auch catalog_b auf denselben Block, der einmal unter &read_access definiert ist. Ändert man den Anchor, ändern sich beide entsprechend.

Wichtig zu verstehen ist, dass all dies eine Eigenschaft von YAML selbst ist. Die Auflösung erfolgt durch den YAML-Parser beim Einlesen der Datei, noch bevor Databricks den Inhalt überhaupt zu Gesicht bekommt. Es ist keine bundle-spezifische „Magie“ im Spiel; Anchors funktionieren in jeder YAML-Datei.

Warum sich Grants in Databricks Bundles ständig wiederholen

Kommen wir nun zum eigentlichen Aufbau. In einer Medaillon-Architektur bildet jede Ebene einen eigenen Katalog: Bronze, Silber, Gold und jeder Katalog benötigt denselben Basiszugriff: Arbeitsbereichsbenutzer können lesen, das Job-Runner-Service-Principle kann Schemata erstellen. Im Klartext sieht ein Bundle letztendlich so aus:

catalogs:
  bronze:
    name: bronze
    grants:
      - principal: workspace_users
        privileges: [USE_CATALOG]
      - principal: job_runner_sp
        privileges: [USE_CATALOG, CREATE_SCHEMA]
  silver:
    name: silver
    grants:
      - principal: workspace_users
        privileges: [USE_CATALOG]
      - principal: job_runner_sp
        privileges: [USE_CATALOG, CREATE_SCHEMA]
  gold:
    name: gold
    grants:
      - principal: workspace_users
        privileges: [USE_CATALOG]
      - principal: job_runner_sp
        privileges: [USE_CATALOG, CREATE_SCHEMA]

Derselbe achtzeilige Code, dreimal hintereinander - und das noch bevor die Schemata unter jedem Katalog ihre eigenen Berechtigungsblöcke (grants:) wiederholen. Stellen Sie sich nun vor, bei einer Governance-Prüfung wird beschlossen, dass der Job-Runner zusätzlich die Berechtigung BROWSE erhalten soll. Sie bearbeiten dieselbe Änderung in drei Katalogen und jedem Schema, in der Hoffnung, dass Sie alle Stellen finden. Wenn Sie eine übersehen, rutscht Gold unbemerkt von Bronze ab. 

Genau diese Art von Fehlern soll „Infrastructure-as-Code“ eigentlich verhindern, doch durch Kopieren und Einfügen wird dieser Fehler im YAML-Code erneut eingeführt.

Sehen Sie sich die Aufzeichnung unseres Webinars an: "Bridging Business and Analytics: The Plug-and-Play Future of Data Platforms"

YAML Anchors in der Praxis: Grants im Bundle ohne Wiederholung

Hier ist dieselbe Konfiguration, umgeschrieben mit einem Anchor. Definieren Sie den grants:-Block einmalig, vergeben Sie ihm einen Namen mit “&” und verweisen Sie dann in jedem Katalog mit “*” darauf:

_common: &catalog_grants
  - principal: workspace_users
    privileges: [USE_CATALOG]
  - principal: job_runner_sp
    privileges: [USE_CATALOG, CREATE_SCHEMA]

catalogs:
  bronze:
    name: bronze
    grants: *catalog_grants
  silver:
    name: silver
    grants: *catalog_grants
  gold:
    name: gold
    grants: *catalog_grants

Die acht wiederholten Zeilen befinden sich nun an genau einer Stelle. Die Governance-Überprüfung, die BROWSE hinzufügt? Eine einzige Änderung an &catalog_grants und Bronze, Silber und Gold übernehmen sie alle. Es besteht keine Gefahr, dass eine Ebene von den anderen abweicht.

Anchors verwenden einen ganzen Block genau so wieder, wie er definiert ist. Das hat eine Konsequenz, die es wert ist, ausdrücklich erwähnt zu werden: Eine grants:-Liste wird als Ganzes wiederverwendet. YAML-Anchorswerden nicht an eine Liste angehängt. Wenn also ein Katalog einen zusätzlichen Principal benötigt, definieren Sie einen zweiten Anchor, anstatt den ersten zu „erweitern“.
(Wenn Sie das überspringen, landen Sie wieder beim Kopieren und Einfügen des Blocks mit einer geänderten Zeile - genau das, was Anchors eigentlich vermeiden sollen).

Anchors lassen sich auch mit Databricks-Bundle-Variablen kombinieren. Der verankerte Block kann Platzhalter wie ${var...} enthalten, sodass die Struktur über den Anchor wiederverwendet wird, während umgebungsspezifische Werte weiterhin aus Ihrer Variablen-Datei stammen:

_common: &catalog_grants
  - principal: ${var.group_workspace_users}
    privileges: ${var.catalog_privilege_use}

Anchors für die Struktur, Variablen für die Werte. Diese Kombination ist das Muster, das man verinnerlichen sollte. Sie ist auch der Grund dafür, dass ein einziges Bundle in mehreren Umgebungen eingesetzt werden kann: Die gleichen, an Anchor gebundenen Blöcke werden unverändert in DEV, QA und PROD bereitgestellt, während Variablen je nach Umgebung die richtigen Katalognamen und Berechtigungen einfügen.

YAML Anchors vs. Databricks Bundle-Variablen

An dieser Stelle stellt sich eine Frage: Ermöglichen die Databricks-Bundle-Variablen nicht bereits die Wiederverwendung? Sie haben in der gesamten Konfiguration ${var.catalog_privilege_use} und ${resources.catalogs.silver.name} gesehen. Sie scheinen auf dem gleichen Prinzip zu basieren. Warum also zusätzlich Anchors?

Weil sie in unterschiedlichen Phasen wirken. YAML-Anchors werden vom YAML-Parser in dem Moment aufgelöst, in dem die Datei gelesen wird. Bundle-Variablen (${...}) werden später von der Databricks-CLI aufgelöst, wenn diese das Bundle zusammen- und bereitstellt. Anchors werden zuerst expandiert; die Variablenersetzung erfolgt danach, im bereits expandierten Dokument.

Aus dieser Reihenfolge ergibt sich eine klare Faustregel:

• Anchors zur Strukturierung verwenden: eine vollständige Liste der Berechtigungen (grants), eine gemeinsame Clusterkonfiguration

• sowie Variablen für Werte: einen Katalognamen, eine Berechtigungsgruppe und den Umgebungswert.

Anchors und Variablen ergänzen sich. Ein verankerter Block voller ${var...}-Platzhalter ist die ideale Lösung: Der Anchor sorgt dafür, dass jeder Katalog die gleiche Struktur erhält, während die Variablen dafür sorgen, dass die tatsächlichen Namen in allen Umgebungen umgebungsabhängig bleiben.
Takeaway:

• Wenn Sie einen Block wiederholen, greifen Sie auf einem Anchor zurück.

• Wenn Sie einen Wert wiederholen, greifen Sie auf eine Variable zurück.

Wenn man diese durcheinanderbringt, versucht, einen variablen Punkt an einem Block festzulegen, oder Werte, die ein Anchor enthalten soll, hardcodet, werden Konfigurationen anfällig.

Häufige Fallstricke bei YAML Anchors in Databricks Bundles

Anchors sind ein tolles Tool, aber es lohnt sich, ein paar Dinge zu wissen, bevor man sich auf sie verlässt.

• Anchors gelten nur für den jeweiligen Dateibereich. Ein in schemas.yml definierter Anchor kann nicht aus catalogs.yml referenziert werden. Der Alias wird einfach nicht aufgelöst. Aus diesem Grund sieht man in einem echten Bundle mit mehreren Dateien manchmal, dass ein scheinbar „gleicher“ Block zweimal definiert ist, einmal pro Datei. Das ist kein Versehen, sondern liegt an der Geltungsbereichsregel. Wenn Sie eine echte dateiübergreifende Wiederverwendung wünschen, ist das die Aufgabe von Bundle-Variablen, nicht von Anchors.

• Die Lesbarkeit hat ihre Grenzen. Ein Alias wie *general_privileges ist nur dann verständlich, wenn der Leser *general_privileges schnell finden kann. Sind die Anchors über eine lange Datei verstreut, muss jeder Prüfer scrollen, um die Definition zu finden. Der “DRY-Vorteil” wird so zu einem Aufwand für das Verständnis.

• Führen Sie die Fehlerbehebung (Debug) anhand des erweiterten Dokuments durch, nicht anhand des Quellcodes. Was Sie geschrieben haben, entspricht nicht ganz dem, was Databricks bereitstellt. Der Parser hat zunächst alle Aliase aufgelöst. Wenn eine Berechtigung falsch erscheint, führen Sie databricks bundle validate aus und überprüfen Sie die vollständig aufgelöste Ausgabe. Das ist die Version, auf die es tatsächlich ankommt.

• Verankere keine Elemente, die nur einmal vorkommen. Ein Anchor, auf den nur einmal verwiesen wird, führt zu Umwegen, ohne einen Vorteil zu bieten. Anchors machen sich erst durch Wiederholungen bezahlt. Wenn ein Block nicht wiederholt wird, lass ihn inline stehen.

YAML Anchors: Best Practices für Databricks-Teams

Wenn Anchors in einem Bundle untergebracht werden sollen, das von mehreren Personen gepflegt wird, sorgt ein wenig Disziplin dafür, dass sie ein Gewinn bleiben und nicht zu einem Rätsel werden.

• Legen Sie eine Namenskonvention für Anchors fest, die den Geltungsbereich und den Zweck deutlich macht. Bezeichnungen wie &catalog_grants oder &schema_read sind wesentlich aussagekräftiger als &block1. Der Alias sollte einem Anwender bereits auf den ersten Blick vermitteln, was ihn erwartet, ohne dass er bis zur Definition scrollen muss.

• Sorgen Sie dafür, dass Anchor Definitionen leicht auffindbar sind. Definieren Sie sie am Anfang der Datei oder in einem deutlich gekennzeichneten Konventionsblock, damit es einen offensichtlichen Ort gibt, an dem man nachsehen kann (_common).  Ein Anchor, der zwischen zwei nicht zusammenhängenden Ressourcen versteckt ist, wird leicht übersehen.

• Denken Sie daran, dass eine Änderung an einem gemeinsam genutzten Anchor eine weitreichende Änderung darstellt. Durch die Bearbeitung von &catalog_grants werden bronze, silver und gold Kataloge gleichzeitig aktualisiert. Das ist zwar nützlich, sollte aber vor dem Commit sorgfältig geprüft werden.

Und führen Sie vor jeder Bereitstellung immer eine Validierung durch. Führen Sie databricks bundle validate in der CI aus, damit die vollständig aufgelöste Konfiguration bei jeder Änderung überprüft wird: derselbe umgebungsbezogene, genehmigungspflichtige Ansatz, den wir in Teil 1 dieses Artikels durchgesprochen haben. Anchors verringern die Fehleranfälligkeit; ein Validierungsschritt fängt die Fehler ab, die dennoch durchrutschen.

Databricks-Governance mit YAML Anchors vereinfachen: Unser Fazit

YAML-Anchors tauchen weder in den Databricks-Release-Notes noch in einem Governance-Framework auf. Sie sind eine kleine, native Funktion der Konfigurationssprache selbst. Aber genau deshalb sind sie für Administratoren so wichtig. Wenn Ihre Medallion-Architektur von einer Handvoll Ressourcen auf Bronze-, Silber- und Gold-Kataloge mit jeweils zugrunde liegenden Schemata, Volumes und Berechtigungen anwächst, besteht das eigentliche Risiko darin, dass die Wiederholungen unbemerkt aus dem Gleichgewicht geraten. Anchors bündeln diese Wiederholungen zu einer single source of truth, sodass eine Änderung an der Governance nur noch eine einzige Bearbeitung statt eines Dutzends erfordert.

Zur Erinnerung: Anchors für die Struktur, Variablen für Werte und Validierung vor jedem Deployment. Bei konsequenter Anwendung sorgen Anchors für kürzere Bundles, übersichtlichere Reviews und eine einheitliche Governance des Unity Catalogs über alle Umgebungen hinweg, was ja der eigentliche Sinn dieser deklarativen Vorgehensweise ist.

Damit schließen wir unseren Überblick darüber ab, wie Databricks-Asset-Bundles auch in großem Maßstab wartbar bleiben. Wenn Sie eine Plattform-Governance aufbauen und einen Partner suchen, der die Tücken bereits kennt, helfen wir Ihnen gerne weiter.