אבל הרבה פעמים אני מגלה דיי מהר שאלו מונחים שימושיים, שכמו Patterns, עוזרים לנו לתקשר בצורה פשוטה ומדויקת יותר.
בפוסט זה אני רוצה לדבר על כמה מונחים כאלו, שיכולים להישמע ברגע ראשון כמו מונחים סתמיים – אך בעצם יש מאחוריהם כמה רעיונות חשובים.
בסיס הנתונים האופרטיבי – הוא בסיס הנתונים של המערכת, שם מוכנסים ומעובדים הנתונים לצורך תפעול המערכת השוטף. במקרה של Gett, למשל, זהו בסיס הנתונים בו נרשמות נסיעות, נהגים, לקוחות, וכו’.
כאשר אנו רוצים לבצע ניתוחים מקיפים על הנתונים במערכת האופרטיבית – יש בעיה אמיתית פשוט “להריץ שאילתות על בסיס הנתונים האופרטיבי”:
- האינדקסים ומבני-הנתונים בבסיס הנתונים האופרטיבי מותאמים לשימושים האופרטיביים (למשל: הכנסה ועדכון של רשומות בתכיפות גבוהה), ופחות לצרכים האנליטיים (למשל: שאילתות גדולות עם הרבה joins). התוצאה: השאילתות יכולות לקחת זמן רב מאוד.
- הפעלת שאילתות כבדות על בסיס-הנתונים האופרטיבי יכולות לפגוע בתפקוד השוטף. אמנם גם ניתוח נתונים הוא חשוב, אך הוא כמעט-תמיד פחות דחוף מהמשך הפעולה התקין של המערכת האופרטיבית.
התמודדות עם בסיס נתונים אופרטיבי “גדול מדי”
מה עושים?
בתור שלב ראשון אפשר לייצר Replica של בסיס הנתונים האופרטיבי – ולהריץ עליה את השאילתות.
אבל:
- רפליקה משכפלת את מבני-הנתונים והאינדקסים מבסיס הנתונים האופרטיבי – שכבר ציינו שאינם אופטימליים לשאילתות האנליטיות.
- אם נעמיס את הרפליקה יותר מדי, אנו עלולים לגרום להאטה גם בבסיס הנתונים הראשי – שעסוק בלהמתין לרפליקה שתקבל את העדכונים שלו.
השלב הבא בהתפתחות הוא ליצור מחסן נתונים (Data Warehouse, או בקיצור DWH או DW) – בסיס נתונים בו מאוחסן עותק של הנתונים מבסיס הנתונים האופרטיבי (ייתכן שב delay מסוים, נאמר שעה עד יממה) – אבל עם החופש ליצור סכמה שונה, ואינדקסים שונים.
 |
| מקור: הבלוג של James Serra |
כעת אנו יכולים לבצע שאילתות אנליטיות “כבדות” על ה DWH. הן:
- ירוצו מהר יותר – כי מבנה הנתונים / האינדקסים מותאמים לשאילתות.
- לא ישפיעו על הביצועים או ה Stability של בסיס הנתונים האופרטיבי (!Hurray)
- לשמור נתונים לטווח ארוך – וכך לשחרר את המערכת התפעולית מלאחסן אותם.
נאמר: ה DWH יכיל נתונים עשר שנים אחורה, בעוד בסיס הנתונים האופרטיבי – נתונים של חצי שנה אחרונה בלבד. - עבור הנתונים שיש הרבה מהם – שומרים לרוב סיכומים, ולא את כל הנתונים המקוריים שהיו במערכת התפעולית.
למשל: במקום סכום של כל עסקה – שומרים רק את סכום העסקאות היומי, מה שיכול לצמצם את כמות הנתונים בסדרי-גודל, ובהתאמה להקל על השאילתות האנליטיות (שרצות עכשיו על פחות נתונים).
יש לזה מחיר: אנו מאבדים נתונים – היכולת להבין את הפיזור המדויק של סכומי העסקאות, למשל. - להשתמש במהדורה מעט שונה של Database Server שמתאימה בצורה טובה יותר לצרכים אנליטיים. למשל: Vertica, Greenplum, Sybase IQ – הם בסיסי נתונים שמיועדים לשמש כ DWH.
מהפיכת הביג דאטה
- כמות הנתונים הנאספת – הלכה וגדלה, הלכה וגדלה.
- הדיסקים והזיכרון הפכו לזולים בצורה שוברת-שוויון. ספקי ענן אפשרו צריכה דינמית של כמות גדולה של משאבים במחירים מגוחכים.
- התפתחו טכנולוגיות חדשות, חלקן קשורות למחירי הדיסקים והזיכרון – המאפשרות ניתוח נתונים בצורות חדשות.
הגידול בכמות הנתונים לחץ על מערכי ה DWH הקיימים, וטכנולוגיות ה NoSQL/BigData החדשות – יצרו הזדמנות לשינוי.
ה DWH היה בשלב זה כבר פתרון מקובל, אך היו לחצים שהלכו וגברו:
- חלק מהנתונים החלו לנהל בבסיסי נתונים לא-רלציונים – שלא נתמכים / נתמכים בצורה חלקית ע”י כלי ה ETL המסורתיים. מצבים של אי-עקביות בנתונים (inconsistency) וסכמה דינמית (למשל ב Document Databases) הפכו את מלאכת ה ETL ל”גיהינום” עבור ה DBAs.
- כמות הנתונים במערכת האופרטיבית גדלו בצורה דרמטית – מה שגם הקשה על ה ETL להתבצע בזמנים טובים ו / או להישאר מעודכן לכל סוגי הנתונים שנוספו.
- ברגע שה DWH לא מעודכן בכל הנתונים האחרונים, מערכות ה BI הן כבר פחות טובות – והמשתמשים הזקוקים לנתונים מתחילים למצוא “דרכי-מעקף” על מנת להשיג ולנתח את הנתונים שלהם.
- כל המידע נאסף, בצורה גולמית וללא עיבוד (“as-is”), מהמערכות התפעוליות – ונשמר על גבי שטח האכסון האינסופי (Hadoop, S3, או Azure Data Lake).
- נתונים שהמערכת התפעולית לא יכולה להמשיך ולשמור (משיקולי ביצועים) – נשמרים ולא נזרקים.
- נגמר המירוץ של ה DBAs לעקוב ולהתאים את ה ETL לשינויי הסכמה במערכת התפעולית. המנגנון החדש יודע לאסוף את כל הנתונים.
- מאוחר יותר, כשיהיה צורך מעשי בנתונים – ינקו אותם, יסכמו אותם, וינתחו אותם, באותו הרגע.
- ה Stack של Hadoop – נבנה ממש לצרכים שכאלו.
- Avro – פורמט כללי, שדוחס את הנתונים ומאפשר לחלק קובץ ל-2 מבלי לקרוא את כולו (כי הנתונים שמורים במבנה ידוע). זו תכונה חשובה ל Map-Reduce.
- Parquet – פורמט ששומר את הנתונים בצורה Columnar ומאפשר לקרוא מהדיסק את עמודות ספציפיות של הנתונים. הדחיסה כאן היא אפילו גבוהה יותר, כי הדמיון בין ערכים באותה עמודה – הוא באופן טבעי גבוה יותר.
Hadoop, למשל, לא מתנהג יפה עם הרבה קבצים קטנים – ולכן יש להכין לו קבצים גדולים יותר, המסכמים “אצווה של רשמות”.
 |
| תהליך ELT. מקור: www.ironsidegroup.com |
- מהגישה החרוצה: ניקוי, ארגון, וסיכום הנתונים ואז שמירה שלהם מה DWH – המאפשרת שליפה קלה.
- לגישה העצלה: שמירת כל הנתונים המלוכלכים, raw, עם כפילויות וחוסרי התאמות ב Data Lake. ניקוי וסידור הנתונים יתבצע – רק ברגע שרוצים לתשאל אותם.
 |
| מקור: Martin Fowler |
- הסכמה וצורת שמירת הנתונים השתנו עשרות פעמים בתקופה – ואין לנו דרך לדעת בדיוק ממתי השינוי. שמירת שדה “version” על הנתונים במקור – היה יכול להיות השקעה קטנה שתחסוך זמן רב בעתיד.
- נתונים שחסר איזה מפתח או נתון לקשר ביניהם. אם היינו מוסיפים זאת במקור – זו הייתה תוספת קטנה מאוד, אבל כיום צריך להתחיל להריץ יוריסטיקות וניתוחים – רק על מנת לקשר את הנתונים שהיו עד לא מזמן “במרחק נגיעה”.
- שמירת נתונים בצורה אחידה, למשל שמירת תאריכים בפורמט אחיד (האם 1/4/12 זה אפריל או ינואר?) – או הקפדה על שמירת ה timezone הרלוונטי. נתונים שלא נשמרו כך – בדיעבד קשה לנקות ולסדר.
- שמירת פרטים על המערכת ממנה מגיעים כל מקבץ-נתונים – יכול לסייע מאוחר יותר לקבוע את האיכות שלהם, או לשפר אותה.
- לאסוף “חוסרי-נתונים”. יש סיפור על חברת טלקום שבנתה מערך Big-Data מרשים, אבל שכחה לאסוף אינדיקטור על ניתוק שיחה (שלא נשמר בבסיס הנתונים האופרטיבי – אני מניח). אחרי שנה+ של צבירת נתונים, היא לא הייתה מסוגלת לנתח בעיות במערכת – כי היה לה רק “מידע חיובי”.
נקודה זו מתייחסת גם לנתונים שהמערכת האופרטיבית “תיקנה”, למשל – כאשר היא קובעת “ערך מקסימום” לסוג נתון כלשהו, עדיין עשוי להיות מעניין מה היה הערך המקורי. - כדאי לעקוב ולתעד את השמירה של מידע רגיש (מספרי טלפון של משתמשים, למשל) – כדי שיהיה ניתן להגן עליו. לא כל אנליסט עסקי אמור להיות מסוגל לגשת לנתונים הללו.
ה RAW הם נתונים שהגיעו מהמערכות התפעוליות ללא כל עיבוד, כאשר ה Gold הוא storage של הנתונים לאחר עיבוד מסוים. ה Work הוא אזור העבודה של ה Data Scientists, ויש אזור Sensitive אליו מעבירים את כל הנתונים הרגישים (שמחליטים לשמור. לפעמים פשוט מטשטשים אותם).
נוטים לרוב להבחין בין אנשי BI / Data Analysts שעובדים מול נתונים נקיים יחסית (“Gold”) ל Data Scientist – שמבינים טוב יותר את הבעיות השונות של נתונים (חוסר עקביות, פורמטים לא-אחידים, סתירות), ויכולים אף לכתוב custom code בכדי “לנקות נתונים קשים”.
DWH ו Data Lake הם לא רק גישות הפוכות: בד בבד – הן גם גישות משלימות.
יש נתונים שנכון יותר לאחסן ב DWH, ויש כאלו שב Data Lake, ועצם קיום שני הכלים זה-לצד-זה – מאפשר מנעד רחב יותר של יכולות.
חלוקת הנתונים בארגון
כמו תמיד, הארכיטקטורה הנקייה, בה יש DWH אחד ו Data Lake אחד ממנו כל הארגון צורך נתונים, היא טובה – בעיקר כתיאוריה.
לרוב בארגון יהיו לנו צרכים שונים של נתונים, ויהיה קשה למצוא פתרון אחד שיספק את כולם. למשל:
- מחלקת הכספים מוכנים לוותר על פירוט של כל עסקה ועסקה – ולהסתפק בסכום יומי, על עוד המידע נשמר ל-7 שנים לפחות.
- מחלקת המכירות דווקא רוצה לדעת פירוט מלא על העסקאות – ולנתח מהן מגמות. לצורך זה הן זקוקות לכל נתוני-העסקאות, אבל מספיק להם שנה אחת אחורה.
בסה”כ זה סיפור קלאסי של trade-offs כאשר ליחידות ארגוניות שונות, מתאימים trade-offs שונים ברמת הנתונים.
לעתים אלו יחידות עסקיות שונות (כספים, מכירות, שירות), לעתים זו רמת-פירוט (הנהלה בכירה, תפעול בשטח) ולעתים חלוקה אחרת (למשל: התפעול של ארה”ב מול התפעול של אירופה).
 |
| מקור: datamartist.com |
מתוך כך צצו, עוד בימי ה DWH – “מרכולי הנתונים” (Data Marts), שהם סוג של DWH קטן וממוקד.
- הוא משרת יחידה מוגדרת בארגון.
- לרוב הוא מנוהל על שרת בסיס נתונים משלו (אבל הוא יכול גם להיות עוד סכמה ב DWH).
- לרוב הוא שואב נתונים רלוונטיים מה DWH בפילוח מסוים, ומוסיף עליהם עוד נתונים ספציפיים שלא מגיעים ל DWH.
ישנן עוד כמה שאלות הנוגעות לקשר בין ה DWH ל Data Marts. למשל: האם קודם יוצרים את ה DWH ואז גוזרים ממנו Data Marts, או האם נותנים ליחידות Data Marts ואז אוספים אותם ליצירת DWH ארגוני? אם ישנם נתונם שנכונים ל-2 Data Marts, האם להחזיק אותם ב Data Mart שלישי או ב DWH? וכו’…
 |
| מקור: datamartist.com |
סיכום
- להשתדל לאסוף ל Data Lake נתונים ברזולוציה של אירועים בעלי משמעות עסקית (קנייה, הצעת מחיר, רישום, וכו’).
- זו הרזולוציה שלרוב יהיה מעניין לנתח.
- לשלוח את הנתונים ל Data Lake לא כשהם ממש Raw, אלא לאחר עיבוד-קל (“Medium-Rare”):
- להשתדל “לשטח” לתוך האירוע נתונים חשובים שיהיה קשה לקשר אותם מאוחר יותר. למשל: באירוע הצימוד בין נהג ונוסע, מעניין לשמור את המיקומים המדויקים שלהם באותו הרגע, כפי שהם ידועים לשרת. חלק הקוד שמפיק את אירוע-הנתונים יכול לספק נתון כזה בקלות יחסית, אבל להגיע לתובנות כאלו בדיעבד – זה יכול להיות קשה, ואפילו לא מדויק. הבנה עמוקה של הביזנס – היא כמובן המפתח להחלטה.
- להוסיף metadata שבסבירות גבוה יכול להיות שימושי בעתיד: גרסה של מבנה הנתונים, מה לא נשמר ומאיזו סיבה, ציון תיקונים שנעשו בנתונים או ציון נתונים רגישים, וכו’
- להחליט ע”פ הצורך אילו נתונים רוצים להכין / “לנקות” ב Data Lake בצורה יזומה (“Golden Data” או “tidy data”) – כדי שיהיו זמינים לניתוח מהיר. אלו לרוב הנתונים שמתארים את המדדים הביצועיים החשובים של הארגון.
- לנסות ליצור סדר מובן ב Data Lake, ולא להפוך אותו ל Data Swamp. איזה סדר? מה שמתאים לצרכים הייחודיים של הארגון שלכם.
- אנשים בתחום מדברים על תכון ה data pipeline (תהליך ניהול הנתונים) ו / או ה data lineage (המסלול והתחנות בו עוברים הנתונים לאורך חייהם).
- (שנוי במחלוקת): נסו להוסיף נתונים ל Data Lake ב Pull (כלומר: ע”פ צורך ניתוח ממשי), ולא ב Push (כלומר: כי הם שם).
- היתרון: יהיה לכם הרבה פחות “זבל” ו”בלאגן” ב Data Lake.
- החיסרון: לא תוכלו לחקור נתונים שלא שמרתם.
- “לשחק” בציר היכולות (ה trade-offs) בין Data Warehouse ובין Data Lake.
- “לשחק” בציר היכולות בין ארגון מידע ריכוזי (DWH או Data Lake מרכזי) לארגון מידע מבוזר ע”פ צרכים (Data Marts או אזורים ספציפיים ב Data Lake).
שיהיה בהצלחה!
כתבה מצוינת. תודה.
מעניין מאוד, תודה !
מרתק! תודה רבה!
מרתק! תודה רבה!
החכמתי, תודה.
הרבה מושגים שהתבהרו! תודה.
מאמר מרתק, תודה רבה!
תודה!
אני מזדהה עם התחושה (ביטויים פלצניים וכו'), אבל בהחלט עשית פה סדר. קצר וקולע!
כתבת עומק ברורה. כל הכבוד
מצוין