מבוא להעברות נתונים מ-Microsoft SQL Server
אתם יכולים לטעון נתונים מ-Microsoft SQL Server ל-BigQuery באמצעות שירות העברת הנתונים ל-BigQuery למחבר של Microsoft SQL Server. המחבר תומך במכונות של Microsoft SQL Server שמתארחות בסביבה המקומית, ב-Cloud SQL ובספקי שירותי ענן ציבורי אחרים כמו Amazon Web Services (AWS) ו-Microsoft Azure. במאמר הזה נסביר על האפשרויות להטמעת נתונים בהעברה מ-Microsoft SQL Server, על מיפוי סוגי הנתונים ועל התמחור.
במאמר טעינת נתונים מ-Microsoft SQL Server ל-BigQuery מוסבר איך מתזמנים העברה מ-Microsoft SQL Server.
אפשרויות להטמעת נתונים
בקטעים הבאים מפורטות האפשרויות להטמעת נתונים כשמגדירים העברת נתונים מ-Microsoft SQL Server.
הגדרת TLS
המחבר של Microsoft SQL Server תומך בהגדרה של אבטחה ברמת התעבורה (TLS) כדי להצפין את העברות הנתונים ל-BigQuery. מחבר Microsoft SQL Server תומך בהגדרות ה-TLS הבאות:
מצב הצפנת נתונים ואימות של רשות אישורים ושם מארח. במצב הזה מתבצע אימות מלא של השרת באמצעות TLS בפרוטוקול TCPS. הוא מצפין את כל הנתונים במעבר ומאמת שהאישור של שרת מסד הנתונים נחתם על ידי רשות אישורים (CA) מהימנה. במצב הזה גם נבדק אם שם המארח שאליו אתם מתחברים תואם בדיוק לשם הנפוץ (CN) או לשם החלופי של הבעלים (SAN) באישור של השרת. המצב הזה מונע מתוקפים להשתמש באישור תקף לדומיין אחר כדי להתחזות לשרת מסד הנתונים שלכם.
אם שם המארח לא תואם ל-CN או ל-SAN של האישור, החיבור ייכשל. צריך להגדיר פענוח DNS שיתאים לאישור או להשתמש במצב אבטחה אחר. כדאי להשתמש במצב הזה כדי למנוע התקפות של אדם באמצע (PITM).
המצב הצפנת נתונים ואימות CA בלבד. במצב הזה, כל הנתונים מוצפנים באמצעות TLS בפרוטוקול TCPS, והמערכת מאמתת שהאישור של השרת חתום על ידי רשות אישורים (CA) שהלקוח סומך עליה. עם זאת, במצב הזה לא מתבצע אימות של שם המארח של השרת. החיבור במצב הזה יצליח כל עוד האישור תקף והונפק על ידי רשות אישורים מהימנה, בלי קשר לשאלה אם שם המארח באישור תואם לשם המארח שאליו מתחברים.
כדאי להשתמש במצב הזה אם רוצים לוודא שמתחברים לשרת שהאישור שלו חתום על ידי רשות מהימנה שמנפיקה אישורים (CA), אבל אי אפשר לאמת את שם המארח או שאין לכם שליטה על הגדרת שם המארח.
המצב הצפנה בלבד. במצב הזה כל הנתונים שמועברים בין הלקוח לשרת מוצפנים. הוא לא מבצע אימות של אישורים או של שמות מארחים.
המצב הזה מספק רמת אבטחה מסוימת על ידי הגנה על נתונים במעבר, אבל הוא יכול להיות פגיע להתקפות PITM.
השתמשו במצב הזה אם אתם צריכים לוודא שכל הנתונים מוצפנים, אבל אתם לא יכולים או לא רוצים לאמת את זהות השרת. מומלץ להשתמש במצב הזה כשעובדים עם רשתות VPC פרטיות.
מצב ללא הצפנה או אימות. במצב הזה לא מתבצעת הצפנה של נתונים ואימות של אישורים או שמות מארחים. כל הנתונים נשלחים כטקסט פשוט.
לא מומלץ להשתמש במצב הזה בסביבה שבה מתבצע טיפול במידע אישי רגיש. מומלץ להשתמש במצב הזה רק למטרות בדיקה ברשת מבודדת שבה אין חשש לבעיות אבטחה.
אישור שרת מהימן (PEM)
אם אתם משתמשים במצב הצפנת נתונים ואימות של רשות אישורים ושם מארח או במצב הצפנת נתונים ואימות של רשות אישורים, אתם יכולים לספק גם אישור אחד או יותר בקידוד PEM. האישורים האלה נדרשים בתרחישים מסוימים שבהם שירות העברת הנתונים ל-BigQuery צריך לאמת את הזהות של שרת מסד הנתונים במהלך החיבור ל-TLS:
- אם אתם משתמשים באישור שחתום על ידי רשות אישורים פרטית בארגון שלכם או באישור עם חתימה עצמית, אתם צריכים לספק את שרשרת האישורים המלאה או את האישור היחיד עם החתימה העצמית. הפעולה הזו נדרשת לאישורים שהונפקו על ידי רשויות אישורים פנימיות של שירותי ספק שירותי ענן מנוהלים, כמו Amazon מסד נתונים רלציוני Service (RDS).
- אם האישור של שרת מסד הנתונים נחתם על ידי רשות אישורים ציבורית (לדוגמה, Let's Encrypt, DigiCert או GlobalSign), אין צורך לספק אישור. אישורי הבסיס של רשויות אישורים ציבוריות אלה מותקנים מראש ומהימנים על ידי שירות העברת הנתונים ל-BigQuery.
אפשר לציין אישורים בקידוד PEM בשדה Trusted PEM Certificate בהגדרות ההעברה, בהתאם לדרישות הבאות:
- האישור חייב להיות שרשרת אישורים תקינה בקידוד PEM.
- האישור חייב להיות נכון לחלוטין. אם חסרים אישורים בשרשרת או אם התוכן שגוי, חיבור ה-TLS ייכשל.
- לאישור יחיד, אתם יכולים לספק אישור יחיד עם חתימה עצמית משרת מסד הנתונים.
- אם מדובר בשרשרת אישורים מלאה שהונפקה על ידי רשות אישורים פרטית, צריך לספק את שרשרת האמון המלאה. הקובץ הזה כולל את האישור משרת מסד הנתונים וכל אישור CA ברמת ביניים וברמה הבסיסית.
העברות מלאות או מצטברות
כשמגדירים העברה מ-Microsoft SQL Server, אפשר לציין איך הנתונים ייטענו ל-BigQuery על ידי בחירה באפשרות מלאה או מצטברת בהעדפות הכתיבה בהגדרות ההעברה. העברות מצטברות נתמכות בגרסת טרום-השקה (Preview).
אתם יכולים להגדיר העברת נתונים מלאה כדי להעביר את כל הנתונים ממערכי הנתונים של Microsoft SQL Server בכל העברת נתונים.אפשר גם להגדיר העברת נתונים מצטברת (בגרסת Preview) כדי להעביר רק נתונים שהשתנו מאז העברת הנתונים האחרונה, במקום לטעון את כל מערך הנתונים בכל העברת נתונים. אם בוחרים באפשרות Incremental להעברת הנתונים, צריך לציין את מצבי הכתיבה Append או Upsert כדי להגדיר איך הנתונים ייכתבו ב-BigQuery במהלך העברת נתונים מצטברת. בקטעים הבאים מתוארים מצבי הכתיבה הזמינים.
הוספה למצב כתיבה
מצב הכתיבה "הוספה" מוסיף רק שורות חדשות לטבלת היעד. האפשרות הזו רק מוסיפה את הנתונים שהועברו בלי לבדוק אם יש רשומות קיימות, ולכן המצב הזה עלול לגרום לכפילות נתונים בטבלת היעד.
כשבוחרים במצב הוספה, צריך לבחור עמודת סימן מים. כדי שהמחבר של Microsoft SQL Server יעקוב אחרי השינויים בטבלת המקור, צריך עמודת סימן מים.
בהעברות מ-Microsoft SQL Server, מומלץ לבחור עמודה שמתעדכנת רק כשהרשומה נוצרת, ולא משתנה בעדכונים הבאים – לדוגמה, העמודהCREATED_AT.
מצב כתיבה של Upsert
במצב הכתיבה "עדכון או הוספה" (upsert), המערכת בודקת אם יש מפתח ראשי, ואז מעדכנת שורה או מוסיפה שורה חדשה בטבלת היעד. אתם יכולים לציין מפתח ראשי כדי שרכיב המחבר של Microsoft SQL Server יקבע אילו שינויים צריך לבצע כדי שטבלת היעדים תישאר מעודכנת בהתאם לטבלת המקור. אם המפתח הראשי שצוין נמצא בטבלה ב-BigQuery של היעד במהלך העברת נתונים, המחבר של Microsoft SQL Server מעדכן את השורה הזו בנתונים חדשים מטבלת המקור. אם אין מפתח ראשי במהלך העברת נתונים, המחבר של Microsoft SQL Server מוסיף שורה חדשה.
כשבוחרים במצב upsert, צריך לבחור עמודת סימן מים ומפתח ראשי:
- כדי שהמחבר של Microsoft SQL Server יעקוב אחרי שינויים בטבלת המקור, צריך עמודת סימן מים.
- בוחרים עמודת סימן מים שמתעדכנת בכל פעם ששורה משתנה. אנחנו ממליצים על עמודות שדומות לעמודה
UPDATED_ATאוLAST_MODIFIED.
- בוחרים עמודת סימן מים שמתעדכנת בכל פעם ששורה משתנה. אנחנו ממליצים על עמודות שדומות לעמודה
המפתח הראשי יכול להיות עמודה אחת או יותר בטבלה, שנדרשות למחבר של Microsoft SQL Server כדי לקבוע אם צריך להוסיף או לעדכן שורה.
בוחרים עמודות שמכילות ערכים שאינם null, שהם ייחודיים בכל שורות הטבלה. מומלץ להשתמש בעמודות שכוללות מזהים שנוצרו על ידי המערכת, קודי עזר ייחודיים (לדוגמה, מזהים עם הגדלה אוטומטית) או מזהי רצף מבוססי-זמן שלא ניתנים לשינוי.
כדי למנוע אובדן או פגיעה בנתונים, העמודות של המפתח הראשי שאתם בוחרים צריכות להכיל ערכים ייחודיים. אם אתם לא בטוחים שהערכים בעמודת המפתח הראשי שבחרתם הם ייחודיים, מומלץ להשתמש במצב הכתיבה append.
התנהגות של הטמעה מצטברת
כשמבצעים שינויים בסכימת הטבלה במקור הנתונים, העברות נתונים מצטברות מהטבלאות האלה משתקפות ב-BigQuery באופנים הבאים:
| שינויים במקור הנתונים | התנהגות של הטמעה מצטברת |
|---|---|
| הוספת עמודה חדשה | עמודה חדשה נוספת לטבלת היעד ב-BigQuery. כל הרשומות הקודמות בעמודה הזו יכילו ערכי null. |
| מחיקת עמודה | העמודה שנמחקה נשארת בטבלת היעד ב-BigQuery. רשומות חדשות בעמודה שנמחקה מאוכלסות בערכי null. |
| שינוי סוג הנתונים בעמודה | המחבר תומך רק ב
המרות של סוגי נתונים שנתמכות על ידי ALTER COLUMN הצהרת DDL.
כל המרה אחרת של סוג נתונים תגרום לכך שהעברת הנתונים תיכשל.
אם נתקלים בבעיות, מומלץ ליצור הגדרת העברה חדשה. |
| שינוי שם של עמודה | העמודה המקורית נשארת בטבלת היעד ב-BigQuery כמו שהיא, ועמודה חדשה מתווספת לטבלת היעד עם השם המעודכן. |
מיפוי סוגי נתונים
בטבלה הבאה מפורטים סוגי הנתונים ב-Microsoft SQL Server וסוגי הנתונים התואמים ב-BigQuery:
| סוג הנתונים של Microsoft SQL Server | סוג נתונים ב-BigQuery | סוג נתונים מעודכן ב-BigQuery |
|---|---|---|
tinyint |
INTEGER |
|
smallint |
INTEGER |
|
int |
INTEGER |
|
bigint |
BIGNUMERIC |
|
bit |
BOOLEAN |
|
decimal |
BIGNUMERIC |
|
numeric |
NUMERIC |
|
money |
BIGNUMERIC |
|
smallmoney |
BIGNUMERIC |
|
float |
FLOAT |
|
real |
FLOAT |
|
date |
DATE |
|
time |
TIME |
|
datetime2 |
TIMESTAMP |
DATETIME |
datetimeoffset |
TIMESTAMP |
|
datetime |
TIMESTAMP |
DATETIME |
smalldatetime |
TIMESTAMP |
DATETIME |
char |
STRING |
|
varchar |
STRING |
|
text |
STRING |
|
nchar |
STRING |
|
nvarchar |
STRING |
|
ntext |
STRING |
|
binary |
BYTES |
|
varbinary |
BYTES |
|
image |
BYTES |
|
geography |
STRING |
|
geometry |
STRING |
|
hierarchyid |
BYTES |
|
rowversion |
BYTES |
|
sql_variant |
BYTES |
|
uniqueidentifier |
STRING |
|
xml |
STRING |
|
json |
STRING |
|
vector |
STRING |
סוגי הנתונים json ו-vector נתמכים רק ב-Azure.
סוג הנתונים JSON נתמך במסדי נתונים של Azure SQL ובמכונות מנוהלות של Azure SQL שמוגדרות עם מדיניות העדכון "תמיד עדכני". סוג הנתונים JSON לא נתמך במופעים מנוהלים של Azure SQL שהוגדרו עם מדיניות העדכון של Microsoft SQL Server 2022.
Microsoft SQL Server מאחסן JSON כ-NVARCHAR(MAX) ולא כסוג JSON. מומלץ להשתמש ב-CHECK (ISJSON(json_col) = 1) לאימות וב-JSON_VALUE() לשליחת שאילתות.
ל-Microsoft SQL Server אין תמיכה בווקטורים לסוג הנתונים vector. מומלץ לאחסן וקטורים כמערכי JSON ב-NVARCHAR(MAX) ולהשתמש ב-JSON_VALUE() לחילוץ, עם חישובים ידניים של FLOAT לדמיון.
תמחור
בשלב התצוגה המקדימה של התכונה הזו, אין עלות להעברת נתונים מ-Microsoft SQL Server ל-BigQuery.