האם אתם מתחקרים את הנתונים שלכם בתצורה הנכונה?

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

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

במאמר זה אתמקד בשאלה – מתי יש לבחור יבוא דאטה וניתוחו ישירות ממחסן הנתונים (DWH או מבסיס הנתונים ב-Direct Query) ומתי יש להעלותו אל זכרון ה-RAM.

התפתחות שיטות התחקור

נזכיר בקצרה את האתגרים ואת התפתחות שיטות התחקור השונות לאורך הזמן. בתחילה, תחקור הדאטה נעשה ישירות מהמערכת התפעולית – כלומר מבסיס הנתונים של מערכות ה-ERP, ה-CRM או מערכות תפעוליות אחרות. בדרך זו, שאילתות בעלות נפחים גדולים גרמו לצוואר בקבוק, בשל מגבלות בסיס הנתונים או הדיסק ממנו נשלפו הנתונים, ולכן נגרמה האטה בביצועי המערכת התפעולית וביצועי התחקור הפכו לירודים ואיטיים.
את אחת מפריצות הדרך הגדולות בתחום ביצעה חברת קליק (Qlik) לפני כ-30 שנה. לא עוד תחקור על הדיסק הגורם להאטה, אלא תחקור מהיר בהרבה על ה-RAM. שיטה זו עיצבה חלק רחב מעולם ה-BI כפי שהוא מוכר לנו גם היום, כאשר חברות יכולות לבצע היום שאילתות עתירות נתונים מבלי שהמערכת תיתקע או תגרום להמתנה של שעות מרובות.

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

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

כיצד לתחקר אותו נכון? ה-BI. צילום: אילוסטרציה. ShutterStock

ביג דאטה והענן

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

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

לכן, בשנים האחרונות, עם העברת הדאטה לענן, התפתח 'טרנד' של חיפוש כלי BI המתחקרים בתצורה של Direct Query ומשתמשים ביכולת העיבוד והשליפה המתקדמות של ה-DB עצמו.

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

יתרונות וחסרונות בשיטת Direct Query

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

תקציב – בניגוד לתחקור In Memory, בו הנתונים נמשכים פעם אחת בלבד לזיכרון (עם אפשרות לטעינה אינקרמנטלית), כאשר מתבצע תחקור ב-Direct Query, מתבצעות שאילתות מול מערכת המקור בכל לחיצה ולחיצה, מה שיכול להוביל לעלויות גבוהות מאוד.

יכולות תחקור – בתחקור בשיטת Direct Query, נפגעות יכולות התחקור המתקדמות הקיימות בתחקור In Memory, כגון: יכולת חיפוש ברמת השורה על כל שדה, יצירת גרפים ברמת המשתמש הסופי (Self service) לפי הרשאות, התרעות ושליחת דו"חות מתוזמנים, אינדיקציה משלימה על הדאטה שלא נבחרה, ועוד.

אז מתי יהיה נכון לתחקר בצורה של Direct Query ומה הם יתרונות התחקור בתצורה זו? התשובה היא – כאשר מדובר על תחקור של מיליארדי רשומות ברמת ה-Raw Data וכאשר מדובר על תחקור ב-Real Time – כאשר נרצה תחקור קרוב מאוד לזמן אמת. 

יש לציין כי בנוסף לשתי שיטות התחקור שהוזכרו, קימת שיטה נוספת לתחקור במצב שבו קיימות מיליארדי רשומות: ODAG – On Demand App Generation.

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

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

הכותב הוא ארכיטקט נתונים בחברת הדאטה וה-BI קליק ישראל