נושאים מתקדמים ב MySQL: חלק א' – עבודה עם JSON

פוסטים בסדרה:
"תסביר לי" – גרסת ה SQL
לקחת את הביצועים ברצינות, בעזרת MySQL Performance Schema
נושאים מתקדמים ב MySQL: חלק א' – עבודה עם JSON
נושאים מתקדמים ב MySQL: חלק ב' – json_each  ו Generated Columns

MySQL הוא בסיס-נתונים פשוט.

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

גרסה 8 שיצאה לא מכבר הייתה עשויה להיקרא גרסה 5.8 – היא הוסיפה כמות נאה של תוספות, אבל בוודאי לא מהפיכה. (במיוחד לאחר שכמה שינויים זכו ל down-port לגרסה 5.7). לא ניתן להשוות אותה לחידושים של גרסה 5.

MySQL עדיין בסיס הנתונים הפופולרי ביותר בעולם אחרי Oracle המסחרי, ובפער גדול גם על PostgreSQL שזכה לצמיחה יפה בשנים האחרונות. MariaDB – ה fork של MySQL שמשוחרר מההשפעה של חברת אורקל, נמצא במקום 13 ברשימה למטה, ואפשר להחשיב אותו כעוד פלח-שוק של MySQL – וכנראה כמחליף העתידי.

מקור: DB-engines.com

אם אתם עובדים בסטארט-אפ – אזי יש סיכוי טוב ש MySQL נמצא בסט הכלים שלכם.

הרבה פעמים נתקלתי בטיעונים שעדיף להשתמש ב MongoDB או PostgreSQL על פני MySQL.
כשניסיתי לחקור מדוע, קיבלתי מגוון תשובות שלא שיכנעו אותי:

  • "בסיסי-נתונים רלציונים הם העבר"
  • "ל PostgresSQL יש יותר שיטות לבצע join – אז הביצועים שלו טובים יותר"
  • "בכנס חשוב-כלשהו היו 3 הרצאות על PostgreSQL ורק אחת על MySQL"
  • "ל MySQL אין רפליקציה טובה (כמו ל Mongo, לכאורה)". "הוא לא בנוי ל Scale".
  • "ל Postgres יש פי 3 יכולות מאשר ל MySQL".
אלו דוגמאות לטיעונים לא לא עקרוניים. יש הרבה רצון לחדש ולעבוד עם "בסיס נתונים חדש יותר" – אבל גם המוכר והלא buzzy יכול להיות מוצלח מאוד.
נוכחתי לאורך הקריירה בכמה יוזמות אימוץ של "בסיס נתונים מתקדם יותר" – שנגמרו במפח-נפש.
שלא תבינו לא נכון: PostgreSQL ו MongoDB (ועוד אחרים) הם Databases מרשימים וטובים – אבל גם להם יש חסרונות, ואם אתם עושים מעבר – חשוב מאוד שתהינה לכן סיבות עמוקות ומבוססות. חבל להשקיע חודשים במעבר ואז לגלות שחיסרון חדש מעיב על כל המאמץ שהושקע. מעבר של בסיס נתונים במערכת "חיה" הוא שינוי לא-קל. הכלל הזה נכון גם לגבי מעבר ל MySQL – כמובן.
דיאגרמה (לא בהכרח מאלה) של Databases בתחום הרלציוני. מקור: 451 Research.

בכמה פוסטים הקרובים הייתי רוצה להתעמק קצת ביכולות של MySQL. יחסית לפופולריות השימוש שבו, MySQL לא "מסופר" בצורה טובה , כבר כמה שנים טובות. הרבה יכולות טובות נוספו בכמה שנים הללו – אך נראה שחלק נכבד מקהל השמתמשים לא מכיר אותן.
אמנם עכשיו עם השחרור של MySQL גרסה 8, הולכים ויוצאים ספרים חדשים – אך חלק גדול מהפוקוס שלהם הוא על מה שחדש בגרסה החדשה, ופחות במה שאפשר לעשות עם גרסה 5.7 – שהיא כנראה תישאר הגרסה הדומיננטית בשנתיים הקרובות (בסיס נתונים לא משדרגים כ"כ מהר – וטוב שכך).

הנה רשימת של נושאים שנראים לי מעניינים:

    • עבודה עם JSON וה Document Store.
    • Generated columns
    • פיצוי על יכולות חסרות ב MySQL כמו json_each או fist_value/last_value – איך אפשר להסתדר בלעדיהם.
    • מנועי Storage וההבדלים ביניהם: InnoDB ל MyISAM, וכו' (לא חדש בכלל – אך ידע חסר, ממה שנתקלתי).
    • סטטיסטיקות של אינדקסים וטבלאות – ואיך זה משפיע עלינו (גם לא חדש).
    • Full Text indexes
  • Partitioning
  • Large Hadron Migrator- https://github.com/soundcloud/lhm, ביצוע migrations גדולים ללא downtime.
כל הנושאים הנ"ל הם נושאים שלי יצא באופן אישי, או לאנשים מסביבי להשתמש בהם. הם נושאים ישימים ופרקטיים – עד כמה שאני יכול לומר.

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

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

JSON וה MySql Document Store

לפני כעשור, עולם ה Databases התחלק ל-2 קבוצות דומיננטיות של שימוש עיקרי:

  • בסיסי-נתונים רלציוניים
  • בסיסי-נתונים מבוססי-מסמכים (Document-Based)
* נכון, יש גם K/V DB שנמצאים בשימוש נרחב, וגם columnar, wide-column, וגם graph ו time series – אך עדיין בסיסי נתונים רלציוניים ו document-based אחראים למגוון הגדול יותר של הנתונים והשימושים.
ההרכב הנפוץ הוא שארגון מחזיק את רוב האובייקטים בבסיס נתונים רלציוני / מסמכים, והיכן שצריך scale גבוה יותר – פונה לפתרונות יותר ממוקדים לצורך הספציפי.

בסיסי הנתונים מבוססי המסמכים (כמו CouchDb, MongoDB) הציגו חזון מסעיר וחדשני, יחסית לבסיסי-הנתונים הרלציוניים – והיה נדמה שהם עומדים לכבוש את עולם בסיסי-הנתונים בסערה. הנה פוסט עתיק שלי על MongoDB (שלום, מונגו!)
המהפכה הזו לא קרתה כפי שחזו – אך היא בהחלט השפיעה על עולם בסיס הנתונים.
אנשי תוכנה רבים, החלו ליישם עקרונות של בסיסי-נתונים מבוססי-מסמכים על בסיסי-נתונים רלציוניים (הנה פוסט ישן נוסף, המתאר כיצד עושים זאת: עשה זאת בעצמך: NoSQL).
בסיסי הנתונים הרלציוניים, החלו לספק גם יכולות של ניהול מסמכים (או JSON snippets, לפחות. ה"מסמכים" הכי שימושיים), והיום יש יכולות Document כאלו ואחרות ברוב בסיסי-הנתונים הרלציוניים המוכרים. השילוב הזה – מאוד מוצלח, לטעמי.
מאז MySQL גרסה 5.7.12 (אמצע 2016, בעזרת plugin) יש ל MySQL ממשק עבודה שדומה מאוד לעבודה מול בסיס-נתונים מבוסס מסמכים, מה שנקרא The MySQL Document Store:
  • "מסמכים" (כלומר: JSON), מאוחסנים ב Collections.
    • מאחורי הקלעים, לאכסון collection של מסמכים, נוצרות טבלאות בנות שתי-עמודות id_ ו doc (כמו שהיינו עושים פעם, בעצמנו…)
  • בעזרת API (או ה shell החדש, mysqlsh) ניתן לגשת ל"מסמכים" ב API המוכר מבסיסי-נתונים מבוססי-מסמכים. למשל:
    • ("db.product.find('_id = "iPhone XI
    • (…)db.createCollection
    • (…)add(…), sort(…), modify, וכו'
  • את המסמכים ניתן לאנקס
    • מאחורי הקלעים MySQL יוצר generated columns – נושא שארצה לכסות בהרחבה.
  • ל API יש clients זמינים ל JavaScript ול Python – אם כי כמה פעולות, תחזוקה וטיפול בעיקר, עדיין יש לעשות ב SQL.
אף פעם לא "נפלתי" מהממשק של ה Documents Stores ולכן מעולם משך אותי לנסות ולהשתמש ב MySQL Document Store.
אני אישית מעדיף בהרבה לעבוד בסגנון מעורב (רלציוני-Document).

הייתי שמח מאוד להיות מסוגל לעשות מניפולציות על json ב js או פייטון המקונן בתוך שאילתת SQL – אך לצערי לא נראה שהשוק הולך לשם…
עדכון: תודה לנדב נווה שעדכון אותי שכן יש plugin ל User Defined Functions ב js עבור MySQL. מעניין!

עדיין, לא נראה שה plugin הזה נתמך ע"י AWS RDS. חבל…

JSON ב MySQL דרך SQL

column מטיפוס JSON הוסף ב MySQL גרסה 5.7.8 (אוג' 2015), אם כי ניתן להשתמש ביכולות ה JSON שנוספו לבסיס הנתונים גם על גבי עמודות מסוג text, varchar, BLOB וכו'. עמודות טקסטואליות.

אם אתם רוצים לשמור בבסיס הנתונים ייצוג של אובייקט או מבנה היררכי מורכב – קידוד שלו ל JSON יהיה פשוט עשרות מונים מיצירת קבוצה של סכמות (טבלאות) רלציוניות שיכילו את אותו המידע ויתארו את ההיררכיה.

יתרון נוסף בשימוש ב"מסמך" JSON הוא האטומיות: הכל משתנה ביחד – הכל, או לא כלום.
בקבוצה של סכמות יהיה עליכם להתעסק עם טרנזקציות בכדי לקבל הגנה בפני 2 תהליכים שמשנים באופן לא-עקבי שני חלקים של האובייקט. טרנזקציות על עדכון של שורה של טבלאות (פעם ראיתי אובייקט שמופה ל 35 טבלאות שונות בבסיס הנתונים) – הוא לא דבר פשוט.

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

  • יש ב MySQL תחביר המאפשר לאמוד אם שדה x בתוך אובייקט o שבתוך ה JSON כחלק מפקודת WHERE.
    כמו שנראה בהמשך, כשמבנה ה json הוא מורכב יותר – זה הולך והופך להיות קשה יותר.
  • ביצועים: כאשר אנו רוצים להשוות שדה אחד מתוך אובייקט עם 50 שדות – עלינו לטעון לזיכרון את כל 50 השדות בכל פעם, שזה הרבה I/O מיותר (מדד חשוב מאוד בביצועים של בסיסי-נתונים).
    הגישה המקובלת להתמודד עם בעיית הביצועים היא להוציא לעמודות מקבילות לעמודת ה JSON "שכפול" של שדות אותן נרצה לתשאל בצורה תדירה (ולכן גם לאנדקס).
    בהמשך נראה כיצד MySQL יכול לסייע להפוך לעשות את התהליך הזה לפשוט יותר בעזרת Generated Columns.
טיפוס ה json ב MySQL שונה מ text בשתי תכונות עיקריות:

  1. בהכנסת ערך לעמודה מסוג json – בסיס הנתונים יוודא את תקינות ה format של ה json.
  2. בעמודה מסוג json ולא text – בסיס הנתונים ידחוס את ה json לפורמט בינארי דחוס יותר, בו המפתחות ממוינים (בדומה לפורמט bson שנעשה בו שימוש ב MongoDB).

json תקין הוא כמובן אובייקט ({}), מערך ([]), מחרוזת (""), או null.

שווה לציין שמחרוזת ה json שהוכנסה לעמודה מסוג json לא תחזור כמחרוזת זהה: במעבר לפורמט בינארי ינקו את ה whitespace וסדר המפתחות ישתנה.
כמו כן, אם יש אובייקטים עם מפתחות "כפולים" – אזי המפתח הראשון הוא זה שישמר, עד לגרסה 8.0.3 ממנה המפתח האחרון הוא זה שישמר (מה שיותר עקבי עם רוב המימושים של javaScript).
כל עוד אנחנו עובדים עם json בצורה תקינה – זה פרט שלא נשים אליו לב.

טיפוס ה json של mySQL הוא optimized לקריאות, כך שאם אנחנו הולכים לכתוב יותר (למשל: audit) – יכול להיות שיהיה עדיף, מבחינת ביצועים, להשתמש בעמודה מסוג text.

הפקודה הבסיסית בעבודה עם json ב MySQL היא JSON_EXTRACT:

SELECT c, JSON_EXTRACT(c, "$.id"), g
FROM some_table
WHERE JSON_EXTRACT(c, "$.id") > 1
ORDER BY JSON_EXTRACT(c, "$.name");
++++| c | c>"$.id"| g |++++| {"id": "3", "name": "Barney"} |"3"| 3 || {"id": "4", "name": "Betty"} |"4"| 4 || {"id": "2", "name": "Wilma"} |"2"| 2 |++++

יש גם תחביר מקוצר:

SELECT c, c->>'$.id', g
FROM some_table
WHERE c->"$.id" > 1
ORDER BY c->'$.name';
++++| c | c>"$.id"| g |++++| {"id": "3", "name": "Barney"} | 3 | 3 || {"id": "4", "name": "Betty"} | 4 | 4 || {"id": "2", "name": "Wilma"} | 2 | 2 |++++

כאשר <<- הוא תחליף ל  ((JSON_UNQUOTE( JSON_EXTRACT(column, path. הפונקציה JSON_UNQUOTE מסירה את ה quotes – אם קיימים.

ניתן להשתמש בביטויים מורכבים יותר כמו 'column->'$[2].person.pets[1].name
  • את כל הביטוי יש לעטוף במירכאות בודדות או כפולות – כי זו מחרוזת ב SQL.
  • יש לציין את ה $ – המתאר את ה root של ה json (לפי תקן ה json path – ה $ נקרא "context").
  • כאשר יש שמות של keys המשתמשים בסימנים מסוימים – יש לעטוף אותם ב quotes, למשל:
    'column->'$[2].person."my-pets"[1].name
  • ניתן להשתמש ב * בכמה מצבים:
    • [*]$ – יחזיר את כל האיברים במערך (או null אם הפעלתם על אובייקט או מחרוזת)
    • price.*.$ יחזיר מערך של כל שדות ה price בכל האובייקטים שבתוך העמודה.
    • price.**.$ יחזיר מערך של כל שדות ה price בכל האובייקטים, או תתי-האובייקטים, שבתוך העמודה.
  • יש פונקציות כגון ()JSON_KEYS ו ()JSON_SEARCH – שיחזירו בהתאמה את רשימת ה keys באובייקט, או רשימת האובייקטים המכילים ערכים מסוימים.
יש פעולות שלא ניתן להשיג בעזרת ה path כפי שמתאפשר היום ב MySQL 5.7.x. דוגמה נפוצה בשימוש: בחירת האיבר האחרון מתוך רשימה, או פעולות מיון / סינון על מפתחות מסוימים.
תמיד ניתן לעשות את הניתוח ברמה האפליקטיבית, שם ה json הוא "כחומר ביד היוצר" אם כי עבור שאילתות ניתוח /ואו כלי BI – עדיין יהיה שימושי מאוד להיות מסוגלים לעשות את כל הניתוחים בשפת SQL.
יכולות ה JSON של PostgreSQL הן מתקדמות יותר משל MySQL – אך נראה ש PostgreSQL הוא פשוט פחות סטנדרטי. מקור/2016.
ישנן עוד סדרה של פונקציות המאפשרות פעולות על json ב MySQL – אני רק אזכיר אותן בקצרה, בידיעה שתמיד אפשר לפנות לתיעוד (שהוא ברמה טובה):
  • יצירה של אובייקטי json כחלק משאילתה, בעזרת הפונקציות ()JSON_ARRAY(), JSON_OBJECT ו ()JSON_MERGE_PRESERVE.
  • שינוי של ה json מתוך SQL בעזרת הפונקציות:
    JSON_APPEND(), JSON_ARRAY_APPEND() JSON_ARRAY_INSERT(), JSON_INSERT(), JSON_REMOVE(), JSON_REPLACE(), JSON_SET.
  • פונקציות עזר שימושיות הן:
    ()JSON_UNQUOTE(), JSON_QUOTE(), JSON_DEPTH(), JSON_PRETTY(), JSON_LENGTH(), JSON_TYPE ו ()JSON_VALID
פונקציה שלי מאוד חסרה ב MySQL אך קיימת ב PostgreSQL היא json_each ההופכת מערך או זוגות מתוך עמודת json לרשומות רלציוניות עליהן ניתן לבצע פעולות ב SQL שונות.
בפוסט המשך אני אראה "תרגיל" ב SQL בו אני משתמש בכדי לעשות זאת גם על MySQL.

הערה: יש פתרון לשליפת האיבר האחרון במערך ב MySQL 8 בצורת:

JSON_EXTRACT(JsonData, '$[last]')
או שליפת האיבר לפני האחרון בעזרת last-1.
אני אראה גם "תרגיל" איך ניתן לעשות זאת גם בגרסה 5.7, וללא התמיכה של operator ה last.

סיכום

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

שיהיה בהצלחה!

גם "Data Science בשקל" – יכול להיות שווה הרבה! (על Tableau)

נתונים של מערכת הם לרוב משאב שלא מוצה.

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

למשל:

  • למצוא קשרים לא-צפויים בין נתונים, למשל: הידע שכרטיסי אשראי עם מאפיינים מסוימים אחראים לפי-19 הונאות משימוש בכרטיסים אחרים – הוא ידע שניתן להפוך אותו ליתרון עסקי.
  • היכולת לזהות שתקלה או מצב עומד להתרחש בעזרת סדרה של נתונים מקדימים.
  • היכולת לזהות שמקרה קצה מסוים לא מתרחש או כמעט ולא מתרחש – הוא הזדמנות לקחת החלטה במערכת ולא לתמוך במקרה הזה / לבצע אופטימיזציה עסקית או של ביצועי המערכת.
הדרך להשיג ידע שכזה היא לא קלה, ולרבות מההצלחות להשיג תובנה משמעותית – קודמים כמות ניסיונות כושלים.
בעקבות הטרנדים החמים היום של "Big Data" ושל "AI/ML" – מפתחים רבים מחליטים להשקיע ולהעשיר את הידע שלהם בכיוונים של Data Science.
לפעמים זה ידע תאורטי, לפעמים זו התנסות בסיסית ביצירת רשת ניורונים או Random forest.
בעזרת הטכנולוגיות הללו, נעשים בעולם דברים מדהימים – ואותם אנשי-תוכנה מקווים להגיע להישגים באזורים שלהם.
אני חושב שזו טעות טקטית נפוצה:

  • Data Science, בעיקרML ובמיוחד Deep Learning – הם תחומים עם עקומת למידה תלולה למדי, עדיין.
    • איש תוכנה יכול להשקיע עשרות ומאות שעות בלמידה ופיתוח skill – שעדיין יהיה בסיסי מאוד, יחסית למי שעוסק בתחום במשרה מלאה. לא יהיה לאיש התוכנה יתרון יחסי ברור מול איש-מקצוע ב Data Science, במיוחד לא כזה עם ניסיון לא-מבוטל.
    • אני מעריך שככל שהזמן יעבור – יהיה קל יותר ללמוד וליישם פתרונות Data Science, כך שייתכן ש 100 שעות למידה היום – יהפכו ל 20 שעות למידה בעוד 5 שנים. חלקים רבים מהידע שנלמד היום – יהפכו לכמעט-לא-חשובים, עבור מגוון נפוץ של יישומים / בעיות.
  • דווקא שיטות "פחות-מתוחכמות" של Data Science עשויות להניב לאיש התוכנה יתרון יחסי: שיטות כגון שאילתות SQL, סקריפטים שמעבדים ומנתחים נתונים, או כלי ויזואליזציה.
    • התחומים / שיטות הללו מפותחים כבר מאוד – קל ללמוד אותם מהר, ויש מגוון רחב מאוד של כלים ופרקטיקות שתומכים בהם.
    • יש כאן יתרון יחסי ברור של איש תוכנה המכיר את המערכת מקרוב:
      • הוא מבין את הנתונים (או לפחות חלקים מהם) – בצורה עמוקה.
      • נתון שאינו מכיר – הוא יכול למצוא את הקוד וללמוד בדיוק כיצד הוא מתנהג.
      • הוא יכול להוסיף נתונים ולטייב נתונים, ולהבין בצורה מהירה מה המורכבות של שיפור / טיוב נתונים שכאלו.
        • מה הבעיה ללכת לקוד ולבצע עוד כמה בדיקות / להזיז מקום את הקוד שאוסף נתונים – כך שיהיה מדויק יותר? – לאיש Data Science זוהי מלאכה קשה מאוד.
ארצה להציג דוגמה לשימוש בכלי Data Science "פשוט", שאינו קשור ללמידת מכונה או "Big Data". ספציפית, אסקור כלי בשם Tableau שאני משתמש בו לאחרונה.
Workbook לדוגמה מ Tableau Public
מקור: https://public.tableau.com/en-us/s/gallery/books-made-movies

למה טאבלו (Tableau)?

טוב, אז יש מגוון רחב של כלים לשליפה והצגת נתונים.
הכלי הבסיסי ביותר הוא client (למשל SequelPro או HeidiSql) – שאני מניח שכולנו עובדים איתו, מידי פעם.

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

אין תחליף לכלי להרצת SQL (או שפה אחרת של בסיס הנתונים) – אבל כאשר אנחנו רוצים לחזור לנתונים, או לשתף אותם – זה לא מספיק טוב.

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

כלים דיי ידועים הם MyDBR או Redash (הישראלי / של יוצא GetTaxi) – שהם טובים ופשוטים, וקל מאוד להתחיל לעבוד איתם בזמן קצר.

אני אכתוב על Tableau שהוא "כלי BI", כלומר שהוא יקר יותר (תשלום ע"פ מספר משתמשים, 30-70 דולר בחודש למשתמש), וההטמעה שלו היא מורכבת יותר.

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

בחרתי לדבר דווקא על Tableau כי זה כלי שנבחר לעבודה במקום העבודה הנוכחי שלי. יש לנו גם Redash – אבל בטאבלו אפשר לעשות יותר.
יש עוד סדרה של כלים דומים ל Tableau, כמו MicroStrategy, Qlik, או SiSense (גם חברה ישראלית). הכלים הללו, כמובן, הם לא שקולים לגמרי – ולכל כלי יש את החוזקות היחסיות שלו.

עוד נקודה שכדאי לציין כבר עכשיו היא שאין כלי BI מושלם. קל לדמיין כלי אולטימטיבי – אבל קצת יותר קשה לפתח אחד (אני מניח). לכל כלי שאי-פעם נחשפתי אליו היו גם צדדים מוגבלים ומעצבנים.

לטאבלו יש כמה גרסאות, אך אני רוצה לציין את החשובות שבהן:

  • Tableau Desktop – אפליקציית Desktop לזריזות וגמישות מרביים. זה הרישיון היקר יותר.
  • Tableau Server – גרסה וובית ומצומצמת יותר של גרסת ה Desktop. השיתוף הוא קל יותר – והרישיון עולה כחצי מחיר. רישיון של Tableau Desktop כולל גם רישיון ל Tableau Server על מנת לשתף את המידע.
  • Tableau Public – גרסה חינמית של ה Desktop, שניתן להשתמש בה רק מול שרת ציבורי של טאבלו בו הנתונים יהיו נגישים לכל העולם, וכמות מוגבלת של נתונים (15 מיליון רשומות).

ב Tableau Public אתם יכולים להגביל את הגישה של משתמשים אחרים לנתונים / לקוד המקור (ה Workbook) – אם כי משתמשים רבים מתירים את ההורדה.

בכל מקרה, זו בהחלט לא סביבה מתאימה להעלות מידע רגיש עסקית – כי בעקבות תקלה מישהו יוכל לגשת למידע הזה, ורמת האבטחה – לא מובטחת.

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

כמה טיפים חשובים על טאבלו שיאפשרו לכם כניסה מהירה יותר

Undo הוא חברכם הטוב 

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

להבין את ההבדל בין Measures ל Dimension

זה קצת מבלבל בהתחלה:

  • Measure הוא נתון שאנו רוצים להציג אותו, או בד"כ – Aggregation שלו (כמו SUM, AVG, אחוזון מסוים, וכו'). מכירות, אחוז הצלחה, וזמן ריצה – הם measures קלאסיים.
  • Dimension הוא נתון שלפיו אנחנו רוצים לפלח את הנתונים ולהציג אותם כשורה / עמודה / אזור בגרף.
    למשל: תאריך (שנה / חודש / יום), מיקום גאוגרפי, קטגוריה, סטטוס (הצלחה / כישלון) וכו' – הם dimension קלאסיים.
איך יודעים מה זה מה? – זה לא כ"כ חד משמעי.

טאבלו ינחש בצורה "תבונית" מה הוא מה – ויקטלג לכם אותם ב Data pane:
טאבלו יטעה מדי פעם – ויהיה עליכם לתקן אותו, ע"י פעולות ה"Convert to Measure" או "Convert to Dimension".
Measures יהיו בד"כ מספרים – עליהם באמת אפשר לבצע Aggregations.
Dimension יהיו בד"כ מחרוזות ותאריכים.
אבל מה אם אני רוצה להשתמש בנתון מספרי טהור, כמו זמן ריצה – כ dimension? לדומה להציג תהליכים מהירים ואטיים בנפרד?
במקרה הזה עליכם ליצור Bins (בתפריט של פריט המידע: …create/bins), שהוא בעצם שדה חדש המקטלג טווחים של הנתון (הרציף, עם אינספור ערכים) שבחרתם.
בטאבלו, כחצי מהזמן שמשקיעים בויזואליזציה יהיה בארגון הנתונים בצורה שטאבלו ידע לעבוד איתם בצורה נכונה. זה תהליך של ניסוי-וטעיה, שמתרחש תוך כדי בניית הויזואליזציה.

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

להבין את ההבדל בין Columns, Rows, ל Marks

גם זה מאוד בסיסי, אם כי מעט מבלבל בהתחלה.

הכי פשוט וטוב הוא להתחיל ממבנה של טבלה, בלי קשר לצורת הויזואליזציה שאתם רוצים להשיג בסוף (נניח: treeMap).

באופן הזה מאוד קל לחשוב על טורים ועמודות כמימדים שונים בהם אתם עושים חישוב – ו marks – כנתונים (measures) שאותם נרצה להציג:

טור ושורה הם שני מימדים שמאוד קל להבין במבנה של טבלה.
הרבה פעמים נרצה 3 ויותר מימדים.

הנה הוספתי לטבלה הנ"ל עוד שני מימדים נוספים:

ההפרדה בין עמודות ושורות היא פחות חשובה, ההפרדה החשובה היא בין מימדים ל Marks, שלרוב יהיו גם מימדים ו measures.

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

Customer הוא אחד ה Segments, ומתחתיו ניתן לראות את השנים.

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

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

הנה אותה הטבלה בדיוק, כאשר אני מציג כ 3 measures כ marks שונים:

  • סכום העסקאות – כגדול הסימון (עיגול).
  • מספר העסקאות – כטקסט (label). הביטוי CNTD הוא קיצור של Count Distinct.
  • אחוז הרווח – כצבע (gradient), כאשר כחול הוא רווח, וכתום הוא הפסד. כתום גדול = הפסד גדול!

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

עוד Marks שניתן להשתמש בהם הוא סוג הצורה (בשימוש ב Shapes) או tool-tip שמופיע ב popup כאשר מצביעים על האיבר.

Show Me הוא כלי חשוב – לא רק למתחילים!

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

בפינה הימנית עליונה נמצא כפתור Show Me – שעוזר לי לדעת למה אני זקוק.
עבור היסטוגרמה, אומרים לספק measure אחד (קל!) – ומודיעים לי שטאבלו ייצור bin field מתאים. יש גם אזהרה שלא כל measure יעבוד.

אני זורק את ה measure של Sales לאחד המימדים (עמודות או שורות – לא משנה) – טאבלו אוטומטית מנחש שאני רוצה לעשות לו aggregation של Sum.
אח"כ אני לוחץ ב Show Me על גרף ההיסטוגרמה – ומקבל את התוצאה הבאה:

הערה: שיניתי את השנתות של ציר ה Y ל logarithmic scale – אחרת היה קשה להבחין בערכים השונים.

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

מה הצבעים ירוק וכחול אומרים?

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

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

למשל: אם ציר ה X שלכם הוא חודש בשנה, ומופיעות שנתות לערכים 0 ו 13 – זה בגלל שהתאריך הוא שדה רציף. הפכו אותו לבדיד – וזה יסתדר.

השתמשו ב Calculated Fields

אופן חשוב בו ניתן לעבד נתונים היא Calculated Fields.
שימוש פשוט הוא פעולה חשבונית כזו או אחרת (חיבור, חיסור, חילוק), אבל אפשר גם לפתור בעיות יותר משמעותיות בטאבלו בעזרת calculated fields.

למשל, הנה סקריפט פשוט שיוצר מימד חדש מכמה שדות (שמותיהם – בכתום):

היה לי קשה יותר לבנות את המימד הזה בדרך אחרת / SQL query.

לטאבלו יש רשימה של פונקציות זמינות, ותחביר שמזכיר כתיבת פונקציות ב SQL – בהם ניתן להשתמש ב calculated fields. שימו לב שחלק מהפונקציות זמין רק מול data sources ספציפיים כמו Hive או Google BigQuery (המספקים את הפונקציות בצורה טבעית)

עבור חישובים מורכבים יותר אפשר להשתמש בשפת R – שפת תכנות לכל דבר ועניין.
כדי לכתוב Calculated Fields בשפת R יש להתקין מנוע חישובי בשם RServe המריץ את R. טאבלו ישלח את הנתונים ל RServe – שיבצע את החישוב של השדה הנתון – ויחזיר את התוצאות.

SCRIPT_STR(`substr(.arg1, regexpr(" ", .arg1) -1 )`, ATTR([Business Name ]))

הפונקציה SCRIPT_STR שולחת ל R ביטוי בשפה העטוף במירכאות + פריט המידע שאותו יש לעבד – ומחזירה תשובה מסוג מחרוזת. האינטגרציה היא סבירה – אבל לא מצוינת. למשל: איתור תקלות היה יכול להיות פשוט בהרבה.

השתמשו ב Filters

בכל ויזואליזציה – ניתן "לגרור" שדות לאזור ה "filters" ולסנן לפי ערכים מסוימים של השדה הזה. זה שימוש אחד ויעיל ל Filters.

שימוש נוסף חשוב הוא ב Dashboards, כאשר אני מצרף כמה ויזואליזציות ובמקום אחד יכול לפלטר את כולם באותה הצורה. מה שנחמד שה Filters ב Dashboard מופיעים ב View Mode (אם לא סילקנו אותם משם) – וכך הקהל הרחב של המשתמשים יכול להשתמש בהם, מבלי להכנס לעומק ה Data Model.

הנה דוגמה של Dashboard פשוט שיצרתי מ-2 הויזואליזציות הנ"ל:

הוספתי Filter דרך אחד מהויזואליזציות (תפריט = חץ למטה/filters – מציג לי את כל המימדים / measures שבשימוש ולכן ניתן לפלטר לפיהם).

בשלב הבא, אני משייך את הפילטר (דרך התפריט שלו) – לכל הנתונים על ה Dashboard:

עכשיו אפשר לראות שצמצום השנים בעזרת הפילטר – משפיע על כל הנתונים ב Dashboard. איזה יופי!

סיכום

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

הוא כלי רב-עוצמה, אך לא מורכב כ"כ לשימוש.

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

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

שיהיה בהצלחה!