Leitfaden zur Snowflake SQL-Übersetzung
In diesem Dokument werden die Ähnlichkeiten und Unterschiede in der SQL-Syntax zwischen Snowflake und BigQuery beschrieben, um die Planung und Ausführung der Verlagerung Ihres Enterprise Data Warehouse (EDW) nach BigQuery zu beschleunigen. Snowflake für Data Warehousing wurde für die SQL-Syntax von Snowflake entwickelt. Für Snowflake geschriebene Skripts müssen möglicherweise geändert werden, bevor Sie sie in BigQuery verwenden können, da die SQL-Dialekte zwischen den Diensten variieren. Verwenden Sie die Batch-SQL-Übersetzung, um Ihre SQL-Skripts im Bulk zu migrieren, oder die interaktive SQL-Übersetzung, um Ad-hoc-Abfragen zu übersetzen. Snowflake SQL wird von beiden Tools in der Vorschau unterstützt.
Datentypen
In diesem Abschnitt werden die Entsprechungen zwischen den Datentypen in Snowflake und BigQuery beschrieben.
Snowflake | BigQuery | Hinweise |
---|---|---|
NUMBER/
DECIMAL/NUMERIC |
NUMERIC |
Der Datentyp NUMBER in Snowflake unterstützt eine Genauigkeit von 38 Ziffern und 37 Dezimalstellen. Die Genauigkeit und Skalierung können durch den Nutzer festgelegt werden.BigQuery unterstützt NUMERIC und BIGNUMERIC mit optional angegebener Genauigkeit und Skalierung innerhalb bestimmter Grenzen. |
INT/INTEGER |
BIGNUMERIC |
INT/INTEGER und alle anderen INT -ähnlichen Datentypen, beispielsweise BIGINT, TINYINT, SMALLINT, BYTEINT , stellen einen Alias für den NUMBER -Datentyp dar, bei dem die Genauigkeit und die Skalierung nicht angegeben werden können und immer NUMBER(38, 0) sind. |
BIGINT |
BIGNUMERIC |
|
SMALLINT |
BIGNUMERIC |
|
TINYINT |
BIGNUMERIC |
|
BYTEINT |
BIGNUMERIC |
|
FLOAT/ |
FLOAT64 |
Der Datentyp FLOAT in Snowflake legt „NaN“ als > X fest, wobei X ein beliebiger FLOAT-Wert (außer „NaN“ selbst) ist.Der Datentyp FLOAT in BigQuery legt „NaN“ als < X fest, wobei X ein beliebiger FLOAT-Wert (außer „NaN“ selbst) ist. |
DOUBLE/ REAL |
FLOAT64 |
Der Datentyp DOUBLE in Snowflake ist synonym mit dem Datentyp FLOAT in Snowflake, wird jedoch häufig fälschlicherweise als FLOAT angezeigt. Er wird ordnungsgemäß als DOUBLE gespeichert. |
VARCHAR |
STRING |
Der Datentyp VARCHAR in Snowflake hat eine maximale Länge von 16 MB (unkomprimiert). Wenn keine Länge angegeben ist, wird die standardmäßig die maximale Länge verwendet.Der Datentyp STRING in BigQuery wird als UTF-8-codierter Unicode mit variabler Länge gespeichert. Die maximale Länge beträgt 16.000 Zeichen. |
CHAR/CHARACTER |
STRING |
Der Datentyp CHAR in Snowflake hat eine maximale Länge von 1. |
STRING/TEXT |
STRING |
Der Datentyp STRING in Snowflake ist synonym mit VARCHAR von Snowflake. |
BINARY |
BYTES |
|
VARBINARY |
BYTES |
|
BOOLEAN |
BOOL |
Der Datentyp BOOL in BigQuery kann nur TRUE/FALSE akzeptieren, im Gegensatz zum Datentyp BOOL in Snowflake, der TRUE/FALSE/NULL akzeptieren kann. |
DATE |
DATE |
Der Typ DATE in Snowflake akzeptiert die meisten gängigen Datumsformate im Gegensatz zum Typ DATE in BigQuery, der nur Datumsangaben im Format „JJJJ-[M]M-[D]D“ akzeptiert. |
TIME |
TIME |
Der TIME-Typ in Snowflake unterstützt eine Genauigkeit von 0 bis 9 Nanosekunden, während der Typ TIME in BigQuery eine Genauigkeit von 0 bis 6 Nanosekunden unterstützt. |
TIMESTAMP |
DATETIME |
TIMESTAMP ist ein vom Nutzer konfigurierbarer Alias, der standardmäßig TIMESTAMP_NTZ ist, der in BigQuery DATETIME zugeordnet ist. |
TIMESTAMP_LTZ |
TIMESTAMP |
|
TIMESTAMP_NTZ/DATETIME |
DATETIME |
|
TIMESTAMP_TZ |
TIMESTAMP |
|
OBJECT |
JSON |
Der Typ OBJECT in Snowflake unterstützt keine explizit typisierten Werte. Werte entsprechen dem Typ VARIANT . |
VARIANT |
JSON |
Der Typ OBJECT in Snowflake unterstützt keine explizit typisierten Werte. Werte entsprechen dem Typ VARIANT . |
ARRAY |
ARRAY<JSON> |
Der Typ ARRAY in Snowflake unterstützt nur VARIANT -Typen, während der ARRAY-Typ in BigQuery alle Datentypen mit Ausnahme eines Arrays selbst unterstützen kann. |
BigQuery verfügt auch über die folgenden Datentypen, die kein direktes Snowflake-Analog haben:
Abfragesyntax und Abfrageoperatoren
In diesem Abschnitt werden Unterschiede in der Abfragesyntax zwischen Snowflake und BigQuery behandelt.
SELECT
-Anweisung
Die meisten Snowflake-SELECT
-Anweisungen sind mit BigQuery kompatibel. Die folgende Tabelle enthält eine Liste mit geringfügigen Unterschieden.
Snowflake | BigQuery | |
---|---|---|
|
|
|
Hinweis: Snowflake unterstützt das Erstellen und Referenzieren eines Alias in derselben SELECT -Anweisung. |
|
|
|
|
Bei Snowflake-Aliassen und -Kennungen wird standardmäßig die Groß-/Kleinschreibung nicht berücksichtigt. Um die Groß- und Kleinschreibung beizubehalten, setzen Sie Aliasse und Kennungen in doppelte Anführungszeichen (").
BigQuery unterstützt die folgenden Ausdrücke in SELECT
-Anweisungen, für die es kein Snowflake-Äquivalent gibt:
FROM
-Klausel
Eine FROM
-Klausel in einer Abfrage gibt die möglichen Tabellen, Ansichten, Unterabfragen oder Tabellenfunktionen an, die in einer SELECT-Anweisung verwendet werden sollen. Alle diese Tabellenreferenzen werden in BigQuery unterstützt.
Die folgende Tabelle enthält eine Liste mit geringfügigen Unterschieden.
Snowflake | BigQuery | |
---|---|---|
|
WITH table1 AS |
|
|
|
|
|
Hinweis. BigQuery hat keine direkte Alternative zu Snowflakes BEFORE unter Verwendung einer Anweisungs-ID. Der Wert von timestamp darf nicht mehr als 7 Tage vor dem aktuellen Zeitstempel liegen. |
|
|
BigQuery unterstützt das Konzept bereitgestellter Dateien nicht. |
|
|
BigQuery bietet keine direkte Alternative zum |
Auf BigQuery-Tabellen kann in der FROM
-Klausel durch Folgendes verwiesen werden:
[project_id].[dataset_id].[table_name]
[dataset_id].[table_name]
[table_name]
BigQuery unterstützt auch zusätzliche Tabellenreferenzen:
- Frühere Versionen der Tabellendefinition und der Zeilen mit
FOR SYSTEM_TIME AS OF
. - Feldpfade oder jeder Pfad, der in ein Feld innerhalb eines Datentyps aufgelöst wird (d. h. ein
STRUCT
) - Vereinfachte Arrays
WHERE
-Klausel
Die Snowflake-WHERE
-Klausel und die BigQuery-WHERE
-Klausel sind identisch, bis auf die folgenden Elemente:
Snowflake | BigQuery | |
---|---|---|
|
SELECT col1, col2 Hinweis: BigQuery unterstützt die (+) -Syntax für JOIN s nicht. |
JOIN
-Typen
Sowohl Snowflake als auch BigQuery unterstützen die folgenden Join-Typen:
[INNER] JOIN
LEFT [OUTER] JOIN
RIGHT [OUTER] JOIN
FULL [OUTER] JOIN
CROSS JOIN
und der entsprechende implizite „durch Komma getrenntes Cross Join“
Sowohl Snowflake als auch BigQuery unterstützen die Klausel ON
und USING
.
Die folgende Tabelle enthält eine Liste mit geringfügigen Unterschieden.
Snowflake | BigQuery | |
---|---|---|
|
Hinweis: In BigQuery erfordern JOIN -Klauseln eine JOIN-Bedingung, es sei denn, es ist ein CROSS JOIN oder eine der verknüpften Tabellen ist ein Feld innerhalb eines Datentyps oder eines Arrays. |
|
Hinweis: Im Gegensatz zur Ausgabe eines nicht lateralen Joins enthält die Ausgabe eines „Lateral Join“ nur die Zeilen, die aus der Inline-Ansicht generiert wurden. Die Zeilen auf der linken Seite müssen nicht mit der rechten Seite verknüpft sein, da die Zeilen auf der linken Seite bereits berücksichtigt wurden, indem sie in die Inline-Ansicht übergeben wurden. |
LATERAL JOIN s. |
WITH
-Klausel
Eine BigQuery-WITH
-Klausel enthält eine oder mehrere Unterabfragen, die jedes Mal ausgeführt werden, wenn eine nachfolgende SELECT
-Anweisung auf sie verweist. Snowflake-WITH
-Klauseln verhalten sich genauso wie BigQuery, mit der Ausnahme, dass BigQuery WITH RECURSIVE
nicht unterstützt.
GROUP BY
-Klausel
Snowflake-GROUP BY
-Klauseln unterstützen GROUP
BY
, GROUP BY
ROLLUP
, GROUP BY GROUPING
SETS
und GROUP BY
CUBE
, während BigQuery-GROUP BY
-Klauseln GROUP
BY
und GROUP BY
ROLLUP
unterstützen.
Snowflake-HAVING
und BigQuery-HAVING
sind synonym. Beachten Sie, dass HAVING
nach GROUP BY
und der Aggregation und vor ORDER BY
auftritt.
Snowflake | BigQuery | |
---|---|---|
|
|
|
|
|
|
Hinweis: Snowflake erlaubt bis zu 128 Gruppierungssätze im selben Abfrageblock. |
BigQuery unterstützt keine direkte Alternative zu den GROUP BY GROUPING SETS von Snowflake. |
|
Hinweis: Snowflake erlaubt in jedem Cube bis zu 7 Elemente (128 Gruppierungssätze) |
BigQuery unterstützt keine direkte Alternative zu den GROUP BY CUBE von Snowflake. |
ORDER BY
-Klausel
Zwischen den Snowflake-ORDER BY
-Klauseln und BigQuery-ORDER BY
-Klauseln gibt es einige geringfügige Unterschiede.
Snowflake | BigQuery | |
---|---|---|
In Snowflake werden NULL s standardmäßig am niedrigsten eingestuft (aufsteigende Reihenfolge). |
In BigQuery werden NULLS s standardmäßig am höchsten eingestuft (aufsteigende Reihenfolge). |
|
Sie können mit NULLS FIRST oder NULLS LAST angeben, ob NULL -Werte zuerst oder zuletzt sortiert werden sollen. |
Es gibt kein Äquivalent, um anzugeben, ob NULL -Werte in BigQuery zuerst oder zuletzt sein sollen. |
LIMIT/FETCH
-Klausel
Die LIMIT/FETCH
-Klausel in Snowflake beschränkt die maximale Anzahl von Zeilen, die von einer Anweisung oder Unterabfrage zurückgegeben werden.
LIMIT
(Postgres-Syntax) und FETCH
(ANSI-Syntax) führen zum selben Ergebnis.
In Snowflake und BigQuery hat die Anwendung einer LIMIT
-Klausel auf eine Abfrage keine Auswirkungen auf die Menge der gelesenen Daten.
Snowflake | BigQuery | |
---|---|---|
Hinweis: NULL , leere String ('') und $$$$ -Werte werden akzeptiert und werden als „unbegrenzt“ behandelt. Wird hauptsächlich für Connectors und Treiber verwendet. |
Hinweis: FETCH wird von BigQuery nicht unterstützt. LIMIT ersetzt FETCH .Hinweis: In BigQuery muss OFFSET zusammen mit einem LIMIT count verwendet werden. Achten Sie darauf, den INT64-Wert count auf die mindestens erforderlichen geordneten Zeilen festzulegen, um eine optimale Leistung zu erzielen. Das Sortieren aller Ergebniszeilen führt zu einer unnötigen Verschlechterung der Abfrageausführungsleistung. |
QUALIFY
-Klausel
Die QUALIFY
-Klausel in Snowflake gestattet Ihnen, Ergebnisse für Fensterfunktionen zu filtern, die dem ähnlich sind, was HAVING
mit Aggregatfunktionen und GROUP BY
-Klauseln macht.
Snowflake | BigQuery | |
---|---|---|
|
Die Snowflake QUALIFY -Klausel mit einer Analysefunktion wie ROW_NUMBER() , COUNT() und mit OVER PARTITION BY wird in BigQuery als WHERE -Klausel für eine Unterabfrage ausgedrückt, die den Analysewert enthält.Mit ROW_NUMBER() :SELECT col1, col2
Verwendung von ARRAY_AGG() , wodurch größere Partitionen unterstützt werden:
|
Funktionen
In den folgenden Abschnitten werden die Snowflake-Funktionen und ihre BigQuery-Entsprechungen aufgeführt.
Aggregatfunktionen
Die folgende Tabelle zeigt Zuordnungen zwischen gängigen Snowflake-Aggregat-, Aggregatanalyse- und ungefähren Aggregatfunktionen mit ihren BigQuery-Entsprechungen.
Snowflake | BigQuery |
---|---|
Hinweis: DISTINCT hat keine Auswirkungen |
|
Hinweis: DISTINCT hat keine Auswirkungen |
Hinweis: BigQuery unterstützt APPROX_COUNT_DISTINCT mit Fensterfunktionen nicht. |
Hinweis: Snowflake hat nicht die Möglichkeit, RESPECT NULLS zu verwenden. |
Hinweis: BigQuery unterstützt APPROX_QUANTILES mit Fensterfunktionen nicht. |
|
BigQuery unterstützt nicht die Möglichkeit, einen Zwischenzustand zu speichern, wenn ungefähre Werte vorhergesagt werden. |
|
BigQuery unterstützt nicht die Möglichkeit, einen Zwischenzustand zu speichern, wenn ungefähre Werte vorhergesagt werden. |
|
BigQuery unterstützt nicht die Möglichkeit, einen Zwischenzustand zu speichern, wenn ungefähre Werte vorhergesagt werden. |
Hinweis: Wenn kein Zahlenparameter angegeben ist, ist der Standardwert 1. Zähler sollten deutlich größer als die Anzahl sein. |
Hinweis: BigQuery unterstützt APPROX_TOP_COUNT mit Fensterfunktionen nicht. |
|
BigQuery unterstützt nicht die Möglichkeit, einen Zwischenzustand zu speichern, wenn ungefähre Werte vorhergesagt werden. |
|
BigQuery unterstützt nicht die Möglichkeit, einen Zwischenzustand zu speichern, wenn ungefähre Werte vorhergesagt werden. |
|
BigQuery unterstützt nicht die Möglichkeit, einen Zwischenzustand zu speichern, wenn ungefähre Werte vorhergesagt werden. |
|
Sie können eine benutzerdefinierte UDF verwenden, um MINHASH mit k verschiedenen Hash-Funktionen zu implementieren. Ein weiterer Ansatz zur Reduzierung der Varianz in MINHASH besteht darin,k der Mindestwerte einer Hash-Funktion beizubehalten. In diesem Fall kann der Jaccard-Index so approximiert werden:
|
|
Dies ist ein Synonym für APPROXIMATE_JACCARD_INDEX und kann auf die gleiche Weise implementiert werden. |
|
|
|
Hinweis: AVG von BigQuery führt kein automatisches Umwandeln für STRING s durch. |
|
INTEGER um. |
|
Hinweis: BigQuery wandelt Zeichen-/Textspalten nicht implizit in die nächste INTEGER um. |
|
Hinweis: BigQuery wandelt Zeichen-/Textspalten nicht implizit in die nächste INTEGER um. |
Hinweis: Snowflake ermöglicht die Behandlung numerischer, Dezimal- und Gleitkommawerte als TRUE , wenn nicht null. |
|
Hinweis: Snowflake ermöglicht die Behandlung numerischer, Dezimal- und Gleitkommawerte als TRUE , wenn nicht null. |
|
Hinweis: Snowflake ermöglicht die Behandlung numerischer, Dezimal- und Gleitkommawerte als TRUE , wenn nicht null. |
Für numerischen Ausdruck:
Zur Verwendung von OVER können Sie Folgendes ausführen (boolesches Beispiel bereitgestellt):
|
|
|
|
|
|
|
|
|
|
BigQuery unterstützt keine direkte Alternative zu den GROUPING von Snowflake. Verfügbar über eine benutzerdefinierte Funktion. |
|
BigQuery unterstützt keine direkte Alternative zu den GROUPING_ID von Snowflake. Verfügbar über eine benutzerdefinierte Funktion. |
|
BIT_XOR( FARM_FINGERPRINT( TO_JSON_STRING(t))) [OVER] AUS t AUSWÄHLEN |
Hinweis: In Snowflake können Sie die Genauigkeit nicht angeben. |
Hinweis: BigQuery unterstützt HLL_COUNT… nicht mit Fensterfunktionen. Ein Nutzer kann nicht mehrere Ausdrücke in einer einzelnen HLL_COUNT... -Funktion zusammenfassen. |
Hinweis: In Snowflake können Sie die Genauigkeit nicht angeben. |
HLL_COUNT.INIT (Ausdruck [, Genauigkeit]) |
|
HLL_COUNT.MERGE_PARTIAL (Skizze) |
|
|
|
BigQuery unterstützt keine direkte Alternative zu den HLL_EXPORT von Snowflake. |
|
BigQuery unterstützt keine direkte Alternative zu den HLL_IMPORT von Snowflake. |
|
BigQuery unterstützt keine direkte Alternative zu den KURTOSIS von Snowflake. |
|
|
Hinweis: Snowflake unterstützt nicht die Möglichkeit, IGNORE|RESPECT NULLS und LIMIT direkt in ARRAY_AGG. zu verwalten. |
|
|
|
|
Sie können eine benutzerdefinierte UDF verwenden, um MINHASH mit k verschiedenen Hash-Funktionen zu implementieren. Ein weiterer Ansatz zur Reduzierung der Varianz in MINHASH besteht darin, k der Mindestwerte einer Hash-Funktion beizubehalten: SELECT DISTINCT FARM_FINGERPRINT( TO_JSON_STRING(t)) AS MINHASH
|
|
<code<select FROM ( SELECT DISTINCT FARM_FINGERPRINT( TO_JSON_STRING(t)) AS h FROM TA AS t ORDER BY h LIMIT k UNION SELECT DISTINCT FARM_FINGERPRINT( TO_JSON_STRING(t)) AS h FROM TB AS t ORDER BY h LIMIT k ) ORDER BY h LIMIT k |
|
|
|
Sie können TO_JSON_STRING verwenden, um einen Wert in einen JSON-formatierten String zu konvertieren. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
BigQuery unterstützt keine direkte Alternative zum SKEW von Snowflake. |
|
|
|
|
|
|
|
|
Hinweis: Snowflake unterstützt die Möglichkeit, VARCHAR s in Gleitkommawerte umzuwandeln. |
|
Hinweis: Snowflake unterstützt die Möglichkeit, VARCHAR s in Gleitkommawerte umzuwandeln. |
|
Hinweis: Snowflake unterstützt die Möglichkeit, VARCHAR s in Gleitkommawerte umzuwandeln. |
|
Hinweis: Snowflake unterstützt die Möglichkeit, VARCHAR s in Gleitkommawerte umzuwandeln. |
|
BigQuery bietet auch die folgenden Aggregat-, Aggregatanalyse- und ungefähren Aggregatfunktionen, die kein direktes Äquivalent in Snowflake haben:
Bitweise Ausdrucksfunktionen
Die folgende Tabelle zeigt Zuordnungen zwischen gängigen bitweisen Snowflake-Ausdrucksfunktionen mit ihren BigQuery-Entsprechungen.
Wenn der Datentyp eines Ausdrucks nicht INTEGER
ist, versucht Snowflake, in INTEGER
umzuwandeln. BigQuery versucht jedoch nicht, in INTEGER
umzuwandeln.
Snowflake | BigQuery |
---|---|
|
|
|
|
|
|
|
|
BITSHIFTRIGHT
|
|
Hinweis: Snowflake unterstützt DISTINCT. nicht. |
|
Funktionen für bedingte Ausdrücke
Die folgende Tabelle zeigt Zuordnungen zwischen gängigen bedingten Snowflake-Ausdrücken und ihren BigQuery-Entsprechungen.
Snowflake | BigQuery |
---|---|
|
|
Hinweis: Snowflake ermöglicht die Behandlung numerischer, Dezimal- und Gleitkommawerte als TRUE , wenn nicht null. |
|
Hinweis: Snowflake ermöglicht die Behandlung numerischer, Dezimal- und Gleitkommawerte als TRUE , wenn nicht null. |
|
BOOLOR Hinweis: Snowflake ermöglicht die Behandlung numerischer, Dezimal- und Gleitkommawerte als TRUE , wenn nicht null. |
|
BOOLXOR Hinweis: Snowflake ermöglicht die Behandlung numerischer, Dezimal- und Gleitkommawerte als TRUE , wenn nicht null. |
BigQuery unterstützt keine direkte Alternative zum BOOLXOR. von Snowflake. |
|
|
Hinweis: Snowflake benötigt mindestens zwei Ausdrücke. BigQuery benötigt nur einen. |
|
|
DECODE von Snowflake reproduziert werden. Der Nutzer muss IS NULL anstelle von = NULL verwenden, um NULL -Auswahlausdrücke mit NULL -Suchausdrücken abzugleichen. |
|
BigQuery unterstützt keine direkte Alternative zum EQUAL_NULL. von Snowflake. |
|
|
|
|
|
|
|
|
|
BigQuery unterstützt keine direkte Alternative zum IS [ NOT ] DISTINCT FROM. von Snowflake. |
|
|
|
BigQuery unterstützt keine VARIANT -Datentypen. |
|
|
|
|
|
|
|
|
|
REGR... -Funktionen von Snowflake. |
|
Hinweis: BigQuery unterstützt keine direkte Alternative zu den REGR... -Funktionen von Snowflake. |
|
|
Kontextfunktionen
Die folgende Tabelle zeigt Zuordnungen zwischen gängigen Snowflake-Kontextfunktionen und ihren BigQuery-Entsprechungen.
Snowflake | BigQuery |
---|---|
Hinweis: Kein direkter Vergleich. Snowflake gibt die Konto-ID zurück, BigQuery gibt die E-Mail-Adresse des Nutzers zurück. |
|
In BigQuery nicht verwendetes Konzept |
|
Dies gibt eine Tabelle mit Projektnamen zurück. Kein direkter Vergleich. |
|
Hinweis: Snowflake erzwingt „()“ nach dem Befehl CURRENT_DATE nicht, um ANSI-Standards zu erfüllen. |
Hinweis: CURRENT_DATE von BigQuery unterstützt die optionale Zeitzonenspezifikation. |
Hinweis: INFORMATION_SCHEMA.SCHEMATA von BigQuery gibt allgemeinere Standortreferenzen zurück als CURRENT_REGION() von Snowflake. Kein direkter Vergleich. |
|
In BigQuery nicht verwendetes Konzept |
|
Dadurch wird eine Tabelle aller Datasets (auch Schemas genannt) zurückgegeben, die im Projekt oder in der Region verfügbar sind. Kein direkter Vergleich. |
|
In BigQuery nicht verwendetes Konzept |
|
In BigQuery nicht verwendetes Konzept |
|
Hinweis: INFORMATION_SCHEMA.JOBS_BY_* in BigQuery ermöglicht die Suche nach Abfragen nach Jobtyp, Start-/Endtyp usw. |
|
Hinweis: Snowflake ermöglicht eine optionale Genauigkeit mit Bruchteilen einer Sekunde. Gültige Werte reichen von 0 bis 9 Nanosekunden. Der Standardwert ist 9. Zur Einhaltung von ANSI kann dies ohne „()“ aufgerufen werden. |
|
Hinweis: Snowflake ermöglicht eine optionale Genauigkeit mit Bruchteilen einer Sekunde. Gültige Werte reichen von 0 bis 9 Nanosekunden. Der Standardwert ist 9. Zur Einhaltung von ANSI kann dies ohne „()“ aufgerufen werden. Legen Sie TIMEZONE als Sitzungsparameter fest. |
Hinweis:
CURRENT_DATETIME gibt den Datentyp DATETIME zurück (in Snowflake nicht unterstützt). CURRENT_TIMESTAMP gibt den Datentyp TIMESTAMP zurück. |
INFORMATION_SCHEMA.JOBS_BY_* von BigQuery können Sie Job-IDs nach Jobtyp, Start-/Endtyp usw. suchen. |
|
Hinweis: Snowflake erzwingt „()“ nach dem Befehl CURRENT_USER nicht, um ANSI-Standards zu erfüllen. |
|
In BigQuery nicht verwendetes Konzept |
|
|
|
|
Hinweis: INFORMATION_SCHEMA.JOBS_BY_* von BigQuery ermöglicht die Suche nach Job-IDs nach Jobtyp, Start-/Endtyp usw. |
Hinweis: INFORMATION_SCHEMA.JOBS_BY_* von BigQuery ermöglicht die Suche nach Job-IDs nach Jobtyp, Start-/Endtyp usw. |
|
Hinweis: Snowflake erzwingt „()“ nach dem Befehl LOCALTIME nicht, um ANSI-Standards zu erfüllen. |
|
Hinweis:
CURRENT_DATETIME gibt den Datentyp DATETIME zurück (in Snowflake nicht unterstützt). CURRENT_TIMESTAMP gibt den Datentyp TIMESTAMP zurück. |
Umrechnungsfunktionen
Die folgende Tabelle zeigt Zuordnungen zwischen gängigen Snowflake-Konvertierungsfunktionen und ihren BigQuery-Entsprechungen.
Beachten Sie, dass Funktionen, die in Snowflake und BigQuery identisch erscheinen, unterschiedliche Datentypen zurückgeben können.
Snowflake | BigQuery |
---|---|
|
|
|
|
Hinweis: Snowflake unterstützt die Konvertierung HEX , BASE64 und UTF-8 . Snowflake unterstützt auch TO_BINARY mit dem Datentyp VARIANT . BigQuery hat keine Alternative zum Datentyp VARIANT . |
Hinweis: Die standardmäßige STRING -Umwandlung von BigQuery verwendet die UTF-8 -Codierung. Snowflake bietet keine Option zur Unterstützung der BASE32 -Codierung. |
Hinweis:
|
Hinweis:
|
Hinweis: Die Formatmodelle von Snowflake finden Sie hier. BigQuery hat keine Alternative zum Datentyp VARIANT . |
Hinweis: Der Eingabeausdruck von BigQuery kann mit FORMAT_DATE , FORMAT_DATETIME , FORMAT_TIME oder FORMAT_TIMESTAMP formatiert werden. |
Hinweis: Snowflake unterstützt die Möglichkeit, INTEGER -Typen direkt in DATE -Typen zu konvertieren. Die Formatmodelle von Snowflake finden Sie hier. BigQuery hat keine Alternative zum Datentyp VARIANT . |
Hinweis: Der Eingabeausdruck von BigQuery kann mit FORMAT , FORMAT_DATETIME oder FORMAT_TIMESTAMP formatiert werden. |
Hinweis: Die Formatmodelle von Snowflake für die Datentypen DECIMAL , NUMBER und NUMERIC finden Sie hier. BigQuery hat keine Alternative zum Datentyp VARIANT . |
Hinweis: Der Eingabeausdruck von BigQuery kann mit FORMAT. formatiert werden. |
Hinweis: Die Formatmodelle von Snowflake für die DOUBLE -Datentypen finden Sie hier. BigQuery hat keine Alternative zum Datentyp VARIANT . |
Hinweis: Der Eingabeausdruck von BigQuery kann mit FORMAT. formatiert werden. |
|
BigQuery hat keine Alternative zum Datentyp VARIANT von Snowflake. |
|
BigQuery hat keine Alternative zum Datentyp VARIANT von Snowflake. |
Hinweis: Die Formatmodelle von Snowflake für die STRING -Datentypen finden Sie hier. BigQuery hat keine Alternative zum Datentyp VARIANT . |
Hinweis: BigQuery hat keine Alternative zum Datentyp VARIANT von Snowflake. Der Eingabeausdruck von BigQuery kann mit FORMAT , FORMAT_DATETIME , FORMAT_TIMESTAMP oder FORMAT_TIME formatiert werden. |
Hinweis: BigQuery hat keine Alternative zum Datentyp VARIANT . |
Hinweis: Der Eingabeausdruck von BigQuery kann mit FORMAT , FORMAT_DATE , FORMAT_DATETIME , FORMAT_TIME formatiert werden. Die Zeitzone kann über FORMAT_TIMESTAMP -Parameter einbezogen oder nicht einbezogen werden. |
|
BigQuery hat keine Alternative zum Datentyp VARIANT von Snowflake. |
|
BigQuery hat keine Alternative zum Datentyp VARIANT von Snowflake. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
BigQuery bietet auch die folgenden Konvertierungsfunktionen, die in Snowflake keine direkte Entsprechung haben:
CODE_POINTS_TO_BYTES
CODE_POINTS_TO_STRING
FORMAT
FROM_BASE32
FROM_BASE64
FROM_HEX
SAFE_CONVERT_BYTES_TO_STRING
TO_BASE32
TO_CODE_POINTS
Datengenerierungsfunktionen
Die folgende Tabelle zeigt Zuordnungen zwischen gängigen Snowflake-Datengenerierungsfunktionen und ihren BigQuery-Entsprechungen.
Snowflake | BigQuery |
---|---|
|
BigQuery unterstützt keinen direkten Vergleich mit NORMAL. von Snowflake. |
|
Hinweis: BigQuery unterstützt kein Seeding. |
|
BigQuery unterstützt keinen direkten Vergleich mit RANDSTR. von Snowflake. |
SEQ1 / SEQ2 / SEQ4 / SEQ8 |
BigQuery unterstützt keinen direkten Vergleich mit SEQ_. von Snowflake. |
|
Hinweis:Verwenden Sie persistente UDFs, um ein Äquivalent zum UNIFORM von Snowflake zu erstellen. Beispiel hier. |
UUID_STRING([uuid, name]) Hinweis: Snowflake gibt 128 zufällige Bits zurück. Snowflake unterstützt UUIDs Version 4 (zufällig) und Version 5 (benannt) |
Hinweis: BigQuery gibt 122 zufällige Bits zurück. BigQuery unterstützt nur UUIDs der Version 4. |
|
BigQuery unterstützt keinen direkten Vergleich mit ZIPF. von Snowflake. |
Funktionen für Datum und Uhrzeit
Die folgende Tabelle zeigt Zuordnungen zwischen gängigen Datums- und Uhrzeitfunktionen von Snowflake mit ihren BigQuery-Entsprechungen. BigQuery-Datums- und -Uhrzeitfunktionen umfassen Datumsfunktionen, Datums-/Uhrzeitfunktionen, Uhrzeitfunktionen und Zeitstempelfunktionen.
Snowflake | BigQuery |
---|---|
|
|
|
Hinweis: source_timezone ist in BigQuery immer UTC. |
Hinweis: Snowflake unterstützt den Überlauf und negative Datumsangaben. Zum Beispiel gibt DATE_FROM_PARTS(2000, 1 + 24, 1) den 1. Januar 2002 zurück. Dies wird in BigQuery nicht unterstützt. |
|
Hinweis: Snowflake unterstützt die Teiletypen ISO-Wochentag, Nanosekunde und Epochensekunde/Millisekunde/Mikrosekunde/Nanosekunde. BigQuery tut dies nicht. Die vollständige Liste der Snowflake-Teiletypen finden Sie hier
. |
Hinweis: BigQuery unterstützt die Teiletypen "Woche(<Wochentag>)", "Mikrosekunde" und "Millisekunden". Snowflake tut dies nicht. Die vollständige Liste der BigQuery-Teiletypen finden Sie hier und hier. |
Hinweis: Snowflake unterstützt den Typ „Nanosekunden“. BigQuery tut dies nicht. Die vollständige Liste der Snowflake-Teiletypen finden Sie hier
. |
Hinweis: BigQuery unterstützt die Teiletypen "Woche(<Wochentag>)", ISO-Woche und ISO-Jahre. Snowflake tut dies nicht. |
|
|
Hinweis: Snowflake unterstützt in dieser Funktion die Berechnung der Differenz zwischen zwei Datums-, Uhrzeit- und Zeitstempeltypen. |
Hinweis: BigQuery unterstützt die Teiletypen "week(<weekday>)" und "ISO-Jahre". |
|
|
Hinweis: Snowflake unterstützt die Teiletypen ISO-Wochentag, Nanosekunde und Epochensekunde/Millisekunde/Mikrosekunde/Nanosekunde. BigQuery tut dies nicht. Die vollständige Liste der Snowflake-Teiletypen finden Sie hier
. |
Hinweis: BigQuery unterstützt die Teiletypen "Woche(<Wochentag>)", "Mikrosekunde" und "Millisekunden". Snowflake tut dies nicht. Die vollständige Liste der BigQuery-Teiletypen finden Sie hier und hier. |
|
|
|
|
|
|
|
Hinweis: dowString muss möglicherweise neu formatiert werden. Zum Beispiel ist „su“ von Snowflake der „SUNDAY“ von BigQuery. |
|
Hinweis: dowString muss möglicherweise neu formatiert werden. Zum Beispiel ist „su“ von Snowflake der „SUNDAY“ von BigQuery. |
Hinweis: Snowflake unterstützt Überlaufzeiten. Beispiel: TIME_FROM_PARTS(0, 100, 0) gibt 01:40:00 zurück...
Dies wird in BigQuery nicht unterstützt. BigQuery unterstützt keine Nanosekunden. |
|
|
Hinweis: BigQuery unterstützt keinen direkten, genauen Vergleich mit TIME_SLICE von Snowflake. Verwenden Sie DATETINE_TRUNC , TIME_TRUNC , TIMESTAMP_TRUNC für den entsprechenden Datentyp. |
|
|
Hinweis: Snowflake unterstützt in dieser Funktion die Berechnung der Differenz zwischen zwei Datums-, Uhrzeit- und Zeitstempeltypen. |
Hinweis: BigQuery unterstützt die Teiletypen "week(<weekday>)" und "ISO-Jahre". |
|
Hinweis: Für BigQuery müssen Zeitstempel als STRING -Typen eingegeben werden. Beispiel: "2008-12-25 15:30:00" |
|
|
Hinweis: Snowflake unterstützt in dieser Funktion die Berechnung der Differenz zwischen zwei Datums-, Uhrzeit- und Zeitstempeltypen. |
Hinweis: BigQuery unterstützt die Teiletypen "week(<weekday>)" und "ISO-Jahre". |
Hinweis: Snowflake unterstützt den Typ „Nanosekunden“. BigQuery tut dies nicht. Die vollständige Liste der Snowflake-Teiletypen finden Sie hier
. |
Hinweis: BigQuery unterstützt die Teiletypen "Woche(<Wochentag>)", ISO-Woche und ISO-Jahre. Snowflake tut dies nicht. |
|
|
BigQuery bietet außerdem die folgenden Datums- und Uhrzeitfunktionen, die in Snowflake keine direkte Entsprechung haben:
Informationsschema- und Tabellenfunktionen
BigQuery unterstützt konzeptionell nicht viele der Informationsschema- und Tabellenfunktionen von Snowflake. Snowflake bietet die folgenden Informationsschema- und Tabellenfunktionen, die in BigQuery keine direkte Entsprechung haben:
AUTOMATIC_CLUSTERING_HISTORY
COPY_HISTORY
DATA_TRANSFER_HISTORY
DATABASE_REFRESH_HISTORY
DATABASE_REFRESH_PROGRESS, DATABASE_REFRESH_PROGRESS_BY_JOB
DATABASE_STORAGE_USAGE_HISTORY
EXTERNAL_TABLE_FILES
EXTERNAL_TABLE_FILE_REGISTRATION_HISTORY
LOGIN_HISTORY
,LOGIN_HISTORY_BY_USER
MATERIALIZED_VIEW_REFRESH_HISTORY
PIPE_USAGE_HISTORY
REPLICATION_USAGE_HISTORY
STAGE_STORAGE_USAGE_HISTORY
TASK_DEPENDENTS
VALIDATE_PIPE_LOAD
WAREHOUSE_LOAD_HISTORY
WAREHOUSE_METERING_HISTORY
Nachfolgend finden Sie eine Liste der zugehörigen BigQuery- und Snowflake-Informationsschema- und -Tabellenfunktionen.
Snowflake | BigQuery |
---|---|
QUERY_HISTORY QUERY_HISTORY_BY_* |
INFORMATION_SCHEMA.JOBS_BY_* Hinweis: Keine direkte Alternative. |
TASK_HISTORY |
INFORMATION_SCHEMA.JOBS_BY_* Hinweis: Keine direkte Alternative. |
BigQuery bietet die folgenden Informationsschema- und Tabellenfunktionen, die in Snowflake keine direkte Entsprechung haben:
INFORMATION_SCHEMA.SCHEMATA
INFORMATION_SCHEMA.ROUTINES
INFORMATION_SCHEMA.TABLES
INFORMATION_SCHEMA.VIEWS
Numerische Funktionen
Die folgende Tabelle zeigt Zuordnungen zwischen gängigen numerischen Funktionen von Snowflake und ihren BigQuery-Entsprechungen.
Snowflake | BigQuery |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hinweis: CEIL von BigQuery unterstützt keine Möglichkeit, die Genauigkeit oder Skalierung anzugeben. In ROUND können Sie keine Rundung festlegen. |
|
|
|
|
|
|
|
|
|
|
|
BigQuery hat keine direkte Alternative zum FACTORIAL von Snowflake. Verwenden Sie eine benutzerdefinierte Funktion. |
|
Hinweis: FLOOR von BigQuery unterstützt keine Möglichkeit, die Genauigkeit oder Skalierung anzugeben. In ROUND können Sie keine Rundung festlegen. TRUNC funktioniert synonym für positive Zahlen, aber nicht für negative Zahlen, da der absolute Wert ausgewertet wird. |
|
Hinweis: Keine genaue Übereinstimmung, aber nah genug. |
|
|
|
Hinweis: Die Standardbasis für LOG ist 10. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Hinweis: Der zurückgegebene Wert von BigQuery muss kleiner sein als der Ausdruck. Er unterstützt nicht „ist gleich mit“. |
BigQuery bietet auch die folgenden mathematischen Funktionen, die in Snowflake keine direkte Entsprechung haben:
IS_INF
IS_NAN
IEEE_DIVIDE
DIV
SAFE_DIVIDE
SAFE_MULTIPLY
SAFE_NEGATE
SAFE_ADD
SAFE_SUBTRACT
RANGE_BUCKET
semistrukturierte Datenfunktionen
Snowflake | BigQuery |
---|---|
ARRAY_APPEND |
Benutzerdefinierte Funktion |
ARRAY_CAT |
ARRAY_CONCAT |
ARRAY_COMPACT |
Benutzerdefinierte Funktion |
ARRAY_CONSTRUCT |
[ ] |
ARRAY_CONSTRUCT_COMPACT |
Benutzerdefinierte Funktion |
ARRAY_CONTAINS |
Benutzerdefinierte Funktion |
ARRAY_INSERT |
Benutzerdefinierte Funktion |
ARRAY_INTERSECTION |
Benutzerdefinierte Funktion |
ARRAY_POSITION |
Benutzerdefinierte Funktion |
ARRAY_PREPEND |
Benutzerdefinierte Funktion |
ARRAY_SIZE |
ARRAY_LENGTH |
ARRAY_SLICE |
Benutzerdefinierte Funktion |
ARRAY_TO_STRING |
ARRAY_TO_STRING |
ARRAYS_OVERLAP |
Benutzerdefinierte Funktion |
AS_<object_type> |
CAST |
AS_ARRAY |
CAST |
AS_BINARY |
CAST |
AS_BOOLEAN |
CAST |
AS_CHAR , AS_VARCHAR |
CAST |
AS_DATE |
CAST |
AS_DECIMAL , AS_NUMBER |
CAST |
AS_DOUBLE , AS_REAL |
CAST |
AS_INTEGER |
CAST |
AS_OBJECT |
CAST |
AS_TIME |
CAST |
AS_TIMESTAMP_* |
CAST |
CHECK_JSON |
Benutzerdefinierte Funktion |
CHECK_XML |
Benutzerdefinierte Funktion |
FLATTEN |
UNNEST |
GET |
Benutzerdefinierte Funktion |
GET_IGNORE_CASE |
Benutzerdefinierte Funktion |
|
Benutzerdefinierte Funktion |
IS_<object_type> |
Benutzerdefinierte Funktion |
IS_ARRAY |
Benutzerdefinierte Funktion |
IS_BINARY |
Benutzerdefinierte Funktion |
IS_BOOLEAN |
Benutzerdefinierte Funktion |
IS_CHAR , IS_VARCHAR |
Benutzerdefinierte Funktion |
IS_DATE , IS_DATE_VALUE |
Benutzerdefinierte Funktion |
IS_DECIMAL |
Benutzerdefinierte Funktion |
IS_DOUBLE , IS_REAL |
Benutzerdefinierte Funktion |
IS_INTEGER |
Benutzerdefinierte Funktion |
IS_OBJECT |
Benutzerdefinierte Funktion |
IS_TIME |
Benutzerdefinierte Funktion |
IS_TIMESTAMP_* |
Benutzerdefinierte Funktion |
OBJECT_CONSTRUCT |
Benutzerdefinierte Funktion |
OBJECT_DELETE |
Benutzerdefinierte Funktion |
OBJECT_INSERT |
Benutzerdefinierte Funktion |
PARSE_JSON |
JSON_EXTRACT |
PARSE_XML |
Benutzerdefinierte Funktion |
STRIP_NULL_VALUE |
Benutzerdefinierte Funktion |
STRTOK_TO_ARRAY |
SPLIT |
TRY_PARSE_JSON |
Benutzerdefinierte Funktion |
TYPEOF |
Benutzerdefinierte Funktion |
XMLGET |
Benutzerdefinierte Funktion |
String- und Binärfunktionen
Snowflake | BigQuery |
---|---|
|
|
ASCII |
|
BASE64_DECODE_BINARY |
|
BASE64_DECODE_STRING |
|
BASE64_ENCODE |
|
BIT_LENGTH |
CHARACTER_LENGTH |
|
|
CHR,CHAR |
|
COLLATE |
Benutzerdefinierte Funktion |
COLLATION |
Benutzerdefinierte Funktion |
COMPRESS |
Benutzerdefinierte Funktion |
|
CONCAT (...) in BigQuery unterstützt die Verkettung einer beliebigen Anzahl von Strings. |
CONTAINS |
Benutzerdefinierte Funktion |
DECOMPRESS_BINARY |
Benutzerdefinierte Funktion |
DECOMPRESS_STRING |
Benutzerdefinierte Funktion |
EDITDISTANCE |
Benutzerdefinierte Funktion |
ENDSWITH |
Benutzerdefinierte Funktion |
HEX_DECODE_BINARY |
|
HEX_DECODE_STRING |
|
HEX_ENCODE |
|
ILIKE |
Benutzerdefinierte Funktion |
ILIKE ANY |
Benutzerdefinierte Funktion |
INITCAP |
INITCAP |
INSERT |
Benutzerdefinierte Funktion |
LEFT |
Benutzerdefinierte Funktion |
LENGTH |
|
LIKE |
LIKE |
LIKE ALL |
Benutzerdefinierte Funktion |
LIKE ANY |
Benutzerdefinierte Funktion |
LOWER |
|
LPAD |
|
LTRIM |
|
|
|
MD5_BINARY |
Benutzerdefinierte Funktion |
OCTET_LENGTH |
Benutzerdefinierte Funktion |
PARSE_IP |
Benutzerdefinierte Funktion |
PARSE_URL |
Benutzerdefinierte Funktion |
POSITION |
|
REPEAT |
|
REPLACE |
|
REVERSE
|
|
RIGHT |
Benutzerdefinierte Funktion |
RPAD |
RPAD |
RTRIM |
|
RTRIMMED_LENGTH |
Benutzerdefinierte Funktion |
SHA1,SHA1_HEX |
|
SHA1_BINARY |
Benutzerdefinierte Funktion |
SHA2,SHA2_HEX |
Benutzerdefinierte Funktion |
SHA2_BINARY |
Benutzerdefinierte Funktion |
SOUNDEX |
Benutzerdefinierte Funktion |
SPACE |
Benutzerdefinierte Funktion |
SPLIT |
SPLIT |
SPLIT_PART |
Benutzerdefinierte Funktion |
SPLIT_TO_TABLE |
Benutzerdefinierte Funktion |
STARTSWITH |
Benutzerdefinierte Funktion |
STRTOK |
Hinweis: Das gesamte delimiter-Stringargument wird als einzelnes Trennzeichen verwendet. Das Standardtrennzeichen ist ein Komma. |
STRTOK_SPLIT_TO_TABLE |
Benutzerdefinierte Funktion |
SUBSTR,SUBSTRING |
SUBSTR |
TRANSLATE |
Benutzerdefinierte Funktion |
TRIM |
TRIM |
TRY_BASE64_DECODE_BINARY |
Benutzerdefinierte Funktion |
TRY_BASE64_DECODE_STRING |
|
TRY_HEX_DECODE_BINARY |
|
TRY_HEX_DECODE_STRING |
|
UNICODE |
Benutzerdefinierte Funktion |
|
UPPER |
Stringfunktionen (reguläre Ausdrücke)
Snowflake | BigQuery |
---|---|
REGEXP |
|
REGEXP_COUNT |
Wenn position angegeben ist:
Hinweis: BigQuery unterstützt reguläre Ausdrücke mithilfe der re2-Bibliothek; in der jeweiligen Dokumentation finden Sie weitere Informationen zur Syntax der regulären Ausdrücke. |
REGEXP_INSTR |
Wenn position angegeben ist:
Wenn occurrence angegeben ist:
Hinweis: BigQuery unterstützt reguläre Ausdrücke mithilfe der re2-Bibliothek; in der jeweiligen Dokumentation finden Sie weitere Informationen zur Syntax der regulären Ausdrücke. |
|
|
REGEXP_REPLACE |
Wenn replace_string angegeben ist:
Wenn position angegeben ist:
Hinweis: BigQuery unterstützt reguläre Ausdrücke mithilfe der re2-Bibliothek; in der jeweiligen Dokumentation finden Sie weitere Informationen zur Syntax der regulären Ausdrücke. |
REGEXP_SUBSTR |
Wenn position angegeben ist:
Wenn occurrence angegeben ist:
Hinweis: BigQuery unterstützt reguläre Ausdrücke mithilfe der re2-Bibliothek; in der jeweiligen Dokumentation finden Sie weitere Informationen zur Syntax der regulären Ausdrücke. |
RLIKE |
|
Systemfunktionen
Snowflake | BigQuery |
---|---|
SYSTEM$ABORT_SESSION |
Benutzerdefinierte Funktion |
SYSTEM$ABORT_TRANSACTION |
Benutzerdefinierte Funktion |
SYSTEM$CANCEL_ALL_QUERIES |
Benutzerdefinierte Funktion |
SYSTEM$CANCEL_QUERY |
Benutzerdefinierte Funktion |
SYSTEM$CLUSTERING_DEPTH |
Benutzerdefinierte Funktion |
SYSTEM$CLUSTERING_INFORMATION |
Benutzerdefinierte Funktion |
SYSTEM$CLUSTERING_RATIO — Deprecated |
Benutzerdefinierte Funktion |
SYSTEM$CURRENT_USER_TASK_NAME |
Benutzerdefinierte Funktion |
SYSTEM$DATABASE_REFRESH_HISTORY |
Benutzerdefinierte Funktion |
SYSTEM$DATABASE_REFRESH_PROGRESS , SYSTEM$DATABASE_REFRESH_PROGRESS_BY_JOB |
Benutzerdefinierte Funktion |
SYSTEM$GET_AWS_SNS_IAM_POLICY |
Benutzerdefinierte Funktion |
SYSTEM$GET_PREDECESSOR_RETURN_VALUE |
Benutzerdefinierte Funktion |
SYSTEM$LAST_CHANGE_COMMIT_TIME |
Benutzerdefinierte Funktion |
SYSTEM$PIPE_FORCE_RESUME |
Benutzerdefinierte Funktion |
SYSTEM$PIPE_STATUS |
Benutzerdefinierte Funktion |
SYSTEM$SET_RETURN_VALUE |
Benutzerdefinierte Funktion |
SYSTEM$SHOW_OAUTH_CLIENT_SECRETS |
Benutzerdefinierte Funktion |
SYSTEM$STREAM_GET_TABLE_TIMESTAMP |
Benutzerdefinierte Funktion |
SYSTEM$STREAM_HAS_DATA |
Benutzerdefinierte Funktion |
SYSTEM$TASK_DEPENDENTS_ENABLE |
Benutzerdefinierte Funktion |
SYSTEM$TYPEOF |
Benutzerdefinierte Funktion |
SYSTEM$USER_TASK_CANCEL_ONGOING_EXECUTIONS |
Benutzerdefinierte Funktion |
SYSTEM$WAIT |
Benutzerdefinierte Funktion |
SYSTEM$WHITELIST |
Benutzerdefinierte Funktion |
SYSTEM$WHITELIST_PRIVATELINK |
Benutzerdefinierte Funktion |
Tabellenfunktionen
Snowflake | BigQuery | |
---|---|---|
GENERATOR |
Benutzerdefinierte Funktion | |
GET_OBJECT_REFERENCES |
Benutzerdefinierte Funktion | |
RESULT_SCAN |
Benutzerdefinierte Funktion | |
VALIDATE |
Benutzerdefinierte Funktion |
Hilfs- und Hash-Funktionen
Snowflake | BigQuery | |
---|---|---|
GET_DDL |
Funktionsanfrage | |
HASH |
HASH ist eine proprietäre Funktion von Snowflake. Kann nur übersetzt werden, wenn die zugrunde liegende Logik von Snowflake bekannt ist. |
Fensterfunktionen
Snowflake | BigQuery | |
---|---|---|
CONDITIONAL_CHANGE_EVENT |
Benutzerdefinierte Funktion | |
CONDITIONAL_TRUE_EVENT |
Benutzerdefinierte Funktion | |
CUME_DIST |
CUME_DIST |
|
DENSE_RANK |
DENSE_RANK |
|
FIRST_VALUE |
FIRST_VALUE |
|
LAG |
LAG |
|
LAST_VALUE |
LAST_VALUE |
|
LEAD |
LEAD |
|
NTH_VALUE |
NTH_VALUE |
|
NTILE |
NTILE |
|
PERCENT_RANK |
PERCENT_RANK |
|
RANK |
RANK |
|
RATIO_TO_REPORT |
Benutzerdefinierte Funktion | |
ROW_NUMBER |
ROW_NUMBER |
|
WIDTH_BUCKET |
Benutzerdefinierte Funktion |
BigQuery unterstützt auch SAFE_CAST
(Ausdruck AS Typname). Dieser gibt NULL zurück, wenn BigQuery keine Umwandlung durchführen kann (z. B. SAFE_CAST
(„apple“ AS INT64) gibt NULL zurück).
Operatoren
In den folgenden Abschnitten werden die Snowflake-Operatoren und ihre BigQuery-Entsprechungen aufgeführt.
Arithmetischer Operator
Die folgende Tabelle zeigt Zuordnungen zwischen den arithmetischen Operatoren von Snowflake und ihren BigQuery-Entsprechungen.
Snowflake | BigQuery |
---|---|
|
|
|
|
|
Hinweis: BigQuery unterstützt das standardmäßige unäres Minus, konvertiert aber keine Ganzzahlen im Stringformat in den Typ INT64 , NUMERIC oder FLOAT64 . |
|
|
|
|
|
|
|
|
|
|
Informationen zur Anzeige der Skalierungs- und Genauigkeitsdetails von Snowflake bei der Durchführung arithmetischer Operationen finden Sie in der Dokumentation zu Snowflake.
Vergleichsoperator
Vergleichsoperatoren von Snowflake und Vergleichsoperatoren für BigQuery sind identisch.
Logische/boolesche Operatoren
Logische/boolesche Operatoren von Snowflake und logische/boolesche Operatoren von BigQuery sind identisch.
Set-Operatoren
Die folgende Tabelle zeigt Zuordnungen zwischen den Set-Operatoren von Snowflake und ihren BigQuery-Entsprechungen.
Snowflake | BigQuery |
---|---|
|
INTERSECT DISTINCT
|
Hinweis: MINUS und EXCEPT sind Synonyme. |
|
|
|
Unterabfrageoperatoren
Die folgende Tabelle zeigt Zuordnungen zwischen den Unterabfrageoperatoren von Snowflake und ihren BigQuery-Entsprechungen.
Snowflake | BigQuery |
---|---|
|
BigQuery unterstützt keine direkte Alternative zu den ALL/ANY von Snowflake. |
|
|
|
|
|
Hinweis: BigQuery benötigt Klammern, um verschiedene Set-Vorgänge zu trennen. Wenn derselbe Set-Operator wiederholt wird, sind keine Klammern erforderlich. |
DML-Syntax
In diesem Abschnitt werden Unterschiede in der Syntax der Datenverwaltungssprache zwischen Snowflake und BigQuery behandelt.
INSERT
-Anweisung
Snowflake bietet ein konfigurierbares DEFAULT
-Schlüsselwort für Spalten. In BigQuery lautet der DEFAULT
-Wert für Spalten mit zulässigen Nullwerten NULL und DEFAULT
wird für die erforderlichen Spalten nicht unterstützt. Die meisten Snowflake-INSERT
-Anweisungen sind mit BigQuery kompatibel. Die folgende Tabelle enthält Ausnahmen.
Snowflake | BigQuery |
---|---|
Hinweis: BigQuery unterstützt nicht das Einfügen von JSON -Objekten mit einer INSERT -Anweisung. |
VALUES (DEFAULT [, ...]) Hinweis: BigQuery unterstützt keine direkte Alternative zum OVERWRITE von Snowflake. Verwenden Sie stattdessen DELETE . |
|
|
... Hinweis:
<intoClause> steht für den oben aufgeführten Standard-INSERT statement . |
BigQuery unterstützt kein bedingtes und bedingungsfreies INSERTs mit mehreren Tabellen. |
BigQuery unterstützt auch das Einfügen von Werten mithilfe einer Unterabfrage (wobei einer der Werte mithilfe einer Unterabfrage berechnet wird), was in Snowflake nicht unterstützt wird. Beispiel:
INSERT INTO table (column1, column2)
VALUES ('value_1', (
SELECT column2
FROM table2
))
COPY
-Anweisung
Snowflake unterstützt das Kopieren von Daten aus Staging-Dateien in eine vorhandene Tabelle und aus einer Tabelle in eine benannte interne Phase, eine benannte externe Phase und einen externen Speicherort (Amazon S3, Google Cloud Storage oder Microsoft Azure).
BigQuery verwendet nicht den Befehl COPY
, um Daten zu laden. Sie können jedoch eines bzw. eine der verschiedenen Nicht-SQL-Tools und -Optionen verwenden, um Daten in BigQuery-Tabellen zu laden. Sie können auch Datenpipeline-Senken verwenden, die in Apache Spark oder Apache Beam bereitgestellt werden, um Daten in BigQuery zu schreiben.
UPDATE
-Anweisung
Die meisten Snowflake-UPDATE
-Anweisungen sind mit BigQuery kompatibel. Die folgende Tabelle enthält Ausnahmen.
Snowflake | BigQuery | |
---|---|---|
|
Hinweis: Alle UPDATE -Anweisungen in BigQuery erfordern das Schlüsselwort WHERE , gefolgt von einer Bedingung. |
DELETE
- und TRUNCATE TABLE
-Anweisungen
Die Anweisungen DELETE
und TRUNCATE TABLE
sind beide Möglichkeiten zum Entfernen von Zeilen aus einer Tabelle, ohne dass sich dies auf das Tabellenschema oder die Indexe auswirkt.
In Snowflake verwalten sowohl DELETE
als auch TRUNCATE TABLE
gelöschte Daten mithilfe der Zeitreise von Snowflake zur Wiederherstellung für die Aufbewahrungsdauer.
DELETE löscht jedoch nicht den externen Dateiladeverlauf und die Lademetadaten.
In BigQuery muss die DELETE
-Anweisung eine WHERE
-Klausel enthalten. Weitere Informationen zu DELETE
in BigQuery finden Sie in den BigQuery-DELETE
-Beispielen in der DML-Dokumentation.
Snowflake | BigQuery |
---|---|
|
Hinweis: BigQuery- DELETE -Anweisungen erfordern eine WHERE -Klausel. |
MERGE
-Anweisung
Die MERGE
-Anweisung kann die Vorgänge INSERT
, UPDATE
und DELETE
in einer einzigen „upsert“ -Anweisung kombinieren und die Vorgänge automatisch ausführen. Der MERGE
-Vorgang muss mit maximal einer Quellzeile für jede Zielzeile übereinstimmen.
BigQuery-Tabellen sind auf 1.000 DML-Anweisungen pro Tag beschränkt. Daher sollten Sie INSERT-, UPDATE- und DELETE-Anweisungen optimal in einer einzigen MERGE-Anweisung zusammenfassen, wie in der folgenden Tabelle dargestellt:
Snowflake | BigQuery |
---|---|
Hinweis: Snowflake unterstützt den Sitzungsparameter ERROR_ON_NONDETERMINISTIC_MERGE, um nicht deterministische Ergebnisse zu verarbeiten. |
Hinweis: Alle Spalten müssen aufgelistet werden, wenn alle Spalten aktualisiert werden. |
GET
- und LIST
-Anweisungen
Mit der Anweisung GET
werden Datendateien aus einer der folgenden Snowflake-Phasen in ein lokales Verzeichnis bzw. einen lokalen Ordner auf einem Clientrechner heruntergeladen:
- Benannte interne Phase
- Interne Phase für eine angegebene Tabelle
- Interne Phase für den aktuellen Nutzer
Die LIST
-(LS-)Anweisung gibt eine Liste von Dateien zurück, die in einer der folgenden Snowflake-Phasen bereitgestellt wurden (d. h. von einem lokalen Dateisystem hochgeladen oder aus einer Tabelle entladen):
- Benannte interne Phase
- Benannte externe Phase
- Staging für eine bestimmte Tabelle
- Phase für den aktuellen Nutzer
BigQuery unterstützt das Konzept des Staging nicht und hat keine Entsprechungen für GET
und LIST
.
PUT
- und REMOVE
-Anweisungen
Mit der PUT
-Anweisung werden Datendateien (d. h. Phasen) aus einem lokalen Verzeichnis bzw. Ordner auf einem Clientcomputer in eine der folgenden Snowflake-Phasen hochgeladen:
- Benannte interne Phase
- Interne Phase für eine angegebene Tabelle
- Interne Phase für den aktuellen Nutzer
Mit der REMOVE
-(RM)
-Anweisung werden Dateien entfernt, die in einer der folgenden internen Snowflake-Phasen bereitgestellt wurden:
- Benannte interne Phase
- Staging für eine bestimmte Tabelle
- Phase für den aktuellen Nutzer
BigQuery unterstützt das Konzept des Staging nicht und hat keine Entsprechungen für PUT
und REMOVE
.
DDL-Syntax
In diesem Abschnitt werden Unterschiede in der Syntax der Datendefinitionssprache zwischen Snowflake und BigQuery behandelt.
Datenbank-, Schema- und Freigabe-DDL
Der Großteil der Snowflake-Terminologie entspricht der von BigQuery, mit der Ausnahme, dass die Snowflake-Datenbank dem BigQuery-Dataset ähnelt. Weitere Informationen finden Sie in der detaillierten Zuordnung von Snowflake zu BigQuery-Terminologie.
CREATE DATABASE
-Anweisung
Snowflake unterstützt das Erstellen und Verwalten einer Datenbank über Befehle zur Datenbankverwaltung, während BigQuery mehrere Optionen wie die Verwendung der Console, der Befehlszeile, Clientbibliotheken usw. zum Erstellen von Datasets{ bietet. In diesem Abschnitt werden BigQuery-Befehlszeilenbefehle verwendet, die den Snowflake-Befehlen entsprechen, um die Unterschiede hervorzuheben.
Snowflake | BigQuery |
---|---|
Hinweis: Snowflake stellt diese Anforderungen für die Benennung von Datenbanken bereit. Der Name darf nur 255 Zeichen lang sein. |
Hinweis: BigQuery hat ähnliche Dataset-Benennungsanforderungen wie Snowflake, mit dem Unterschied, dass im Namen 1.024 Zeichen zulässig sind. |
|
Das Ersetzen des Datasets wird in BigQuery nicht unterstützt. |
|
Das Erstellen eines temporären Datasets wird in BigQuery nicht unterstützt. |
|
Konzept wird in BigQuery nicht unterstützt |
|
Das Klonen von Datasets wird in BigQuery noch nicht unterstützt. |
|
Zeitreisen auf Dataset-Ebene werden in BigQuery nicht unterstützt. Zeitreisen für Tabellen- und Abfrageergebnisse werden jedoch unterstützt. |
|
Die Sortierung in DDL wird in BigQuery nicht unterstützt. |
|
|
|
Das Erstellen freigegebener Datasets wird in BigQuery nicht unterstützt. Nutzer können das Dataset jedoch über die Console/Benutzeroberfläche freigeben, sobald das Dataset erstellt wurde. |
Hinweis: Snowflake bietet die Option für die automatische Hintergrundwartung von materialisierten Ansichten in der sekundären Datenbank, die in BigQuery nicht unterstützt wird. |
|
BigQuery bietet auch die folgenden bq mk
-Befehlsoptionen, die in Snowflake keine direkte Entsprechung haben:
--location <dataset_location>
--default_table_expiration <time_in_seconds>
--default_partition_expiration <time_in_seconds>
ALTER DATABASE
-Anweisung
In diesem Abschnitt werden BigQuery-Befehlszeilenbefehle verwendet, die den Snowflake-Befehlen entsprechen, um die Unterschiede in ALTER-Anweisungen zu beheben.
Snowflake | BigQuery |
---|---|
|
Das Umbenennen von Datasets wird in BigQuery nicht unterstützt, das Kopieren von Datasets wird jedoch unterstützt. |
|
Der Austausch von Datasets wird in BigQuery nicht unterstützt. |
|
Die Verwaltung der Datenaufbewahrung und -sortierung auf Dataset-Ebene wird in BigQuery nicht unterstützt. |
|
|
|
Das Konzept wird in BigQuery nicht unterstützt. |
|
Das Konzept wird in BigQuery nicht unterstützt. |
|
Das Konzept wird in BigQuery nicht unterstützt. |
|
Das Konzept wird in BigQuery nicht unterstützt. |
|
Das Konzept wird in BigQuery nicht unterstützt. |
|
Das Konzept wird in BigQuery nicht unterstützt. |
|
Das Konzept wird in BigQuery nicht unterstützt. |
DROP DATABASE
-Anweisung
In diesem Abschnitt wird der BigQuery-Befehlszeilenbefehl verwendet, der dem Befehl „Snowflake“ entspricht, um den Unterschied in der DROP-Anweisung zu beheben.
Snowflake | BigQuery |
---|---|
Hinweis: Durch das Löschen einer Datenbank in Snowflake wird sie nicht dauerhaft aus dem System entfernt. Eine Version der verworfenen Datenbank wird für die Anzahl der Tage aufbewahrt, die durch den Parameter DATA_RETENTION_TIME_IN_DAYS für die Datenbank angegeben sind. |
-r werden alle Objekte im Dataset entfernt
-d gibt ein Dataset anHinweis: In BigQuery ist das Löschen eines Datasets endgültig. Außerdem wird die Kaskadierung auf Dataset-Ebene nicht unterstützt, da alle Daten und Objekte im Dataset gelöscht werden. |
Snowflake unterstützt auch den Befehl UNDROP DATASET
, mit dem die neueste Version eines verworfenen Datasets wiederhergestellt wird. In BigQuery wird dies derzeit nicht auf Dataset-Ebene unterstützt.
USE DATABASE
-Anweisung
Snowflake bietet die Option, die Datenbank für eine Nutzersitzung mit dem Befehl USE DATABASE
festzulegen. Dadurch müssen Sie in SQL-Befehlen keine voll qualifizierten Objektnamen angeben. BigQuery bietet keine Alternative zum Befehl USE DATABASE von Snowflake.
SHOW DATABASE
-Anweisung
In diesem Abschnitt wird der BigQuery-CLI-Befehl verwendet, der dem Befehl „Snowflake“ entspricht, um den Unterschied in der SHOW-Anweisung zu beheben.
Snowflake | BigQuery |
---|---|
Hinweis: Snowflake bietet eine einzige Option zum Auflisten und Anzeigen von Details zu allen Datenbanken, einschließlich verworfener Datenbanken, die sich innerhalb der Aufbewahrungsdauer befinden. |
bq ls --format=prettyjsonund / oder
Hinweis: In BigQuery enthält der Befehl „ls“ nur Dataset-Namen und grundlegende Informationen. Der Befehl „einblenden“ enthält Details wie den Zeitstempel der letzten Änderung, ACLs und Labels eines Datasets. BigQuery stellt außerdem über das Informationsschema weitere Details zu den Datasets bereit. |
Hinweis: Mit der TERSE-Option ermöglicht Snowflake die Anzeige nur bestimmter Informationen/Felder zu Datasets. |
Das Konzept wird in BigQuery nicht unterstützt. |
Das Zeitreisekonzept wird in BigQuery auf Dataset-Ebene nicht unterstützt. | |
SHOW DATABASES
|
Das Filtern von Ergebnissen nach Dataset-Namen wird in BigQuery nicht unterstützt. Das Filtern nach Labels wird jedoch unterstützt. |
SHOW DATABASES
Hinweis: Standardmäßig begrenzt Snowflake die Anzahl der Ergebnisse nicht. Der Wert für LIMIT darf jedoch 10.000 nicht überschreiten. |
Hinweis: Standardmäßig zeigt BigQuery nur 50 Ergebnisse an. |
BigQuery bietet auch die folgenden bq
-Befehlsoptionen, die in Snowflake keine direkte Entsprechung haben:
- bq ls --format=pretty: Gibt einfach formatierte Ergebnisse zurück
- *bq ls -a: *Gibt nur anonyme Datasets zurück (die mit einem Unterstrich beginnen).
- bq ls --all: Gibt alle Datasets zurück, einschließlich anonymer Datasets
- bq ls --filter labels.key:value: Gibt Ergebnisse zurück, die nach Dataset-Label gefiltert sind
- bq ls --d: Schließt anonyme Datasets aus Formularergebnissen aus
- bq show --format=pretty: Gibt detaillierte grundlegend formatierte Ergebnisse für alle Datasets zurück
SCHEMA
-Verwaltung
Snowflake bietet mehrere Schemaverwaltungsbefehle ähnlich wie die Befehle zur Datenbankverwaltung. Dieses Konzept zum Erstellen und Verwalten von Schemas wird in BigQuery nicht unterstützt.
Mit BigQuery können Sie jedoch das Schema einer Tabelle angeben, wenn Sie Daten in eine Tabelle laden oder eine leere Tabelle erstellen. Für unterstützte Datenformate können Sie alternativ auch die automatische Schemaerkennung nutzen.
SHARE
-Verwaltung
Snowflake bietet mehrere Freigabeverwaltungsbefehle wie die Datenbank- und Schemaverwaltungsbefehle. Dieses Konzept zum Erstellen und Verwalten von Freigaben wird in BigQuery nicht unterstützt.
Tabellen-, Ansichts- und Sequenz-DDL
CREATE TABLE
-Anweisung
Die meisten Snowflake-CREATE TABLE
-Anweisungen sind mit BigQuery kompatibel, mit Ausnahme der folgenden Syntaxelemente, die in BigQuery nicht verwendet werden:
Snowflake | BigQuery |
---|---|
Hinweis: UNIQUE - und PRIMARY KEY -Einschränkungen sind informationell und werden vom Snowflake-System nicht erzwungen. |
|
Dabei gilt: table_constraints sind:
Hinweis:
UNIQUE - und PRIMARY KEY -Einschränkungen sind informativ und werden vom Snowflake-System nicht erzwungen. |
Hinweis: BigQuery verwendet keine UNIQUE -, PRIMARY KEY -, FOREIGN - oder KEY -Tabelleneinschränkungen. Um eine ähnliche Optimierung zu erreichen, die diese Einschränkungen während der Abfrageausführung gewährleisten, partitionieren und clustern Sie Ihre BigQuery-Tabellen. CLUSTER BY unterstützt bis zu vier Spalten. |
|
In diesem Beispiel erfahren Sie, wie Sie mit den INFORMATION_SCHEMA -Tabellen Spaltennamen, Datentypen und NOT NULL-Einschränkungen in eine neue Tabelle kopieren. |
Hinweis: In Snowflake ist die Einstellung BACKUP NO angegeben, um „Verarbeitungszeit beim Erstellen von Snapshots und Wiederherstellen aus Snapshots zu sparen und Speicherplatz zu reduzieren“. |
Die Tabellenoption BACKUP NO wird nicht verwendet oder benötigt, da BigQuery automatisch bis zu 7 Tage an früheren Versionen aller Tabellen speichert, ohne dass sich dies auf die Verarbeitungszeit oder den abgerechneten Speicher auswirkt. |
Dabei gilt: table_attributes sind:
|
BigQuery unterstützt das Clustering, sodass Schlüssel in sortierter Reihenfolge gespeichert werden können. |
|
|
|
|
BigQuery unterstützt auch die DDL-Anweisung CREATE OR REPLACE
TABLE
-Anweisung, mit der eine Tabelle überschrieben wird, wenn sie bereits vorhanden ist.
Die CREATE TABLE
-Anweisung von BigQuery unterstützt auch die folgenden Klauseln, für die es kein Snowflake-Äquivalent gibt:
Weitere Informationen zu CREATE TABLE
in BigQuery finden Sie in den BigQuery CREATE
-Beispielen in der DML-Dokumentation.
ALTER TABLE
-Anweisung
In diesem Abschnitt werden BigQuery-Befehlszeilenbefehle verwendet, die den Snowflake-Befehlen entsprechen, um die Unterschiede in ALTER-Anweisungen für Tabellen zu beheben.
Snowflake | BigQuery |
---|---|
|
|
|
Der Austausch von Tabellen wird in BigQuery nicht unterstützt. |
|
Die Verwaltung der Datensortierung für Tabellen wird in BigQuery nicht unterstützt. |
|
|
|
|
Darüber hinaus bietet Snowflake Clustering-, Spalten- und Einschränkungsoptionen zum Ändern von Tabellen, die von BigQuery nicht unterstützt werden.
DROP TABLE
- und UNDROP TABLE
-Anweisungen
In diesem Abschnitt wird der BigQuery-CLI-Befehl verwendet, der dem Befehl „Snowflake“ entspricht, um den Unterschied in den Anweisungen DROP und UNDROP zu beheben.
Snowflake | BigQuery |
---|---|
Hinweis: Durch das Löschen einer Tabelle in Snowflake wird sie nicht dauerhaft aus dem System entfernt. Eine Version der verworfenen Tabelle wird für die Anzahl der Tage aufbewahrt, die durch den Parameter DATA_RETENTION_TIME_IN_DAYS für die Datenbank angegeben sind. |
-f überspringt die Bestätigung für die Ausführung -d gibt das Dataset an Hinweis: In BigQuery ist das Löschen einer Tabelle nicht endgültig, aber ein Snapshot bleibt derzeit nur sieben Tage lang erhalten. |
|
Hinweis: In BigQuery müssen Sie zuerst einen UNIX-Zeitstempel in Millisekunden für die Zeit ermitteln, zu der die Tabelle existiert hat. Kopieren Sie die Tabelle dann mit diesem Zeitstempel in eine neue Tabelle. Die neue Tabelle muss einen anderen Namen als die gelöschte Tabelle haben. |
CREATE EXTERNAL TABLE
-Anweisung
Mit BigQuery können Sie sowohl permanente als auch temporäre externe Tabellen erstellen und Daten direkt aus folgenden Quellen abfragen:
Snowflake ermöglicht das Erstellen einer permanenten externen Tabelle, die bei der Abfrage Daten aus einer Reihe von einer oder mehreren Dateien in einer angegebenen externen Phase liest.
In diesem Abschnitt wird der BigQuery-CLI-Befehl verwendet, der dem Befehl „Snowflake“ entspricht, um die Unterschiede in der Anweisung CREATE EXTERNAL TABLE zu beheben.
Snowflake | BigQuery |
---|---|
CREATE [OR REPLACE] EXTERNAL TABLE
Hinweis: Snowflake ermöglicht das Staging der Dateien mit Daten, die gelesen werden sollen, und legt Optionen für das Format von externen Tabellen fest. Die Snowflake-Formattypen: CSV, JSON, AVRO, PARQUET und ORC werden mit Ausnahme des XML-Typs von BigQuery unterstützt. |
Hinweis: In BigQuery können Sie eine permanente Tabelle erstellen, die mit Ihrer Datenquelle verknüpft ist, indem Sie eine Tabellendefinitionsdatei [1], eine JSON-Schemadatei [2] oder eine Inline-Schemadefinition [3] verwenden. Das Staging von zu lesenden Dateien und die Angabe von Optionen für das Format werden in BigQuery nicht unterstützt. |
|
Hinweis: BigQuery unterstützt derzeit keine der optionalen Parameteroptionen von Snowflake zum Erstellen externer Tabellen. Für die Partitionierung unterstützt BigQuery die Verwendung der Pseudospalte _FILE_NAME, um partitionierte Tabellen/Ansichten über den externen Tabellen zu erstellen. Weitere Informationen finden Sie unter Pseudospalte _FILE_NAME abfragen. |
Darüber hinaus unterstützt BigQuery auch das Abfragen extern partitionierter Daten in den Formaten AVRO, PARQUET, ORC, JSON und CSV, die die auf Google Cloud Storage gespeichert sind und ein Standardlayout für Hive-Partitionierung. verwenden.
CREATE VIEW
-Anweisung
Die folgende Tabelle zeigt Entsprechungen zwischen Snowflake und BigQuery für die Anweisung CREATE VIEW
.
Snowflake | BigQuery |
---|---|
|
|
|
CREATE OR REPLACE VIEW
|
|
|
Nicht unterstützt | CREATE VIEW IF NOT EXISTS
|
|
In BigQuery müssen alle referenzierten Objekte bereits vorhanden sein, um eine Ansicht zu erstellen. Mit BigQuery können Sie externe Datenquellen abfragen. |
CREATE SEQUENCE
-Anweisung
Sequenzen werden in BigQuery nicht verwendet und können mit der folgenden Batchmethode erreicht werden. Weitere Informationen zu Ersatzschlüsseln und zu einer langsam ändernden Dimension (SCD) finden Sie in den folgenden Anleitungen:
|
---|
Laden und Entladen von Daten DDL
Snowflake unterstützt das Laden und Entladen von Daten über Phasen-, Dateiformat- und Pipe-Verwaltungsbefehle. BigQuery bietet auch mehrere Optionen, z. B. zum bq load, BigQuery Data Transfer Service, bq extract usw. In diesem Abschnitt werden die Unterschiede in der Verwendung dieser Methoden zum Laden und Entladen von Daten erläutert.
Konto- und Sitzungs-DDL
Die Konto- und Sitzungskonzepte von Snowflake werden in BigQuery nicht unterstützt. BigQuery ermöglicht die Verwaltung von Konten über Cloud IAM auf allen Ebenen. Außerdem werden Transaktionen mit mehreren Anweisungen in BigQuery noch nicht unterstützt.
Benutzerdefinierte Funktionen (UDF)
Mithilfe einer UDF können Sie Funktionen für benutzerdefinierte Vorgänge erstellen. Diese Funktionen akzeptieren Spalten als Eingabe, führen Aktionen aus und geben das Ergebnis dieser Aktionen als Wert zurück.
Sowohl Snowflake als auch BigQuery unterstützen UDF mit SQL-Ausdrücken und JavaScript-Code.
Im GitHub-Repository GoogleCloudPlatform/bigquery-utils/ finden Sie eine Bibliothek gängiger BigQuery-UDFs.
CREATE FUNCTION
-Syntax
In der folgenden Tabelle werden die Unterschiede in der SQL-UDF-Erstellungssyntax zwischen Snowflake und BigQuery behandelt.
Snowflake | BigQuery |
---|---|
|
Hinweis: In BigQuery SQL-UDF ist der Rückgabedatentyp optional. BigQuery leitet den Ergebnistyp der Funktion aus dem SQL-Funktionsrumpf ab, wenn eine Abfrage die Funktion aufruft. |
|
Hinweis: In BigQuery SQL-UDF wird der zurückgegebene Tabellentyp derzeit nicht unterstützt. Er ist aber in Planung und wird bald verfügbar sein. BigQuery unterstützt jedoch die Rückgabe von ARRAYs vom Typ STRUCT. |
Hinweis: Snowflake bietet eine sichere Option zum Einschränken der UDF-Definition und der Details auf autorisierte Nutzer (d. h., auf die Nutzer, denen die Rolle gehört, die die Ansicht besitzt). |
Hinweis: Die Sicherheit der Funktion ist in BigQuery kein konfigurierbarer Parameter. BigQuery unterstützt das Erstellen von IAM-Rollen und -Berechtigungen, um den Zugriff auf die zugrunde liegenden Daten und Funktionsdefinitionen einzuschränken. |
|
Hinweis: Das Verhalten der Funktion bei Nulleingaben wird implizit in BigQuery verarbeitet und muss nicht als separate Option angegeben werden. |
|
Hinweis: Die Volatilität der Funktion ist in BigQuery kein konfigurierbarer Parameter. Die gesamte BigQuery-UDF-Volatilität entspricht der IMMUTABLE -Volatilität von Snowflake (d.0h., sie führt keine Datenbanksuche durch und verwendet keine Informationen, die nicht direkt in der Argumentliste vorhanden sind). |
|
CREATE [OR REPLACE] FUNCTION
Hinweis: Verwenden Sie einfache Anführungszeichen oder eine Zeichensequenz wie Dollar-Anführungszeichen ($$) is not required or supported in BigQuery. BigQuery implicitly interprets the SQL expression. |
|
Note:Adding comments or descriptions in UDFs is currently not supported in BigQuery. |
|
Note: BigQuery supports using ANY TYPE as argument type. The function will accept an input of any type for this argument. For more information, see templated parameter in BigQuery. |
BigQuery also supports the CREATE FUNCTION IF NOT EXISTS
statement
which treats the query as successful and takes no action if a function with the
same name already exists.
BigQuery's CREATE FUNCTION
statement also supports creating
TEMPORARY or TEMP functions
,
which do not have a Snowflake equivalent. See
calling UDFs
for details on executing a BigQuery persistent UDF.
DROP FUNCTION
syntax
The following table addresses differences in DROP FUNCTION syntax between Snowflake and BigQuery.
Snowflake | BigQuery |
---|---|
|
Note: BigQuery does not require using the function's signature (argument data type) for deleting the function. |
BigQuery requires that you specify the project_name if the function is not located in the current project.
Additional function commands
This section covers additional UDF commands supported by Snowflake that are not directly available in BigQuery.
ALTER FUNCTION
syntax
Snowflake supports the following operations using
ALTER FUNCTION
syntax.
- Renaming a UDF
- Converting to (or reverting from) a secure UDF
- Adding, overwriting, removing a comment for a UDF
As configuring function security and adding function comments is not available in BigQuery, ALTER FUNCTION syntax is currently not supported. However, the CREATE FUNCTION statement can be used to create a UDF with the same function definition but a different name.
DESCRIBE FUNCTION
syntax
Snowflake supports describing a UDF using DESC[RIBE] FUNCTION syntax. This is currently not supported in BigQuery. However, querying UDF metadata via INFORMATION SCHEMA will be available soon as part of the product roadmap.
SHOW USER FUNCTIONS
syntax
In Snowflake, SHOW USER FUNCTIONS syntax can be used to list all UDFs for which users have access privileges. This is currently not supported in BigQuery. However, querying UDF metadata via INFORMATION SCHEMA will be available soon as part of the product roadmap.
Stored procedures
Snowflake stored procedures are written in JavaScript, which can execute SQL statements by calling a JavaScript API. In BigQuery, stored procedures are defined using a block of SQL statements.
CREATE PROCEDURE
syntax
In Snowflake, a stored procedure is executed with a CALL command while in BigQuery, stored procedures are executed like any other BigQuery function.
The following table addresses differences in stored procedure creation syntax between Snowflake and BigQuery.
Snowflake | BigQuery |
---|---|
Note: Snowflake requires that stored procedures return a single value. Hence, return data type is a required option. |
CREATE [OR REPLACE] PROCEDURE
Note: BigQuery doesn't support a return type for stored procedures. Also, it requires specifying argument mode for each argument passed. |
|
|
|
CREATE [OR REPLACE] PROCEDURE
Hinweis: Das Prozedurverhalten bei Nulleingaben wird implizit in BigQuery verarbeitet und muss nicht als separate Option angegeben werden. |
CREATE [OR REPLACE] PROCEDURE
|
Hinweis: Die Volatilität der Prozedur ist in BigQuery kein konfigurierbarer Parameter. Dies entspricht der IMMUTABLE -Volatilität von Snowflake. |
CREATE [OR REPLACE] PROCEDURE
|
Hinweis: Das Hinzufügen von Kommentaren oder Beschreibungen in Prozedurdefinitionen wird derzeit in BigQuery nicht unterstützt. |
CREATE [OR REPLACE] PROCEDURE
Hinweis: Snowflake unterstützt die Angabe des Aufrufers oder des Inhabers der Prozedur für die Ausführung. |
Hinweis: Gespeicherte BigQuery-Prozeduren werden immer als Aufrufer ausgeführt. |
BigQuery unterstützt auch die Anweisung CREATE PROCEDURE IF NOT EXISTS
, die die Abfrage als erfolgreich behandelt und keine Aktion ausführt, wenn bereits eine Funktion mit demselben Namen vorhanden ist.
DROP PROCEDURE
-Syntax
In der folgenden Tabelle werden die Unterschiede in der DROP FUNCTION-Syntax zwischen Snowflake und BigQuery behandelt.
Snowflake | BigQuery |
---|---|
|
Hinweis: BigQuery erfordert zum Löschen der Prozedur keine Signatur der Prozedur (Argumentdatentyp). |
BigQuery erfordert, dass Sie project_name angeben, wenn sich die Prozedur nicht im aktuellen Projekt befindet.
Weitere Prozedurbefehle
Snowflake bietet zusätzliche Befehle wie ALTER PROCEDURE
, DESC[RIBE] PROCEDURE
und SHOW PROCEDURES
zum Verwalten der gespeicherten Prozeduren. Diese werden derzeit in BigQuery nicht unterstützt.
Metadaten- und Transaktions-SQL-Anweisungen
Snowflake | BigQuery |
---|---|
|
BigQuery verwendet immer die Snapshot-Isolation. Weitere Informationen finden Sie an anderer Stelle in diesem Dokument unter Konsistenzgarantien. |
|
Wird in BigQuery nicht verwendet. |
|
Wird in BigQuery nicht verwendet. |
|
Wird in BigQuery nicht verwendet. |
Mehrfachanweisungen und mehrzeilige SQL-Anweisungen
Sowohl Snowflake als auch BigQuery unterstützen Transaktionen (Sitzungen) und unterstützen daher durch Semikolons getrennte Anweisungen, die konsistent zusammen ausgeführt werden. Weitere Informationen finden Sie unter Transaktionen mit mehreren Anweisungen.
Metadatenspalten für bereitgestellte Dateien
Snowflake generiert automatisch Metadaten für Dateien in internen und externen Phasen. Diese Metadaten können zusammen mit regulären Datenspalten abgefragt und in eine Tabelle geladen werden. Die folgenden Metadatenspalten können verwendet werden:
Konsistenzgarantien und Transaktionsisolation
Sowohl Snowflake als auch BigQuery sind unteilbar, d. h. ACID-konform auf Mutationsebene über viele Zeilen hinweg.
Transaktionen
Jeder Snowflake-Transaktion wird eine eindeutige Startzeit (einschließlich Millisekunden) zugewiesen, die als Transaktions-ID festgelegt wird. Snowflake unterstützt nur die Isolationsebene READ COMMITTED
. Eine Anweisung kann jedoch Änderungen sehen, die von einer anderen Anweisung vorgenommen wurden, wenn sich beide in derselben Transaktion befinden, auch wenn diese Änderungen noch nicht per Commit bestätigt wurden. Snowflake-Transaktionen erhalten Sperren für Ressourcen (Tabellen), wenn diese Ressource geändert wird. Nutzer können die maximale Zeit anpassen, die eine blockierte Anweisung wartet, bis das Zeitlimit der Anweisung überschritten wird. DML-Anweisungen werden automatisch per Commit ausgeführt, wenn der Parameter AUTOCOMMIT
aktiviert ist.
BigQuery unterstützt auch Transaktionen. BigQuery sorgt mit der Snapshot-Isolation für eine optimistische Gleichzeitigkeitserkennung (der erste Commit erhält Vorrang), bei der eine Abfrage die letzten übergebenen Daten liest, bevor die Abfrage beginnt. Dieser Ansatz sorgt für die gleiche Konsistenz auf Zeilen- und Mutationsbasis sowie zeilenübergreifend innerhalb derselben DML-Anweisung, vermeidet dabei jedoch Deadlocks. Bei mehreren DML-Aktualisierungen für dieselbe Tabelle wechselt BigQuery zur pessimistischen Nebenläufigkeitserkennung. Ladejobs können vollständig unabhängig ausgeführt und an Tabellen angefügt werden. BigQuery bietet jedoch noch keine explizite Transaktionsgrenze oder Sitzung.
Rollback
Wenn die Sitzung einer Snowflake-Transaktion unerwartet beendet wird, bevor die Transaktion in einem Commit-Vorgang ausgeführt oder ein Rollback durchgeführt wird, bleibt die Transaktion in einem getrennten Zustand. Der Nutzer sollte SYSTEM$ABORT_TRANSACTION ausführen, um die getrennte Transaktion abzubrechen. Andernfalls führt Snowflake ein Rollback der getrennten Transaktion nach vier Stunden der Inaktivität aus. Wenn ein Deadlock auftritt, erkennt Snowflake den Deadlock und wählt die aktuellere Anweisung für das Rollback aus. Wenn die DML-Anweisung in einer explizit geöffneten Transaktion fehlschlägt, wird ein Rollback der Änderungen durchgeführt. Die Transaktion bleibt jedoch so lange geöffnet, bis sie in einem Commit-Vorgang bestätigt oder ein Rollback dafür durchgeführt wird. Für DDL-Anweisungen in Snowflake kann kein Rollback durchgeführt werden, da für sie automatisch ein Commit durchgeführt wird.
BigQuery unterstützt die Anweisung ROLLBACK TRANSACTION
.
In BigQuery gibt es keine ABORT
-Anweisung.
Datenbanklimits
Die aktuellen Kontingente und Limits finden Sie immer in der öffentlichen BigQuery-Dokumentation . Viele Kontingente für Nutzer mit hohem Datenvolumen können durch Kontaktaufnahme mit dem Cloud-Supportteam erhöht werden.
Für alle Snowflake-Konten sind standardmäßig weiche Limits festgelegt. Weiche Limits werden während der Kontoerstellung festgelegt und können variieren. Viele weiche Limits von Snowflake können über das Snowflake-Account-Management-Team oder ein Support-Ticket erhöht werden.
Die folgende Tabelle zeigt einen Vergleich der Snowflake- und BigQuery-Datenbanklimits.
Limit | Snowflake | BigQuery |
---|---|---|
Größe des Abfragetexts | 1 MB | 1 MB |
Maximale Anzahl gleichzeitiger Abfragen | XS Warehouse - 8 S Warehouse - 16 M Warehouse - 32 L Warehouse - 64 XL Warehouse - 128 |
100 |