כיצד BigQuery של Google ביצעה דמוקרטיה של ניתוח נתונים. חלק 1

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

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

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

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

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

• BigQuery: מחסן נתונים ארגוני עם מנוע SQL מבוסס דראמל, אשר מפורסמת בזכות המהירות, הפשטות וההתמודדות שלה למידת מכונה.
• Data Studio: כלי להדמיה של נתונים גדולים עם תכונות שיתוף פעולה דמויות Google Docs.

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

היסטוריה של חנויות הנתונים של טוויטר

לפני שצולל לתוך BigQuery, כדאי לספר בקצרה את ההיסטוריה של אחסון הנתונים של טוויטר. בשנת 2011, בוצע ניתוח נתונים בטוויטר ב-Vertica ו-Hadoop. השתמשנו ב-Pig כדי ליצור משרות MapReduce Hadoop. ב-2012 החלפנו את Pig ב-Scalding, שהיה לו Scala API עם יתרונות כמו היכולת ליצור צינורות מורכבים וקלות בדיקה. עם זאת, עבור מנתחי נתונים ומנהלי מוצר רבים שהיה להם נוח יותר לעבוד עם SQL, זו הייתה עקומת למידה תלולה למדי. בסביבות 2016, התחלנו להשתמש ב-Presto כממשק SQL לנתוני Hadoop. Spark הציעה ממשק Python, מה שהופך אותו לבחירה טובה עבור מדעי נתונים אד-הוק ולמידת מכונה.

מאז 2018, השתמשנו בכלים הבאים לניתוח נתונים והדמיה:

• צריבה עבור מסועי ייצור
• Scalding ו-Spark לניתוח נתונים אד-הוק ולמידת מכונה
• Vertica ו-Presto לניתוח SQL אד-הוק ואינטראקטיבי
• דרואיד עבור גישה אינטראקטיבית נמוכה, חקירת והשהייה נמוכה למדידי סדרות זמן
• Tableau, Zeppelin ו- Pivot להדמיית נתונים

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

מחסן הנתונים BigQuery של גוגל

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

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

הנה תרשים ברמה גבוהה של ארכיטקטורת מחסני הנתונים של Google BigQuery שלנו.

אנו מעתיקים נתונים מאשכולות Hadoop מקומיים ל-Google Cloud Storage (GCS) באמצעות הכלי הפנימי Cloud Replicator. לאחר מכן אנו משתמשים ב-Apache Airflow כדי ליצור צינורות המשתמשים ב-"bq_load» כדי לטעון נתונים מ-GCS לתוך BigQuery. אנו משתמשים ב-Presto כדי לבצע שאילתות על מערכי נתונים של Parquet או Thrift-LZO ב-GCS. BQ Blaster הוא כלי Scalding פנימי לטעינת מערכי נתונים של HDFS Vertica ו-Thrift-LZO לתוך BigQuery.

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

קלות שימוש

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

המטרה שלנו להזנת נתונים ל-BigQuery הייתה לאפשר טעינה חלקה של מערכי נתונים HDFS או GCS בלחיצה אחת. שקלנו מלחין ענן (מנוהל על ידי Airflow) אך לא הצליחו להשתמש בו בגלל מודל האבטחה שלנו לשיתוף מוגבל בדומיין (עוד על כך בסעיף ניהול נתונים למטה). ניסינו להשתמש בשירות העברת הנתונים של Google (DTS) כדי לתזמן עומסי עבודה של BigQuery. בעוד ש-DTS מיהר להגדיר, הוא לא היה גמיש לבניית צינורות עם תלות. עבור מהדורת האלפא שלנו, בנינו מסגרת משלנו של Apache Airflow ב-GCE ומכינים אותה לפעול בייצור ולהיות מסוגלים לתמוך במקורות נתונים נוספים כמו Vertica.

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

פרודוקטיביות

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

ניתחנו למעלה מ-800 שאילתות שעבדו כ-1 TB של נתונים כל אחת ומצאנו שזמן הביצוע הממוצע היה 30 שניות. למדנו גם שביצועים תלויים מאוד בשימוש במשבצת שלנו בפרויקטים ומשימות שונות. היינו צריכים להגדיר בבירור את עתודות הייצור וחריצי האד-הוק שלנו כדי לשמור על ביצועים עבור מקרי שימוש בייצור וניתוח מקוון. זה השפיע רבות על העיצוב שלנו לשמירת משבצות והיררכיית הפרויקט.

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

קרא עוד:

• כלי לבניית נתונים או מה שמשותף בין Data Warehouse ל-Smoothie
• צלול לתוך אגם Delta: Schema Enforcement and Evolution
• פרקט אפאצ'י מהיר בפייתון עם חץ אפאצ'י

מקור: www.habr.com