ברוך הבא, אורח
שם משתמש: סיסמא: זכור אותי

דיון: שימוש בכלי ETL אחר וב QV כתצוגה

שימוש בכלי ETL אחר וב QV כתצוגה 10 years 7 months ago #5203

  • revitalae
  • revitalae's Avatar
  • Offline
  • Fresh Boarder
  • הודעות: 2
  • קרמה: 0
האם מישוה ניסה להשתמש בכלי ETL כמו - DATASTAGE  או אינפורמטיקה  וב QV ככלי תצוגה.

אם כן, באיזה קשיים נתקלת?
הנהלת האתר ביטלה גישת כתיבה ציבורית.

בעניין: שימוש בכלי ETL אחר וב QV כתצוגה 10 years 7 months ago #5205

  • avishayl
  • avishayl's Avatar
  • Offline
  • Moderator
  • הודעות: 84
  • קרמה: 1
אין שום בעיה להשתמש ב QV ככלי DESIGN ולייצר איתו את כל התצוגה.
גם פה יש ל QV הרבה יתרון.
בשכבת התצוגה של QV ניתן לבצע את כל המגוון שקיים:
Reporting
Dashboard
KPI
Analytics...

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

דעתי האישית היא בכל מקרה להשתמש ביכולות ה ETL של ה QV.
לאחר שימוש ממושך בכלי פיתוח שונים כמו DATASTAGE ו SSIS, לקח לי זמן להתרגל ל SCRIPT של QV, אבל לאחר תקופה, למדתי שקיימות בו יכולות רבות ומגוונות, וכיום אני נמנע ככל האפשר משימוש בכלי אחר.  ;)

אבישי


הנהלת האתר ביטלה גישת כתיבה ציבורית.

בעניין: שימוש בכלי ETL אחר וב QV כתצוגה 10 years 7 months ago #5233

  • davidvir
  • davidvir's Avatar
  • Offline
  • Expert Boarder
  • הודעות: 91
  • קרמה: 0
שאלה טובה,

לדעתי התשובה מחולקת לשתיים.
במקומות שהמודל פשוט יחסית אין שום בעיה להקים הכל ב-QV ולהינות מהיתרונות שלו
בדיוק כמו שאבישי מנה פה.

לאחרונה בשני פרויקטים שונים שביצעתי לא הייתה ברירה אלא להקים בעזרת SSIS
DWH שאותו ה-  QV קורא ולמעשה משמש ככלי GUI בלבד.

בסופו של דבר QV הוא לא כלי ETL במהותו,הוא אומנם יכול לעשות פעולות ETL אבל ככל שרמת הסיבוכיות עולה ,העסק ניהיה מורכב הרבה יותר.


הנהלת האתר ביטלה גישת כתיבה ציבורית.

בעניין: שימוש בכלי ETL אחר וב QV כתצוגה 10 years 7 months ago #5247


שלום לכולכם,
לקח לי מספר ימים לנסח את התשובה שלי ואני מתנצל מראש גם על האחור וגם על האורך :)

בואו ננסה לבצע את ההשוואה בצורה קצת יותר מפורטת
אני בטוח שכולם יודעים שהETL מורכב מ-3 שלבים
Extract – בו נשלפים הנתונים ממערכות המקור
Transform – בו מעובדים הנתונים בדרכים שונות
Load – בו נטענים הנתונים למערכת ה-BI
Extract
אפשר לחלק שלב זה לשני חלקים.
התחברות למקור הנתונים ושליפתם
אחסון הנתונים כהכנה לשלב הבא
ההתחברות לנתונים נעשית בתוכנות ETL מסורתיות (בדרך כלל) על ידי מנהלי התחברות אשר מבצעים את החבור אל מקורות הנתונים  ואז יש קומפוננטות שמתחברות למנהלים הללו ומבצעות את השליפה. הן בתורן מעבירות את הנתונים לקומפוננטות נוספות שאחראיות על כתיבת הנתונים ומתחברות לסדרה נוספת של מנהלי התחברות אשר מתחברים למקום אליו מאחסנים את הנתונים(בדרך כלל לטבלאות בדטהבייס שנבנה במיוחד למטרה זו) .
מנהלי ההתחברות (קריאה וכתיבה) צריכים להווצר אחד לכל מקור/יעד.
קומפוננטות הקריאה/כתיבה צריכות להווצר לפחות אחת מכל סוג עבור כל טבלה במקור/יעד הנתונים.
כלומר אם יש לנו 4 מקורות נתונים אשר שולפים נתונים מ30 טבלאות וכותבים לאותו דטהבייס אנו נצטרך:
מנהלי התחברות למקורות 4
מנהל התחברות ליעד 1
קומפוננטות שליפת נתונים 30
קומפוננטות כתיבת נתונים 30
סה"כ קומפננטות 65
בנוסף רוב תוכנות ה ETL מנהלות עבור כל העסק מנגנון META DATA אשר כל שינוי בתהליך מחייב סינכרון שלו. (בדרך כלל הסינכרון מתבצע באופן אוטומטי על ידי המערכת – אך לעד כמה שידוע לי בSSIS יש לסנכרן כל קומפוננטה בנפרד).
ברוב תוכנות הETL ורוב הדטהבייסים הגדולים יש מנגנוני בדיקת סוגי נתונים מחמירים ביותר הדורשים התאמה ב:
גודל השדה
codePage של השדה
שדה טקסט או שדה נומרי
התאמה ל META DATA
כלומר במערכת יחסית פשוטה עם מספר טבלאות קטן יש לנו 65 קומפננטות לנהל (רק דרך תפריטים וחלונות בחירה). כל סטיה קטנה באחד מהחלקים, מספיק ששדה שינה גודל מ3 תווים ל4 תווים וכבר יש צורך לטפל ב4 קומפוננטות ולבצע הסבה לבסיס הנתונים שאליו מאוחסנים הנתונים. עכשיו תארו לעצמכם שהשדה שהשתנה מופיע בכמה טבלאות?
ואנו רק בשלב הראשון!!! של שליפת הנתונים
ואם אנו מנהלים את הכל לפי הספר אז אנו קודם מבצעים MIROR ואז מבצעים DATA STAGEING שזו בעצם הכפלה של כל מה שאמרנו למעלה.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 130 קומפוננטות !!!!!!!!!!!!!!!!!!!
ושני דטהבייסים.

ממש פשוט.......פשוט.........פשוט

עכשיו בואו נראה איך זה בקליקוויו.
4 חיבורי ODBC  או OLEDB למקורות הנתונים (אגב הם נחוצים גם בכלים האחרים בנוסף על מנהלי ההתחברות)
4 שורות CONNECT בסקריפט.
30 שאילתות SQL/LOAD השולפות מתוך מקורות הנתונים
בתוספת שורת קוד 1 לכל טבלה שגם כותבת את הנתונים בקבצי QVD (פורמט אחסון טבלאות בדיסק).
הממממממ
זהו אני חושב........... סיימנו את שלב ה Extract בקליקוויו.  (ואו זה היה ממש מסובך)
הקליקויו מנחש לבד 99 אחוז מסוגי הנתונים.
מכיוון שאין לו META DATA  גם לא נוצרת בעית חוסר הסנכרון המוכרת מכלי ETL מסורתיים.
הוא אינו מושפע משינוי גודל השדה או סוגו.


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

לעומת השלב הראשון שאינו תלוי בכלי הסופי שנבחר לשמש ככלי התצוגתי, בשלב הזה כבר דרושה החלטה.
במידה ובונים קוביית OLAP הרי שכאן יש לבנות מערכת של טבלאות פאקט וטבלאות מימד והקשרים שביניהם.
במידה וכלי התצוגה הוא קליקוויו אז יש רק להגדיר את מערכת הקשרים הלוגיים בין הטבלאות.
אנו נתמקד באפשרות השניה (קליקוויו)  מכיוון שזו השאלה המקורית.
(אני לא מציין את ענין הטיוב ובדיקות האיכות מכיוון שכל מה שיאמר על יתר השלב מתאים גם להם)
אם נעבוד עם כלי ETL חיצוני הרי שהתוצר של שלב זה רצוי שיהיה מבנה של טבלאות מוכן
(לרוב זה יהיה Star Schema    או  Snowflake) שהקליקוויו רק יצטרך לקרוא.
נצטרך דטהבייס חדש שאליו נאחסן את הנתונים במבנה החדש ושוב נעבוד עם מנהלי התחברות ועם קומפוננטות ובהנחה שנצטרך לטפל בקשרים בין הטבלאות ולבצע joins רבים וlookup רבים אנו עלולים להגיע גם לכ 2-5 קומפוננטות לכל טבלת מקור (בין 60-150 בדוגמה של 30 טבלאות מקור).
כמובן שחלק מהטבלאות מתמזג ובסוף נגיע למשהו כמו 3 טבלאות פאקט וכ10 טבלאות לווין.
שאותן יש לכתוב לדטהבייס החדש.
כלומר
קומפננטות 16
מנהלי התחברות 2
וכמובן שכל מה שנאמר לגבי בדיקות ההתאמה והצורך בשמירת הסנכרון של  ה META DATA נכון גם כאן.
וכמו מקודם גם עכשיו: ממש פשוט.......פשוט........פשוט

ובקליקוויו?
אלו השלבים:
שליפת הנתונים מקבצי הQVD.
בדיקות הטיוב מתבצעות תוך כדי השליפה וכן גם שינוי שמות השדות כדי שיווצרו הקשרים המתאימים אוטומטית על ידי קליקוויו.
קיימות פונקציות מיוחדות לטיפול במקרים מיוחדים כמו מרווחי זמן ו slowly changing dimensions
בצורה פשוטה בהרבה מאשר ברוב תוכנות ה-ETL,
ותהליכי עבוד נוספים שליישמם בכלי ETL זה מסורבל ולא יעיל בעליל.
הממממ........
אני חושב שסיימנו את שלב הTRANSFORM בקליקוויו
אבל רגע!!!
סיימנו גם את שלב הLOAD!!!
המודל כבר מוכן לתצוגה.
בעוד שאם היינו עובדים עם כלי חצוני עדיין היינו שלב אחד לפני הסוף והיינו צריכים גם לבנות מודל שיקרא לתוך הקליקוויו את התוצר של שלב 2.

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

(אני מניח דביר שכשכתבת:  "לאחרונה בשני פרויקטים שונים שביצעתי לא הייתה ברירה אלא להקים בעזרת  SSIS DWH"  התכוונת לחוסר ברירה שנבע מאילוצים אחרים, כי אני לא ממש רואה מה יכול להיות כלכך מורכב לביצוע שיהיה יותר קל לבצע אותו בSSIS מאשר בקליקוויו)

בברכה
הנהלת האתר ביטלה גישת כתיבה ציבורית.
זמן יצירת העמוד: 0.169 שניות

הדף שלנו בפייסבוק

מעניין? שתפו דף זה באמצעות הטלפון הנייד

מאמרים

מגמות של ביג דאטה בעולם הביטוח
CA Technologies
SSIS - Buffer Size Optimization
קטגוריה ראשית
בדיקות BI ו-DWH לעומת הבדיקות בתחומים אחרים
קטגוריה ראשית
איסוף דרישות לפרויקטי BI
קטגוריה ראשית
כח המידע במיקוד
קטגוריה ראשית
0

Microsoft

Oracle

IBM

Informatica

Sap

SAS

Qlikview

Cloudera

Machine Learning