מה זה Data Warehouse? הסבר + משרות פתוחות בישראל

מחסן נתונים הוא מסד נתונים מרכזי שנבנה לניתוח ולדיווח, ולא להפעלת המוצר. הוא מרכז נתונים מכל מערכות הארגון במבנה שנוח לשאול ממנו שאלות רוחב על פני שנים. בלוח HiTakeJob פתוחות כרגע 133 משרות שמזכירות SQL, 16 שמזכירות BigQuery ו-16 שמזכירות Snowflake.

למה לא פשוט לדווח ממסד הנתונים של המוצר?

זו השאלה הראשונה שכל ארגון שואל, ויש לה ארבע תשובות מעשיות:

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

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

איך בנוי מחסן נתונים - מודל כוכב

המבנה הרווח מורכב משני סוגי טבלאות בלבד:

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

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

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

מחסן, אגם, או שניהם?

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

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

מחסן על שרת מקומי מול מחסן בענן

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

מה עולה כסף במחסן בענן

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

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

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

שכבות בתוך המחסן - למה לא כותבים הכול לטבלה אחת

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

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

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

איך יודעים שהגיע הזמן למחסן נתונים

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

מי עובד מול מחסן נתונים

תפקיד	מה עושה מול המחסן	כלי עיקרי
Data Engineer	בונה את הצינורות שמזינים אותו	Python, Airflow
Analytics Engineer	בונה את שכבת הטבלאות המסודרות	SQL
מפתח BI	מודל דיווח ודשבורדים מעליו	כלי BI, SQL
Data Analyst	שואל שאלות ומנתח	SQL, Excel

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

שאלות נפוצות

מה ההבדל בין מחסן נתונים למסד נתונים רגיל?

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

BigQuery או Snowflake - מה נפוץ בישראל?

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

האם ארגון קטן צריך מחסן נתונים?

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

מה זה Data Mart?

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

איך מטפלים במידע אישי בתוך מחסן נתונים?

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

כמה זמן לוקח להקים מחסן נתונים?

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