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

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

ההקדמה הזו עוזרת לכם להתייחס לשלושה שיקולים עיקריים:

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

בחירה ב-BigQuery

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

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

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

זמינות

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

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

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

עמידות

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

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

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

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

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

שחזור נתונים

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

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

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

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

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

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

טיפול אוטומטי בתרחישים

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

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

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

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

אובדן של אזור

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

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

סוגי הכשלים

יש שני סוגים של כשלים: כשלים זמניים וכשלים קבועים.

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

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

זמינות ועמידות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

תרחיש שימוש: עיבוד נתונים באצווה

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

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

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

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

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

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

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

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

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

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

1. שליחת בקשה אל BigQuery.

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

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

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

5. וכך הלאה, עד (maximum_backoff) פעמים.

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

שימו לב לנקודות הבאות:

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

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

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

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

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

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

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

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

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

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

תרחישי שימוש ודרישות מהימנות

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

דיווח בזמן אמת

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

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

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

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

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