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

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

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

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

בוחרים באפשרות BigQuery

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

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

היבטים של מהימנות ב-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 מאחסנת באופן אוטומטי עותקים של הנתונים בשני Google Cloud אזורים שונים בתוך אזור יחיד במיקום שנבחר.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

נניח שהמשתמש הגדיר ייצוא יומי של נתוני BigQuery ב-us-east4 באמצעות משימות חילוץ ל-Cloud Storage במסגרת סיווג האחסון Archive ב-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, עליכם להעביר את הבעיה לטיפול של Google Cloud התמיכה. חשוב לציין בבירור את ההשפעה של הכשל על העסק, כדי שנוכל לתעדף את הטיפול בבעיה בצורה נכונה. לעומת זאת, אם בקשה נכשלת באופן עקבי עם שגיאה מסוג 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החלטה, הלקוח צריך לציין את מזהה העבודה כדי למנוע ניסיון חוזר לצרף את אותם נתונים בפעם השנייה. השיטה הזו פועלת כי 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. קבלת הדוחות האלה בזמן וללא שגיאות היא דרישה עסקית קריטית. לכן, חשוב לוודא שהנתונים נקלטים בצורה מהימנה ושהדוח נוצר בצורה נכונה ובמסגרת זמן עקבית כדי לעמוד בלוחות הזמנים הנדרשים.