העברת צינורות נתונים
במאמר הזה מוסבר איך אפשר להעביר את צינורות עיבוד הנתונים שלכם במעלה הזרם, שמעמיסים נתונים למחסן הנתונים. במסמך הזה מוסבר מהו פייפליין, אילו הליכים ודפוסים אפשר להשתמש בהם בפייפליין, ואילו אפשרויות וטכנולוגיות להעברה זמינות להעברה של מחסן נתונים.
מהו פייפליין נתונים?
במחשוב, פייפליין הוא סוג של אפליקציה שמעבדת נתונים באמצעות רצף של שלבי עיבוד מחוברים. באופן כללי, אפשר להשתמש בצינורות נתונים להעברת נתונים בין מערכות מידע, לחילוץ, טרנספורמציה וטעינה (ETL), להעשרת נתונים ולניתוח נתונים בזמן אמת. בדרך כלל, צינורות נתונים פועלים כתהליך באצווה שמבצע עיבוד של נתונים כשהוא מופעל, או כתהליך סטרימינג שפועל באופן רציף ומעבד נתונים כשהם הופכים לזמינים לצינור.
בהקשר של אחסון נתונים (data warehousing), Data pipelines משמשים בדרך כלל לקריאת נתונים ממערכות טרנזקציונליות, להחלת טרנספורמציות ואז לכתיבת נתונים למחסן נתונים (data warehouse). כל אחת מהטרנספורמציות מתוארת על ידי פונקציה, והקלט של כל פונקציה נתונה הוא הפלט של הפונקציה או הפונקציות הקודמות. הפונקציות המחוברות האלה מתוארות כגרף, ולגרף הזה קוראים לעיתים קרובות גרף אציקלי מכוון (DAG) – כלומר, הגרף פועל בכיוון מסוים (מהמקור ליעד) והוא אציקלי – הקלט של כל פונקציה לא יכול להיות תלוי בפלט של פונקציה אחרת בהמשך ה-DAG. במילים אחרות, אסור להשתמש בלולאות. כל צומת בתרשים הוא פונקציה, וכל קצה מייצג את הנתונים שזורמים מפונקציה אחת לפונקציה הבאה. הפונקציות הראשוניות הן מקורות, או חיבורים למערכות נתוני מקור. הפונקציות הסופיות הן יעדים, או חיבורים למערכות נתונים של יעדים.
בהקשר של צינורות נתונים, המקורות הם בדרך כלל מערכות טרנזקציונליות – לדוגמה, RDBMS – והיעד מתחבר למחסן נתונים. סוג התרשים הזה נקרא תרשים DAG של זרימת נתונים. אפשר גם להשתמש ב-DAG כדי לתזמן את תנועת הנתונים בין צינורות עיבוד נתונים ומערכות אחרות. השימוש הזה נקרא תיזמור או תרשים DAG של זרימת בקרה.
מתי כדאי להעביר את צינורות עיבוד הנתונים
כשמבצעים מיגרציה של תרחיש שימוש ל-BigQuery, אפשר לבחור להפחית עומס או לבצע מיגרציה מלאה.
מצד אחד, כשמפחיתים עומס של תרחיש שימוש, לא צריך להעביר מראש את צינורות הנתונים שלו במעלה הזרם. קודם מעבירים את סכימת מקרה השימוש ואת הנתונים ממחסן הנתונים הקיים אל BigQuery. לאחר מכן, יוצרים העתקה מצטברת ממחסן הנתונים הישן למחסן הנתונים החדש כדי לשמור על סנכרון הנתונים. לבסוף, מעבירים את התהליכים במורד הזרם, כמו סקריפטים, שאילתות, לוחות בקרה ואפליקציות עסקיות, ומאמתים אותם.
בשלב הזה, צינורות הנתונים במעלה הזרם לא משתנים וממשיכים לכתוב נתונים למחסן הנתונים הקיים. אפשר לכלול שוב את תרחישי השימוש שהועברו לרשימת המשימות להעברה, כדי להעביר אותם באופן מלא באיטרציה הבאה.
לעומת זאת, כשמעבירים תרחיש לדוגמה באופן מלא, צינורות הנתונים במעלה הזרם שנדרשים לתרחיש לדוגמה מועברים אל Google Cloud. כדי לבצע העברה מלאה, צריך קודם להעביר את תרחיש השימוש. אחרי המיגרציה המלאה, אפשר להוציא משימוש את הטבלאות הקודמות התואמות ממחסן הנתונים המקומי, כי הנתונים מוזנים ישירות ל-BigQuery.
במהלך איטרציה, אפשר לבחור באחת מהאפשרויות הבאות:
- העברה של תרחיש השימוש בלבד.
- העברה מלאה של תרחיש שימוש שהועבר קודם.
- להעביר תרחיש לדוגמה באופן מלא מאפס על ידי העברה שלו בשלב הראשון באותו מחזור.
אחרי שכל תרחישי השימוש שלכם יועברו במלואם, תוכלו להשבית את מחסן הנתונים הישן. זהו שלב חשוב לצמצום התקורה והעלויות.
איך מעבירים את צינורות הנתונים
בהמשך המסמך מוסבר איך להעביר את צינורות הנתונים, כולל הגישה והנהלים שבהם צריך להשתמש והטכנולוגיות שבהן צריך להיעזר. האפשרויות הן שימוש חוזר בצינורות נתונים קיימים (הפניה שלהם לטעינה ב-BigQuery) או כתיבה מחדש של צינורות הנתונים כדי לנצל את היתרונות של שירותים מנוהלים של Google Cloud.
הליכים ודפוסים לצינורות עיבוד נתונים
אתם יכולים להשתמש בצינורות עיבוד נתונים כדי להפעיל מספר הליכים ודפוסים. אלה צינורות העיבוד הנפוצים ביותר במחסני נתונים. יכול להיות שיש לכם צינורות של נתונים באצווה או צינורות של נתוני סטרימינג. צינורות להעברת נתונים באצווה פועלים על נתונים שנאספים לאורך תקופה מסוימת (לדוגמה, פעם ביום). צינורות נתונים בסטרימינג מטפלים באירועים בזמן אמת שנוצרים על ידי המערכות התפעוליות שלכם – לדוגמה, שינויים בשורות ב-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, וב-Cloud Composer כדי לתזמן את זרימת הנתונים מקצה לקצה.
בחירת גישה להעברה
בקטע הזה מתוארות גישות שונות שאפשר לאמץ כדי להעביר את צינורות הנתונים.
הפניה מחדש של צינורות נתונים לכתיבה ב-BigQuery
במקרים הבאים, כדאי לבדוק אם הטכנולוגיה שבה אתם משתמשים מציעה מאגר נתונים מובנה של BigQuery (מחבר כתיבה):
- מחסן הנתונים מדור קודם מקבל נתונים מצינורות נתונים שמבצעים הליך ETL.
- הלוגיקה של הטרנספורמציה מופעלת לפני שהנתונים מאוחסנים במחסן הנתונים.
ספקי תוכנה עצמאיים (ISV) מציעים טכנולוגיות לעיבוד נתונים עם מחברים ל-BigQuery, כולל:
- Informatica: מדריך למחבר BigQuery
- Talend: כתיבת נתונים ב-BigQuery
אם הטכנולוגיה של פייפליין הנתונים לא תומכת בהטמעת נתונים ב-BigQuery, אפשר להשתמש בשיטה חלופית שבה הנתונים נכתבים באופן זמני לקבצים, ואז מוטמעים ב-BigQuery.
איור 7. לשכתב או להגדיר מחדש את הפונקציה האחרונה של פייפליין כדי לכתוב נתונים ב-BigQuery.
באופן כללי, העבודה כוללת כתיבה מחדש או הגדרה מחדש של הפונקציה האחרונה ב-פייפליין, כדי לכתוב נתונים ל-BigQuery. עם זאת, יש כמה אפשרויות שעשויות לדרוש שינויים נוספים או עבודה חדשה, למשל:
פונקציונלי
- מיפויי נתונים: יכול להיות שתצטרכו להגדיר מחדש את המיפויים האלה, כי יכול להיות שהסכימה של טבלת מסד הנתונים של היעד תשתנה.
- אימות מדדים: צריך לאמת גם דוחות היסטוריים וגם דוחות חדשים, כי יכול להיות שהסכימה והשאילתות ישתנו.
Nonfunctional
- יכול להיות שתצטרכו להגדיר חומות אש כדי לאפשר העברת נתונים יוצאת משרתים מקומיים אל BigQuery.
- יכול להיות שיהיה צורך לבצע שינויים ברשת כדי ליצור רוחב פס נוסף, כדי להתאים להעברת נתונים יוצאים.
הפניית צינורות נתונים באמצעות קבצים ככלי ביניים
אם הטכנולוגיה הקיימת של פייפליין הנתונים המקומי לא תומכת ב-Google APIs, או אם יש לכם הגבלות על השימוש ב-Google APIs, אתם יכולים להשתמש בקבצים כדרך ביניים להעברת הנתונים ל-BigQuery.
הגישה הזו דומה לגישת ההפניה האוטומטית, אבל במקום להשתמש ביעד מקורי שיכול לכתוב ל-BigQuery, משתמשים ביעד שיכול לכתוב למערכת קבצים מקומית. כשהנתונים נמצאים במערכת הקבצים, מעתיקים את הקבצים ל-Cloud Storage. לפרטים נוספים, ראו סקירה כללית על אפשרויות ההעלאה ל-Cloud Storage והקריטריונים לבחירת אפשרות העלאה.
השלב האחרון הוא לטעון את הנתונים מ-Cloud Storage ל-BigQuery בהתאם להנחיות שבמאמר טעינת נתונים באצווה.
בתרשים הבא מוצג התהליך שמתואר בקטע הזה.
איור 8. הפניית צינורות נתונים באמצעות קבצים ככלי ביניים.
כדי לתזמן את צינור ה-ETL, צריך לבצע שני שלבים נפרדים:
- אפשר להשתמש מחדש בתיזמור הקיים של צינורות העיבוד המקומיים כדי לכתוב את הנתונים שעברו טרנספורמציה במערכת הקבצים. אפשר להרחיב את התזמור הזה כדי להעתיק את הקבצים ממערכת הקבצים המקומית אל Cloud Storage, או ליצור סקריפט נוסף שפועל באופן קבוע כדי לבצע את שלב ההעתקה.
- אחרי שהנתונים נמצאים ב-Cloud Storage, אפשר להשתמש בהעברה מ-Cloud Storage כדי לתזמן טעינות חוזרות מ-Cloud Storage ל-BigQuery. חלופות להעברות ב-Cloud Storage הן טריגרים של Cloud Storage ו-Cloud Composer.
באיור 8 אפשר לראות שאפשר גם להשתמש בתזמור ב-Google Cloud במודל משיכה, על ידי אחזור הקבצים באמצעות פרוטוקול כמו SFTP.
העברת צינורות ELT קיימים אל BigQuery
צינורות ELT מורכבים משני חלקים: החלק שמעלה את הנתונים למחסן הנתונים, והחלק שמשנה את הנתונים באמצעות SQL כדי שאפשר יהיה להשתמש בהם בהמשך. כשמעבירים צינורות ELT, לכל אחד מהחלקים האלה יש שיטה משלו להעברה.
בנוגע לחלק שבו הנתונים נטענים למחסן הנתונים (החלק של EL), אפשר לפעול לפי ההנחיות שבקטע צינורות להפניית נתונים, בלי העצות לגבי טרנספורמציות, שלא נכללות בצינור EL.
אם מקורות הנתונים שלכם נתמכים על ידי שירות העברת נתונים ל-BigQuery (DTS) ישירות או דרך שילובים של צד שלישי, אתם יכולים להשתמש ב-DTS כדי להחליף את צינור ה-EL.
העברת צינורות נתונים קיימים של OSS ל-Dataproc
כשמעבירים את פייפליין הנתונים אל Google Cloud, יכול להיות שתרצו להעביר כמה משימות מדור קודם שנכתבו באמצעות מסגרת תוכנה בקוד פתוח כמו Apache Hadoop, Apache Spark או Apache Flink.
Dataproc מאפשר לפרוס אשכולות של Hadoop ו-Spark במהירות, בקלות ובאופן מנוהל לחלוטין, בצורה פשוטה וחסכונית. Dataproc משתלב עם BigQuery connector, ספריית Java שמאפשרת ל-Hadoop ול-Spark לכתוב נתונים ישירות ל-BigQuery באמצעות גרסאות מופשטות של המחלקות InputFormat ו-OutputFormat של Apache Hadoop.
בעזרת Dataproc קל ליצור ולמחוק אשכולות, כך שבמקום להשתמש באשכול מונוליטי אחד, אפשר להשתמש באשכולות זמניים רבים. לגישה הזו יש כמה יתרונות:
- אתם יכולים להשתמש בהגדרות שונות של אשכולות לעבודות נפרדות, וכך לא תצטרכו לנהל כלים בעבודות שונות.
- אתם יכולים לשנות את גודל האשכולות בהתאם למשימות ספציפיות או לקבוצות של משימות.
- אתם משלמים על המשאבים רק כשהעבודות שלכם משתמשות בהם.
- אתם לא צריכים לתחזק את האשכולות לאורך זמן, כי הם מוגדרים מחדש בכל פעם שאתם משתמשים בהם.
- אתם לא צריכים לתחזק תשתית נפרדת לפיתוח, לבדיקה ולייצור. אתם יכולים להשתמש באותן הגדרות כדי ליצור כמה גרסאות שונות של אשכול שאתם צריכים, מתי שאתם צריכים.
כשמעבירים את העבודות, מומלץ להשתמש בגישה מצטברת. העברה מצטברת מאפשרת לכם:
- לבודד משימות ספציפיות בתשתית Hadoop הקיימת מהמורכבות שמאפיינת סביבה בוגרת.
- בודקים כל משימה בנפרד כדי להעריך את הצרכים שלה ולקבוע את הדרך הטובה ביותר להעברה.
- לפתור בעיות לא צפויות שמתעוררות בלי לעכב משימות שתלויות בהן.
- אפשר ליצור הוכחת היתכנות לכל תהליך מורכב בלי להשפיע על סביבת הייצור.
- כדאי להעביר את העבודות למודל המומלץ של משימות זמניות בצורה מושכלת ומכוונת.
כשמעבירים את המשימות הקיימות ב-Hadoop וב-Spark אל Dataproc, אפשר לבדוק אם התלות של המשימות מכוסה על ידי גרסאות Dataproc הנתמכות. אם אתם צריכים להתקין תוכנה בהתאמה אישית, אתם יכולים ליצור תמונה משלכם ב-Dataproc, להשתמש בפעולות אתחול שזמינות (לדוגמה, ל-Apache Flink), לכתוב פעולת אתחול משלכם או לציין דרישות מותאמות אישית לחבילות Python.
כדי להתחיל, אפשר לעיין במדריכים למתחילים של Dataproc ובדוגמאות קוד של מחבר BigQuery.
אירוח מחדש של צינורות עיבוד נתונים של צד שלישי כדי להריץ אותם ב- Google Cloud
תרחיש נפוץ כשיוצרים צינורות עיבוד נתונים במקום הוא שימוש בתוכנה של צד שלישי כדי לנהל את ההפעלה של צינור עיבוד הנתונים ואת ההקצאה של משאבי מחשוב.
כדי להעביר את צינורות הנתונים האלה לענן, יש כמה חלופות, בהתאם ליכולות של התוכנה שבה אתם משתמשים, וגם בהתאם לתנאי הרישוי, התמיכה והתחזוקה שלכם.
בקטעים הבאים מוצגות כמה מהחלופות האלה.
באופן כללי, יש לכם את החלופות הבאות להרצת תוכנות צד שלישי ב- Google Cloud, מהפשוטה ביותר למורכבת ביותר:
- ספק התוכנה שלכם שיתף פעולה עם Google Cloud כדי להציע את התוכנה שלו ב-Google Cloud Marketplace.
- ספק התוכנה של הצד השלישי יכול לפעול ב-Kubernetes.
- התוכנה של הצד השלישי פועלת במכונה וירטואלית אחת או יותר (VM).
אם התוכנה של הצד השלישי מספקת פתרון ב-Cloud Marketplace, הפעולות שצריך לבצע הן:
- פורסים את תוכנת הצד השלישי ממסוף Cloud Marketplace.
- בוחרים את תרחישי השימוש ומעבירים אותם לפי הגישה האיטרטיבית שמפורטת במאמר העברה באמצעות גישה איטרטיבית.
החלופה הזו היא הפשוטה ביותר, כי אתם מעבירים את צינורות הנתונים שלכם לענן באמצעות הפלטפורמה המוכרת שסופקה על ידי הספק. יכול להיות שתוכלו גם להשתמש בכלים קנייניים מהספק כדי להקל על המעבר בין הסביבה המקורית לסביבה החדשה ב- Google Cloud.
אם הספק לא מספק פתרון ב-Cloud Marketplace, אבל המוצר שלו יכול לפעול על Kubernetes, אפשר להשתמש ב-Google Kubernetes Engine (GKE) כדי לארח את צינורות העיבוד. העבודה כוללת את הפעולות הבאות:
- יוצרים אשכול GKE בהתאם להמלצות של הספק כדי לוודא שהמוצר של הצד השלישי יכול לנצל את ההקצאה המקבילה של משימות ש-Kubernetes מציעה.
- מתקינים את התוכנה של הצד השלישי באשכול GKE בהתאם להמלצות הספק.
- בוחרים את תרחישי השימוש ומעבירים אותם לפי הגישה האיטרטיבית שמפורטת במאמר העברת מחסני נתונים ל-BigQuery: סקירה כללית.
החלופה הזו מספקת פתרון ביניים מבחינת מורכבות. הוא מנצל את התמיכה המובנית של הספק ב-Kubernetes כדי להרחיב את הצינורות ולהריץ אותם במקביל. עם זאת, צריך ליצור ולנהל אשכול GKE.
אם הספק שלכם לא תומך ב-Kubernetes, אתם צריכים להתקין את התוכנה שלו במאגר של מכונות וירטואליות כדי לאפשר הרחבה מקבילית של העבודה. אם התוכנה של הספק תומכת באופן מובנה בהפצת העבודה לכמה מכונות וירטואליות, אפשר להשתמש במתקנים האלה, ואולי לקבץ את המופעים של המכונות הווירטואליות בקבוצת מופעי מכונה מנוהלים (MIG) לצורך הגדלה והקטנה של הקיבולת לפי הצורך.
הטיפול בהרצה מקבילית של העבודה הוא לא פשוט. אם הספק לא מספק יכולות להפצת משימות למכונות וירטואליות שונות, מומלץ להשתמש בדפוס של חלוקת משימות כדי להפיץ את העבודה למכונות וירטואליות ב-MIG. התרשים הבא ממחיש את הגישה הזו.
איור 9. קבוצת מופעי מכונה מנוהלים (MIG) עם שלוש מכונות וירטואליות.
בתרשים הזה, כל VM ב-MIG מריצה את תוכנת הצינור של הצד השלישי. ניתן להפעיל הרצת צינור בכמה דרכים:
- באופן אוטומטי, באמצעות Cloud Scheduler, Cloud Composer או טריגר של Cloud Storage, כשנתונים חדשים מגיעים לקטגוריה של Cloud Storage.
- באופן פרוגרמטי, על ידי קריאה ל-Cloud Endpoint או ל-Cloud Function, או באמצעות Pub/Sub API.
- באופן ידני, על ידי הצבת הודעה חדשה בנושא Pub/Sub באמצעות Google Cloud CLI.
במהותן, כל השיטות האלה שולחות הודעה לנושא Pub/Sub שהוגדר מראש. יוצרים סוכן פשוט להתקנה בכל מכונה וירטואלית. הנציג מקשיב לנושא אחד או יותר של Pub/Sub. בכל פעם שהודעה מגיעה לנושא, הסוכן שולף את ההודעה מהנושא, מתחיל צינור (pipeline) בתוכנת הצד השלישי ומאזין להשלמתו. כשהצינור מסתיים, הסוכן מאחזר את ההודעה הבאה מהנושאים שהוא מאזין להם.
בכל התרחישים, מומלץ לעבוד עם הספק כדי לעמוד בתנאי הרישיון המתאימים לצינורות שלך, כדי שהם יפעלו ב- Google Cloud.
כתיבה מחדש של צינורות עיבוד נתונים כדי להשתמש בשירותים מנוהלים של Google Cloud
במקרים מסוימים, יכול להיות שתבחרו לשכתב חלק מצינורות הנתונים הקיימים כדי להשתמש במסגרות ובשירותים חדשים שמנוהלים באופן מלא ב- Google Cloud. האפשרות הזו מתאימה אם צינורות הנתונים הקיימים שלכם הוטמעו במקור באמצעות טכנולוגיות שיצאו משימוש, או אם אתם צופים שהעברה של צינורות הנתונים האלה לענן והמשך התחזוקה שלהם ללא שינויים יהיו לא מעשיים או יקרים מדי.
בקטעים הבאים מוצגים שירותים מנוהלים במלואם Google Cloud שמאפשרים לבצע המרות מתקדמות של נתונים בהיקף גדול: Cloud Data Fusion ו-Dataflow.
Cloud Data Fusion
Cloud Data Fusion, שמבוסס על פרויקט הקוד הפתוח CDAP, הוא שירות מנוהל לחלוטין לשילוב נתונים, שמאפשר ליצור ולנהל צינורות עיבוד נתונים באמצעות ממשק גרפי.
מפתחים את צינורות הנתונים בממשק המשתמש של Cloud Data Fusion על ידי חיבור מקורות לטרנספורמציות, ליעדים ולצמתים אחרים כדי ליצור DAG. כשפורסים את פייפליין הנתונים, מתכנן Cloud Data Fusion הופך את ה-DAG הזה לסדרה של חישובים מקבילים שיופעלו כמשימת Apache Spark ב-Dataproc.
כשמשתמשים ב-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, שבהם פייפליין יחיד מפעיל כמה פייפליינים אחרים; או לרוב שניהם, כפי שמוצג בתרשים הבא.
איור 10. תלויות מסוג fan-in ו-fan-out שמשמשות בשילוב.
בסביבות לא אופטימליות, חלק מהתלות נובע ממגבלות בכמות המשאבים הזמינים. לדוגמה, פייפליין נתונים פועל ומפיק נתונים נפוצים כתוצר לוואי. צינורות אחרים של נתונים מסתמכים על הנתונים המשותפים האלה רק כדי להימנע מחישוב מחדש, אבל הם לא קשורים לצינור הנתונים שיצר את הנתונים. אם בצינור הנתונים הראשון הזה מתגלות בעיות פונקציונליות או בעיות אחרות, הכשלים משפיעים על צינורות הנתונים שתלויים בו – במקרה הטוב, הם נאלצים להמתין, ובמקרה הרע, הם לא יכולים לפעול בכלל, כמו שמוצג בתרשים הבא.
איור 11. כשלים שמתרחשים בפייפליין מונעים את ההפעלה של פייפליינים שתלויים בו.
ב- Google Cloud, יש שפע של משאבי מחשוב וכלים ייעודיים שיעזרו לכם לבצע אופטימיזציה של ההרצה של צינורות הנתונים והתזמור שלהם. בסעיפים הבאים מוסבר על המשאבים והכלים האלה.
העבודה שנדרשת להעברה
מומלץ לפשט את הצרכים שלכם בתיאום. המורכבות של התזמור גדלה עם מספר התלויות בין צינורות הנתונים. המעבר אל Google Cloud מאפשר לבדוק את הגרפים המכוונים האציקליים (DAG) של תזמור, לזהות את התלותיות ולקבוע איך לבצע אופטימיזציה של התלותיות האלה.
מומלץ לבצע אופטימיזציה של התלות באופן מצטבר, באופן הבא:
- באיטרציה הראשונה, מעבירים את האורקסטרציה כמו שהיא אל Google Cloud.
- באיטרציות מאוחרות יותר, כדאי לנתח את התלויות ולהריץ אותן במקביל אם אפשר.
- לבסוף, מארגנים מחדש את התזמור על ידי חילוץ משימות משותפות ל-DAGs משלהן.
בקטע הבא מוסבר על השיטה הזו באמצעות דוגמה מעשית.
דוגמה מעשית
נניח שיש לארגון שני צינורות קשורים:
- הפייפליין הראשון מחשב את הרווחים וההפסדים (P&L) של הארגון כולו. זהו צינור מורכב שכולל הרבה טרנספורמציות. חלק מהצינור כולל חישוב של נתוני המכירות החודשיים, שמשמשים בשלבי טרנספורמציה עוקבים ובסופו של דבר נכתבים בטבלה.
- בצינור השני מחושב גידול המכירות משנה לשנה ומחודש לחודש של מוצרים שונים, כדי שמחלקת השיווק תוכל לשפר את הקמפיינים הפרסומיים שלה. פייפליין זה צריך להשתמש בנתוני המכירות החודשיים שחושבו קודם לכן בפייפליין הנתונים של דוח רווח והפסד.
הארגון רואה בפייפליין של נתוני הדוחות על רווח והפסד עדיפות גבוהה יותר מאשר בפייפליין השיווקי. לצערנו, מכיוון ש-P&L הוא פייפליין נתונים מורכב, הוא צורך כמות גדולה של משאבים, ולכן מונע הפעלה של פייפליינים אחרים בו-זמנית. בנוסף, אם צינור הנתונים של הרווח וההפסד נכשל, לצינור הנתונים של השיווק ולצינורות נתונים תלויים אחרים אין את הנתונים הנדרשים כדי לפעול, והם צריכים לחכות לניסיון חוזר של צינור הנתונים של הרווח וההפסד. התרשים הבא ממחיש את המצב הזה.
איור 12. צינורות נתונים מורכבים יכולים למנוע הפעלה של צינורות נתונים בעדיפות נמוכה יותר.
הארגון עובר ל-BigQuery. המערכת זיהתה את שני תרחישי השימוש – רווח והפסד וצמיחה במכירות שיווקיות – והוסיפה אותם לרשימת המשימות לביצוע של ההעברה. בשלב התכנון של האיטרציה הבאה, הארגון נותן עדיפות לתרחיש השימוש של רווח והפסד וכולל אותו ב-backlog של האיטרציה, כי הוא מוגבל מאוד על ידי המשאבים הנוכחיים במקום וגורם לעיכובים באופן קבוע. הוא כולל גם חלק מתרחישי השימוש שתלויים בו, ביניהם תרחיש השימוש השיווקי.
צוות ההעברה מריץ את האיטרציה הראשונה. הם בוחרים להעביר את תרחישי השימוש של רווח והפסד ושיווק אל Google Cloud באמצעות הפניה לכתובת אחרת. הם לא מבצעים שינויים בשלבי הצינור או בתיאום. ההבדל העיקרי הוא שעכשיו צינור הנתונים של P&L יכול להשתמש בכמעט בלתי מוגבלת של כוח מחשוב, ולכן הוא פועל הרבה יותר מהר מאשר בשרתים מקומיים. הצינור כותב את נתוני המכירות החודשיים לטבלה ב-BigQuery שבה נעשה שימוש בצינור השיווקי להגדלת נפח הפעילות. התרשים הבא מדגים את השינויים האלה.
איור 13. האצת פייפליין נתונים מורכב באמצעות גישה של הפניה אוטומטית.
למרות ש Google Cloud עזר לפתור את הבעיות שקשורות לרווח והפסד, עדיין יש בעיות שקשורות לפונקציונליות. משימות לא קשורות שמתבצעות לפני החישוב של המכירות החודשיות גורמות לעיתים קרובות לשגיאות שמונעות את החישוב הזה, וכתוצאה מכך, צינורות התלויים לא יכולים להתחיל.
באיטרציה השנייה, הצוות מקווה לשפר את הביצועים על ידי הכללת שני תרחישי השימוש ב-backlog של האיטרציה. הצוות מזהה את השלבים בצינור המכירות כדי לחשב את המכירות החודשיות בצינור המכירות של דוח רווח והפסד. השלבים האלה הם תת-DAG, כמו שמוצג בתרשים הבא. צוות ההעברה מעתיק את ה-DAG המשני לצינור השיווק כדי שצינור השיווק יוכל לפעול באופן עצמאי מ-P&L. אם יש לכם מספיק כוח מחשוב ב- Google Cloud , תוכלו להפעיל את שני צינורות הנתונים בו-זמנית.
איור 14. צינורות שפועלים בו-זמנית באמצעות DAG משני.
החיסרון הוא שכפילות של הלוגיקה של ה-DAG המשני יוצרת תקורה של ניהול קוד, כי עכשיו הצוות צריך לשמור על סנכרון בין שני העותקים של הלוגיקה של ה-DAG המשני.
באיטרציה השלישית, הצוות בוחן מחדש את תרחישי השימוש ומחלץ את ה-DAG המשני של המכירות החודשיות לצינור נתונים עצמאי. כשהמשפך החדש של המכירות החודשיות מסתיים, הוא מפעיל או מתפצל לתוך דוחות רווח והפסד, צמיחה שיווקית ומשפכים תלויים אחרים. ההגדרה הזו יוצרת DAG חדש של תזמור כולל, כאשר כל אחד מצינורות הנתונים הוא אחד מ-DAG המשנה שלו.
איור 15. תרשים DAG כולל של תזמור עם כל צינור משנה בתרשים DAG משלו.
באיטרציות הבאות, צוות ההעברה יכול לפתור בעיות פונקציונליות שנותרו ולהעביר את צינורות הנתונים לשימוש בשירותים מנוהלים שלGoogle Cloud, בין היתר:
- Dataflow: מאפשר להגדיר כל פייפליין נתונים כ-DAG עצמאי באמצעות מודל Beam.
- Cloud Composer: מאפשר להגדיר את התזמור הרחב יותר כ-Airflow DAGs אחד או יותר.
למרות ש-Airflow תומך באופן מובנה ב-sub-DAGs, הפונקציונליות הזו עלולה להגביל את הביצועים שלו, ולכן לא מומלץ להשתמש בה.
במקומם, משתמשים ב-DAG עצמאיים עם האופרטור TriggerDagRunOperator.
המאמרים הבאים
מידע נוסף על השלבים הבאים בהעברה של מחסן נתונים:
- סקירה כללית על מיגרציה
- הערכת תהליך ההעברה
- סקירה כללית של סכימה והעברת נתונים
- תרגום SQL באצווה
- תרגום אינטראקטיבי של SQL
- אבטחת מידע ומשילות מידע
- הכלי לאימות נתונים
אפשר גם לקרוא על מעבר מטכנולוגיות ספציפיות של מחסני נתונים ל-BigQuery: