היי , אני קורא לזה... תהליכים ל "מידות גדולות..."

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

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

• שיפור איכות הנתונים.
• טיוב נתונים.
• בדיקות מידע.
• תמיכה בחוקים עסקיים
• חוסר עקביות של דוחות תפעוליים.
• גישה ותחקור של Meta data.
• שיתוף מידע.
• ניווט במידע.
• תמיכה ברמות משתמשים שונות.
• הפצת ושיתוף מידע עסקי.
• תמיכה ברמות סיכום שונות.
• תמיכה בתחקור היסטוריות שונות.
• אינטגרציית נתונים ממקורות מרובים ושונים.
• איחוד סכמות שונות ומבני נתונים שונים.
• קישור ישויות מערכת.
• יצירת מילון מונחים עסקי ומימדים משותפים.
• תמיכה בקשרים עסקיים משתנים.
• תמיכה ברמות נתונים שונות.
• עדכוני נתונים שונים.
• האצת תחקור המשתמשים.
• שיפור ביצועי המערכת.

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

DBA, מפתחי BI, מנהלי תחום מחסן הנתונים כל הזמן עסוקים במתן אחריות לנושא זה   J

האם ה DBA  אמון לתהליך שיפור הביצועים או האם מפתח ה BI נדרש לפתח תהליך מיטבי?

האם ה ERD  ואפיון הפיסי תואם את הדרישות?

האם ה DBA שותף לתכנון הפיסי או לתהליכי ה Source To Target ?

טוב, ישנן עשרות שאלות תהליכיות ולצערי גם טריטוריות ולכן לא אעסוק בהן כאן!

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

קישור למאמר

The Data Loading Performance Guide

בהצלחה , תהנו.