הסבר על אמינות

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

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

ממדי האמינות ב-BigQuery

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

זמינות

הזמינות מגדירה את היכולת לקרוא נתונים מ-BigQuery או לכתוב אליו נתונים. ‫BigQuery בנוי כך שפעולות קריאה וכתיבה יהיו עם זמינות גבוהה, עם הסכם רמת שירות (SLA) של 99.99% זמן פעולה תקינה. שני רכיבים מעורבים בשתי הפעולות:

• שירות BigQuery
• משאבי המחשוב שנדרשים כדי להריץ את השאילתה הספציפית

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

עמידות

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

עקביות הנתונים

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

עקביות בביצועים

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

שחזור נתונים

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

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

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

תכנון למקרה אסון

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

ב-BigQuery יש הסכם SLA של 99.99% זמן פעולה תקינה. הזמינות הזו נתמכת על ידי הארכיטקטורה האזורית של BigQuery, שכותבת נתונים לשני אזורים שונים ומקצה קיבולת מחשוב מיותרת. הסכם ה-SLA של BigQuery זהה לאזורים (כמו us-central1) ולמספר אזורים (כמו US).

טיפול אוטומטי בכשלים

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

אובדן של מכונה

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

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

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

אובדן של אזור

כדי לעמוד בהסכם רמת השירות (SLA) של 99.99% זמן פעולה תקינה, BigQuery מספק יתירות אזורית אוטומטית גם לנתונים וגם ל-compute slots. מכיוון שזמינות המחשוב באזור אחד לא יכולה לעמוד בהסכם SLA כזה לבדה, BigQuery מנתב באופן אוטומטי שאילתות חדשות לאזור אחר תוך דקה מרגע שיש שיבוש חמור באזור. יכול להיות שייקח יותר זמן להשלים שאילתות שנמצאות בתהליך, אבל שאילתות חדשות יושלמו כרגיל באזור אחר.

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

סוגי כשלים

יש שני סוגים של כשלים: כשלים קלים וכשלים חמורים.

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

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

יתירות מיקום והתנהגות במקרה של כשל

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

• אזור: מיקום גיאוגרפי ספציפי, כמו איווה (us-central1) או מונטריאול (northamerica-northeast1).
• מספר אזורים: אזור גיאוגרפי נרחב שכולל שני מקומות גיאוגרפיים או יותר, כמו ארצות הברית (US) או אירופה (EU).

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

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

הערה: בחירה במיקום במספר אזורים לא מספקת רפליקציה בין אזורים או יתירות אזורית. ‫BigQuery מאחסן את הנתונים באזור אחד בתוך המיקום במספר אזורים.

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

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

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

תרחיש: אובדן אזור

‫BigQuery לא מספק עמידות או זמינות אם אזור פיזי נהרס. המגבלה הזו חלה גם על אזור אחד וגם על מספר אזורים, ולכן כדי לשמור על העמידות והזמינות בזמן הפסקה אזורית, צריך לתכנן מראש. אם הסכם רמת השירות (SLA) של BigQuery, שמבטיח זמינות של 99.99%, לא עומד בדרישות הזמינות שלכם במהלך הפסקה זמנית בשירות באזור מסוים, כדאי להגדיר זמינות יתירה (redundant) באזורים שונים.

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

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

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

תרחיש: מחיקה בטעות או פגיעה בנתונים

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

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

תוכנית התאוששות מאסון (DR) לניתוח נתונים בזמן אמת

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

לדוגמה, נניח שאתם מגדירים משימות חילוץ ליליות כדי לייצא נתוני BigQuery מ-us-east4 לאחסון בארכיון של Cloud Storage ב-us-central1. הייצוא הזה מספק גיבוי עמיד למקרה של אובדן נתונים קטסטרופלי ב-us-east4. בהגדרה הזו, יעד נקודת השחזור (RPO) הוא 24 שעות, כי הגיבוי האחרון יכול להיות בן 24 שעות לכל היותר. יעד זמן ההתאוששות (RTO) יכול להיות כמה ימים, כי צריך לשחזר את הנתונים מהגיבוי ב-Cloud Storage ל-BigQuery ב-us-central1. אם אתם מקצים את BigQuery באזור שונה מהגיבויים, קודם אתם צריכים להעביר את הנתונים לאזור הזה. אם לא תרכשו מראש משבצות מיותרות באזור השחזור, יכול להיות שייקח יותר זמן להקצות את הקיבולת הנדרשת ב-BigQuery, בהתאם לכמות שביקשתם.

תוכנית התאוששות מאסון (DR) לעיבוד נתונים באצווה

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

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

טיפול בשגיאות

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

ניסיון חוזר של בקשות API שנכשלו

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

שימוש בהשהיה מעריכית קטועה לפני ניסיון חוזר (truncated exponential backoff) הופך את האפליקציה לעמידה יותר בפני שגיאות זמניות. גם בתנאי הפעלה רגילים, אפשר לצפות שבערך אחת מתוך 10,000 בקשות תיכשל, כפי שמתואר בהסכם רמת השירות (SLA) של BigQuery לזמינות של 99.99%. בתנאים חריגים, שיעור השגיאות עשוי לעלות, אבל אם השגיאות מופצות באופן אקראי, השהיה מעריכית לפני ניסיון חוזר יכולה לצמצם את רוב הכשלים.

אם בקשה נכשלת שוב ושוב עם השגיאה 5xx, פנו ל-Cloud Customer Care וציינו בבירור את ההשפעה על העסק כשאתם מגדירים את רמת העדיפות של בקשת התמיכה, כדי שהתמיכה תוכל למיין את הבעיה בצורה מדויקת. לעומת זאת, אם בקשה נכשלת באופן עקבי עם שגיאת 4xx, אפשר לפתור את הבעיה על ידי שינוי האפליקציה. פרטים נוספים מופיעים בהודעת השגיאה.

דוגמה ללוגיקה של השהיה מעריכית לפני ניסיון חוזר (exponential backoff)

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

1. שולחים בקשה ל-BigQuery.

2. אם הבקשה נכשלת, צריך להמתין 1 + random_number_milliseconds שניות ולנסות שוב.

3. אם הבקשה נכשלת, צריך להמתין 2 + random_number_milliseconds שניות ולנסות שוב.

4. אם הבקשה נכשלת, צריך להמתין 4 + random_number_milliseconds שניות ולנסות שוב.

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

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

כמה דברים שחשוב לדעת על החישוב של זמן ההמתנה:

• זמן ההמתנה הוא min(((2^n)+random_number_milliseconds), maximum_backoff), כאשר n גדל ב-1 בכל איטרציה (בקשה).

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

• מרווח ההשהיה המקסימלי (maximum_backoff) הוא בדרך כלל 32 או 64 שניות. הערך המתאים ל-maximum_backoff תלוי בתרחיש לדוגמה.

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

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

ניסיון חוזר להוסיף משימות שנכשלו

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

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

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

אם בעיה זמנית ברשת מונעת מהלקוח לקבל אישור על הוספת משימה, ניסיון חוזר עם אותו מזהה משימה ייכשל עם השגיאה status=ALREADY_EXISTS (code=409 ו-reason="duplicate"). צריך להפעיל את jobs.get כדי לאחזר את הסטטוס של המשימה הקיימת ולקבוע אם ליצור משימה חדשה עם מזהה משימה חדש.

תרחישים לדוגמה ודרישות אמינות

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

ניתוח נתונים בזמן אמת

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

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

עיבוד נתונים באצווה

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

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