אפשר להפחית עלויות ב־Google Cloud BigQuery באמצעות צמצום סריקות נתונים מיותרות, מניעת חישובים חוזרים והגדרת מכסות לשליטה בצריכה. ב־Investing.com, הגדרת מכסות הורידה את ההוצאה החודשית מכ־3,000 דולר לכ־600 דולר, ירידה של 80%. בהמשך, שינויים בארכיטקטורה אפשרו לעבד פי חמישה נתונים במסגרת התקציב החודשי המקורי של כ־3,000 דולר.
לצפייה ב־YouTube (נפתח בכרטיסייה חדשה) (ההרצאה באנגלית)
איך הפחתנו את עלויות BigQuery ב־Investing.com
כשהתחלתי לעבוד על פרויקט ה־BigQuery ב־Investing.com, החשבון החודשי היה כ־3,000 דולר. בתוך חודש הוא ירד לכ־600 דולר. השינוי הראשון היה הגדרת מכסות לשאילתות.
בשנה שלאחר מכן שינינו גם את הארכיטקטורה. היקף הנתונים שעיבדנו גדל מכ־20 TB לכ־100 TB, כשההוצאה החודשית חזרה לכ־3,000 דולר. הירידה הראשונית של 80% והיכולת לעבד יותר נתונים בתקציב המקורי היו שני הישגים נפרדים, בשלבים שונים של העבודה.
מאחורי המספרים היו החלטות הנדסיות מוכרות: אילו נתונים לסרוק, מה לחשב מראש ובאיזו תדירות באמת צריך לרענן דוחות. אלה השיקולים שהצגתי בהרצאה במסגרת Big Data Demystified, ועליהם מבוסס המאמר.
מציבים גבול לטעויות יקרות
התחלתי ממכסות כי הן אפשרו להגביל את הצריכה מיד. הן גם הכניסו את עלות השאילתות לשיקולים של הצוות בעבודה היומיומית.
חשוב להבין מה מכסה עושה: היא מגבילה את היקף העבודה שאפשר להריץ. היא אינה מוזילה את השאילתה עצמה, וכשמגיעים לתקרה, שאילתות נוספות עלולות להיחסם. לכן, הירידה הראשונית של 80% היא ירידה בהוצאה בעקבות הגבלת הצריכה, ולא מדידת ביצועים שמראה שאותו עומס עבודה התבצע בחמישית מהעלות.
במודל תמחור לפי שימוש, On-demand, אפשר להגדיר מכסות יומיות ברמת הפרויקט והמשתמש. ברמת השאילתה, הגדרת maximum bytes billed מונעת את הרצתה אם אומדן נפח הנתונים לחיוב חורג מהסף שנקבע. פירוט מופיע בתיעוד בקרת העלויות של Google (נפתח בכרטיסייה חדשה).
צריך להשאיר מרווח לעבודה החיונית. בהגדרות שתיארתי, המכסה למשתמש הייתה נמוכה מהמכסה הכוללת של הפרויקט, כדי שטעות של אדם אחד לא תנצל את כל ההקצאה. את הגבולות קובעים לפי המשתמשים והתהליכים שחולקים את הפרויקט.
בודקים מה השאילתה קוראת בפועל
כדאי להתחיל מ־SELECT *. אם אנליסט צריך שתי עמודות מתוך מאה, קריאת כל המאה מוסיפה עבודה שאין בה צורך לצורך הניתוח.
גם LIMIT עלול להטעות: התוצאה שמוצגת קטנה, אבל הסריקה לא בהכרח קטנה איתה. בטבלאות ללא Clustering, הוא אינו מצמצם את נפח הנתונים שנקרא. לבדיקת שורות לדוגמה משתמשים ב־Preview; בניתוח עצמו בוחרים את העמודות הנחוצות ומסננים את המחיצות הרלוונטיות. ראו הנחיות Google לאופטימיזציית שאילתות (נפתח בכרטיסייה חדשה).
אם השאילתות מסננות באופן קבוע לפי עמודות מסוימות, כדאי לבדוק גם Clustering. הוא יכול לאפשר ל־BigQuery לדלג על בלוקים לא רלוונטיים. בחירת העמודות והסדר שלהן צריכה להתאים לשאילתות שמריצים בפועל, ואת ההשפעה בודקים לפני השינוי ואחריו. ראו שאילתות על טבלאות עם Clustering (נפתח בכרטיסייה חדשה).
View חוסך תחזוקה, אבל עדיין עולה כסף בשימוש
מצאנו שכ־60% מעומס העבודה שלנו יכול להתבסס על Views במקום על תהליכי ETL נפרדים. המשמעות הייתה פחות תהליכים לפתח ולתחזק.
העלות עוברת למקום אחר. View לוגי שומר את לוגיקת ה־SQL, והשימוש בו מפעיל את השאילתה שמאחוריו. חוסכים בתחזוקת תהליך עיבוד נפרד, ומשלמים על העיבוד בזמן השימוש. ראו תיעוד ה־Views של BigQuery (נפתח בכרטיסייה חדשה).
לניתוח שמתבצע מדי פעם, זו יכולה להיות בחירה טובה. שאילתה כבדה שרצה כל חמש דקות מצריכה שיקול אחר. במקרה כזה הייתי בודק אם כדאי לחשב את התוצאה מראש ולתת למשתמשים לעבוד מול טבלת סיכום קטנה.
למשל, דאשבורד שמציג סיכומים יומיים יכול לעיתים לקרוא טבלת סיכום במקום לחשב אותם מחדש מהאירועים (events) הגולמיים בכל רענון. השאלה היא אם עדכון הטבלה עולה פחות מהחישובים החוזרים שהיא חוסכת. לעומסי עבודה מתאימים אפשר לבחון גם Materialized View. ראו ההשוואה של Google בין סוגי ה־Views (נפתח בכרטיסייה חדשה).
סופרים גם את הרענונים
בדוגמת דיווח נוספת שהצגתי, שאילתה שנראתה זולה הפכה להוצאה משמעותית בגלל רענונים חוזרים. העלות של הרצה אחת הסתירה את עלות השימוש בדוח לאורך היום.
כדאי לבדוק מה קורה כשפותחים דאשבורד, משנים פילטר או מרעננים גרף. אותה בדיקה רלוונטית לתהליכי העיבוד: אם השתנו רק הנתונים של אתמול, האם צריך לבנות מחדש את כל טווח הדיווח? נתונים שמגיעים באיחור ותיקונים יכולים להצדיק עיבוד חוזר, אבל הם צריכים לקבוע כמה רחוק חוזרים בהיסטוריה.
Caching יכול לעזור כשאפשר להשתמש שוב בתוצאות. מטמון התוצאות של BigQuery מונע חיוב על שאילתה כשמתקיימים תנאי השימוש בו, ובהם טקסט שאילתה זהה ונתוני מקור שלא השתנו. לפני שמניחים ששאילתה חוזרת תהיה ללא עלות, בודקים את תנאי השימוש במטמון (נפתח בכרטיסייה חדשה).
מגדירים כמה עדכניים הנתונים צריכים להיות
ב־Investing.com, הניתוחים שתיארתי עסקו בימים, שבועות וחודשים. לא היה צורך בקליטת נתונים ב־Streaming עבורם, כי ניתוח השעה האחרונה לא היה דרישה.
הצורך הזה עזר לקבוע את תדירות העיבוד. דוח הנהלה יומי והתראה תפעולית עשויים לדרוש פתרונות שונים, גם כשהם מבוססים על אותם נתוני מקור.
הפרדתי את קליטת הנתונים, העיבוד, המודלים האנליטיים וצריכת ה־BI לשכבות נפרדות. כך אפשר היה לבחור טכנולוגיה לכל שלב ולהחליף מימוש יקר בלי לבנות מחדש את כל מה שסביבו.
גם התחזוקה הייתה שיקול. בבדיקות שתיארתי, מנוע עיבוד חלופי יכול היה להוזיל חלק מהשלבים, אבל דרש יותר עבודה על כוונון ותפעול. גם לזמן הזה של צוות ההנדסה יש עלות.
בודקים מה התקציב מאפשר לבצע
התוצאה בהמשך הדרך הייתה עיבוד של פי חמישה נתונים בקירוב, במסגרת התקציב החודשי המקורי. לכן אני בוחן את החשבון לצד היקף העבודה שהמערכת מאפשרת לבצע.
בהשוואה כדאי לכלול נפח נתונים, תדירות שאילתות, זמינות דוחות ומאמץ תחזוקה. אם החשבון ירד כי אנשים כבר לא יכולים להריץ את הדוחות הדרושים להם, עדיין יש בעיה שצריך לפתור.
ההרצאה המקורית התייחסה לתמחור וליכולות המוצר במועד הקלטתה. בבדיקה כיום צריך להביא בחשבון אם העבודה מחויבת לפי שימוש או לפי קיבולת, משום שמודל החיוב משפיע על האופן שבו שיפור בעיבוד מתורגם לחיסכון. ראו תמחור BigQuery העדכני (נפתח בכרטיסייה חדשה).
הייתי מתחיל מתהליך אחד שחוזר על עצמו: בודק מה הוא קורא, כמה פעמים הוא רץ ואם באמת צריך לחשב את התוצאה בכל פעם מחדש. כך אפשר למדוד שינוי מוגדר לפני שנכנסים לתכנון מחדש של המערכת.