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

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

קרא את החלק הראשון

ניהול נתונים

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

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

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

• שיתוף מוגבל בדומיין: תכונת בטא כדי למנוע ממשתמשים לשתף מערכי נתונים של BigQuery עם משתמשים מחוץ ל-Twitter.
• בקרות שירות VPC: פקד המונע חילוף נתונים ודורש ממשתמשים לגשת ל-BigQuery מטווחי כתובות IP ידועים.

יישמנו דרישות אימות, הרשאות וביקורת (AAA) לאבטחה כדלקמן:

• אימות: השתמשנו בחשבונות משתמש של GCP עבור בקשות אד-הוק וחשבונות שירות עבור בקשות ייצור.
• הרשאה: דרשנו שלכל מערך נתונים יהיה חשבון שירות בעלים וקבוצת קוראים.
• ביקורת: ייצאנו יומני BigQuery stackdriver, שהכילו מידע מפורט על ביצוע שאילתות, לתוך מערך נתונים של BigQuery לניתוח קל.

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

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

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

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

באשר לרישום, השתמשנו במשימות מתוזמנות כדי לספור מערכי נתונים של BigQuery ולרשום אותם בשכבת הגישה לנתונים (DAL), מאגר מטא נתונים של טוויטר. משתמשים יביאו הערות למערכי נתונים עם מידע פרטיות וגם יציינו תקופת שמירה. באשר לניקיון, אנו מעריכים את הביצועים והעלות של שתי אפשרויות: 1. ניקוי מערכי נתונים ב-GCS באמצעות כלים כמו Scalding וטעינתם לתוך BigQuery; 2. שימוש בהצהרות BigQuery DML. סביר להניח שנשתמש בשילוב של שתי השיטות כדי לעמוד בדרישות של קבוצות ונתונים שונים.

פונקציונליות המערכת

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

עלות

Наш предварительный анализ показал, что стоимость запросов для BigQuery и Presto была на одном уровне. Мы приобрели слоты по קבוע מחיר שיהיה עלות חודשית יציבה במקום תשלום לפי דרישה לכל TB של נתונים מעובדים. החלטה זו התבססה גם על משוב ממשתמשים שלא רצו לחשוב על עלויות לפני כל בקשה.

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

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

השלבים הבאים

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

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

הנה כמה מבקשות התכונה בעדיפות גבוהה שלנו עבור Google:

• כלים לקליטת נתונים נוחה ותמיכה בפורמט LZO-Thrift.
• פילוח לפי שעה
• שיפורי בקרת גישה כגון הרשאות ברמת הטבלה, השורה והעמודה.
• BigQuery מקורות נתונים חיצוניים עם אינטגרציה של Hive Metastore ותמיכה בפורמט LZO-Thrift.
• שילוב משופר של קטלוג נתונים בממשק המשתמש של BigQuery
• שירות עצמי להקצאת משבצות וניטור.

מסקנה

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

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

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

מילות תודה

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

אם אתה מעוניין לעבוד על בעיות אלה, בדוק את שלנו משרות פנויות בצוות Data Platform.

איכות נתונים ב-DWH - עקביות במחסן נתונים

מקור: www.habr.com