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

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

מהו צינור נתונים?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

איור 3. תהליך ELT טיפוסי.

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

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

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

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

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

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

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

איור 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. הגישה הזו מבטיחה שתהיה לכם היסטוריה מלאה של שינויים בנתונים במעלה הזרם, ומספקת הפרדה טובה של האחריות – למשל:

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

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

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

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

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

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

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

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

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

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

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

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

הפניה מחדש של צינורות נתונים לכתיבה ב-BigQuery

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

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

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

• ‫Informatica: מדריך למחבר BigQuery
• ‫Talend: כתיבת נתונים ב-BigQuery

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

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

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

פונקציונלי

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

Nonfunctional

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

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

אם הטכנולוגיה הקיימת של צינור הנתונים המקומי לא תומכת בממשקי Google API, או אם יש לכם הגבלות על השימוש בממשקי Google API, אתם יכולים להשתמש בקבצים כדרך ביניים להעברת הנתונים ל-BigQuery.

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

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

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

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

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

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

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

העברת צינורות ELT קיימים אל BigQuery

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

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

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

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

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

‫Managed Service for Apache Spark מאפשר לכם לפרוס אשכולות של Hadoop ו-Spark במהירות, בקלות ובאופן מנוהל לחלוטין, בצורה פשוטה וחסכונית. השירות המנוהל של 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 Connector.

אירוח מחדש של צינורות עיבוד נתונים של צד שלישי כדי להריץ אותם ב- Cloud de Confiance

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• באופן אוטומטי, באמצעות Cloud Scheduler,‏ Managed Airflow או טריגר של Cloud Storage כשנתונים חדשים מגיעים לקטגוריה של Cloud Storage.
• באופן פרוגרמטי, באמצעות קריאה ל-Cloud Endpoint או ל-Cloud Function, או באמצעות Pub/Sub API.
• באופן ידני, על ידי הצבת הודעה חדשה בנושא Pub/Sub באמצעות Google Cloud CLI.

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

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

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

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

בקטעים הבאים מוצגים שירותים מנוהלים במלואם Cloud de Confiance שמאפשרים לבצע המרות מתקדמות של נתונים בהיקף גדול: Cloud Data Fusion ו-Dataflow.

Cloud Data Fusion

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

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

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

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

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

תזמור ותזמון

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

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

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

תלויות

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

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

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

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

ב- Cloud de Confiance, יש שפע של משאבי מחשוב וכלים ייעודיים שיעזרו לכם לבצע אופטימיזציה של ההרצה של צינורות הנתונים והתזמור שלהם. בסעיפים הבאים נסביר על המשאבים והכלים האלה.

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

מומלץ לפשט את הצרכים שלכם בתיזמור. ככל שיש יותר תלות בין צינורות הנתונים, כך התזמור הופך למורכב יותר. המעבר אל Cloud de Confiance מאפשר לבדוק את הגרפים המכוונים האציקליים (DAG) של תזמור הפעולות, לזהות את התלותיות ולקבוע איך לבצע אופטימיזציה של התלותיות האלה.

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

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

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

דוגמה מעשית

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ‫Dataflow: מאפשר להגדיר כל צינור נתונים כ-DAG עצמאי באמצעות מודל Beam.
• ‫Managed Airflow: מאפשר להגדיר את התזמור הרחב יותר בתור Airflow DAGs אחד או יותר.

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

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

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

• סקירה כללית על מיגרציה
• הערכת תהליך ההעברה
• סקירה כללית של סכימה והעברת נתונים
• תרגום SQL באצווה
• תרגום אינטראקטיבי של SQL
• אבטחה ומשילות מידע
• כלי לאימות נתונים

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

• העברה מ-Netezza
• העברה מ-Oracle
• מיגרציה מ-Amazon Redshift
• העברה מ-Teradata
• העברה מ-Snowflake