מבוא להעברות נתונים מ-Oracle

אתם יכולים לטעון נתונים ממסד הנתונים של Oracle ל-BigQuery באמצעות המחבר של שירות העברת הנתונים ל-BigQuery ל-Oracle. במאמר הזה מפורטות אפשרויות ההגדרה של העברת Oracle, ומידע על מיפוי סוגי נתונים והעברת מטא-נתונים.

איך טוענים נתוני Oracle ל-BigQuery

אפשרויות להטמעת נתונים

בקטעים הבאים מוסבר בהרחבה על האפשרויות להטמעת נתונים כשמגדירים העברת נתונים מ-Oracle.

הגדרת TLS

המחבר של Oracle תומך בהגדרה של אבטחת שכבת התעבורה (TLS) כדי להצפין את העברות הנתונים ל-BigQuery. מחבר Oracle תומך בהגדרות ה-TLS הבאות:

• המצב הצפנת נתונים ואימות של רשות האישורים ושם המארח. במצב הזה מתבצע אימות מלא של השרת באמצעות TLS בפרוטוקול TCPS. הוא מצפין את כל הנתונים במעבר ומאמת שהאישור של שרת מסד הנתונים נחתם על ידי רשות אישורים (CA) מהימנה. במצב הזה גם נבדק אם שם המארח שאליו אתם מתחברים תואם בדיוק לשם הנפוץ (CN) או לשם החלופי של הבעלים (SAN) באישור של השרת. המצב הזה מונע מתוקפים להשתמש באישור תקף של דומיין אחר כדי להתחזות לשרת של מסד הנתונים.

  אם שם המארח לא תואם ל-CN או ל-SAN של האישור, החיבור ייכשל. צריך להגדיר פתרון DNS שתואם לאישור או להשתמש במצב אבטחה אחר. השתמשו במצב הזה כדי לקבל את האפשרות הכי מאובטחת למניעת מתקפות מסוג 'אדם באמצע' (PITM).

• מצב הצפנת נתונים ואימות CA בלבד. במצב הזה, כל הנתונים מוצפנים באמצעות TLS על גבי פרוטוקול TCPS, ונבדק אם האישור של השרת נחתם על ידי רשות אישורים שהלקוח סומך עליה. עם זאת, במצב הזה לא מתבצעת אימות של שם המארח של השרת. במצב הזה, החיבור יצליח כל עוד האישור תקף והונפק על ידי רשות אישורים מהימנה, גם אם שם המארח באישור לא תואם לשם המארח שאליו אתם מתחברים.

  כדאי להשתמש במצב הזה אם רוצים לוודא שמתחברים לשרת שהאישור שלו חתום על ידי רשות מהימנה שמנפיקה אישורים (CA), אבל אי אפשר לאמת את שם המארח או שאין לכם שליטה על הגדרת שם המארח.

• המצב הצפנה בלבד. במצב הזה, כל הנתונים שמועברים בין הלקוח לשרת מוצפנים באמצעות Native Network Encryption של Oracle דרך יציאת ה-TCP הרגילה. הוא לא מבצע אימות של אישורים או של שמות מארחים.

  המצב הזה מספק רמת אבטחה מסוימת על ידי הגנה על נתונים במעבר, אבל הוא יכול להיות פגיע להתקפות PITM.

  השתמשו במצב הזה אם אתם צריכים לוודא שכל הנתונים מוצפנים, אבל אתם לא יכולים או לא רוצים לאמת את זהות השרת. מומלץ להשתמש במצב הזה כשעובדים עם רשתות VPC פרטיות.

• המצב ללא הצפנה או אימות. במצב הזה לא מתבצעת הצפנה של נתונים ולא מתבצע אימות של אישורים או של שמות מארחים. כל הנתונים נשלחים כטקסט פשוט.

  לא מומלץ להשתמש במצב הזה בסביבה שבה מטפלים במידע אישי רגיש. אנחנו ממליצים להשתמש במצב הזה רק למטרות בדיקה ברשת מבודדת שבה אין חשש לאבטחה.

אישור שרת מהימן (PEM)

אם אתם משתמשים במצב הצפנת נתונים ואימות של רשות האישורים ושם המארח או במצב הצפנת נתונים ואימות של רשות האישורים, אתם יכולים גם לספק אישור אחד או יותר בקידוד PEM. האישורים האלה נדרשים בתרחישים מסוימים שבהם שירות העברת הנתונים ל-BigQuery צריך לאמת את הזהות של שרת מסד הנתונים במהלך החיבור ל-TLS:

• אם אתם משתמשים באישור שחתום על ידי רשות אישורים (CA) פרטית בארגון שלכם או באישור עם חתימה עצמית, אתם צריכים לספק את שרשרת האישורים המלאה או את האישור היחיד עם החתימה העצמית. הדרישה הזו חלה על אישורים שהונפקו על ידי רשויות אישורים פנימיות של שירותי ספקי ענן מנוהלים, כמו Amazon Relational Database Service‏ (RDS).
• אם האישור של שרת מסד הנתונים שלכם חתום על ידי רשות אישורים ציבורית (לדוגמה, Let's Encrypt,‏ DigiCert או GlobalSign), אתם לא צריכים לספק אישור. אישורי הבסיס של רשויות האישורים הציבוריות האלה מותקנים מראש ומהימנים על ידי שירות העברת הנתונים ל-BigQuery.

אפשר לציין אישורים בקידוד PEM בשדה Trusted PEM Certificate בהגדרות ההעברה, בהתאם לדרישות הבאות:

• האישור חייב להיות שרשרת אישורים תקינה בקידוד PEM.
• האישור חייב להיות נכון לחלוטין. אם חסרים אישורים בשרשרת או אם התוכן שגוי, חיבור ה-TLS ייכשל.
• לאישור יחיד, אתם יכולים לספק אישור יחיד בחתימה עצמית משרת מסד הנתונים.
• כדי לקבל שרשרת אישורים מלאה שהונפקה על ידי רשות אישורים פרטית, צריך לספק את שרשרת האמון המלאה. הקובץ כולל את האישור משרת מסד הנתונים ואת כל אישורי הביניים והאישורים הבסיסיים של רשות האישורים (CA).

העברות מלאות או מצטברות

אתם יכולים לציין איך הנתונים נטענים ל-BigQuery על ידי בחירה באפשרות מלאה או מצטברת בהעדפות הכתיבה בהגדרות ההעברה כשמגדירים העברה מ-Oracle. העברות מצטברות נתמכות בתצוגה מקדימה.

אתם יכולים להגדיר העברת נתונים מלאה כדי להעביר את כל הנתונים ממערכי הנתונים של Oracle בכל העברת נתונים.

לחלופין, אתם יכולים להגדיר העברת נתונים מצטברת (תצוגה מקדימה) כדי להעביר רק את הנתונים שהשתנו מאז העברת הנתונים האחרונה, במקום לטעון את כל מערך הנתונים בכל העברת נתונים. אם בוחרים באפשרות Incremental להעברת הנתונים, צריך לציין את מצבי הכתיבה Append או Upsert כדי להגדיר איך הנתונים ייכתבו ב-BigQuery במהלך העברת נתונים מצטברת. בקטעים הבאים מתוארים מצבי הכתיבה הזמינים.

מצב כתיבה של הוספה

מצב הכתיבה "הוספה" מוסיף רק שורות חדשות לטבלת היעד. האפשרות הזו מוסיפה את הנתונים שהועברו בלי לבדוק אם יש רשומות קיימות, ולכן המצב הזה עלול לגרום לשכפול נתונים בטבלת היעד.

כשבוחרים במצב הוספה, צריך לבחור עמודת סימן מים. כדי שהמחבר של Oracle יוכל לעקוב אחרי שינויים בטבלת המקור, צריך עמודת סימן מים.

בהעברות מ-Oracle, מומלץ לבחור עמודה שמתעדכנת רק כשהרשומה נוצרת, ולא משתנה בעדכונים הבאים – לדוגמה, העמודה CREATED_AT.

מצב כתיבה של Upsert

במצב הכתיבה upsert, המערכת מעדכנת שורה או מוסיפה שורה חדשה בטבלת היעד על ידי בדיקה של מפתח ראשי. אתם יכולים לציין מפתח ראשי כדי לאפשר למחבר של Oracle לקבוע אילו שינויים נדרשים כדי שהטבלה ביעד תהיה מעודכנת בהתאם לטבלה במקור. אם המפתח הראשי שצוין קיים בטבלה ב-BigQuery במהלך העברת נתונים, המחבר של Oracle מעדכן את השורה הזו עם נתונים חדשים מטבלת המקור. אם אין מפתח ראשי במהלך העברת נתונים, המחבר של Oracle מוסיף שורה חדשה.

כשבוחרים במצב "עדכון או הוספה", צריך לבחור עמודת סימן מים ומפתח ראשי:

• כדי שהמחבר של Oracle יוכל לעקוב אחרי שינויים בטבלת המקור, צריך להוסיף עמודת סימן מים.
  • בוחרים עמודת סימן מים שמתעדכנת בכל פעם ששורה משתנה. אנחנו ממליצים על עמודות שדומות לעמודה UPDATED_AT או LAST_MODIFIED.

• המפתח הראשי יכול להיות עמודה אחת או יותר בטבלה שנדרשות למחבר Oracle כדי לקבוע אם צריך להוסיף או לעדכן שורה.

  בוחרים עמודות שמכילות ערכים לא ריקים שהם ייחודיים בכל השורות של הטבלה. מומלץ להשתמש בעמודות שכוללות מזהים שנוצרו על ידי המערכת, קודי עזר ייחודיים (לדוגמה, מזהים עם הגדלה אוטומטית) או מזהי רצף מבוססי-זמן שלא ניתנים לשינוי.

  כדי למנוע אובדן או פגיעה בנתונים, העמודות של המפתח הראשי שאתם בוחרים צריכות להכיל ערכים ייחודיים. אם יש לכם ספק לגבי הייחודיות של עמודת המפתח הראשי שבחרתם, מומלץ להשתמש במקום זאת במצב כתיבה של הוספה.

התנהגות של הוספה מצטברת

כשמבצעים שינויים בסכימת הטבלה במקור הנתונים, העברות נתונים מצטברות מהטבלאות האלה משתקפות ב-BigQuery באופנים הבאים:

שינויים במקור הנתונים	התנהגות של הוספה מצטברת
הוספת עמודה חדשה	עמודה חדשה נוספת לטבלת היעד ב-BigQuery. כל הרשומות הקודמות בעמודה הזו יקבלו ערכי null.
מחיקת עמודה	העמודה שנמחקה נשארת בטבלת היעד ב-BigQuery. ערכים חדשים בעמודה שנמחקה יאוכלסו בערכי null.
שינוי סוג הנתונים בעמודה	המחבר תומך רק ב המרות של סוגי נתונים שנתמכות על ידי הצהרת ה-DDL‏ ALTER COLUMN. המרות של סוגי נתונים אחרים גורמות לכך שהעברת הנתונים תיכשל. אם נתקלים בבעיות, מומלץ ליצור הגדרת העברה חדשה.
שינוי שם של עמודה	העמודה המקורית נשארת בטבלת היעד ב-BigQuery כמו שהיא, ועמודה חדשה מתווספת לטבלת היעד עם השם המעודכן.

מיפוי סוגי נתונים

בטבלה הבאה מפורט מיפוי של סוגי נתונים ב-Oracle לסוגי הנתונים התואמים ב-BigQuery:

סוג הנתונים של Oracle	סוג נתונים ב-BigQuery
BFILE	BYTES
BINARY_DOUBLE	FLOAT
BINARY_FLOAT	FLOAT
BLOB	BYTES
CHAR	STRING
CLOB	STRING
DATE	DATETIME
FLOAT	FLOAT
INTERVAL DAY TO SECOND	STRING
INTERVAL YEAR TO MONTH	STRING
LONG	STRING
LONG RAW	BYTES
NCHAR	STRING
NCLOB	STRING
NUMBER (without precision and scale)	STRING
NUMBER (with precision and scale lower than the BigQuery Numeric range)	NUMERIC
NUMBER (with precision and scale lower than the BigQuery BigNumeric range)	BIGNUMERIC
NUMBER (with precision and scale greater than the BigQuery BigNumeric range)	STRING
NVARCHAR2	STRING
RAW	BYTES
ROWID	STRING
TIMESTAMP	DATETIME
TIMESTAMP WITH LOCAL TIME ZONE	DATETIME
TIMESTAMP WITH TIME ZONE	TIMESTAMP
UROWID	STRING
VARCHAR	STRING
VARCHAR2	STRING

העברת מטא-נתונים

אפשר גם להשתמש במחבר Oracle כדי להעביר מטא-נתונים אל Knowledge Catalog. מידע נוסף זמין במאמר טעינת מטא-נתונים של Oracle ל-Knowledge Catalog.

תמחור

למידע על התמחור של העברות Oracle, אפשר לעיין במאמר בנושא התמחור של שירות העברת נתונים.

המאמרים הבאים

• מידע נוסף על הגדרת העברה מ-Oracle
• מידע נוסף על שירות העברת הנתונים ל-BigQuery