בעוד שטכנולוגיית ה-
In memory קורמת עור וגידים אל מול עינינו ונמצאת בקו ישיר אל עבר אופק המבטיח לנו ביצועים אדירים,כרגע המצב הוא שישנם ארגונים שבהם יושבים משתמשי מפתח כדוגמת אנליסטים בכירים,מנהלי מחלקות,אנשי BI וכו' הזקוקים בצדק או שלא לניתוח כמויות אדירות של נתונים.
מה זה כמויות אדירות ?ממאות אלפי רשומות עד כמה מליוני רשומות מאוחזרות ומשם מה קורה ?
ניסיונות ניתוח ושפיכתם לאקסל 2007 ומעלה או לקובצי csv,טעינה למסדי נתונים מקומיים ,מניפולציות של מיון וסינון על התוצאה באמצעות כלי האחזור ועוד...
מגבלות האקסל העכשוויות הם:
Excel 2007-1,048,576 row limit
Excel 2010 – more than 100 milion rows- install power pivot
בכדי לגלות גם מה מגבלות הזיכרון של גרסאת האקסל שלכם מומלץ לקרוא כאן:
http://www.decisionmodels.com/memlimitsc.htm
מבחינת המשתמש כל בעיה שמתעוררת בתוכנה,בקצב ההורדה או בביצועים היא עדות מוכחת ל-2 מסקנות:
א.כלי ה-BI לא טוב ולא מתאים ("תמצאו לי אז כלי שמתאים לדרישותיי..." יגיד המשתמש)
ב.מחסן הנתונים לא בנוי ולא מתאים לצרכי הניתוח של המשתמש
("מה הטעם בבסיס נתונים אם הוא לא מתאים לצרכיי?" יזעק שוב המשתמש).
לא נתקלתי בשום כלי BI מן השורה הראשונה שפותר כרגע בעיה זו:לא ה-Deski וה-Webi של Sap Business objects לא הקוגנוס ובטח שלא ה-Reporting Services של microsoft ,לגבי חלק משאר הכלים כמו Oracle BI ו-Web focus ו-microstrategy אני לא יודע אבל אני בספק מאחר והם אינם ידועים כמובילים בתחום זה אם כי חלקם גם בדרך לשם.
נכון ש-Power Pivot כבר נמצא שם אבל כולל הרבה מגבלות התקנה:קונפיגורציית זיכרון מקומית חזקה(לפחות 4G ram )ומערכת הפעלה של 64bit ואני מזכיר לכם שה-Power Pivot לא מקצר את זמן האחזור (100 מליון רשומות ימוינו כהרף עין על תחנת המשתמש אבל יאוחזרו במשך שעות רבות).
מוצר – Sap Explorer בטכנולוגיות In memory עובד מצוין אמנם :מליון רשומות תוך פחות משנייה וזמן האינדוקס של הנתונים מהיר אף הוא או כמו שמנהלי המוצר טוענים:
Returns multi-cube query results from 280M records in less than 0.03 seconds
אך מותנה בהתקנת שרתי Sap blades .
אגב לפי תפיסת Sap הוא נועד לתחקור מסוג Search ולא Exploration ,סאפ מתווה את פיתוח מוצריה העתידיים לפי תפיסת הצורך שיש למשתמש בנתונים-
http://timoelliott.com/blog/docs/forrester_it_forum_sap.zip
אף על פי שהטכנולוגיה אמורה להתרחב לשאר המוצרים.
Qliqview אף הוא מבצע פריצת דרך אך אני מאמין (ולא בדקתי) שגם זמני טעינת הנתונים תלויים במגבלות הידועות לכולנו,אז עם מה נשארנו ?
עם מחלקת BI שנדרשת להרים את רף המגבלות גם מבלי שיהיו בידיה כל הפתרונות.
אז בוא נבחן לרגע את הפתרונות האפשריים המיושמים כיום ברחבי הארגונים לאחר שכל האמצעים הידועים לנו כדוגמת טיוב ה-SQL,הטבלאות,הסיכומים ב-DB,דרכי עבודה של המשתמשים וכו' לא עזרו:
1. מדיניות ארגונית ברשות מנהלי ה-BI שאוסרת ולא מאפשרת סוג כזה של אחזור ומגובית הן בהנהלה והן באמצעים טכנולוגיים ואמצעי אבטחה שאינם מאפשרים אחזור של מעל X רשומות:
בתור Designer אפשר להכיל הרשאה כזו על קבוצת משתמשים/משתמש בודד,ה-DBA יכול להגדיר rules על ה-DB ובאמצעות מוצרים כמו
Active base אפשר להגביל גישה לטבלאות לפי כמות רשומות לפי משתמש,סוג מידע ,ערכים ספציפיים וכו'.
2. גישה המאפשרת לאותם משתמשים להוריד כמות גדולה של נתונים ממומשת באמצעות כמה דרכים:
א. יוצרים תהליכי ETL או בונים views/טבלאות זמניות ב-DB שלמעשה מהוות שאילתות מורצות לפי הגדרות המשתמש,בסוף התהליך או שמייצאים את הנתונים לקובץ csv שנפתח ע"י המשתמש על התחנה,או שמשתמש פונה לאותה טבלה זמנית שעדין מכילה מיליוני שורות אך קטנה משמעותית מה-SQL שהמשתמש ניסה להריץ טרם נבנה לו התהליך ב-DB,כמובן שעם קצת index ו-partitions מעלים את ביצועי הטבלה,המשתמש יכול לנסות ולהוריד מיליוני רשומות או להריץ כל פעם מחדש עם תנאי אחר,זמן האחזור יהיה יחסית מהיר (אם מדובר בכלל בהרצה ולא בפתיחת קובץ ה-csv) ומכאן המשתמש יהיה תלוי בביצועי המחשב והזיכרון ובמגבלות התוכנה.
לכל הסיפור הזה יש מגבלות כי כל משתמש יכול לבוא בכל יום עם בקשה חדשה ואז התחזוקה מתחילה להסתבך,ניתן לפתור זאת חלקית ע"י פיתוח יישום של מסך הגדרות למשתמש ב-ASP או ב-.net שהפרמטרים שהמשתמש בוחר מפעילים את התהליך שירוץ בלילה ובכך התחזוקה יורדת ואופי התהליך/גזירה שירוץ בלילה תלוי בבחירת המשתמש (דינאמי....).
ב. ישנם ארגונים עם מספיק משאבים (כסף,זמן ,אנשים) שבונים תשתית נפרדת עבור אותם משתמשים (שרת אפליקציה נפרד,DB נפרד רק עם הטבלאות הרלוונטיות והקצעת רוחב פס גדול יותר).
אותם משתמשים טוחנים סביבה סטרילית וכמובן שביצועי האחזור עולים,עם השקעה נוספת במחשב עם זיכרון חזק ומערכת הפעלה של 64bit ומעבדים חזקים גם שלב התצוגה והעיצוב מהיר יחסית,אבל עדין שום כלי לא יתמודד היטב עם אחזור של עשרות מיליוני רשומות והעסק עלול להיתקע.
ג. רכישת כלי BI בטכנולוגיית In memory כדוגמת Power pivot, QlikView,Sap explorer והתקנתם בקרב אותם משתמשים "מיוחדים".
כמובן שיש עם כך לא מעט בעיות:מדובר כלי BI נפרד שאינו בהכרח חלק מהפלטפורמה הארגונית,עוד רישיונות,עוד כסף,תחזוקה נוספת,הרשאות,עמידה בתקני האבטחה וה-QA הארגוניים,סטנדרטיזציה ,ניטור ובדיקה שכלי כזה אכן עומד בכל שאר הדרישות.
עם ניקח למשל את המקרה של ה - power pivot החיסרון הגדול הוא היעדר security.
ד. התקנת כלי SQL אצל תחנת המשתמש כדוגמת Toad,PL SQL Developer,SQL Navigator עם השקעה בלימוד המשתמשים קריאה וכתיבה של SQL ותפעול התוכנה הם יוכלו לעבוד עם כלי בלי יכולות עיצוביות אבל יוכלו להריץ שאילתות ענק בעצמם מבלי להיתקע בשלב העיצוב,משם אם ירצו לייצא אתה-Data לאקסל ושות',יהיו תלויים שוב בביצועי המחשב וגרסת האקסל שמותקנת אצלם.
הנה כמה ממבחר התגובות שקבלתי מראשי תחום BI בארגונים שונים בארץ :
• "כל עוד הדוח סוחב להם אין לי בעיה עם זה..."
• "מנסים לתת להם את המיטב במסגרת המגבלות הטכניות..."
• "ממליצים לייצא לאקסל במקרה של מאות אלפי רשומות..."
• "באופן חד פעמי אנו מאפשרים את זה אך לא ככלל..."
• "מניסיון רוב המשתמשים שרוצים מיליוני רשומות עושים זאת כתוצאה
מטעות/אי הבנה של מבנה הנתונים/הצורך העסקי..."
• "בונים להם view ..."
• "מחלקים את הטבלה ל-partitions ושולפים בנפרד עבור כל חלוקה (לפי תאריך למשל)..."
• "אין לנו משתמשים כאלו,ה-DB לא מאפשר זאת ומי שצריך מיליוני רשומות עובד חד משמעית לא נכון..."
• "אין דבר כזה,זה נוגד את מדיניות האבטחה בארגון..."
לסיכום:
פתרונות כבר יש,הם עדין לא בשלים ב-100% והם מגיעים בעיקר מתוך שדרוג התשתית,ה-hardware ומשאבי המחשב/שרת,בחלק מן המקרים פשוט לוגיקה חכמה עושה את כל ההבדל והשאלה הגדולה שנשאלת היא
האם מערכת ה-BI היא של המשתמשים או בשימושם...?
