מדריך לתרגום Snowflake SQL
במסמך הזה מפורטים קווי הדמיון וההבדלים בתחביר של SQL בין Snowflake ל-BigQuery, כדי לעזור לכם לתכנן ולבצע את המעבר של ה-EDW (מחסן נתונים ארגוני) ל-BigQuery. מחסן הנתונים של Snowflake מיועד לעבוד עם תחביר SQL ספציפי ל-Snowflake. יכול להיות שתצטרכו לשנות סקריפטים שנכתבו ל-Snowflake לפני שתוכלו להשתמש בהם ב-BigQuery, כי פורמטי ה-SQL משתנים בין השירותים. אתם יכולים להשתמש בתרגום SQL באצווה כדי להעביר את הסקריפטים של SQL בכמות גדולה, או בתרגום SQL אינטראקטיבי כדי לתרגם שאילתות אד-הוק. שני הכלים תומכים ב-Snowflake SQL בגרסת טרום-השקה (Preview).
סוגי הנתונים
בקטע הזה מוצגים סוגי הנתונים המקבילים ב-Snowflake וב-BigQuery.
| פתית שלג | BigQuery | הערות |
|---|---|---|
NUMBER/
DECIMAL/NUMERIC |
NUMERIC/BIGNUMERIC |
אפשר למפות ל-NUMERIC או ל-BIGNUMERIC, בהתאם לדיוק ולסולם.סוג הנתונים NUMBER ב-Snowflake תומך ב-38 ספרות של דיוק וב-37 ספרות של קנה מידה. אפשר לציין את הדיוק והקנה מידה בהתאם למשתמש.BigQuery תומך ב- NUMERIC וב-BIGNUMERIC עם אפשרות לציין דיוק וקנה מידה בטווח מסוים. |
INT/INTEGER |
BIGNUMERIC |
INT/INTEGER וכל סוגי הנתונים האחרים שדומים ל-INT, כמו BIGINT, TINYINT, SMALLINT, BYTEINT, מייצגים כינוי לסוג הנתונים NUMBER שבו אי אפשר לציין את הדיוק והקנה מידה, והוא תמיד NUMBER(38, 0)כברירת מחדל, BigQuery ממיר את INTEGER ל-INT64. כדי להגדיר את תרגום ה-SQL כך שימיר אותו לסוגי נתונים אחרים, אפשר להשתמש באפשרות ההגדרה REWRITE_ZERO_SCALE_NUMERIC_AS_INTEGER. |
BIGINT |
BIGNUMERIC |
|
SMALLINT |
BIGNUMERIC |
|
TINYINT |
BIGNUMERIC |
|
BYTEINT |
BIGNUMERIC |
|
FLOAT/ |
FLOAT64 |
סוג הנתונים FLOAT ב-Snowflake מגדיר את NaN כ-> X, כאשר X הוא כל ערך FLOAT (מלבד NaN עצמו).סוג הנתונים FLOAT ב-BigQuery מגדיר את "NaN" כ-< X, כאשר X הוא כל ערך FLOAT (מלבד "NaN" עצמו). |
DOUBLE/REAL |
FLOAT64 |
סוג הנתונים DOUBLE ב-Snowflake הוא שם נרדף לסוג הנתונים FLOAT ב-Snowflake, אבל בדרך כלל הוא מוצג באופן שגוי בתור FLOAT. הוא מאוחסן כמו שצריך בתור DOUBLE. |
VARCHAR |
STRING |
האורך המקסימלי של סוג הנתונים VARCHAR ב-Snowflake הוא 128MB (ללא דחיסה). אם לא מציינים אורך, ברירת המחדל היא האורך המקסימלי.סוג הנתונים STRING ב-BigQuery מאוחסן כ-Unicode בקידוד UTF-8 באורך משתנה. מידע נוסף על מגבלות של עמודות ושורות זמין במאמר משימות שאילתה. |
CHAR/CHARACTER |
STRING |
|
STRING/TEXT |
STRING |
סוג הנתונים STRING ב-Snowflake הוא שם נרדף ל-VARCHAR של Snowflake. |
BINARY |
BYTES |
|
VARBINARY |
BYTES |
|
BOOLEAN |
BOOL |
סוג הנתונים BOOL ב-BigQuery יכול לקבל רק TRUE/FALSE, בניגוד לסוג הנתונים BOOL ב-Snowflake, שיכול לקבל TRUE/FALSE/NULL. |
DATE |
DATE |
הסוג DATE ב-Snowflake מקבל את רוב הפורמטים הנפוצים של תאריכים, בניגוד לסוג DATE ב-BigQuery, שמקבל רק תאריכים בפורמט 'YYYY-[M]M-[D]D'. |
TIME |
TIME |
הסוג TIME ב-Snowflake תומך בדיוק של 0 עד 9 ננו-שניות, ואילו הסוג TIME ב-BigQuery תומך בדיוק של 0 עד 6 ננו-שניות. |
TIMESTAMP |
DATETIME |
TIMESTAMP הוא כינוי שניתן להגדרה על ידי המשתמש, שמוגדר כברירת מחדל ל-TIMESTAMP_NTZ וממופה ל-DATETIME ב-BigQuery. |
TIMESTAMP_LTZ |
TIMESTAMP |
|
TIMESTAMP_NTZ/DATETIME | ||
DATETIME |
||
TIMESTAMP_TZ |
TIMESTAMP |
|
OBJECT |
JSON |
|
VARIANT |
JSON |
|
ARRAY |
ARRAY<JSON> |
שירות התרגום של SQL שומר על סוג הנתונים של מערכים מוגדרים. במערכים ללא סוג, כמו ARRAY<VARIANT>, המערכת ממירה אותם ל-ARRAY<JSON> ב-BigQuery |
ב-BigQuery יש גם את סוגי הנתונים הבאים, שאין להם מקבילה ישירה ב-Snowflake:
תחביר CREATE FUNCTION
בטבלה הבאה מפורטים ההבדלים בתחביר ליצירת פונקציות UDF ב-SQL בין Snowflake לבין BigQuery.
| Snowflake | BigQuery |
|---|---|
|
הערה: ב-SQL UDF של BigQuery, סוג הנתונים שמוחזר הוא אופציונלי. כאשר שאילתה קוראת לפונקציה, BigQuery מסיק את סוג התוצאה של הפונקציה מגוף פונקציית ה-SQL. |
|
הערה:ב-SQL UDF של BigQuery, החזרת סוג טבלה לא נתמכת, אבל היא נמצאת בתוכנית השיווקית למוצר ותהיה זמינה בקרוב. עם זאת, BigQuery תומך בהחזרת ARRAY מסוג STRUCT. |
|
הערה: ב-Snowflake יש אפשרות מאובטחת להגביל את ההגדרה והפרטים של ה-UDF רק למשתמשים מורשים (כלומר, משתמשים שקיבלו את התפקיד שהתצוגה בבעלותו). |
הערה: אבטחת הפונקציות היא לא פרמטר שאפשר להגדיר ב-BigQuery. ב-BigQuery אפשר ליצור תפקידים והרשאות של IAM כדי להגביל את הגישה לנתונים הבסיסיים ולהגדרת הפונקציה. |
|
הערה: התנהגות הפונקציה עבור קלט null מטופלת באופן משתמע ב-BigQuery ואין צורך לציין אותה כאפשרות נפרדת. |
|
הערה:תנודתיות הפונקציה היא לא פרמטר שניתן להגדרה ב-BigQuery. כל התנודתיות של UDF ב-BigQuery שוות ערך לתנודתיות IMMUTABLE של Snowflake (כלומר, היא לא מבצעת חיפושים במסד הנתונים או משתמשת במידע שלא נמצא ישירות ברשימת הארגומנטים שלה). |
|
CREATE [OR REPLACE] FUNCTION
הערה: אם משתמשים בגרשיים או ברצף תווים כמו ציטוט בדולר ($$) 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
הערה: ההתנהגות של הפרוצדורה לגבי קלט מסוג null מטופלת באופן משתמע ב-BigQuery, ואין צורך לציין אותה כאפשרות נפרדת. |
CREATE [OR REPLACE] PROCEDURE
|
הערה:תנודתיות הפרוצדורה היא לא פרמטר שאפשר להגדיר ב-BigQuery. הוא מקביל ל- IMMUTABLE volatility ב-Snowflake. |
CREATE [OR REPLACE] PROCEDURE
|
הערה: ב-BigQuery אין תמיכה בהוספת הערות או תיאורים בהגדרות של פרוצדורות. |
CREATE [OR REPLACE] PROCEDURE
הערה: ב-Snowflake אפשר לציין את מי שמפעיל את הפרוצדורה או את הבעלים שלה. |
הערה: פרוצדורות מאוחסנות ב-BigQuery תמיד מופעלות בתור המתקשר |
ב-BigQuery יש גם תמיכה בהצהרה CREATE PROCEDURE IF NOT EXISTS, שמתייחסת לשאילתה כאל שאילתה שהצליחה ולא מבצעת שום פעולה אם כבר קיימת פונקציה עם אותו שם.
תחביר DROP PROCEDURE
בטבלה הבאה מפורטים ההבדלים בתחביר של DROP FUNCTION בין Snowflake ל-BigQuery.
| Snowflake | BigQuery |
|---|---|
|
הערה: ב-BigQuery לא צריך להשתמש בחתימה של הפרוצדורה (סוג הנתונים של הארגומנט) כדי למחוק את הפרוצדורה. |
ב-BigQuery צריך לציין את project_name אם הפרוצדורה לא נמצאת בפרויקט הנוכחי.
פקודות נוספות לתהליכים
ב-Snowflake יש פקודות נוספות כמו ALTER PROCEDURE, DESC[RIBE] PROCEDURE ו-SHOW PROCEDURES לניהול הפרוצדורות המאוחסנות. אין תמיכה בהם ב-BigQuery.
הצהרות SQL של מטא-נתונים ועסקאות
| Snowflake | BigQuery |
|---|---|
|
ב-BigQuery תמיד נעשה שימוש בבידוד snapshot. לפרטים נוספים, ראו הבטחות לעקביות במקום אחר במסמך הזה. |
|
לא בשימוש ב-BigQuery. |
|
לא בשימוש ב-BigQuery |
|
לא בשימוש ב-BigQuery. |
הצהרות SQL עם מספר הצהרות ומספר שורות
גם Snowflake וגם BigQuery תומכים בטרנזקציות (סשנים), ולכן תומכים בהצהרות שמופרדות בנקודה ופסיק ומבוצעות באופן עקבי ביחד. מידע נוסף מופיע במאמר טרנזקציות עם כמה הצהרות.
עמודות של מטא-נתונים לקבצים בשלב הביניים
Snowflake יוצרת באופן אוטומטי מטא-נתונים לקבצים בשלבים פנימיים וחיצוניים. אפשר לשאול את המטא-נתונים האלה ולטעון אותם לטבלה לצד עמודות נתונים רגילות. אפשר להשתמש בעמודות המטא-נתונים הבאות:
התחייבויות לעקביות ורמת בידוד של טרנזקציה
גם Snowflake וגם BigQuery הם אטומיים – כלומר, תואמים ל-ACID ברמת המוטציה על פני שורות רבות.
טרנזקציות
לכל טרנזקציה ב-Snowflake מוקצית שעת התחלה ייחודית (כולל אלפיות השנייה) שמוגדרת כמזהה הטרנזקציה. ב-Snowflake יש תמיכה רק ברמת הבידוד READ COMMITTED. עם זאת, הצהרה יכולה לראות שינויים שבוצעו על ידי הצהרה אחרת אם שתיהן נמצאות באותה עסקה, גם אם השינויים האלה עדיין לא בוצעו. טרנזקציות ב-Snowflake נועלות משאבים (טבלאות) כשהמשאב משתנה. המשתמשים יכולים לשנות את משך הזמן המקסימלי שבו הצהרה חסומה תמתין עד שתוקף ההצהרה יפוג. פקודות DML מאושרות אוטומטית אם הפרמטר AUTOCOMMIT מופעל.
ב-BigQuery אפשר גם לבצע טרנזקציות. בעזרת BigQuery אפשר להבטיח בקרת בו-זמניות אופטימית (הראשון שמבצע commit מנצח) עם בידוד snapshot, שבו שאילתה קוראת את הנתונים האחרונים שבוצע להם commit לפני שהשאילתה מתחילה. הגישה הזו מבטיחה את אותה רמת עקביות על בסיס כל שורה וכל מוטציה, וגם בין שורות באותה פקודת DML, אבל מונעת מבוי סתום. אם יש כמה עדכוני DML באותה טבלה, BigQuery עובר לבקרת בו-זמניות פסימית. משימות טעינה יכולות לפעול באופן עצמאי לחלוטין ולהוסיף לטבלאות. עם זאת, BigQuery לא מספק גבולות מפורשים לטרנזקציות או לסשנים.
חזרה לגרסה קודמת
אם סשן של טרנזקציית Snowflake מסתיים באופן בלתי צפוי לפני שהטרנזקציה בוצעה או בוטלה, הטרנזקציה נשארת במצב מנותק. המשתמש צריך להריץ את SYSTEM$ABORT_TRANSACTION כדי לבטל את הטרנזקציה המנותקת, אחרת Snowflake יחזיר את הטרנזקציה המנותקת למצב הקודם אחרי ארבע שעות של חוסר פעילות. אם מתרחש מבוי סתום, Snowflake מזהה אותו ובוחרת את ההצהרה האחרונה כדי לבטל את השינויים. אם פקודת ה-DML בעסקה שנפתחה באופן מפורש נכשלת, השינויים מבוטלים, אבל העסקה נשארת פתוחה עד שהיא מאושרת או מבוטלת. אי אפשר לבטל הצהרות DDL ב-Snowflake כי הן נשמרות באופן אוטומטי.
BigQuery תומך בהצהרת ROLLBACK TRANSACTION.
אין הצהרת ABORT ב-BigQuery.
מגבלות של מסדי נתונים
תמיד כדאי לבדוק את המסמכים הציבוריים של BigQuery כדי לראות את המכסות והמגבלות העדכניות. משתמשים עם נפח שימוש גדול יכולים לפנות לצוות התמיכה של Cloud כדי להגדיל הרבה מהמכסות.
בכל החשבונות ב-Snowflake מוגדרות מגבלות גמישות כברירת מחדל. המגבלות הגמישות מוגדרות במהלך יצירת החשבון, והן יכולות להשתנות. אפשר להגדיל הרבה מהמגבלות הגמישות של Snowflake באמצעות צוות ניהול החשבון של Snowflake או כרטיס תמיכה.
בטבלה הבאה מוצגת השוואה בין מגבלות מסד הנתונים של Snowflake ושל BigQuery.
| מגבלה | Snowflake | BigQuery |
|---|---|---|
| גודל הטקסט של השאילתה | 1MB | 1MB |
| המספר המקסימלי של שאילתות בו-זמניות | XS Warehouse – 8 S Warehouse – 16 M Warehouse – 32 L Warehouse – 64 XL Warehouse – 128 |
100 |