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 Vorabversion unterstützt.
Datentypen
In diesem Abschnitt werden die Entsprechungen zwischen den Datentypen in Snowflake und BigQuery beschrieben.
| Snowflake | BigQuery | Hinweise |
|---|---|---|
NUMBER/
DECIMAL/NUMERIC |
NUMERIC/BIGNUMERIC |
Kann je nach Genauigkeit und Skalierung NUMERIC oder BIGNUMERIC zugeordnet werden.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 wie BIGINT, TINYINT, SMALLINT, BYTEINT stellen einen Alias für den Datentyp NUMBER dar, bei dem die Genauigkeit und die Anzahl der Nachkommastellen nicht angegeben werden können und immer NUMBER(38, 0)BigQuery konvertiert INTEGER standardmäßig in INT64. Wenn Sie die SQL-Übersetzung so konfigurieren möchten, dass sie in andere Datentypen konvertiert wird, können Sie die Konfigurationsoption REWRITE_ZERO_SCALE_NUMERIC_AS_INTEGER verwenden. |
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 gleichbedeutend mit dem Datentyp FLOAT in Snowflake, wird aber 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 128 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. Weitere Informationen zu Spalten- und Zeilenlimits finden Sie unter Abfragejobs. |
CHAR/CHARACTER |
STRING |
|
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 auf TIMESTAMP_NTZ gesetzt ist und in BigQuery DATETIME zugeordnet wird. |
TIMESTAMP_LTZ |
TIMESTAMP |
|
TIMESTAMP_NTZ/DATETIME | ||
DATETIME |
||
TIMESTAMP_TZ |
TIMESTAMP |
|
OBJECT |
JSON |
|
VARIANT |
JSON |
|
ARRAY |
ARRAY<JSON> |
Der SQL-Übersetzungsdienst behält den Datentyp für typisierte Arrays bei. Nicht typisierte Arrays wie ARRAY<VARIANT> werden von BigQuery in ARRAY<JSON> konvertiert. |
BigQuery verfügt auch über die folgenden Datentypen, die kein direktes Snowflake-Analog haben:
CREATE FUNCTION-Syntax
Die folgende Tabelle befasst sich mit den Unterschieden in der SQL-UDF-Erstellungssyntax zwischen Snowflake und BigQuery.
| Snowflake | BigQuery |
|---|---|
|
Hinweis: In einer BigQuery-SQL-UDF ist ein 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 nicht unterstützt. Er ist aber in der Produkt-Roadmap 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 zugrunde liegende Daten und Funktionsdefinitionen einzuschränken. |
|
Hinweis: Das Funktionsverhalten für Null-Eingaben wird in BigQuery implizit 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: Die Verwendung von einfachen Anführungszeichen oder einer Zeichensequenz wie Dollarzeichen ($$) is not required or supported in BigQuery. BigQuery implicitly interprets the SQL expression. |
|
Note: Adding comments or descriptions in UDFs is 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 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 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 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 Verhalten der Prozedur für Null-Eingaben wird in BigQuery implizit 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 in BigQuery nicht unterstützt. |
CREATE [OR REPLACE] PROCEDURE
Hinweis: Snowflake unterstützt die Angabe des Aufrufers oder 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 nicht die Signatur der Prozedur (Argumentdatentyp). |
BigQuery erfordert, dass Sie den project_name angeben, wenn sich die Prozedur nicht im aktuellen Projekt befindet.
Zusätzliche Befehle für Verfahren
Snowflake bietet zusätzliche Befehle wie ALTER PROCEDURE, DESC[RIBE] PROCEDURE und SHOW PROCEDURES zum Verwalten der gespeicherten Prozeduren. Diese werden 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 Stages. 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 Isolationsstufe 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 festgeschrieben 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 ein Zeitüberschreitungsfehler auftritt. DML-Anweisungen werden automatisch bestätigt, wenn der Parameter AUTOCOMMIT aktiviert ist.
BigQuery unterstützt auch Transaktionen. BigQuery sorgt mit der Snapshot-Isolation für eine optimistische Nebenläufigkeitserkennung (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 keine explizite Transaktionsgrenze oder Sitzung.
Rollback
Wenn die Sitzung einer Snowflake-Transaktion unerwartet beendet wird, bevor die Transaktion festgeschrieben oder zurückgesetzt wird, bleibt die Transaktion in einem getrennten Zustand. Der Nutzer sollte SYSTEM$ABORT_TRANSACTION ausführen, um die getrennte Transaktion abzubrechen. Andernfalls wird die getrennte Transaktion nach vier Stunden Inaktivität von Snowflake zurückgesetzt. Wenn ein Deadlock auftritt, erkennt Snowflake diesen und wählt die neuere Anweisung für ein Rollback aus. Wenn die DML-Anweisung in einer explizit geöffneten Transaktion fehlschlägt, werden die Änderungen rückgängig gemacht. Die Transaktion bleibt jedoch geöffnet, bis ein Commit oder Rollback ausgefü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 bei der Kontoerstellung festgelegt und können variieren. Viele weiche Snowflake-Limits 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 |