סקירה כללית של מתודולוגיות עיצוב זריז של DWH

פיתוח מתקן אחסון הוא משימה ארוכה ורצינית.

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

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

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

ואם בחיים השקטים והנעימים שלך כמפתח DWH פתאום:

• המשימה עלתה "לעשות לפחות משהו מהר, ואז נראה";
• הופיע פרויקט המתפתח במהירות, עם חיבור של מקורות חדשים ועיבוד מחדש של המודל העסקי לפחות פעם בשבוע;
• הופיע לקוח שאין לו מושג איך המערכת צריכה להיראות ואיזה פונקציות היא אמורה לבצע בסופו של דבר, אבל הוא מוכן להתנסות ולחדד באופן עקבי את התוצאה הרצויה תוך התקרבות אליה באופן עקבי;
• מנהל הפרויקט הגיע עם החדשות הטובות: "ועכשיו יש לנו זריזות!"

או אם אתה רק מעוניין לגלות איך עוד אתה יכול לבנות מתקני אחסון - ברוכים הבאים לגזרה!

מה זאת אומרת "גמישות"?

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

בנפרד, ראוי להזכיר כי המאפיינים המתוארים צריכים להתייחס ספציפית המערכת, לא תהליך הפיתוח שלה. לכן, אם רציתם לקרוא על Agile כמתודולוגיית פיתוח, עדיף לקרוא מאמרים אחרים. לדוגמה, ממש שם, על Habré, יש הרבה חומרים מעניינים (כמו סקירה и מעשיו - בעייתי).

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

אז, אילו יכולות צריכות להיות לאחסון גמיש? יש כאן שלוש נקודות:

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

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

להלן אשקול שתיים מהמתודולוגיות הפופולריות ביותר לעיצוב זריז עבור מחסני נתונים - דגם עוגן и כספת נתונים. נותרו מחוץ לסוגריים טכניקות מצוינות כמו למשל EAV, 6NF (בצורתו הטהורה) וכל מה שקשור לפתרונות NoSQL - לא בגלל שהם איכשהו גרועים יותר, ואפילו לא בגלל שבמקרה הזה המאמר יאים לרכוש הנפח של דיסר ממוצע. רק שכל זה קשור לפתרונות של מעמד קצת שונה - או לטכניקות שאתה יכול להשתמש בהן במקרים ספציפיים, ללא קשר לארכיטקטורה הכוללת של הפרויקט שלך (כמו EAV), או לפרדיגמות אחסון מידע אחרות בעולם (כגון מסדי נתונים של גרפים ואפשרויות אחרות NoSQL).

בעיות של הגישה ה"קלאסית" ופתרונותיהן במתודולוגיות גמישות

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

1. קרדינליות נוקשה של קשרים

מודל זה מבוסס על חלוקה ברורה של נתונים ל מֵמַד и עובדות. וזה, לעזאזל, הגיוני - אחרי הכל, ניתוח נתונים ברוב המכריע של המקרים מסתכם בניתוח של אינדיקטורים מספריים מסוימים (עובדות) בחלקים מסוימים (מימדים).

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

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

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

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

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

מערכות יחסים ב-Data Vault ומודל עוגן

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

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

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

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

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

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

2. שכפול נתונים

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

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

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

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

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

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

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

3. מורכבות לא לינארית של עיבוד מחדש

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

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

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

אחסון אובייקטים ותכונות ב-Data Vault ומודל עוגן

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

יש להפריד בין מה שמשתנה לבין מה שנשאר אותו דבר. כלומר, אחסן מפתחות בנפרד מתכונות.

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

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

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

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

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

• מפתחות ישות טבעיים
• מפתח סרוגייט
• קישור למקור
• שיא זמן הוספה

פוסטים ברכזות לעולם לא ישתנו ואין להם גרסאות. חיצונית, רכזות דומות מאוד לטבלאות מסוג ID-map המשמשות במערכות מסוימות ליצירת פונדקאיות, עם זאת, מומלץ להשתמש ב-hash מקבוצה של מפתחות עסקיים בתור פונדקאיות ב-Data Vault. גישה זו מפשטת טעינת מערכות יחסים ותכונות ממקורות (אין צורך להצטרף לרכזת כדי לקבל פונדקאית, רק לחשב את ה-hash של מפתח טבעי), אך עלולה לגרום לבעיות אחרות (קשורות, למשל, להתנגשויות, רישיות ולא ניתנות להדפסה תווים במקשי מחרוזת וכו' .p.), לכן זה לא מקובל בדרך כלל.

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

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

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

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

В דגם עוגן טבלאות המאחסנות מפתחות נקראות עוגנים. והם שומרים:

• רק מפתחות פונדקאים
• קישור למקור
• שיא זמן הוספה

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

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

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

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

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

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

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

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

הבדל חשוב נוסף בין Data Vault למודל ה-Anchor הוא הזמינות תכונות של קשרים:

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

אחסון עובדות

לפני כן, דיברנו בעיקר על מידול מדידה. העובדות קצת פחות ברורות.

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

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

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

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

כיצד מושגת גמישות

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

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

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

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

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

צד אפל

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

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

ישנן מספר עובדות המקלות על המצב הזה:

כאשר עובדים עם ממדים גדולים, כמעט אף פעם לא נעשה שימוש בכל התכונות שלו בו-זמנית. המשמעות היא שייתכן שיהיו פחות הצטרפות ממה שנראה במבט ראשון בדגם. Data Vault יכולה גם לקחת בחשבון את התדירות הצפויה של שיתוף בעת הקצאת תכונות ללוויינים. יחד עם זאת, Hubs או Anchors עצמם נחוצים בעיקר לצורך יצירה ומיפוי של פונדקאים בשלב הטעינה והם משמשים לעתים רחוקות בשאילתות (זה נכון במיוחד עבור Anchors).

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

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

הרבה תלוי במנוע. לפלטפורמות מודרניות רבות יש מנגנוני אופטימיזציית הצטרפות פנימיים. לדוגמה, MS SQL ו-Oracle יכולות "לדלג" על הצטרפות לטבלאות אם הנתונים שלהן אינם בשימוש בשום מקום מלבד צירוף אחרים ואינם משפיעים על הבחירה הסופית (ביטול טבלה/הצטרפות), ו-MPP Vertica ניסיון של עמיתים מ-Avito, הוכיח את עצמו כמנוע מצוין עבור דגם העוגן, בהינתן אופטימיזציה ידנית מסוימת של תוכנית השאילתות. מצד שני, אחסון מודל העוגן, למשל, בקליק האוס, שיש לו תמיכת הצטרפות מוגבלת, עדיין לא נראה כמו רעיון טוב במיוחד.

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

בסך הכל

המהות העיקרית של הארכיטקטורות הגמישות הנחשבות היא המודולריות של ה"עיצוב" שלהן.

נכס זה הוא המאפשר:

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

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

Apps

סוגי ישויות כספת נתונים

מידע נוסף על Data Vault:
האתר של דן ליישטדט
הכל על Data Vault ברוסית
על Data Vault ב-Habré

סוגי ישויות דגם עוגן

פרטים נוספים על דגם עוגן:

אתר היוצרים של Anchor Model
מאמר על חווית הטמעת מודל עוגן באוויטו

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

מקור: www.habr.com