Best Practices für semantische Ansichten¶

Eigentümerschaft und Datenzugriff¶

Semantische Ansichten erleichtern den Zugriff auf Informationen, die in verschiedenen kanonischen Datenquellen vorhanden sind. Die semantische Schicht ermöglicht ein Umdenken weg von der Überlegung, wie eine bestimmte Datenquelle abgefragt werden kann, hin zur Fokussierung auf Anwendungsfälle und Geschäftsfragen, die von einer einheitlichen Ansicht der verfügbaren Daten unterstützt werden. Mit diesem übergeordneten Ziel vor Augen Data-Engineering- und Business-Teams eng zusammenarbeiten. Die Business-Teams verfügen über Fachkenntnisse zu den Geschäftsfällen, während die Data-Engineering-Teams wissen, wie sie auf die Daten aus Tabellen und Ansichten zugreifen können. Beide Teams müssen sich die Eigentümerschaft an dem semantischen Modell teilen.

Um die semantische Schicht so zu schützen, dass sie die Anforderungen beider Teams erfüllt, verwenden Sie eine rollenbasierte Zugriffssteuerung (Role-based Access Control, RBAC), um semantischen Ansichten und ihren abhängigen Objekten entsprechende Berechtigungen zu erteilen. Wenn Sie bei Null beginnen, können Sie die Abfolge von GRANT-Anweisungen im nächsten Abschnitt als Arbeitsvorlage verwenden. Wenn Ihre Teammitglieder jedoch bereits über Berechtigungen für Entwicklungs-, Test- und Produktionsumgebungen verfügen, müssen Sie möglicherweise einige Änderungen vornehmen oder sie anweisen, je nach Bedarf andere Rollen zu verwenden.

-- Set variables for the specified role, database, and schema
SET my_role = 'snowflake_intelligence_sales_analysis_role';
SET my_db = 'sales';
SET my_schema = 'sales_analysis';
SET my_full_schema = $my_db || '.' || $my_schema;

-- Grant usage on the database and schema that will contain the tables and views
GRANT USAGE ON DATABASE IDENTIFIER($my_db) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- Grant privileges on future objects within the schema
-- For tables and views, SELECT is the typical "usage" grant for read access
GRANT SELECT ON FUTURE TABLES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT SELECT ON FUTURE VIEWS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT SELECT ON FUTURE SEMANTIC VIEWS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- For other object types, USAGE is the correct privilege
GRANT USAGE ON FUTURE FUNCTIONS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE PROCEDURES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE STAGES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE CORTEX SEARCH SERVICES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- Grant usage on the database and schema that will contain the tables and views
GRANT USAGE ON DATABASE IDENTIFIER($my_db) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- Grant privileges on future objects within the schema
-- For tables and views, SELECT is the typical "usage" grant for read access
GRANT SELECT ON FUTURE TABLES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT SELECT ON FUTURE VIEWS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT SELECT ON FUTURE SEMANTIC VIEWS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- For other object types, USAGE is the correct privilege
GRANT USAGE ON FUTURE FUNCTIONS IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE PROCEDURES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE STAGES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);
GRANT USAGE ON FUTURE CORTEX SEARCH SERVICES IN SCHEMA IDENTIFIER($my_full_schema) TO ROLE IDENTIFIER($my_role);

-- Row access policy (restricts rows by user email)
CREATE OR REPLACE ROW ACCESS POLICY my_schema.account_row_policy AS (user_email STRING)
  RETURNS BOOLEAN ->
    EXISTS (
      SELECT 1
      FROM my_schema.account_access_list
      WHERE email = user_email()
    );

-- Masking policy (masks "sensitive_col" for users without a privileged role)
CREATE OR REPLACE MASKING POLICY my_schema.sensitive_col_masking_policy AS (val STRING)
RETURNS STRING ->
  CASE
    WHEN current_role() IN ('SENSITIVE_DATA_ACCESS_ROLE') THEN val
    ELSE 'MASKED'
  END;

-- Attach row access policy to the user_email column in the accounts table
ALTER TABLE my_schema.accounts
  ADD ROW ACCESS POLICY account_row_policy ON (user_email);

-- Attach masking policy to the sensitive_col column
ALTER TABLE my_schema.accounts
  MODIFY COLUMN sensitive_col
  SET MASKING POLICY sensitive_col_masking_policy;

-- Create the semantic view on the "accounts" table
CREATE OR REPLACE SEMANTIC VIEW my_schema.account_semantic_view
  TABLES (
    accounts AS my_schema.accounts
    PRIMARY KEY (account_id)
  )
  FACTS (
    account_id AS accounts.account_id,
    account_name AS accounts.account_name
  )
  DIMENSIONS (
    user_email AS accounts.user_email,
    sensitive_col AS accounts.sensitive_col
);

models:
- name: accounts
  description: "Table of accounts for semantic analytics."
  columns:
    - name: account_id
      description: "Unique identifier for the account."
    - name: account_name
      description: "Name of the account."
    - name: user_email
      description: "Email address linked to each account row."
    - name: sensitive_col
      description: "Sensitive information to be masked for non-privileged users."
  post-hook:
    - >
      ALTER TABLE {{ this }}
        ADD ROW ACCESS POLICY account_row_policy ON (user_email);
  ...

SELECT GET_DDL('SEMANTIC_VIEW','TEST_SAMPLE_VALUES');

create or replace semantic view TEST_SAMPLE_VALUES
tables (MARCH_TEMPS
  ...)
facts (MARCH_TEMPS.TEMPERATURE as TEMPERATURE
  ...)
dimensions (MARCH_TEMPS.CITY as CITY,
MARCH_TEMPS.COUNTY as COUNTY,
MARCH_TEMPS.OBSERVED as OBSERVED)
  ...
with extension (CA='{"tables":[{"name":"MARCH_TEMPS","dimensions":[{"name":"CITY","sample_values":["South Lake Tahoe","Big Bear City"]},{"name":"COUNTY","sample_values":["San Bernardino","El Dorado"]}],"facts":[{"name":"TEMPERATURE","sample_values":["44","46","52"]}],"time_dimensions":[{"name":"OBSERVED","sample_values":["2025-03-15T09:50:00.000+0000","2025-03-15T09:55:00.000+0000","2025-03-15T10:10:00.000+0000"]}]}
...);

Optionen zum Erstellen, Aktualisieren und Abfragen von semantischen Ansichten¶

Sie können semantische Ansichten in Snowflake erstellen, indem Sie eine YAML-Datei schreiben, die DDL-Syntax von Snowflake verwenden oder die UI in Snowsight nutzen. Snowflake bietet praktische Funktionen sowohl für den Import von YAML-Modellen als auch für den Export von semantischen Ansichten in YAML-Modelle. Weitere Details dazu finden Sie unter Konvertierung von semantischen YAML-Modellen in native semantische Ansichten.

Generell ist es am besten, mit der Erstellung semantischer Ansichten (anstelle semantischer Modelle) zu beginnen, bei denen es sich um Snowflake-Metadatenobjekte handelt, die von RBAC, Nutzungsstatistiken und einer direkten Integration in andere Snowflake-Features, z. B. Cortex Analyst und Snowflake Intelligence, profitieren.

Für das Erstellen einer semantischen Ansicht haben Sie drei Hauptoptionen:

• Erstellen einer semantischen Ansicht in Snowsight:

  • Sie können den Assistenten verwenden oder eine YAML-Spezifikation hochladen.

  • Für die Ersteinrichtung wird die Verwendung des Assistenten empfohlen. Er umfasst die automatische Erstellung von Synonymen, Beispielwerten und Spaltenbeschreibungen. Eine Anweisung dazu finden Sie unter Snowsight zum Erstellen und Verwalten von semantischen Ansichten verwenden.

• Erstellen einer semantischen Ansicht über eine SQL CREATE OR REPLACE SEMANTIC VIEW-Anweisung unter Verwendung einer Schnittstelle, die SQL unterstützt. Eine Anweisung dazu finden Sie unter Verwendung von SQL-Befehlen zum Erstellen und Verwalten semantischer Ansichten.

  Das programmgesteuerte Erstellen und Abfragen ist über Schnittstellen wie JDBC- und ODBC-Treiber oder die SQL-API </developer-guide/sql-api/index>`möglich. Sie können jedoch nicht die :doc:/developer-guide/snowflake-rest-api/snowflake-rest-api` verwenden.

• Erstellen einer semantischen Ansicht von einer YAML-Spezifikation in SQL durch Aufrufen der gespeicherten Prozedur SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML. Siehe Konvertierung von semantischen YAML-Modellen in native semantische Ansichten.

Wenn Sie dbt verwenden, können Sie außerdem die Erstellung von semantischen Ansichten in Snowflake konfigurieren, indem Sie das Paket dbt_semantic_view installieren. Weitere Informationen dazu finden Sie unter Integration in dbt-Projekte.

Denken Sie daran, dass die Einrichtung von Rollen und Berechtigungen für Ihre Teammitglieder einen Einfluss auf deren Fähigkeit haben kann, semantische Ansichten zu erstellen. Beispiel: Wenn Sie in Ihrer Produktionsumgebung als SERVICE-Benutzender agieren müssen, können Sie sich in dieser Umgebung nicht bei Snowsight anmelden, sondern müssen SQL-Befehle zum Erstellen und Verwalten von semantischen Ansichten verwenden.

Wenn in einer Snowflake-Datenbank semantische Ansichten erstellt wurden, können Administrierende diese mit den Standardbefehlen SHOW und DESCRIBE verwalten, und Benutzende können nachgelagert über SQL SELECT-Anweisungen und auf folgende Weisen auf sie zugreifen:

• Direkt über die Benutzeroberfläche von Cortex Analyst

• Über Streamlit oder andere kundenspezifische Anwendungen, die die Cortex Analyst-API verwenden und/oder SELECT FROM SEMANTIC_VIEW-Anweisungen generieren

• Über Cortex Agents via Cortex Analyst (semantische Ansichten müssen einem neuen oder vorhandenen Agent hinzugefügt werden)

Mit Ausnahme von Kommentaren können Sie Tabellen, Spalten oder Metadaten innerhalb bestehender semantischer Ansichten nicht hinzufügen oder ändern. Sie müssen diese also neu erstellen (mit CREATE OR REPLACE-Befehlen), um Änderungen zu übernehmen. Beachten Sie außerdem, dass durch Aktualisieren einer semantischen Ansicht über einen SQL-Befehl alle manuellen Änderungen überschrieben werden, die Sie in einer aktiven Snowsight-Sitzung vorgenommen haben. Es wird nicht unterstützt, beide Arten von Änderungen beizubehalten.

Konvertierung von semantischen YAML-Modellen in native semantische Ansichten¶

Sie können SQL-Systemfunktionen und gespeicherte Prozeduren zur Erstellung von semantischen Ansichten aus YAML-Modellen verwenden und YAML-Modelle aus semantischen Ansichten erstellen.

Derzeit unterstützt Snowflake keine Massenkonvertierung, das heißt, Sie müssen YAML-Dateien nacheinander in native semantische Ansichten umwandeln. Sie können die gespeicherte Prozedur SYSTEM$CREATE_SEMANTIC_VIEW_FROM_YAML für die Konvertierung verwenden. Wenn Sie eine Massenkonvertierung oder -integration in eine CI/CD-Pipeline ausführen müssen, müssen Sie die Konvertierungen in Form eines Skripts in einer Serie schreiben. In naher Zukunft plant Snowflake keine Unterstützung der Batch/Massen-Konvertierung.

Um eine native semantische Ansicht zurück nach YAML zu exportieren, können Sie die Funktion SYSTEM$READ_YAML_FROM_SEMANTIC_VIEW verwenden. Diese Funktion ermöglicht die automatische Nachbearbeitung, das Roundtripping oder die Serialisierung in die Versionskontrolle.

Die gleichen praktischen Richtlinien bezüglich der Größe gelten sowohl für native semantische Ansichten als auch für YAML-basierte Modelle. Es gibt eine praktische Richtlinie (keine feste Grenze), dass für optimale Performance semantische Ansichten insgesamt nicht mehr als 50–100 Spalten über alle Tabellen hinweg haben sollten. Diese Richtlinie gilt sowohl für native semantische Ansichten als auch für YAML-basierte Modelle und ist hauptsächlich auf die Einschränkungen des Kontextfensters in AI-Komponenten wie Cortex Analyst zurückzuführen. Eine Überschreitung dieser Empfehlung kann zu Latenzen oder Beeinträchtigungen der Qualität führen, stellt jedoch keine technische Grenze dar.

Automatisierte Bereitstellung von semantischen Ansichten¶

Wenn möglich, nutzen Sie CI/CD-Pipelines und programmgesteuerte Schnittstellen zum Erstellen, Ändern und Verwalten von semantischen Ansichten. Idealerweise richten Sie Ihren Workflow so ein, dass Aktualisierungen an semantischen Ansichten automatisch mit Ihrem Git-Repository synchronisiert werden. Dieser Ansatz verringert manuelle Fehler, die durch das Kopieren und Einfügen oder das Pushen von Änderungen an Git verursacht werden können.

• Speichern Sie die semantische Ansicht YAML (oder SQL-DDL) in einem Git-Repository. Dieser Ansatz unterstützt Versionskontrolle, Peer-Review, Verlauf und Rollback.

• Bei Verwendung von Snowsight sollten Sie das YAML-Modell regelmäßig exportieren oder herunterladen und an Git übergeben.

• Lösen Sie CI/CD-Pipelines bei Änderungen an Git aus (um Tests und Genauigkeitsprüfungen durchzuführen und nur dann bereitzustellen, wenn diese Tests bestanden wurden).

• Führen Sie bei Bedarf ein Rollback durch, indem Sie die vorherige, bekanntermaßen funktionierende YAML oder DDL von Git erneut bereitstellen.

Um Modelle von der Entwicklungs- in die Test- oder Produktionsumgebung heraufzustufen, können Sie automatisierte Bereitstellungsskripte einbinden oder Klonen auf Schemaebene verwenden. Semantische Ansichten werden geklont, wenn Schemas, die diese Ansichten enthalten, geklont werden. Da die Replikation für semantische Ansichten noch nicht unterstützt wird, ist das Klonen eine gute Alternative, um semantische Ansichten über Datenbanken und Umgebungen, die dasselbe Snowflake-Konto verwenden, heraufzustufen.

Semantische Ansichten können direkt über den Snowflake Marketplace und per Datenfreigabe freigegeben werden. Sie können sichere Ansichten basierend auf semantischen Ansichten erstellen. Die Freigabe dieser verschachtelten Ansichten wird unterstützt. Für einige Szenarien der erneuten Freigabe bestehen jedoch Einschränkungen (z. B. wenn Verbrauchende einer Freigabe eine Ansicht, die auf einer semantischen Ansicht basiert, weiter freigeben möchten).

Um die Materialisierung und Pflege von semantischen Ansichten als Teil einer Snowflake-Datenpipeline zu unterstützen, können Sie ein dbt-Projekt verwenden (siehe Integration in dbt-Projekte). Unterstützung für einen ähnlichen Prozess mit dem Snowflake Terraform-Anbieter ist geplant.

Letztendlich sollte Ihr Ziel darin bestehen, einen Workflow zu ermöglichen, der dem folgenden dbt-Beispiel ähnelt:

• Arbeiten an dbt-Projektänderungen in einer IDE, z. B. VS Code

• Hinzufügen einer neuen Definition semantischer Ansicht zum dbt-Code

• Übertragen der Änderungen an Git

• Festlegen von Triggern, die einen 'dbt run'-Vorgang als Teil der Datenpipeline ausführen

Als Ergebnis würde die semantische Ansicht im Snowflake-Konto materialisiert.

Integration in dbt-Projekte¶

Sie können semantische Ansichten in Ihren dbt-Workflow integrieren, indem Sie das dbt_semantic_view-Paket installieren, das in Snowflake Labs verfügbar ist: https://hub.getdbt.com/Snowflake-Labs/dbt_semantic_view/latest/.

Dieses Paket funktioniert nativ mit dbt-Projekte in Snowflake oder jeder dbt-Installation, die Zugriff auf ein Snowflake-Konto hat. Sie können dieses Paket verwenden, um semantische Ansichten über dbt zu materialisieren und aus nachgelagerten Modellen auf sie zu verweisen.

Bei den folgenden Anweisungen wird davon ausgegangen, dass Sie mit dbt vertraut sind und dbt bereits in einer Umgebung installiert haben, die eine Verbindung zu Snowflake herstellen kann.

So installieren und verwenden Sie das dbt_semantic_view-Paket:

1. Fügen Sie in der Datei packages.yml folgenden Code hinzu:

   packages:
     - package: Snowflake-Labs/dbt_semantic_view
       version: 1.0.3
   

   Copy

   Stellen Sie sicher, dass Sie die Versionsnummer einschließen. Die Versionsnummer des Pakets kann sich ändern. Es wird empfohlen, die neueste Version zu verwenden.

2. Führen Sie den Befehl dbt deps aus, um das Paket zu installieren.

3. Erstellen Sie im dbt-Verzeichnis models ein Modell, das den Materialisierungscode für semantische Ansichten verwendet:

   {{ config(materialized='semantic_view') }}
   
   TABLES(
   {{ source('<source_name>', '<table_name>') }},
   {{ ref('<another_model>') }}
   )
   [ RELATIONSHIPS ( relationshipDef [ , ... ] ) ]
   [ FACTS ( semanticExpression [ , ... ] ) ]
   [ DIMENSIONS ( semanticExpression [ , ... ] ) ]
   [ METRICS ( semanticExpression [ , ... ] ) ]
   [ COMMENT = '<comment>' ]
   [ COPY GRANTS ]
   

   Copy

   Sie können zum Beispiel eine einfache semantische Ansicht wie folgt materialisieren:

   {{ config(materialized='semantic_view') }}
   
   TABLES(t1 AS {{ ref('base_table') }}, t2 as {{ source('seed_sources', 'base_table2') }})
   DIMENSIONS(t1.count as value, t2.volume as value)
   METRICS(t1.total_rows AS SUM(t1.count), t2.max_volume as max(t2.volume))
   COMMENT='test semantic view'
   

   Copy

4. Konfigurieren Sie Ihre Verbindung zu Snowflake in dbt, und geben Sie die Details der Verbindung in Ihrer profiles.yml-dbt-Datei an. Weitere Informationen dazu finden Sie in der dbt-Dokumentation. Beispiel:

   semantic_project:
     target: snowflake
     outputs:
       snowflake:
       type: "snowflake"
       account: "{{ env_var('SNOWFLAKE_ACCOUNT') }}"
       user: "{{ env_var('SNOWFLAKE_USER') }}"
       password: "{{ env_var('SNOWFLAKE_PASSWORD') }}"
       authenticator: "{{ env_var('SNOWFLAKE_AUTHENTICATOR') }}"
       role: "{{ env_var('SNOWFLAKE_ROLE') }}"
       database: "{{ env_var('SNOWFLAKE_DATABASE') }}"
       warehouse: "{{ env_var('SNOWFLAKE_WAREHOUSE') }}"
       schema: "{{ env_var('SNOWFLAKE_SCHEMA') }}"
       threads: 4
   

   Copy

5. Bei diesem Profil könnten Sie sich mit den folgenden Umgebungsvariablen authentifizieren:

   $ export SNOWFLAKE_ACCOUNT=snowflake_acct1
   $ export SNOWFLAKE_USER=sem_user1
   $ export SNOWFLAKE_PASSWORD=**************
   $ export SNOWFLAKE_AUTHENTICATOR=externalbrowser
   $ export SNOWFLAKE_ROLE=semantic_role
   $ export SNOWFLAKE_DATABASE=sem_db
   $ export SNOWFLAKE_WAREHOUSE=sem_wh
   $ export SNOWFLAKE_SCHEMA=sem_schema
   

   Copy

6. Führen Sie den Befehl dbt build aus, um sich mit Ihrem Snowflake-Konto zu verbinden und das Modell zu erstellen. Im folgenden Beispiel wird ein spezifisches Modell erstellt, das als models/semantic_view_basic definiert ist. Beachten Sie, dass ein anderes Modell, table_refer_to_semantic_view, von diesem Modell abhängt, sodass der Befehl das Zeichen + am Ende erfordert.

   $ dbt build --target snowflake --select semantic_view_basic+
   23:43:16  Running with dbt=1.11.0-b3
   23:43:17  Registered adapter: snowflake=1.10.2
   23:43:17  Found 9 models, 8 data tests, 1 seed, 2 operations, 2 sources, 500 macros
   23:43:17
   23:43:17  Concurrency: 4 threads (target='snowflake')
   23:43:17
   23:43:32  1 of 2 START hook: dbt_semantic_view_integration_tests.on-run-start.0 .......... [RUN]
   23:43:32  1 of 2 OK hook: dbt_semantic_view_integration_tests.on-run-start.0 ............. [OK in 0.90s]
   23:43:33  2 of 2 START hook: dbt_semantic_view_integration_tests.on-run-start.1 .......... [RUN]
   23:43:33  2 of 2 OK hook: dbt_semantic_view_integration_tests.on-run-start.1 ............. [OK in 0.38s]
   23:43:33
   23:43:33  1 of 6 START sql semantic_view model sem_schema.semantic_view_basic ............ [RUN]
   23:43:33  1 of 6 OK created sql semantic_view model sem_schema.semantic_view_basic ....... [SUCCESS 1 in 0.26s]
   23:43:33  3 of 6 START test semantic_view_basic_has_no_copy_grants ....................... [RUN]
   23:43:33  2 of 6 START test semantic_view_basic_has_comment .............................. [RUN]
   23:43:33  4 of 6 START test semantic_view_sum_matches_base_table ......................... [RUN]
   23:43:33  2 of 6 PASS semantic_view_basic_has_comment .................................... [PASS in 0.23s]
   23:43:34  3 of 6 PASS semantic_view_basic_has_no_copy_grants ............................. [PASS in 0.75s]
   23:43:34  4 of 6 PASS semantic_view_sum_matches_base_table ............................... [PASS in 1.05s]
   23:43:34  5 of 6 START sql table model sem_schema.table_refer_to_semantic_view ........... [RUN]
   23:43:35  5 of 6 OK created sql table model sem_schema.table_refer_to_semantic_view ...... [SUCCESS 1 in 1.22s]
   23:43:35  6 of 6 START test table_refer_semantic_view_matches_semantic_view .............. [RUN]
   23:43:36  6 of 6 PASS table_refer_semantic_view_matches_semantic_view .................... [PASS in 0.26s]
   23:43:36
   23:43:36  Finished running 2 project hooks, 1 semantic view model, 1 table model, 4 data tests in 0 hours 0 minutes and 19.34 seconds (19.34s).
   23:43:36
   23:43:36  Completed successfully
   23:43:36
   23:43:36  Done. PASS=8 WARN=0 ERROR=0 SKIP=0 NO-OP=0 TOTAL=8
   

   Copy

Weitere Informationen zum dbt_semantic_view-Paket, das vorgefertigte Modelle und Tests enthält, die Sie ausführen können, finden Sie in der README.md-Datei. Gehen Sie zu https://hub.getdbt.com/Snowflake-Labs/dbt_semantic_view/latest/, und wählen Sie View on GitHub aus.

Siehe auch https://www.snowflake.com/en/engineering-blog/dbt-semantic-view-package/.

Integration in BI-Tools¶

Einige BI-Toolanbieter bieten Integrationen mit semantischen Ansichten von Snowflake an. Wenn Sie mehr über diese Integrationen erfahren möchten, wenden Sie sich bitte an Ihre Account-Teams für BI-Tools, und folgen Sie diesen Links:

• Sigma: https://www.sigmacomputing.com/blog/snowflake-semantic-views-launch

• Omni: https://omni.co/snowflake

• Honeydew: https://honeydew.ai/blog/honeydew-and-snowflake-semantic-views/

• Hex: https://hex.tech/blog/introducing-snowflake-semantic-sync-aisql/