Data Governance mit Snowflake Object Tagging meistern

Object Tagging in Snowflake ist ein Data-Governance-Feature, mit dem sich Objekte (Warehouses, Tabellen etc.) kategorisieren und gruppieren lassen. Ziel ist es, die Auffindbarkeit zu verbessern sowie Nutzung und Compliance der Snowflake-Objekte im Blick zu behalten. Tags sind besonders praktisch, um Snowflake-Objekte mit sensiblen Inhalten wie PII oder Finanzdaten zu kennzeichnen. Auch um Verantwortlichkeiten für Ressourcen zuzuweisen, für Cost Monitoring oder Data Governance, sind sie äußerst nützlich.

Bevor Sie Objekte in Snowflake taggen können, müssen Sie den Tag zunächst selbst anlegen.

Tags sind Objekte auf Schema-Ebene in Snowflake und lassen sich anderen Snowflake-Objekten wie Datenbanken, Schemas, Tabellen, Spalten, Usern, Warehouses, Rollen usw. zuordnen. Die Liste der taggbaren Objekte ist sehr umfangreich und findet sich hier.

Ein Tag ist ein Key-Value-Paar. Der Tag-Name (create tag <tag name>) ist der "Key"; die Werte stammen entweder aus einer vordefinierten Liste erlaubter Werte oder sind frei wählbar, sodass beliebige Strings möglich sind.

Wenn Sie etwa die Zielgruppe einer bestimmten Tabelle nachverfolgen möchten, können Sie einen Tag (Key) namens "audience" anlegen, dessen Werte z. B. HR, Sales, Operations, IT usw. sind. Solche Tags lassen sich bequem abfragen – etwa: Zeige mir alle Tabellen, die Sales nutzt. Mehr dazu später in diesem Beitrag.

Hier eine kurze Auffrischung zur "Container Hierarchy" von Snowflake. Eine Snowflake Organization ist ein Container für Accounts. Ein Account ist ein Container für Datenbanken. Eine Datenbank ist ein Container für Schemas. Und ein Schema ist ein Container für Tabellen, Views, Pipes, File Formats, Stages und viele weitere Objekte.

Wird ein Objekt auf einer beliebigen Ebene der Container-Hierarchie getaggt, wird der Tag an alle darunterliegenden Objekte vererbt. Setze ich zum Beispiel einen Tag auf eine Datenbank, erben alle Tabellen, Views, Spalten sowie weitere Objekte wie Pipes, Stages usw. den Tag dieser Datenbank.

Angenommen, Sie haben Tags explizit auf Account-, Datenbank- und Schema-Ebene gesetzt, etwa so:

{
  "account": {
    "tags": {
      "env": "prod",
      "region": "us-east-1"
    },
    "databases": {
      "analytics": {
        "tags": {
          "owner": "data_team",
          "classification": "restricted"
        },
        "schemas": {
          "sales": {
            "tags": {

Expand Code

Da region auf Account-Ebene getaggt ist, erbt jede Datenbank, jedes Schema, jede Tabelle, jede View und sogar jede einzelne Spalte den Wert us-east-1. Ziemlich praktisch!

Die Tag-Lineage lässt sich bequem mit der Funktion snowflake.account_usage.tag_references_with_lineage abfragen – siehe weiter unten unter "Snowflake-Tags per SQL beobachten".

In Snowflake ist ein Query Tag ein einzelner String-Wert, der an eine Query oder Session angehängt wird und so das Filtern und Durchsuchen der Query-History erleichtert. Query Tags sind keine Key-Value-Paare, sondern lediglich durchsuchbare Strings. Object Tags hingegen sind Key-Value-Paare und Teil des Data-Governance-Frameworks von Snowflake. Sie dienen dazu, den Zugriff auf Datenobjekte wie Tabellen, Spalten oder Schemas zu klassifizieren, zu steuern und zu auditieren.

Wenn jemand in Snowflake von "Tagging" spricht, sollten Sie also immer klären, ob Query Tags oder Object Tags gemeint sind – die beiden Konzepte verfolgen sehr unterschiedliche Ziele.

Tag erstellen

Die Syntax zum Erstellen eines Tags ist denkbar einfach: create tag <tag_name> <allowed values>;

Da Tags Objekte auf Schema-Ebene sind, sollten Sie voll qualifiziertes SQL verwenden oder den Kontext Ihres Worksheets im Blick behalten. Wie alles in Snowflake können Tags in einer Datenbank (oder einem Schema) erstellt und in einer anderen verwendet werden.

Beispiele:

use schema governance.tags;
create tag table_classification allowed_values 'metadata', 'fact', 'dimension';
-- erstellt einen Tag mit einer bestimmten Liste erlaubter Werte.

create tag user_group;
-- erstellt einen Tag, der jeden beliebigen Wert zulässt.

Wird ein Tag ohne Angabe erlaubter Werte erstellt, steht der Parameter allowed_values auf null, und beliebige Textstrings sind als Wert zulässig. Das ist praktisch, wenn die Werteliste dynamisch sein soll. In den meisten Fällen werden Sie die erlaubten Werte jedoch vorab festlegen und den Tag bei Bedarf per alter um weitere Werte ergänzen.

Erlaubte Werte eines Tags prüfen

Wenn Sie die erlaubten Werte eines bestehenden Tags prüfen möchten, gibt es mehrere einfache Wege.

Der Befehl show tags; zeigt die Metadaten aller Tags in Ihrem Account an. Eine der zurückgegebenen Spalten ist allowed_values.

Eine weitere Möglichkeit ist der Aufruf der Systemfunktion system$get_tag_allowed_values für einen bestimmten Tag.

select system$get_tag_allowed_values(
    'governance.tags.cost_center');

Und noch eine Variante: die Funktion get_ddl in Snowflake aufrufen. Zum Beispiel:

1select get_ddl('tag','dev.public.TESTING_TAG_1');

Den Tag verwenden, indem Sie ein Objekt taggen:

Um einen Tag auf einem Objekt zu setzen, nutzen Sie den alter-Befehl. Wenn Sie etwa einen Tag auf eine Tabelle namens select_blog.workday.workday_users setzen möchten:

alter table select_blog.workday.workday_users
set tag tutorial_db.public.table_classification = 'metadata';

In diesem Beispiel wird der Tag in einer Datenbank namens tutorial_db erstellt und in einer Datenbank namens select_blog verwendet.

Option 1: Die View account_usage.tag_references abfragen

Die View snowflake.account_usage.tag_references zeigt Ihnen, wo ein Tag überall verwendet wird und welchen Wert er jeweils hat. Die wichtigsten Filterspalten sind tag_name und tag_value. Diese Tabelle zeigt keine Tag-Vererbung, sondern nur Objekte, die direkt getaggt sind.

SELECT * FROM
snowflake.account_usage.tag_references
where tag_name ilike 'table_class%'
or tag_value ilike 'meta%'
ORDER BY TAG_NAME, DOMAIN, OBJECT_ID;

Wichtig: Die Daten in dieser View weisen eine deutliche Verzögerung auf. Laut Snowflake-Dokumentation kann sie bis zu zwei Stunden betragen. Aus meiner Erfahrung sind es in der Regel mindestens eine Stunde.

Option 2: get_tag-Funktion

Da die View snowflake.account_usage.tag_references verzögert ist, brauchen Sie manchmal eine schnelle Möglichkeit, Änderungen an getaggten Objekten unmittelbar zu beobachten. Die Systemfunktion system$get_tag ist immer aktuell.

Syntax:

SELECT SYSTEM$GET_TAG( <fully qualified tag name>,
<'fully qualified object name'>, <'object class such as table, view, etc' > )
AS TAG_META;

Beispiel:

SELECT SYSTEM$GET_TAG( 'tutorial_db.public.table_classification',
'SELECT_BLOG.WORKDAY.WORKDAY_USERS', 'TABLE' )
AS TAG_META;

Option 3: Die Funktion account_usage.tag_lineage

Weiter oben haben wir die Tag-Vererbung besprochen: Tags werden automatisch von höheren auf niedrigere Ebenen weitergegeben. Mit der Funktion tag_lineage sehen Sie alle Objekte, die entweder direkt getaggt wurden oder einen Tag geerbt haben. Für unser Beispiel table_classification sieht das SQL so aus:

SELECT *
FROM TABLE(
  snowflake.account_usage.tag_references_with_lineage(
    'TUTORIAL_DB.PUBLIC.TABLE_CLASSIFICATION'
  )
);

Hier sehen wir, dass der Tag manuell auf die Tabelle WORKDAY_USERS angewendet wurde und jede Spalte der Tabelle den Tag erbt.

Im Screenshot sind in der Snowsight-UI viele Spalten abgewählt, damit alles ins Bild passt.

Snowflake stellt ein praktisches Dashboard bereit, in dem Sie sämtliche Tags einsehen können.

Verwenden Sie die Rolle accountadmin oder eine Rolle, die korrekt konfiguriert ist, um auf das Dashboard zuzugreifen, und navigieren Sie in der Seitenleiste von Snowsight zu Monitoring → Governance.

So sieht das Dashboard aus. Da ich einen Demo-Account verwende, sind keine Tags gesetzt – Sie können aber gut erkennen, wie nützlich das Dashboard im Alltag ist.

Klicken Sie auf den Tab "Tagged Objects", um alle Tabellen und Views in Ihrem Account samt zugewiesener Tags anzuzeigen. Die Objekte werden gelistet, unabhängig davon, ob ein Tag gesetzt ist oder nicht. Leider sind Objekte wie Users und Warehouses hier nicht zu finden. Snowflake bietet auf dieser Seite gute Filtermöglichkeiten – probieren Sie die Filter ruhig durch.

Aktivieren Sie den Filter "has tags", um ausschließlich Objekte mit Tags anzuzeigen:

Eine zentrale Tagging-Policy entwickeln

Data Governance und der Umgang mit PII sowie sensiblen Daten sind anspruchsvoll. Es handelt sich überwiegend um nicht-technische Arbeit, die viel Abstimmung und Diskussion erfordert!

Der erste Schritt ist eine durchdachte Strategie. Hier ein paar Fragen für den Einstieg:

• Was wollen wir mit Tags erreichen? (Cost Reporting, Schutz sensibler Daten etc.)
• Wer definiert die Liste der Tags und erlaubten Werte? (Strategie)
• Welche Rollen dürfen Tags setzen, und wer bekommt diese Rollen? (Taktik)
• Wie nutzen wir die Tag-Vererbung möglichst wirkungsvoll?

Allowed Values für Tags nutzen

Gerade wenn Tags manuell gesetzt werden, sollten Sie die Einstellung "allowed values" nutzen. Wird die Tag-Zuweisung dagegen auf Basis von Daten in einer Tabelle automatisiert, ist das weniger entscheidend.

Tagging automatisieren, wo immer möglich

Tagging scheitert oft daran, dass Teams Tags von Hand pflegen. Überlegen Sie sich kreative Wege, Tagging zu automatisieren. Ein Beispiel folgt weiter unten!

Tagging in Datenpipelines integrieren, wo möglich

Es gibt ein nützliches dbt-Paket namens dbt_tags. Damit lassen sich Object Tagging in Snowflake automatisieren und Dynamic Masking auf Basis von Tags abstimmen. Wenn Sie Datenmaskierung anhand von Tags benötigen, ist dieses Paket einen Blick wert!

Tag-Nutzung überwachen und auditieren

Warum all diese Tags anlegen, wenn niemand sie überprüft? Reservieren Sie eine Stunde pro Monat, um Tags und deren Nutzung zu prüfen und Ihre Tagging-Policy weiterzuentwickeln.

Das Szenario

Stellen Sie sich vor, Sie pflegen Metadaten zu Ihren Mitarbeitenden in Workday (oder Ihrem bevorzugten ERP), und diese Tabelle wird per ETL nach Snowflake übertragen. Nennen wir sie workday_users. Sie enthält eine Zeile pro User, und jede Spalte steht für ein Attribut, das wir als Tag am Snowflake-User pflegen wollen. So können wir User mit denselben Tags auditieren, beobachten und mit Berechtigungen versehen.

Wechseln User die Abteilung oder Funktion, sollen sich die Snowflake-Tags automatisch aktualisieren.

Mock-Daten anlegen

Legen wir für unser Szenario eine Tabelle samt Mock-Daten an:

-- Diese Tabelle steht für eine Tabelle, die per ETL aus Workday nach Snowflake übertragen würde und User-Metadaten enthält.
-- Ich verwende eine Demo-Datenbank, passen Sie sie an.
create or replace table select_blog.workday.workday_users
(
employee_id text,
work_email text,
manger_email text,
is_manager boolean,
pillar_id text,
group_id text,
team_id text,
department_id text,
job_family_id text,
area text,
cost_center text,

Expand Code

Befüllen Sie die Tabelle mit ein paar Mock-Daten:

1insert into select_blog.workday.workday_users

2values(

33000,

4'[email protected]',

5null,

6true,

7'Pillar-C-SUITE',

8'Group-C-SUITE',

9'Team-Founders',

10'Department-All',

11'JF-Founders',

12'Founders',

13'CC Board of Directors',

14'CC3625'

15),

Expand Code

In diesem Szenario wollen wir jedes Feld, das auf _id endet, in einen Tag am Snowflake-User übersetzen.

Die Tags erstellen

Gehen wir davon aus, dass die Anzahl der Spalten in workday_users relativ stabil ist und die Tags einmalig (oder nur selten) angelegt werden müssen, ohne dass das automatisiert sein muss. Kommt eine Spalte hinzu, können wir einen neuen Tag anlegen. (Oder Sie planen den unten stehenden Code als Task ein! Verzichten Sie bei geplanter Ausführung aber auf das "Replace" der Tags.)

Der folgende Code fragt die Spalten-Metadaten ab und filtert gemäß unserer Anforderung auf Spalten, die _id enthalten. Diese Spaltennamen werden zu unseren Tag-Namen. Für jede _id-Spalte legen wir einen neuen Tag an. In diesem Fall lege ich die erlaubten Werte nicht vorab fest, da sie aus den Daten stammen.

Dieser Code erspart Ihnen, ein Dutzend oder mehr create tag-Statements von Hand zu schreiben. Er führt für jede Zeile eines select-Statements ein create or replace tag ... aus.

BEGIN
    -- Variablen deklarieren
    LET create_tag_statements RESULTSET := (
        SELECT
            'CREATE OR REPLACE TAG "' || COLUMN_NAME || '" COMMENT = ''Tag for ' || COLUMN_NAME || ''';' AS create_tag_statement
        FROM INFORMATION_SCHEMA.COLUMNS
        WHERE TABLE_NAME = 'WORKDAY_USERS'
          AND TABLE_SCHEMA = 'WORKDAY'
          AND LOWER(COLUMN_NAME) ILIKE '%_ID'
    );

    -- Result Set durchlaufen und jedes Statement ausführen
    LET stmt VARCHAR DEFAULT '';
    LET create_tag_cursor CURSOR FOR SELECT * FROM TABLE(RESULT_SCAN(LAST_QUERY_ID()));

Expand Code

Alternativ können Sie Befehle wie diese manuell ausführen:

use schema select_blog.workday;
create tag pillar_id;
create tag team_id;

-- Tags bei Bedarf löschen
drop tag my_obsolete_tag;

Eine View erstellen, die tatsächliche User-Tags mit dem Soll-Zustand vergleicht

Die Tabelle workday_users bildet den "Soll-Zustand" ab, denn sie liefert die aktuellsten Workday-Informationen dazu, wie unsere User-Tags gesetzt sein sollen. Jetzt müssen wir die tatsächlichen User-Tags mit diesem Soll-Zustand abgleichen und alle Zeilen anzeigen, bei denen die Tags nicht korrekt gesetzt sind. (In diesem Fall können wir uns darauf verlassen, dass die Spalte work_email in der Tabelle workday_users der E-Mail-Adresse des Snowflake-Users in der Tabelle snowflake.account_usage.users entspricht.)

Speichern wir diese Abfrage als View – wir werden sie häufig wiederverwenden.

create or replace view tag_updates as
with desired_tags as (
    select
        upper(work_email) as user_email,
        upper(tag_name) as tag_name,
        replace(upper(desired_tag_value), '-', '_') as desired_tag_value,
    from
        workday_users unpivot (
            desired_tag_value for tag_name in (pillar_id, group_id, group_id)
        )
),

snowflake_user_email as (
    select
        upper(name) as user_name,

Expand Code

Kurz zusammengefasst, was die View tut:

• Sie unpivotet die Workday-Tabelle (erzeugt Zeilen aus Spalten), sodass pro User und möglichem Tag eine Zeile entsteht.
• Sie ermittelt den Snowflake-USER_NAME, der getaggt werden soll, sowie die Snowflake-E-Mail-Adresse für den Join mit der "Soll-Zustand"-Tabelle.
• Sie joint über die E-Mail-Adresse, um die bestehenden Tags pro User zu ermitteln.
• Zuletzt zeigt sie alle Datensätze, bei denen der bestehende Tag-Wert nicht dem Soll-Wert entspricht.

Genau diese Datensätze können wir per Stored Procedure automatisch setzen.

Da die View tag_updates nur Zeilen enthält, deren bestehender Tag-Wert nicht dem Soll-Wert entspricht, sollte sie im Idealfall leer sein, wenn alle Tags korrekt gesetzt sind.

Eine Stored Procedure erstellen, die die Tags am User setzt

Die Stored Procedure führt im Kern diese Schritte aus:

• Für jede Zeile in der View tag_updates:
  • alter user, set tag = desired tag

Im Folgenden zeige ich zwei Varianten der Stored Procedure. Die erste ist eine schlanke Version ohne Logging – sehr übersichtlich und gut lesbar. Die zweite ist ausführlicher und eignet sich zum Troubleshooting, falls Ihre Tags nicht wie gewünscht gesetzt werden. Sie gibt Meldungen im SQL-Ergebnisbereich aus.

Schlanke Procedure:

CREATE OR REPLACE PROCEDURE SET_USER_TAGS()
  RETURNS VARCHAR
  LANGUAGE PYTHON
  RUNTIME_VERSION = '3.8'
  PACKAGES = ('snowflake-snowpark-python')
  HANDLER = 'main'
AS
$$
def main(session):
    query = """
      SELECT
        user_name as USER_NAME,
        tag_name as TAG_NAME,
        desired_tag_value as DESIRED_TAG_VALUE
      FROM tag_updates

Expand Code

Ausführliche Sproc mit Logging:

-- Procedure mit einer Admin-Rolle erstellen, die berechtigt ist, "alter user" auszuführen.
user role accountadmin; -- oder useradmin, falls Ihre User tatsächlich useradmin gehören
-- Bei Verwendung der Rolle useradmin müssen Sie dieser Rolle Usage auf der Datenbank gewähren. Daher ist accountadmin einfacher.
CREATE OR REPLACE PROCEDURE SET_USER_TAGS()
  RETURNS VARCHAR
  LANGUAGE PYTHON
  RUNTIME_VERSION = '3.8'
  PACKAGES = ('snowflake-snowpark-python')
  HANDLER = 'main'
AS
$$
def main(session):
    # Genau die Spalten holen, die wir aus der überarbeiteten View brauchen
    query = """
      SELECT

Expand Code

Rufen Sie die Procedure auf:

1call set_user_tags();

Machen Sie jetzt eine Mittagspause und warten Sie etwa eine Stunde (oder länger), bis die View account_usage.tag_references aktualisiert ist. Sind die Tags korrekt gesetzt und die View hat sich aktualisiert, liefert select * from tag_updates; nichts zurück – genau das, was wir wollten.

Einen Task zur Planung der Stored Procedure anlegen

Dieser Task führt die Procedure täglich um 4 Uhr UTC aus.

CREATE TASK set_user_tags
SCHEDULE = 'USING CRON 0 4 * * * UTC' AS
CALL set_user_tags();
alter task set_user_tags resume;

Und schon haben wir einen Prozess geschaffen, der User-Tags auf Basis unserer Workday-Metadatentabelle automatisiert.

Jetzt sind Sie dran

Dieses Beispiel zeigt nur eine mögliche Variante, Tags zu automatisieren. Doch im Sinne unserer Best Practices gilt: Automatisieren Sie Tagging, wo immer möglich. Der Ablauf ist immer derselbe:

• Einen klar definierten Soll-Zustand schaffen.
• Die Tags anlegen (manuell oder automatisiert).
• Das Setzen der Tags automatisieren, indem Soll- und Ist-Zustand abgeglichen werden.

In diesem Artikel haben wir Einsatzmöglichkeiten für Tags in Snowflake beleuchtet, gezeigt, wie sich Tags erstellen lassen, Best Practices vorgestellt und ein fortgeschrittenes Szenario durchgespielt. Werden Sie kreativ! Überlegen Sie, wie Sie Tagging in Ihrem Snowflake-Account automatisieren können.

Jeff ist Data- und Analytics-Consultant mit über 15 Jahren Erfahrung darin, Insights zu automatisieren und Geschäftsprozesse mit Daten zu steuern. Technologisch ist er auf Snowflake + dbt + Tableau spezialisiert. Inhaltlich bringt er Erfahrung aus den Bereichen Versorgungswirtschaft, klinische Studien, Verlagswesen, CPG und Fertigung mit. Kontaktieren Sie ihn jederzeit unter [email protected].