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

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

איך מתזמנים העברה מ-Oracle

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

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

הגדרת TLS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מצב כתיבה של Upsert

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

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

  • כדי לעקוב אחרי שינויים בטבלת המקור, צריך להוסיף עמודה של סימן מים למחבר 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, אפשר לעיין במאמר בנושא התמחור של שירות העברת נתונים.

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