העברת פייפליינים

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

מה זה פייפליין?

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

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

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

מתי להעביר את צינורות עיבוד הנתונים

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

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

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

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

במהלך איטרציה, אתם יכולים לבחור באחת מהאפשרויות הבאות:

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

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

איך מעבירים את צינורות עיבוד הנתונים

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

הליכים ודפוסים של פייפליינים

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

חילוץ, טרנספורמציה וטעינה (ETL)

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

בתרשים הבא מוצג תהליך ETL אופייני.

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

איור 1. תהליך ETL אופייני.

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

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

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

כלי תזמור (DAG) שמנהל שני תהליכי ETL (תת-DAG)

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

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

חילוץ, טעינה וטרנספורמציה (ELT)

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

בתרשים הבא מוצג תהליך ELT אופייני.

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

איור 3. הליך ELT אופייני.

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

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

חילוץ וטעינה (EL)

אפשר להשתמש בתהליך החילוץ והטעינה (EL) בפני עצמו, או להוסיף לו טרנספורמציות, ואז הוא הופך ל-ELT. הזכרנו את EL בנפרד כי יש כמה שירותים אוטומטיים שמבצעים את המשימה הזו, כך שלא תצטרכו ליצור צינור עיבוד נתונים משלכם להטמעת נתונים. למידע נוסף, קראו את המאמר מהו שירות העברת נתונים ל-BigQuery?.

סימון נתונים שהשתנו (CDC)

סימון נתונים שהשתנו (CDC) הוא אחת מכמה תבניות עיצוב של תוכנה שמשמשות למעקב אחרי שינויים בנתונים. הוא משמש לעיתים קרובות במחסני נתונים, כי מחסן הנתונים משמש לאיסוף ולמעקב אחרי נתונים והשינויים שלהם ממערכות מקור שונות לאורך זמן.

בתרשים הבא מוצגת דוגמה לאופן שבו CDC פועל עם ELT.

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

איור 4. איך CDC עובד עם ELT.

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

כדי לבצע את החלק של ה-EL, אתם יכולים לעבד את יומני מסד הנתונים באמצעות תוכנת CDC כמו Datastream או כלים בקוד פתוח כמו Debezium, ולכתוב את הרשומות ב-BigQuery באמצעות Dataflow. לאחר מכן תוכלו להשתמש בשאילתת SQL כדי לקבוע מהי הגרסה העדכנית לפני שתבצעו טרנספורמציות נוספות. הנה דוגמה:

WITH ranked AS (
  SELECT
    *,
    ROW_NUMBER() OVER (
      PARTITION BY RECORD KEY
      ORDER BY EVENT TIMESTAMP DESC
    ) AS rank
  FROM TABLE NAME
)
SELECT *
FROM ranked
WHERE rank = 1

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

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

לולאות משוב עם פייפליינים תפעוליים

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

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

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

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

איור 5. תבנית לפייפליין של נתונים תפעוליים.

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

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

מערכת PCM שמזינה מערכת ETL.

איור 6. פייפליין נתונים תפעולי שכותב את מחירי המוצרים במערכת PCM.

פייפליין תפעולי הוא סוג של תהליך במורד הזרם, ואילו פייפליינים שמטמיעים ETL,‏ ELT או CDC הם תהליכים במעלה הזרם. עם זאת, יכולה להיות חפיפה בין הכלים שמשמשים להטמעה של שתי השיטות. לדוגמה, אתם יכולים להשתמש ב-Dataflow כדי להגדיר ולהריץ את כל ה-DAGs של עיבוד הנתונים, ב-GoogleSQL כדי להגדיר טרנספורמציות שפועלות ב-BigQuery, וב-Managed Service for Apache Airflow כדי לתזמר את זרימת הנתונים מקצה לקצה.

בחירת גישה להעברה

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

הפניית צינורות עיבוד נתונים לכתיבה ב-BigQuery

במקרים הבאים, כדאי לבדוק אם הטכנולוגיה שבה אתם משתמשים מציעה כיור מובנה של BigQuery (מחבר כתיבה):

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

ספקי תוכנה עצמאיים (ISV) מציעים טכנולוגיות לעיבוד נתונים עם מחברים ל-BigQuery, כולל:

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

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

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

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

פונקציונלי

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

לא פונקציונלי

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

הפניה אוטומטית של פייפליינים באמצעות קבצים ככלי ביניים

אם טכנולוגיית הפייפליין המקומית הקיימת לא תומכת ב-Google APIs, או אם אתם מוגבלים בשימוש ב-Google APIs, אתם יכולים להשתמש בקבצים כאמצעי ביניים להעברת הנתונים ל-BigQuery.

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

השלב האחרון הוא לטעון את הנתונים מ-Cloud Storage ל-BigQuery, לפי ההנחיות שבמאמר טעינת נתונים באצווה.

בתרשים הבא מוצגת הגישה שמתוארת בקטע הזה.

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

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

כדי לתזמר את צינור עיבוד הנתונים של ה-ETL, צריך לבצע שני שלבים נפרדים:

  1. משתמשים מחדש בתזמור הצינורות המקומי הקיים כדי לכתוב את הנתונים שעברו טרנספורמציה במערכת הקבצים. אפשר להרחיב את התזמור הזה כדי להעתיק את הקבצים ממערכת הקבצים המקומית ל-Cloud Storage, או ליצור סקריפט נוסף שפועל באופן קבוע כדי לבצע את שלב ההעתקה.
  2. כשהנתונים נמצאים ב-Cloud Storage, משתמשים בהעברה מ-Cloud Storage כדי לתזמן טעינות חוזרות מ-Cloud Storage ל-BigQuery. חלופות להעברות של Cloud Storage הן טריגרים של Cloud Storage ו-Managed Airflow.

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

העברת צינורות עיבוד נתונים קיימים של ELT ל-BigQuery

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

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

אם מקורות הנתונים שלכם נתמכים על ידי שירות העברת הנתונים ל-BigQuery (DTS) ישירות או באמצעות שילובים עם צד שלישי, אתם יכולים להשתמש ב-DTS כדי להחליף את צינור עיבוד הנתונים של ה-EL.

העברת צינורות נתונים קיימים של OSS ל-Managed Service for Apache Spark

כשמעבירים את פייפליין הנתונים ל- Google Cloud, יכול להיות שתרצו להעביר כמה משימות מדור קודם שנכתבו באמצעות מסגרת תוכנה בקוד פתוח כמו Apache Hadoop,‏ Apache Spark או Apache Flink.

Managed Service for Apache Spark מאפשר לפרוס אשכולות Hadoop ו-Spark מהירים, קלים לשימוש ומנוהלים באופן מלא, בצורה פשוטה וחסכונית. ‫Managed Service for Apache Spark משתלב עם המחבר ל-BigQuery, ספריית Java שמאפשרת ל-Hadoop ול-Spark לכתוב נתונים ישירות ל-BigQuery באמצעות גרסאות מופשטות של המחלקות InputFormat ו-OutputFormat של Apache Hadoop.

ב-Managed Service for Apache Spark קל ליצור ולמחוק אשכולות, כך שבמקום להשתמש באשכול מונוליתי אחד, אתם יכולים להשתמש בהרבה אשכולות זמניים. לגישה הזו יש כמה יתרונות:

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

כשאתם מעבירים את המשימות, מומלץ להשתמש בגישה הדרגתית. העברה הדרגתית מאפשרת לכם:

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

כשמעבירים את משימות Hadoop ו-Spark הקיימות ל-Managed Service for Apache Spark, אפשר לבדוק אם יחסי התלות של המשימות נכללים בגרסאות הנתמכות של Managed Service for Apache Spark. אם אתם צריכים להתקין תוכנה בהתאמה אישית, תוכלו ליצור קובץ אימג' משלכם ל-Managed Service for Apache Spark, להשתמש בחלק מפעולות האתחול הזמינות (לדוגמה, ל-Apache Flink), לכתוב פעולת אתחול משלכם או לציין דרישות לחבילת Python בהתאמה אישית.

כדי להתחיל, קראו את המדריכים למתחילים של Managed Service for Apache Spark ואת דוגמאות הקוד של המחבר ל-BigQuery.

אירוח מחדש של צינורות עיבוד נתונים של צד שלישי להרצה ב- Google Cloud

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

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

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

באופן כללי, יש כמה דרכים להפעיל תוכנת צד שלישי ב- Google Cloud, מהפשוטה ביותר למורכבת ביותר:

  • ספק התוכנה שלכם משתף פעולה עם Google Cloud כדי להציע את התוכנה שלו ב-Google Cloud Marketplace.
  • ספק תוכנת צד שלישי יכול לפעול ב-Kubernetes.
  • תוכנת הצד השלישי פועלת במכונה וירטואלית (VM) אחת או יותר.

אם תוכנת הצד השלישי שלכם מספקת פתרון של Cloud Marketplace, העבודה כוללת את הפעולות הבאות:

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

אם הספק לא מציע פתרון ב-Cloud Marketplace, אבל המוצר שלו יכול לפעול ב-Kubernetes, אתם יכולים להשתמש ב-Google Kubernetes Engine (GKE) כדי לארח את צינורות עיבוד הנתונים. העבודה כוללת את השלבים הבאים:

  • יוצרים אשכול GKE לפי ההמלצות של הספק, כדי לוודא שהמוצר של הצד השלישי יכול לנצל את מקביליות המשימות ש-Kubernetes מציע.
  • מתקינים את תוכנת הצד השלישי באשכול GKE לפי ההמלצות של הספק.
  • בוחרים את תרחישי השימוש ומעבירים אותם לפי הגישה האיטרטיבית שמוסברת במאמר העברת מחסני נתונים ל-BigQuery: סקירה כללית.

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

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

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

מספר קלטים מועברים ל-Pub/Sub, שיוצר נושאים. הנושאים נקראים על ידי קבוצות MIG שונות.

איור 9. קבוצת מופעי מכונה מנוהלים (MIG) עם שלוש מכונות וירטואליות.

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

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

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

כתיבה מחדש של צינורות עיבוד נתונים כדי להשתמש בשירותים שמנוהלים על ידי Google Cloud

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

בקטעים הבאים מוצגים שירותים מנוהלים במלואם של Google Cloud , שמאפשרים לבצע טרנספורמציות מתקדמות של נתונים בקנה מידה נרחב: Cloud Data Fusion ו-Dataflow.

Cloud Data Fusion

‫Cloud Data Fusion, שמבוסס על פרויקט CDAP בקוד פתוח, הוא שירות מנוהל לשילוב נתונים שמאפשר ליצור ולנהל צינורות עיבוד נתונים באמצעות ממשק גרפי.

כדי לפתח את פייפליינים של נתונים בממשק המשתמש של Cloud Data Fusion, מחברים מקורות לטרנספורמציות, ל-sink ולצמתים אחרים כדי ליצור DAG. כשפורסים את פייפליין הנתונים, המתכנן של Cloud Data Fusion הופך את ה-DAG הזה לסדרה של חישובים מקבילים שיבוצעו כמשימת Apache Spark ב-Managed Service for Apache Spark.

כשמשתמשים ב-Cloud Data Fusion, אפשר להתחבר למסד נתונים של מערכת מקור באמצעות מנהלי התקנים של Java Database Connectivity ‏ (JDBC) כדי לקרוא נתונים, לשנות אותם ולטעון אותם ליעד לבחירתכם (לדוגמה, BigQuery), בלי לכתוב קוד. כדי לעשות את זה, צריך להעלות מנהל התקן JDBC למכונה של Cloud Data Fusion ולהגדיר אותו כך שתוכלו להשתמש בו בפייפליינים של נתונים. למידע נוסף, קראו את המדריך שימוש במנהלי התקנים של JDBC עם Cloud Data Fusion.

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

באמצעות פייפליינים ב-Cloud Data Fusion, אתם יכולים ליצור פייפליינים באצווה ובסטרימינג. בנוסף, באמצעות מתן גישה ליומנים ולמדדים, צינורות עיבוד הנתונים מאפשרים לאדמינים להפעיל את תהליכי העבודה של עיבוד הנתונים בלי צורך בכלים מותאמים אישית.

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

Dataflow

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

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

אפשר לשלוח משימות Dataflow בדרכים שונות, דרך ממשק שורת הפקודה, Java SDK או Python SDK. בנוסף, אנחנו מפתחים מסגרת ניידות כדי לאפשר יכולת פעולה הדדית מלאה בין כל ערכות ה-SDK ומנהלי הריצה.

אם אתם רוצים להעביר את צינורות עיבוד הנתונים והשאילתות שלכם ממסגרות אחרות ל-Apache Beam ול-Dataflow, קראו על מודל התכנות של Apache Beam ועיינו במסמכי התיעוד הרשמיים של Dataflow.

דוגמאות מעשיות מופיעות במדריכים למתחילים ובמדריכים של Dataflow.

תזמור ותזמון

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

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

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

יחסי תלות

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

כמה צינורות עיבוד נתונים שמסומנים באותיות A,‏ B ו-C מתכנסים לצינור עיבוד נתונים D. צינור עיבוד נתונים D מתפצל לצינורות עיבוד נתונים E,‏ F ו-G. כל התהליך הזה מנוהל על ידי DAG של תזמור.

איור 10. שילוב של יחסי תלות מסוג Fan-in ו-Fan-out.

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

בצינור עיבוד נתונים א' יש תקלה. צינורות עיבוד הנתונים B ו-C תלויים בפלט של צינור עיבוד הנתונים A, ולכן גם הם נכשלים.

איור 11. כשלים שמתפשטים לאורך פייפליין מונעים את ההפעלה של פייפליינים תלויים.

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

העבודה שנדרשת להעברה

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

מומלץ לבצע אופטימיזציה של יחסי התלות באופן הדרגתי, באופן הבא:

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

בקטע הבא נסביר את השיטה הזו באמצעות דוגמה מעשית.

דוגמה מעשית

נניח שלארגון יש שני צינורות עיבוד נתונים קשורים:

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

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

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

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

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

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

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

איור 13. האצת פייפליין נתונים מורכב באמצעות גישת הפניה אוטומטית.

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

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

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

איור 14. צינורות עיבוד נתונים שפועלים בו-זמנית באמצעות DAG משני.

החיסרון הוא ששכפול הלוגיקה של ה-sub-DAG יוצר תקורה של ניהול קוד, כי עכשיו הצוות צריך לסנכרן את שני העותקים של הלוגיקה של ה-sub-DAG.

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

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

איור 15. DAG תזמור כולל, שבו כל צינור עיבוד נתונים נמצא ב-DAG משנה משלו.

באיטרציות הבאות, צוות ההעברה יכול לפתור את כל הבעיות הפונקציונליות שנותרו ולהעביר את צינורות עיבוד הנתונים לשימוש בשירותים המנוהלים שלGoogle Cloud, בין היתר:

למרות ש-Airflow תומך ב-DAG משנה באופן מקורי, הפונקציונליות הזו עלולה להגביל את הביצועים שלו ולכן לא מומלצת. במקומם, השתמשו ב-DAGs עצמאיים עם האופרטור TriggerDagRunOperator.

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

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

אתם יכולים גם לקרוא מידע נוסף על מעבר מטכנולוגיות ספציפיות של מחסני נתונים ל-BigQuery: