SQL ist das Betriebssystem unserer Datenplattformen. Doch während für Java oder Python strikte Standards gelten, herrscht im SQL-Ordner oft Wildwest: Uneinheitliche Styles, fehlende Kommentare, gefühlt kilometerlange Zeilen und schwer reviewbare Code-Monster.
Wie operationalisiert man Data Governance direkt im SQL Code?
SQLFluff ist ein modularer SQL-Linter und Auto-Formatter, der "Policy-as-Code" ermöglicht:
- Standardisierte Regeln im Repo: Ein einheitlicher Stil (Keywords, Einrückung, Kommas, CTE-Struktur …) reduziert kognitive Last und erleichtert Reviews.
- Automatisierte Kontrollen im Entwicklungsprozess (Shift Left): Fehler und Anti-Patterns werden früh sichtbar – nicht erst in Produktion oder beim Incident.
- Nachvollziehbarkeit & Auditierbarkeit: Regeln sind versioniert im Repo – Änderungen daran sind reviewbar und historisiert.
- Skalierbarkeit: Teams können dieselben Regeln auf tausende SQL-Dateien anwenden – unabhängig davon, ob sie Oracle, Postgres, DuckDB, SparkSQL, Snowflake, BigQuery, u.v.a. nutzen. Zusätzlich werden Tools unterstützt, die häufig in modernen Data-Stacks verwendet werden: SQL mit Templates (z. B. Jinja) oder dbt-Integration (dbt = data build tool).
Wie startet man mit SqlFluff?
1) Lokal mittels Befehlszeile
SqlFluff benötigt eine Python-Installation. Danach ist das Tool in der Befehlszeile direkt aufrufbar. Installation in einer (vorzugsweise virtuellen) Python-Umgebung:
pip install sqlfluff
Erster Test mit Oracle-SQL-Dialekt:
sqlfluff lint path/to/sql --dialect oracle
Automatisch korrigieren (sofern möglich und gewollt):
sqlfluff fix path/to/sql --dialect oracle
Im Screenshot (siehe Abbildung rechts - zum Vergrößern bitte anklicken)) ist eine Beispiel-Ausgabe mit 5 Fehlern zu sehen (darunter die selbst erstellte Regel ABU_D001)
Konfigurationen können in der Datei .sqlfluff definiert werden statt in der Befehlszeile, zum Beispiel:
# .sqlfluff
[sqlfluff]
dialect = oracle
templater = jinja
max_line_length = 120
[sqlfluff:rules]
# Beispiel für häufig genutzte, zentrale Regeln (projektweit)
single_table_references = consistent
unquoted_identifiers_policy = all
[sqlfluff:rules:capitalisation.keywords]
capitalisation_policy = upper
Die Konfiguration setzt den Oracle-Dialekt und nutzt den Jinja-Templater, damit auch "templatisiertes" SQL korrekt geparst und geprüft wird; außerdem gilt eine maximale Zeilenlänge von 120 Zeichen. Mit single_table_references = consistent wird erzwungen, dass Tabellenreferenzen einheitlich geschrieben werden (z. B. konsequent mit oder ohne Alias-Präfixe, statt gemischt). unquoted_identifiers_policy = all sorgt dafür, dass Identifier-Regeln konsistent angewendet werden und Entwickler nicht wild zwischen quoted- und unquoted-Bezeichnern mischen. Zusätzlich erzwingt capitalisation_policy = upper, dass SQL-Keywords wie SELECT, FROM, WHERE immer großgeschrieben sind.
SqlFluff kann mittels Python erweitert werden um eigene Regeln (z.B. ABU_D001 im Screenshot). Das GitHub-Repository enthält im Verzeichnis sqlfluff_rules ein einfaches Beispiel. Dies ist häufig eine Anforderung der Governance: Man kann erzwingen, dass jede Datei mit einem Geschäftskontext-Kommentar beginnen muss. Die Qualität des Kommentars ist dann ein anderes Thema ... aber vielleicht eine Aufgabe für ein LLM (Large Language Model) im Review.
2.) CI/CD als Governance-Kontrolle: GitHub Actions mit Annotationen oder pre-commits
Der Governance-Mehrwert entsteht oft erst richtig, wenn SqlFluff nicht nur lokal, sondern verbindlich in CI läuft – und Regelverstöße direkt im Push kommentiert/annotiert werden. Im GitHub Repo ist das obige Beispiel abgelegt: SqlFluff wird mit Hilfe von GitHub Actions aufgerufen beim Einchecken von *sql-Dateien.
Alternativ kann auch ein sog. "pre-commit Hook" verwendet werden, so dass bereits beim commit die Prüfungen durchlaufen und unerwünschter Code schon gar nicht ins Repository eingecheckt werden kann. Das GitHub Repo enthält auch hierzu eine Beispielkonfiguration.
Rollout-Strategie
Ein typischer, konfliktarmer Weg:
- Baseline schaffen: Nur Formatierungs-/Layout-Regeln aktivieren (viel Auto-Fix, wenig Diskussion).
- Team-Standards formalisieren: Keywords/Identifier-Policies (z. B. Groß-/Kleinschreibung) in .sqlfluff festschreiben.
- Schrittweise verschärfen: Regeln, die echte Fehler und Wartbarkeitsprobleme reduzieren.
- CI verbindlich machen: Pull Request verhindern, wenn Fehler vorliegen.
- Ausnahmen steuern: Ignoring/Excludes gezielt einsetzen, statt Regeln "weichzuspülen". In SQL-Dateien können gezielte Ausnahmen angegeben werden.
Fazit
SqlFluff ist mehr als "SQL hübsch machen". Aus Data-Governance-Sicht ist es ein Werkzeug, um Standards als Code zu definieren und kontinuierlich durchzusetzen – lokal in der CLI und verbindlich in CI/CD mit Pull-Request-Feedback. Als Nebeneffekt steigt nicht nur die Codequalität, sondern auch die Review-Geschwindigkeit, Wartbarkeit und das Vertrauen in die Datenprodukte.
Quellcode: https://GitHub.com/abuckenhofer/sql-toolchain
SqlFluff: https://docs.SqlFluff.com/
Andreas Buckenhofer
Als Senior Data Architect bei Adam Riese in Controlling, Finanzen & Regulatorik gestalte ich moderne Datenarchitekturen und Governance-Strukturen. Mein Ziel: Datenlösungen (von AI bis Lakehouse) sicher und skalierbar zu machen. Wenn ich nicht gerade SQL-Standards automatisiere, engagiere ich mich in der DOAG Community für die Themen Data Governance & Sovereignty.
Kontakt: Andreas.Buckenhofer@adam-riese.de
