תכנון צינור עיבוד נתונים של Dataflow

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

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

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

הגדרה ומדידה של SLO

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

• עדכניות הנתונים: יצירת 90% מהמלצות המוצרים על סמך פעילות המשתמשים באתר שהתרחשה לפני 3 דקות לכל היותר.

• דיוק הנתונים: במהלך חודש קלנדרי, פחות מ-0.5% מהחשבוניות של הלקוחות מכילות שגיאות.

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

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

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

מידע נוסף על יעדי SLO חשובים שכדאי לקחת בחשבון זמין בספר Site Reliability Engineering.

עדכניות הנתונים

עדכניות הנתונים מתייחסת למידת השימושיות של הנתונים ביחס לגיל שלהם. בספר Site Reliability Engineering מפורטים הפורמטים הבאים של הסכמי רמת שירות (SLO) נפוצים ביותר לעדכניות נתונים בצינורות:

• ‫X% מהנתונים עובדו ב-Y [שניות, ימים, דקות]. ה-SLO הזה מתייחס לאחוז הנתונים שעוברים עיבוד בפרק זמן נתון. הוא משמש בדרך כלל לצינורות עיבוד נתונים באצווה שמעבדים מקורות נתונים מוגבלים. המדדים לסוג הזה של SLO הם גדלי נתוני הקלט והפלט בשלבי עיבוד מרכזיים, ביחס לזמן הריצה שחלף של צינור הנתונים. אפשר לבחור שלב שקורא קבוצת נתוני קלט ושלב אחר שמבצע עיבוד של כל פריט בקלט. דוגמה ל-SLO: "במשחק Shave the Yak, ‏ 99% מפעילויות המשתמשים שמשפיעות על הניקוד של השחקנים נספרות תוך 30 דקות מסיום המשחק".

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

• משימת הצינור מסתיימת בהצלחה תוך X [שניות, ימים, דקות]. ה-SLO הזה מגדיר מועד סיום להשלמה מוצלחת, והוא משמש בדרך כלל לצינורות עיבוד נתונים באצווה שמעבדים נתונים ממקורות נתונים מוגבלים. הסכם רמת השירות הזה דורש את הזמן הכולל שחלף מתחילת הצינור ואת סטטוס השלמת העבודה, בנוסף לאותות אחרים שמציינים את הצלחת העבודה, כמו אחוז הרכיבים שעברו עיבוד וגרמו לשגיאות. דוגמה ל-SLO: "הזמנות של לקוחות מיום העסקים הנוכחי יעובדו עד השעה 9:00 בבוקר של היום הבא".

מידע על שימוש ב-Cloud Monitoring למדידת עדכניות הנתונים זמין במאמר מדדים של משימות Dataflow.

תקינות הנתונים

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

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

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

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

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

• בכל משימה, פחות מ-X% מפריטי הקלט מכילים שגיאות בנתונים. אתם יכולים להשתמש ב-SLO הזה כדי למדוד את נכונות הנתונים בצינורות (pipelines) של עיבוד אצווה. דוגמה ליעד SLO היא: "בכל משימת אצווה יומית לעיבוד קריאות של מדדי חשמל, פחות מ-3% מהקריאות מכילות שגיאות בהזנת הנתונים".
• בחלון נע של X דקות, פחות מ-Y% מפריטי הקלט מכילים שגיאות בנתונים. אפשר להשתמש ב-SLO הזה כדי למדוד את נכונות הנתונים בצינורות עיבוד נתונים לסטרימינג. דוגמה ל-SLO: "פחות מ-2% מקריאות מד החשמל בשעה האחרונה מכילים ערכים שליליים".

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

מידע על שימוש ב-Cloud Monitoring למדידת נכונות הנתונים זמין במאמר מדדים של משימות Dataflow.

בידוד נתונים ואיזון עומסים

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

נניח שהגדרתם את יעדי רמת השירות (SLO) הבאים לעיבוד תשלומים:

• תשלומים בעדיפות גבוהה מעובדים תוך 10 דקות.
• תשלומים בעדיפות רגילה מעובדים עד השעה 9:00 בבוקר של יום העסקים הבא.

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

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

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

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

שימוש בצינור אחד כדי לעמוד ביעדי SLO מעורבים

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

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

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

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

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

תשלומים בעדיפות גבוהה מבודדים לצינור הזרמה לעיבוד לפי סדר עדיפות. תשלומים בעדיפות רגילה מעובדים על ידי צינור (pipeline) של אצווה שפועל מדי יום ומשתמש במשימות טעינה של BigQuery כדי לכתוב את התוצאות המעובדות.

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

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

תכנון של מקורות נתונים ויעדים

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

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

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

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

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

שיחות לשירותים חיצוניים

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

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

שימוש ב- Google Cloud managed sources וב-sinks

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

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

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

דוגמה 1: Pub/Sub

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

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

בתרשים הבא, Pipeline 1 ו-Pipeline 2 חולקים את אותה מכסת תפוקה של מנוי ומפרסם שזמינה ל-Project A. לעומת זאת, Pipeline 3 יכול להשתמש במלוא מכסת התפוקה של המנוי והמוציא לאור שמצורפת לפרויקט ב'.

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

דוגמה 2: BigQuery

‫Apache Beam SDK תומך בקריאה וכתיבה של נתונים ב-BigQuery בכמה שפות, כולל Java,‏ Python ו-Go. כשמשתמשים ב-Java, המחלקה BigQueryIO מספקת את הפונקציונליות הזו. ‫BigQueryIO תומך בשתי שיטות לקריאת נתונים: EXPORT (ייצוא טבלה) ו-DIRECT_READ. שיטות הקריאה השונות צורכות מכסות שונות של BigQuery.

ייצוא טבלה הוא שיטת הקריאה שמוגדרת כברירת מחדל. התהליך מתבצע כמו שמוצג בדיאגרמה הבאה:

בתרשים מוצג התהליך הבא:

1. ‫BigQueryIO מפעיל בקשת ייצוא של BigQuery כדי לייצא נתונים מטבלה. נתוני הטבלה המיוצאים נכתבים למיקום זמני ב-Cloud Storage.
2. ‫BigQueryIO קורא את נתוני הטבלה ממיקום Cloud Storage הזמני.

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

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

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

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

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

שיקולים אזוריים

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

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

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

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

אזורים

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

עובדי Dataflow

משימות Dataflow משתמשות במכונות וירטואליות ב-Compute Engine, שנקראות Dataflow workers, כדי להריץ את צינור עיבוד הנתונים. עבודות של Dataflow יכולות להשתמש בכל אזור של Compute Engine בשביל העובדים, כולל אזורים שאין בהם מיקומים של Dataflow. כשמציינים אזור עבודה למשרה, אפשר לשלוט במיקום האזורי של העובדים. כדי לציין אזור או תחום של עובד, מבצעים את הפעולות הבאות:

• אם משתמשים ב-CLI של gcloud כדי ליצור עבודה מתבנית Dataflow, צריך להשתמש בדגל --worker-region כדי לשנות את אזור העובד, או בדגל --worker-zone כדי לשנות את אזור הזמינות של העובד.
• אם אתם משתמשים ב-Apache Beam Java SDK כדי ליצור את העבודה, אתם יכולים להגדיר אזורים ומיקומים לעובדים באמצעות אפשרויות של צינורות. משתמשים ב-workerRegion כדי לשנות את אזור העובד או ב-workerZone כדי לשנות את אזור העובד.

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

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

שיקולים לגבי הצפנת נתונים

שירות Dataflow הוא שירות שמנוהל במלואו, ולכן הוא מצפין באופן אוטומטי את הנתונים שעוברים דרך פייפליין הנתונים באמצעות Google-owned and Google-managed encryption keys גם לנתונים במעבר וגם לנתונים במנוחה. במקום להשתמש ב- Google-owned and Google-managed encryption keys, יכול להיות שתעדיפו לנהל מפתחות הצפנה משלכם. במקרה כזה, Dataflow תומך במפתחות הצפנה בניהול הלקוח (CMEK) באמצעות Cloud Key Management Service ‏ (KMS). אפשר גם להשתמש ב-Cloud HSM, שירות של מודול אבטחה לחומרה (HSM) שמארח מפתחות הצפנה ומבצע פעולות קריפטוגרפיות באשכול של HSMs עם אישור FIPS 140-2 ברמה 3.

כשמשתמשים ב-CMEK, ‏ Dataflow משתמש במפתח Cloud KMS כדי להצפין את הנתונים, למעט פעולות שמבוססות על מפתח נתונים, כמו חלוקה לחלונות, קיבוץ וצירוף. אם מפתחות הנתונים מכילים מידע אישי רגיש, כמו פרטים אישיים מזהים (PII), צריך לגבב (hash) את המפתחות או לבצע בהם טרנספורמציה אחרת לפני שהם נכנסים לצינור Dataflow.

שיקולים לגבי רשתות פרטיות

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

מומלץ להשבית כתובות IP ציבוריות עבור עובדי Dataflow, אלא אם נדרשות כתובות IP ציבוריות כדי לגשת למשאבי רשת מחוץ ל-Google Cloud Platform. השבתה של כתובות IP ציבוריות מונעת מעובדי Dataflow לגשת למשאבים שנמצאים מחוץ לרשת המשנה או לגשת לרשתות VPC שכנות. באופן דומה, נמנעת גישה לרשת של VM של עובדים מחוץ לרשת המשנה או לרשתות VPC שכנות.

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

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

• פיתוח ובדיקה של צינור עיבוד הנתונים.
• מידע נוסף על עיצוב תהליכי עבודה מלאים של צינורות
• מידע נוסף על השיטות של Google בנושא Site Reliability Engineering‏ (SRE) לצינורות עיבוד נתונים