סקירה כללית: העברת מחסני נתונים ל-BigQuery

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

הסברים על המונחים

אנחנו משתמשים במינוח הבא כשמדברים על העברה של מחסן נתונים:

תרחיש לדוגמה
תרחיש לדוגמה כולל את כל מערכי הנתונים, עיבוד הנתונים והאינטראקציות של המערכת והמשתמשים שנדרשים כדי להשיג ערך עסקי, כמו מעקב אחר נפחי המכירות של מוצר לאורך זמן. במחסני נתונים, תרחיש השימוש כולל בדרך כלל:
  • Data pipelines שמבצעים המרה של נתונים גולמיים ממקורות נתונים שונים, כמו מסד נתונים של מערכת לניהול קשרי לקוחות (CRM).
  • הנתונים שמאוחסנים במחסן הנתונים.
  • סקריפטים ופרוצדורות לעיבוד נוסף ולניתוח של הנתונים.
  • אפליקציה עסקית שקוראת את הנתונים או מבצעת פעולות שקשורות לנתונים.
עומס עבודה
קבוצה של תרחישי שימוש שמחוברים זה לזה ויש להם תלות משותפת. לדוגמה, לתרחיש שימוש יכולים להיות היחסים והתלות הבאים:
  • דוחות רכישות יכולים לעמוד בפני עצמם, והם שימושיים להבנת ההוצאות ולבקשת הנחות.
  • דיווח על מכירות יכול לעמוד בפני עצמו והוא שימושי לתכנון קמפיינים שיווקיים.
  • עם זאת, הדיווח על רווח והפסד תלוי ברכישות ובמכירות, והוא שימושי לקביעת הערך של החברה.
אפליקציה עסקית
מערכת שמשתמשי הקצה יוצרים איתה אינטראקציה – לדוגמה, דוח חזותי או מרכז בקרה. אפליקציה עסקית יכולה להיות גם פייפליין נתונים תפעולי או לולאת משוב. לדוגמה, אחרי שמחשבים או חוזים שינויים במחירי המוצרים, פייפליין נתונים תפעולי עשוי לעדכן את מחירי המוצרים החדשים במסד נתונים טרנזקציוני.
תהליך Upstream
מערכות המקור וצינורות הנתונים שמעלים נתונים למחסן הנתונים.
תהליך downstream
הסקריפטים, הפרוצדורות והאפליקציות העסקיות שמשמשים לעיבוד הנתונים במחסן הנתונים, להרצת שאילתות עליהם ולהצגתם בצורה ויזואלית.
העברה של Offload
אסטרטגיית מיגרציה שמטרתה להפעיל את תרחיש השימוש עבור משתמש הקצה בסביבה החדשה במהירות האפשרית, או לנצל את הקיבולת הנוספת שזמינה בסביבה החדשה. תרחישי שימוש מועברים על ידי הפעולות הבאות:
  • העתקה ואז סנכרון של הסכימה והנתונים ממחסן הנתונים מדור קודם.
  • העברת הסקריפטים, הפרוצדורות והאפליקציות העסקיות במורד הזרם.

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

העברה מלאה
גישה להעברה שדומה להעברה של נתונים לאחסון זמני, אבל במקום להעתיק את הסכימה והנתונים ואז לסנכרן אותם, מגדירים את ההעברה כך שהנתונים ייקלטו ישירות במחסן הנתונים החדש בענן ממערכות המקור במעלה הזרם. במילים אחרות, גם צינורות הנתונים שנדרשים לתרחיש השימוש מועברים.
מחסן נתונים ארגוני (EDW)
מחסן נתונים שלא כולל רק מסד נתונים אנליטי, אלא גם רכיבים ונהלים אנליטיים קריטיים. הם כוללים צינורות להעברת נתונים, שאילתות ואפליקציות עסקיות שנדרשים כדי לעמוד בעומסי העבודה של הארגון.
מחסן נתונים בענן (CDW)
מחסן נתונים (data warehouse) עם מאפיינים דומים לאלה של EDW, אבל הוא פועל בשירות שמנוהל במלואו בענן – במקרה הזה, BigQuery.
פייפליין
תהליך שמקשר בין מערכות נתונים באמצעות סדרה של פונקציות ומשימות שמבצעות סוגים שונים של טרנספורמציות נתונים. לפרטים נוספים, אפשר לעיין במאמר בנושא מהו פייפליין? בסדרה הזו.

למה כדאי לעבור ל-BigQuery?

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

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

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

לעתים קרובות, רעיונות חדשניים מתעכבים בגלל הגודל והמורכבות של מחלקת ה-IT שמיישמת ומתחזקת את מחסני הנתונים המסורתיים האלה. יכולות לעבור שנים עד שיוצרים ארכיטקטורה של מחסן נתונים (data warehouse) שניתנת להתאמה, עם זמינות גבוהה ומאובטחת. ‫BigQuery מציע טכנולוגיה מתקדמת של תוכנה כשירות (SaaS) שאפשר להשתמש בה לפעולות של מחסן נתונים ללא שרת. כך תוכלו להתמקד בקידום העסק העיקרי שלכם ולהעביר את האחריות לתחזוקת התשתית ולפיתוח הפלטפורמה אל Google Cloud.

‫BigQuery מאפשר גישה לאחסון, לעיבוד ולניתוח של נתונים מובנים, והוא ניתן להתאמה, גמיש וחסכוני. המאפיינים האלה חיוניים כשנפחי הנתונים גדלים באופן אקספוננציאלי – כדי להקצות משאבי אחסון ועיבוד לפי הצורך, וגם כדי להפיק ערך מהנתונים האלה. בנוסף, לארגונים שרק מתחילים להשתמש בניתוח Big Data ובלמידת מכונה, ורוצים להימנע מהמורכבות הפוטנציאלית של מערכות Big Data מקומיות,‏ BigQuery מציע דרך של תשלום לפי שימוש להתנסות בשירותים מנוהלים.

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

מה מעבירים ואיך מעבירים: מסגרת ההעברה

ביצוע מיגרציה יכול להיות תהליך מורכב וארוך. לכן, מומלץ להשתמש במסגרת לארגון ולבנייה של עבודת ההעברה בשלבים:

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

הכנה וגילוי

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

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

תהליך שלב הגילוי כולל את המשימות הבאות:

  1. בדיקת הצעת הערך של BigQuery והשוואה שלה לזו של מחסן הנתונים מדור קודם.
  2. ביצוע ניתוח ראשוני של עלות הבעלות הכוללת (TCO).
  3. מגדירים אילו תרחישי שימוש מושפעים מההעברה.
  4. כדי לזהות יחסי תלות, צריך ליצור מודל של המאפיינים של מערכי הנתונים וצינורות הנתונים הבסיסיים שרוצים להעביר.

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

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

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

מחסן נתונים מדור קודם, שבו מוצגים מקורות נתונים (מכירות, שיווק, ייצור, תקצוב וכו') שמוזנים למחסן הנתונים. דוחות ומרכזי בקרה של BI הם תהליכים במורד הזרם.

תוכנית

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

  1. קטלוג ותעדוף של תרחישי שימוש

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

  2. הגדרת מדדי הצלחה

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

  3. יצירת הגדרה של 'סיום'

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

  4. עיצוב והצעה של הוכחת היתכנות (POC), מצב לטווח קצר ומצב סופי אידיאלי

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

  5. יצירת אומדנים של זמן ועלות

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

  6. זיהוי שותף להעברה ויצירת קשר איתו

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

העברה באמצעות גישה איטרטיבית

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

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

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

תרחיש השימוש המתאים יכול להיות:

  • הזנת הנתונים ממסד נתונים טרנזקציוני שבו מאוחסנים מוצרים ומחירים.
  • המרת הנתונים לסדרת זמן אחת לכל מוצר והזנת ערכים חסרים.
  • אחסון התוצאות בטבלה אחת או יותר במחסן הנתונים.
  • התוצאות זמינות דרך קובץ notebook של Python (האפליקציה העסקית).

הערך העסקי של תרחיש השימוש הזה הוא תמיכה בניתוח תמחור.

כמו ברוב התרחישים לדוגמה, התרחיש הזה כנראה יתמוך בכמה סיפורי משתמשים.

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

קביעת סדר עדיפויות לתרחישי שימוש

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

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

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

גישה: ניצול הזדמנויות קיימות

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

הנה כמה שאלות לדוגמה שיעזרו לכם לזהות אילו תרחישי שימוש כדאי לתת להם עדיפות:

  • האם תרחיש השימוש כולל מערכי נתונים או צינורות נתונים שמוגבלים כרגע על ידי Enterprise Data Warehouse מדור קודם?
  • האם מחסן הנתונים הארגוני הקיים שלכם דורש רענון חומרה, או שאתם צופים צורך בהרחבת החומרה? אם כן, כדאי להעביר את תרחישי השימוש ל-BigQuery מוקדם ככל האפשר.

זיהוי הזדמנויות להעברה יכול ליצור הצלחות מהירות שיובילו ליתרונות מוחשיים ומיידיים למשתמשים ולעסק.

גישה: העברת עומסי עבודה אנליטיים קודם

כדאי להעביר עומסי עבודה (workloads) של עיבוד אנליטי אונליין (OLAP) לפני עומסי עבודה של עיבוד טרנזקציות אונליין (OLTP). מחסן נתונים הוא לרוב המקום היחיד בארגון שבו אפשר למצוא את כל הנתונים ליצירת תצוגה גלובלית יחידה של הפעולות בארגון. לכן, נפוץ בארגונים שיהיו צינורות נתונים מסוימים שמזינים נתונים בחזרה למערכות העסקאות כדי לעדכן את הסטטוס או להפעיל תהליכים – למשל, כדי לקנות עוד מלאי כשמלאי המוצרים נמוך. עומסי עבודה של OLTP הם בדרך כלל מורכבים יותר, ויש להם דרישות תפעוליות מחמירות יותר והסכמי רמת שירות (SLA) מחמירים יותר מעומסי עבודה של OLAP. לכן, בדרך כלל קל יותר להעביר קודם עומסי עבודה של OLAP.

גישה: התמקדות בחוויית המשתמש

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

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

בנוסף, תוכלו לשפר את חוויית המשתמש באמצעות ניתוח נתונים חיזויים וניתוח נתונים שמציע המלצות. לשם כך, אפשר להשתמש ב-BigQuery ML, ב-Vertex AI AutoML tabular או במודלים שאומנו מראש של Google לניתוח תמונות, ניתוח סרטונים, זיהוי דיבור, שפה טבעית ותרגום. אפשר גם להשתמש ב-Vertex AI כדי להפעיל את המודל שאומן בהתאמה אישית, בתרחישי שימוש שמותאמים לצרכים העסקיים שלכם. לדוגמה:

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

יש מספר שאלות שאנשי ה-IT יכולים לשאול כדי להעריך אילו תרחישי שימוש הם הכי פחות מסוכנים להעברה, ולכן הכי כדאי להעביר אותם בשלבים הראשונים של ההעברה. לדוגמה:

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

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

ביצוע

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

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

העברה בדרך כלל כוללת את השלבים הבאים:

תהליך ההעברה כולל שבעה שלבים.

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

1. הגדרה ומשילות מידע (data governance)

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

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

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

2. העברת סכימה ונתונים

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

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

3. תרגום שאילתות

אפשר להשתמש בתרגום SQL באצווה כדי להעביר את קוד ה-SQL בכמות גדולה, או בתרגום SQL אינטראקטיבי כדי לתרגם שאילתות אד-הוק.

חלק ממחסני הנתונים מדור קודם כוללים הרחבות לתקן SQL כדי להפעיל פונקציונליות למוצר שלהם. ‫BigQuery לא תומך בתוספים הקנייניים האלה, אלא תואם לתקן ANSI/ISO SQL:2011. המשמעות היא שעדיין יכול להיות שיהיה צורך לבצע שינויים ידניים בחלק מהשאילתות, אם מתרגמי ה-SQL לא יכולים לפרש אותן.

4. העברה של אפליקציות עסקיות

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

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

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

5. העברת צינורות נתונים

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

6. אופטימיזציה של הביצועים

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

7. אימות ואישור

בסוף כל איטרציה, מאמתים שההעברה של תרחיש השימוש הצליחה על ידי בדיקה של הדברים הבאים:

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

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

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

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

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

סיכום מאמץ ההעברה

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

סיכום של תהליך המיגרציה.

בהנחה שאתם רוצים לבצע מיגרציה מלאה ממחסן הנתונים ל-BigQuery, המצב הסופי של המיגרציה ייראה כך:

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

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