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

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

אם מתכננים את צינורות עיבוד הנתונים לפני שמפתחים אותם, אפשר לשפר את הביצועים והאמינות שלהם. בדף הזה מוסבר על שיקולים שונים לתכנון צינורות 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% of data processed in Y [seconds, days, minutes]. ה-SLO הזה מתייחס לאחוז הנתונים שעוברים עיבוד בפרק זמן נתון. הוא משמש בדרך כלל לצינורות עיבוד נתונים באצווה שמעבדים מקורות נתונים מוגבלים. המדדים לסוג הזה של SLO הם גדלי נתוני הקלט והפלט בשלבי עיבוד מרכזיים, ביחס לזמן הריצה שחלף של צינור הנתונים. אפשר לבחור שלב שקורא קבוצת נתונים של קלט ושלב אחר שמבצע עיבוד של כל פריט בקלט. דוגמה ל-SLO: "במשחק 'גילוח היאק', 99% מפעילויות המשתמשים שמשפיעות על הניקוד של השחקנים נספרות תוך 30 דקות מסיום המשחק".

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

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

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

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

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

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

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

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

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

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

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

במאמר מדדים של משימות Dataflow מוסבר איך משתמשים ב-Cloud Monitoring כדי למדוד את נכונות הנתונים.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שימוש Google Cloud בשירותים מנוהלים עם צינור הנתונים של Dataflow מפשט את ניהול הקיבולת, כי השירותים האלה מספקים יכולת מובנית להתאמה לעומס, ביצועים עקביים ומכסות ומגבלות שמתאימות לרוב הדרישות. עדיין צריך להכיר את המכסות והמגבלות השונות של פעולות בצינור. ל-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 יש השלכות על המכסות. צינורות להרצת משימות באצווה שמשתמשים במשימות טעינה של 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 משתמשות במכונות וירטואליות (VM) של Compute Engine, שנקראות Dataflow workers, כדי להריץ את צינור עיבוד הנתונים. עבודות של Dataflow יכולות להשתמש בכל אזור של Compute Engine בשביל העובדים, כולל אזורים שאין בהם מיקומים של Dataflow. כשמציינים אזור של עובדים למשימה, אפשר לשלוט במיקום האזורי של העובדים. כדי לציין אזור או תחום של עובד, מבצעים את הפעולות הבאות:

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

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

אם לא משתמשים בשירות ארגון נתונים של 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) שמארח מפתחות הצפנה ומבצע פעולות קריפטוגרפיות באשכול של מודולי HSM עם אישור FIPS 140-2 ברמה 3.

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

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

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

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

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

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

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