YT YouTube2Text

YouTube2Text → Transcripts → Lesson 6

Lesson 6 — Transcript

by EH · 6,687 words · 1,151 segments · language en · Watch on YouTube

Open in transcriber Summarize with AI Download SRT/VTT

Full transcript

0:10א שלום רב ברוכים הבאים לשיעור אנחנו היום
0:14ניתן רקע מסוים לקראת הבנתנו של הפא בחלקו
0:19האחרון של הקורס והרקע הזה יעסוק בתהליכים
0:25שמיועדים בעצם להסביר
0:28ניהול נתונים ברמה שלי ארגונים, ארגונים א
0:32החל מהגדולים יותר, לא ארגונים בינוניים,
0:34אפילו ארגונים קטנים, מכלול של ארגונים,
0:38אבל חשוב באמת להבין את כלל המכלול, את
0:41כלל התהליכים
0:44שבעצם מובילים את ניהול הנתונים הערגולים
0:49על ארכיטקטורות שונות, על דרכים שונות,
0:53לאחסן את המידע, לאבד אותו, לאסוף אותו,
0:56לאגור אותו בצורה נכונה בארגונים נים
0:59רבים. כאשר הנושא שלנו היום נוגע הרבה
1:04מאוד בארגון המידע, בארכיטקטורה שהיא
1:08כוללת בתוכה, מחסני נתונים. מחסני נתונים
1:12זה קונספט שאנחנו תכף גם נגדיר אותו, אבל
1:16כיכרון חשוב להגדיר שמחסני נתונים מתאימים
1:20לארגונים שהם גדולים במהותם, גדולים
1:22בינוניים, זה קראוי. בנקים, חברות ביטוח,
1:26חברות סלולר,
1:28חברות בהיקפים מאוד מאוד גדולים כמו אוסם
1:33נסטלה, כמו חברות אחרות שהן בעלות רמות
1:39מאוד גבוהות, נפחים מאוד גבוהים של
1:42טרנזקציות, של תנועות, למשל במלאי, למשל
1:46בהזמנות
1:47של פריטים, תשלומים, העברות, חשבוניות,
1:53קליטה של כוח אדם ועוד ועוד. כך שהיקף
1:57הטרנזקציות המשמעותי הוא עומד בבסיסו בעצם
2:02של הצורך באותו דארה של אותו מחסן נתונים
2:07שכבר נדבר עליו. אז אם כך בואו נלך ונגדיר
2:11מה היא אותה סביבה מחשובית של מחסן
2:14נתונים.
2:16אז מחסן נתונים הוא בעצם בסיס נתונים מאוד
2:19מאוד גדול.
2:21הוא יכול לאחסן מיליארדי או עשרות
2:24מיליארדי רשומות היסטוריות
2:29והוא בעצם קולט הוא
2:33מקבל ועוגר בתוכו נתונים או רשומות או
2:38טרנזקציות
2:39ממערכות הטפעול השונות של הארגול. עכשיו,
2:42אם תיקחו מערכת כמו בנק,
2:46אז בנק ממוצע במדינת ישראל
2:49יש לו סדרי גודל של מיליוני או עשרות
2:53מיליוני
2:55טרנזקציות רשומות על העברות כספים ביום.
3:00בנק בארצות הברית אנחנו כבר מדברים על א
3:04מאות מיליונים או אפילו מיליארדי רשומות
3:09של העברות ביום. אז תראו איזה נפח מידע
3:13כשאתם למשל יכולים להוסיף לזה טרנזקציות
3:18רכש, טרנזקציות כוח הדם, טרנזקציות מכירות
3:23בחברות שמתעסקות בתחום.
3:25למשל ב
3:28חברת נסטלה שיש לה נתח שוק מאוד מאוד
3:32משמעותי בישראל אבל גם בעולם
3:36אם אנחנו מדברים רגע על נסטלי עולמית
3:38אנחנו מדברים ביום על
3:42מיליוני או אפילו עשרות מיליוני טרנזקציות
3:47למשל
3:49הזמנות מספקים
3:53או הז זמנות מלקוחות לרכש, למשל חנויות,
3:58רשתות
4:00א קיוסקים ועוד ועוד ועוד שמזרימים
4:03למערכות של נסטלה הזמנות רכש על מנת שהיא
4:08תספק להם את מגוון המוצרים המאוד רחב,
4:12כמובן כוח אדם. מדובר פה בחברה של עשרות
4:16אלפי עובדים בכל רחבי העולם.
4:20טרנזקציות כספיות, תקבולים כספיים, זאת
4:24אומרת תשלומים שהחברה מקבלת, תשלומים
4:27לספקים, לחומרי גלם, לנותני
4:31שירות, כמובן לעובדים ועוד ועוד ועוד. זה
4:35מסתכם בסדרי גודל באמת של מיליוני רשומות
4:39גם בחברה שהיא לאו דווקא בנק, לא דווקא
4:42חברת ביטוח, אלא חברה שהיא
4:46יצרנית של מוצרי מזון. אז זה מסתכם גם
4:50במיליוני רשומות ביום בהיקפים באמת שנתיים
4:54של מיליארדי רשומות
4:57ומעבר לכך אותן
5:00רשומות אותו היקף עצום של רשומות מפוזרות
5:04לאורך הרבה מאוד מערכות שונות זה יכול
5:08להיות מספר מערכות קטן רכש כוח אדם מכירות
5:12תובלה וכדומה זה יכול להיות מערכות
5:16יעודיות ואז אנחנו מגיעים אפילו כאילו
5:19בחברה כמו למשל בבנק או בחברה מהגודל של
5:23נסטלה או חברת טבע או חברת אנדוקס אנחנו
5:27יכולים להגיע אפילו למאות מערכות
5:30טיפעוליות
5:32שמטפלות בהמון אמתין של העסק ניהול
5:35קמפיינים ניהול פרסום א החזקת כלי רכב
5:39החזקת מנופים היכן שצריך
5:45מערכות להערכת כוח אדם מערכות בקידום כוח
5:48אדם זה מעבר למערכת כוח האדם הבסיסית ועוד
5:52ועוד ועוד
5:54שלמעשה שומרות נתחים מההיקף העצום הזה של
6:00הנתונים בכל מערכת ומערכת
6:04אז יש לנו בעצם עשרות או מאותים
6:09בודדים אפשר לקרוא לזה במערכות
6:12במרכאות כפולות
6:14אם בודדים זה מערכות מידע דה שהן או
6:18סטנדלון עומדות בפני עצמן או מקושרות למעט
6:21מאוד מערכות אבל כל הנתונים כל הרשומות כל
6:26ההיקף הזה של מיליוני רשומות בשנה או
6:29מיליארדי רשומות בשנה הוא בעצם מבוזר
6:35בעשרות עד מאות מערכות שונות שמחזיקות את
6:39הנתונים מבחינת
6:43מקבלי החלטות מנהלים מנכלים סמנקלים ועוד
6:47הם לא מסוגלים בצורה שכזו לראות את כל
6:50התמונה. מנכל לא ילך ועכשיו יקליק או יטי
6:56בן עשות מערכות שונות. תראו לעצמכם רק כמה
6:59זמן לוקח להתמצא, לנוות בכל מערכת ומערכת.
7:03זה לא עובד ככה.
7:05הוא צריך או היא צריכה כמנכל או מנכלית
7:09לוח אחוד מן דאשבורד כזה או מין מערכת
7:14למנהלים שהם יוכלו בעצם לקבל את הנתונים
7:18ולקבל החלטות מושכלות על סמך כל הנתונים
7:23שבארגון
7:25שמאוגדים מחוברים יחדיו
7:28על מנת שהם יוכלו באמת לקבל סליחה בביטוי
7:35את החומר לעס. זאת אומרת,
7:39לאחר עיבוד, לאחר הרצה, לאחר איגוד של
7:43רשומות, לפעמים צריך לחבר שדה מסוים, כמו
7:48למשל סכומי הזמנות. אנחנו רוצים לחבר,
7:51לחבר לפי חודשים, לחבר לפי רועונים, לפי
7:54שבועות, תלוי לפי הצורך העסקי. במקרים
7:57אחרים אנחנו רוצים לערוך עיבוד אחר מסוג
8:01ממוצע. עכשיו תארו לעצמכם
8:05שהבעיה היא א'. איך אנחנו ניגשים עכשיו
8:08להשרות מערכות מידע ומקבלים את הנתונים?
8:13ב' איך אנחנו מקבלים אותם בצורה שניתן
8:17לטפל בנתונים, לשלב אותם, לאדם וכדומה.
8:22ג'. לפעמים המנכל רוצה לראות היסטוריה חמש
8:26שנים אחורה, שבע שנים אחורה. אם אנחנו
8:29נעבוד עם נתונים גולמיים חמש או שבע שנים
8:33אחורה
8:35אז אותו מנכל יבלה את כל הלילה בהמתנה
8:38לתוצאות של העיבוד כי מדובר פה בעיבודים
8:42של עשרות מיליארדים או מאות מיליארדי
8:45רשומות שונות זאת אומרת צריך להביא גם את
8:49הרשומות למצב שהן יעומדו כי למעשה הדata
8:55הוא מעין ארכיון היסטורי של
8:58הרשומות של התקופות הקודמות מהמערכות
9:02הטיפעוליות מעבר לקיבוץ לאיגוד הוא גם
9:05שומר את ההיסטוריה בתוכו עכשיו לכו תעשו
9:08פרocessינ לכו תעשו איבוד על כמה
9:11מיליארדים או עשרות או מאות מיליארדים של
9:14רשומות שונות כדי להביא סדרה של 50 מספרים
9:20נניח היקפי מכירות או הקפי העברות כספיות
9:25שבע שנים אחורה בראייה חודשית חודש אחרי
9:29חודש ואז 7 * 12 אנחנו מקבלים
9:33מעט מאוד מספרים כן כמה עשרות מספרים אבל
9:36העיבוד שנדרש
9:39הוא בעצם רץ על עשרות או מאות מיליארדי
9:42רשומות וזה לוקח המון המון זמן זאת אומרת
9:45שאנחנו זקוקים לדרך מסוימת לאיזה תו לאיזה
9:51אמצעי מתווך שהוא לא רק מאגד בתוך
9:55הדataware
9:57את הרשומות הנאספות מכל המערכות האלה
10:01שאחרת אותו מנכל או מנהל בכיר היה צריך
10:04ללכת מערכת מערכת ולבלות את כל ימיו
10:07בשיטות בין מערכות אלא אנחנו גם מבצאים
10:11עליהם עיבודים בהתאם לבעיות העסקיות או
10:16להחלטות שנדרשות לקבל
10:20שהם כבר עושים את האימוד שחוסך זמן כשמקבל
10:24החלטות מדרש
10:26לראות את הנתונים
10:29המסוכמים באיזשהו גרף או בדוח או בכל
10:32פורמט אחר שמעוניינים בו.
10:38אז כדי לסכם את הנקודה עם כך, מחסן
10:40הנתונים צריך לתמוך בצורה רציפה, זאת
10:44אומרת מדי יום יום או אפילו במה שקראוי
10:48אונליין אה סליחה near time בצורה שהיא
10:52כמעט מיידית
10:55ולהתעדקן
10:56ממערכות המידע
10:58בסוגים השונים של המידע שהוגדרו לאיסוף,
11:02לאסוף אותם בפועל בצורה שהיא אמינה
11:05טכנולוגית. זאת אומרת גם צריך לתת את הדעת
11:08על למשל ניתוק קשר בין מערכת מידע מסוימת
11:15לבין הדataס
11:17מה אנחנו עושים איך אנחנו
11:21למעשה משדרים את המידע בצורה חוזרת איך
11:24אנחנו עולים על כך שישנה תקלה בתקשורת
11:27ועוד ועוד ועוד זאת אומרת יש פה המון
11:29אלמנטים שצריך לתת את הדעת בממשק
11:34בין הדטware
11:36למערכות התפעול, המערכות הטפעוליות השונות
11:39בארגון שמהם הוגדרו נתונים לאיסוף. מה
11:43אנחנו אוספים, באיזה תדירות וכדומה, אנחנו
11:45נדבר על כך. ובסופו של דבר אנחנו צריכים
11:50גם לאחסן את הנתונים באופן שהוא יהיה
11:52אחיד. כלומר אנחנו
11:55מאחידים פורמטים שונים וגם על זה תכף
11:59נדבר.
12:01והנתונים צריכים להיות נגישים למורשים,
12:04למשתמשים, לשם איבוד, לשם הצגה. וכן אנחנו
12:08מבצים עליהם כבר ברמת הדוס או ברמה של
12:12הדטה מרט, שזה בסיסי הנתונים שמשרטים
12:16את מערכות ההצגה למנהלים, מערכות הBI,
12:19הבינה העסקית, buiness inelligence. אז
12:22כבר אנחנו מבצאים עיבודים כמו שהזכרתי כי
12:26אנחנו לא רוצים על כל שאילט ושילטא
12:29להתמודד עם חיפושים ברמה של עשרות או מאות
12:32מיליארדי רשומות בתוך הדטהור אז אנחנו כבר
12:36רוצים כמו שאומרים לאבד את הנתונים שהם
12:39יגיעו לכאורה לאוסים למסד מידע למסד
12:44נתונים משני שמשרט את הצורך העסקי של
12:47המנהלים בהצגה בדוחות בחיתוך ותחקור
12:52נתונים וכדומה.
12:55אז מה היתרונות של הארכיטקטורה שמבוססת על
12:59אמצעי כמו דהס?
13:01אז היתרון הראשון שהוא מאפשר לשלב מידע
13:05ממקורות רבים.
13:09כפי שהזכרתי הדataware בעצם בא ומתקשר
13:16ושולף
13:17ומקבל מידע ומתעדכן מייצרות אפילו מאות
13:21מערכות טיפעוליות מערכות שהן חלק מהטפעול
13:25היומיומי של הארגון או החברה כמו למשל
13:28מערכות הלוואות מערכות של טרנזקציות
13:32העברות כספיות בבנקים מערכות של קליטה
13:36למלאי בחברות
13:38יבו
13:40מערכות של ניפוק מעמלאי, של קבלת הזמנות
13:44מלקוחות ועוד ועוד ועוד. זאת אומרת הוא
13:47אוסף בעצם למקום אחד, למקור אחד את כל
13:52המידע שמפוזר בהרבה מאוד מערכות ניהוליות.
13:56כולל בארגונים שיש להם מערכות ERP, כי לא
14:00תמיד הP הוא מאפשר להתמודד עם כל הצרכים
14:04של החברה. למשל, אם ישנה חברה שהיא תמיעה
14:09א מערכתסאפ
14:10כP
14:12אז עדיין הCRM שלה, הCustomer
14:15relationship management, מערכת הקשרים
14:19מול הלקוחות, ניהול הלקוחות מתבצע במערכת
14:22אחרת, למשל בalילes forורce, כי ליסאפ אין
14:26פתרון מניח את הדעת בתחום של CRM.
14:31או למשל אותה חברה יכולה לנהל הרבה מאוד
14:35אלמנטים
14:37בסאפ בP שלה אבל פיתחו לה מערכת ייחודית
14:43אפילו לא מוצר מדף שהוא מריץ איזשהו מודל
14:46הצטיידות מאוד מאוד ייחודי שאי אפשר היה
14:49לממש בסאפ או לא רצו להתערב בתוך הסאפ ואז
14:53נתוני חיזוי הצריכות של חלקי חילוף של
14:57מוצרים מוגמרים
14:59של צריכות לקוחות או כל אלמנט אחר שעושים
15:02עליו חיזוי הם מבוזרים במערכת אחרת לגמרי
15:08ואז או שמעבירים
15:11לסאפ
15:12את הנתונים בצורה ידנית כשהם מוציאים
15:15הזמנות רכש או שמשנים אותם קצת כי אולי אי
15:20אפשר לקנות את כל מה שחוזים אז מורידים
15:23קצת כמויות ואז יש לנו באמצע פלנר אנושי
15:27שהוא מהווה את המשק רק הידנית, מקבל
15:30ההחלטות בין אותה מערכת חיזוי לבין הסת
15:34ואז אתם מבינים שהמידע לגבי חיזוי הביקוש
15:39מבוזר במערכת חיזוי חיצונית לחלוטין. יתר
15:42המידע לגבי כוח הדם, טרנזקציות כספיות
15:45ועוד נמצא באמת בסא. אז זה למשל דוגמה של
15:50שתי מערכות שהן לחלוטין לא מתקשרות
15:53ביניהן. ואז אנחנו זקוקים לפלנר אנושי
15:57שישב באמצע. גם לקבלת החלטות כמה נדרש
16:01לקנות, אבל גם להעביר נתונים בין מערכת
16:04למערכת, לבחון את החיזוי ובסופו של דבר
16:07להקליד ולהוציא הזמנות רכש לספקים לחידוש
16:11מלא.
16:13אז היתרון פה שלטה שהוא בעצם מהווה צומת
16:19שעוסף ממערכות טיפוליות שונות גם במקרה
16:22שתארתי גם מהסאפ את הנתונים גם מהמערכות
16:27החיצוניות כמו מערכות חיזוי מערכות כוח
16:30אדם אולי שלא מיושמות בשרב מערכות שכר
16:34מערכות יעודיות מיוחדות לתחום ועוד ועוד
16:38ועוד הוא בא משלב את הנתונים נים לתוך
16:43מקור אחד, מקום אחד שבעצם ניתן לתחקר
16:47אותו. זה בעצם היתרון העצום של דטאס.
16:50במקום כמו שטארתי שמנכל או סמנכל או מנהל
16:55בכיר בארגון יתחיל עכשיו לדלג בין עשרות
16:58מערכות כדי לראות תמונה או תמונה חלקית
17:02כלשהיא או לפחות לנסות לא בטוח שיצליח או
17:06או תצליח של הנתונים השונים. אז הדאס בעצם
17:11הוא מאגד את כולם כמו מאגר נתונים אחד
17:14גדול.
17:16היתרון השני שיש לנו תחזוקה קבוהה ואחידה
17:19של מידע.
17:22המידע נאסף הוא נבדק לפני שהוא נכנס לדata
17:27מבחינת כינות מבחינת שלמות המידע שאין לנו
17:30מידע חסר. אנחנו נדבר תכף על איך משלימים
17:34מידע כשהוא חסר או האם נדרש להשלים אותו?
17:39ויכול להיות שאם המידע
17:42משתבש ברמת המערכת המקומית שהיא מערכת
17:44קטנה ומגבלת יותר אז מאוד יכול להיות שהיא
17:48לא יציבה יש באגים היא מיושנת אולי הרבה
17:51שנים כבר היא עובדת הרי שהמידע נבדק ואחר
17:57כך נשמר
17:59ברמת הדטה כלומר יש לנו גם איזשהו גיבוי
18:03לא מבחינת הרשומות עצמן זה קיים במערכות
18:07השונות
18:08גם בגיבויים שלהן, אלא מבחינת משמעות
18:11המידע. אנחנו קלטנו מדי יום ביומו מידע
18:16ממערכות הטיפעול השונות,
18:18בדקנו אותו, ניכינו אותו באופן אוטומטי,
18:22כמובן מדי יום ביומו ורשמנו אותו לבסיס
18:26מידע בפורמט שהוא קבוע ואחרי ובעל משמעות
18:30עסקית. זאת אומרת זה פורמט שאחר כך ניתן
18:34להריץ עליו דוחות גרפים וכדומה בקלות על
18:38מנת לקבל החלטות עסקיות.
18:43יתרון נוסף זה שאנחנו יכולים לפתח ייסומים
18:47שונים מסביב לדata.
18:51אני לא צריך עכשיו על כל ייסום שאני מפתח
18:55ללמוד איך המערכת הטפעולית עובדת. להתחבר
19:00למערכת הטפעולית. יש גם חשש או סיכון
19:04שהייסום שלי יהיה בו באג, תהיה בו תקלה
19:08והוא ישבש את הנתונים הטפעוליים. אנחנו לא
19:10רוצים לעשות את זה. ברגע שיש לנו דהאס,
19:15אנחנו למעשה מתחברים, קוראים את הנתונים
19:18מתוכו את מה שנדרש והיסום רץ על בסיס של
19:22מידע אחד.
19:26לדוגמה,
19:28אם יש לנו
19:30ארגון שמפעיל גם מערכות טיפוליות
19:34פיזיות,
19:36למשל מכירות בסניפים של חנויות,
19:41ועושה את זה הרבה שנים, מערכות קופה
19:44וכדומה, הוא במקביל נכנס לפעילות
19:47אינטרנטית. אז יש לאותו ארגון, לאותה חברה
19:52גם ממשק או גם מערכת שהיא מנהלת את מערכות
19:55הזמנות באינטרנט. אז יש לנו שתי מערכות
19:59שונות.
20:01מערכות א מלאי או ניהול הזמנות, ניהול רכש
20:07למימד הפיזי של החברה ומערכות למימד
20:10הווירטואלי, לרכש בא-קomמרס.
20:14אתם מבינים מפה
20:16שחלוקת המידע בין שתי המערכות חייבת תאום
20:21ביניהם.
20:22כלומר, אם עכשיו אני רוצה לבוא
20:26ולנהל מלאי למשל, שזה ייסום, אז אני צריך
20:30להבין כמה מלאי משכו ממני בחנויות, כמה
20:34רכשו באותו היום וכמה מלאי אני גם צריך
20:37לשריין, כלומר לשמור שמור מה שקראוי,
20:41לצבוע אותו עם שם הלקוח
20:44עבור משלוחים החוצה כנגד האינטרנט. אני לא
20:47אוכל לספק
20:49יותר מלא
20:52ממה שיש לי. אני לא רוצה להגיע למצב של
20:55חוסר. לכן אני חייב לסנכרן
20:59את ממונת המלא שלי אל מול ההזמנות בחנויות
21:03הפיזיות או הקניות בחנויות הפיזיות ואחר
21:06כך אני צריך באמת להשלים את המלאי במדפים
21:09שלא יהיה מחסור. ואל מול הקניות
21:12האינטרנטיות
21:14שהיום כבר מעוות בהרבה מקרים כשליש
21:18מהקניות של ארגונים
21:21וברגע
21:22שמדובר בשתי מערכות נפרדות קשה מאוד לסנכן
21:26אלא אם כן אני מושך את נתוני ההזמנות
21:29נתוני הרכישה נתוני העמליי בחנויות ועל
21:32המדפים
21:34נתוני הרכישות האינטרנטיות חיזוי מלאי
21:38לאינטרנט חיזוי א סליחה חיזוי צריכות
21:41לאינטרנט, חיזוי צריכות לחנויות השונות
21:46שלי, מצליב את כל המידע הזה, מביא אותו
21:49למקום אחד ואז אני יכול להריץ מגוון של
21:51יסומים, כמו למשל
21:54חיזוי צריכות עתידי,
21:57ייסומים של הצטיידות, ייסומים של תכנון
21:59תקציבי למטרת חידוש מלאי
22:03או כל ייסום אחר על אותו בסיס מידע אחיד
22:08במקום
22:10לבוא או להתבזר למספר מערכות שזה כמעט
22:12בלתי אפשרי
22:17ולפתח
22:19גם ממשקים שמדברים עם המערכות האלה מושכות
22:22מהמערכת הזו נתונים מהמערכת הזו ממערכת
22:25שלישית ועוד ועוד ועוד
22:29ברגע שיש לי מקור אחד אמין של נתונים אני
22:35מתחבר אליו אני יוצר ממשק לדataס
22:38מושך נתונים
22:40ואני יכול להתחיל לבצע להם איבודים.
22:44אותו מאגר של נתונים מאפשר לי גם לפתח
22:48פיתוחים עתידיים מאוד מאוד מהר, לתחקר את
22:52הארגון, כי למעשה אני מקבל את כל צורכי
22:55הנתונים במקום אחד. יש לי מאגר אחד שאליו
22:58הכל זורם. זה מין אגמל כזה שאליו בעצם
23:03מתנקזים. הגם ענקי שאליו מתנקים
23:08המון המון נהרות של נתונים ממקורות שונים
23:12בארגון. לכן
23:14בקונסטלציה המודרנית בחרו גם לדata לקרוא
23:19בשם מתוך
23:22איזושהיא אנלוגיה לאותו אגם שמרכז אליו
23:26נערות מידע שונים, נערות נתונים שונים.
23:29אבל אנחנו כרגע מדברים באמת על הדטה
23:33המסורתי והפורמלי יותר. אנחנו לא נכנסים
23:37כשמדובר בדata warה לאלמנטים כמו מידע לא
23:41מובנה, דבר שדיטהלייק למשל הוא בהחלט
23:45תומך בו. אז אם כך אנחנו גם חוסכים
23:50מורכבות מאוד גדולה בפיתוח של ממשקים
23:54בין מערכות חדשות למערכות קיימות ולמספר
23:58מערכות שונות. עכשיו מילה חשובה על גבי
24:01ממשקים.
24:03ממשקים.
24:06אני לא יודע מי מכם באמת התנסע בפיתוח של
24:09ממשקים. אני התנסאתי
24:12אבל ממשקים זה אלמנט הסיכון.
24:16הגבוה ביותר בכל פרויקט תוכנה, בכל פרויקט
24:20פיתוח.
24:23הצורך של שתי מערכות
24:27לדבר אחת עם השנייה. להעביר נתונים באופן
24:31תקין, באופן סדיר, אחת מהשנייה
24:35באופן מלא או אחד מהאלמנטים הכי בעייתיים
24:39והכי מסוכנים בתחום פיתוח מערכות מידע.
24:43אני לא יודע אם זה נאמר לכם באחד הקורסים,
24:46אבל הנה אני אומר
24:49בהרבה סיבות.
24:51יש כל כך הרבה תרחישים
24:54מה יכול להשתבש בתהליך
24:58שלמעשה מגבירים את הסיכון. ובנוסף יש לנו
25:03שני וריאנטים טכנולוגיים, שתי מערכות מידע
25:07מסוגים שונים שצריכות עכשיו איכשהו למצוא
25:12שפה משותפת מבחינת העברת הנתונים.
25:16אני אתן כמה תרחישים שמכסים רק קצה קצהו
25:22של כל התחום הבעייתי של ממשקים ועל מה
25:26אנחנו צריכים לחשוב כשמדובר בממשקים. והנה
25:30ישנן למשל
25:33כשאני מפתח ממשק בין מערכת א' לב
25:37ישנם כבר שלושה סוגי תקלות אפשריים בעברת
25:41המידע.
25:43מערכת א' יכולה לקרוס ולא להעביר את
25:46המידע. יש בג, יש נפילת מתח, כל סיבה
25:51אחרת.
25:53מערכת ב' יכולה לקרוס ולא לקבל את המידע
25:57שהוא עבר לה.
26:00מערכת ובנוסף מערכת המשק ביניהם, צינור
26:04הנתונים ביניהם יכול גם הוא לקרוס בגלל
26:08באג או בעיה טכנולוגית או כל סיבה שהיא
26:11תקיפה של האקרים
26:14כל סיבה שהיא ולא להעביר את המידע בעצם
26:18הסיבה השלישית שהממשק בעצם יקרוס או יפגע
26:22ואז יהיה נתק בין המערכות הנה כבר שלוש
26:25בעיות שצריך להתמודד
26:29עכשיו בנוסף
26:32אם הייתה העברה של נתונים
26:35איך אני מוודא
26:38שמערכת
26:40א' העבירה אותם לב בצורה תקינה
26:44מערכת ב' קיבלה נתונים בלי שהם שתבשו
26:48באמצע
26:50ובסופו של דבר שהממשק היה אמין
26:54ולא נפרץ ולא נפגע
26:57ולא היה גורם שהתערב באמצע ושינה את
27:01הנתונים או הקשיב להם.
27:05הנה כבר אוסף של בעיות ואפשר מפה להמשיך
27:09ולהמשיך ולהמשיך. למשל,
27:12אם מערכת ב' קרסה,
27:14מערכת א' שדרה נתונים, הממשק עבד והנתונים
27:18הגיעו לב, רק לא נקלטו כי מערכת ב' קרסה.
27:22מה אני עושה איתם?
27:24האם אני משמיד אותם כי הם כבר לא עדקניים
27:28לדוגמה שערי מטבע עברה שנייה וחצי הצליחו
27:32להעלות את מערכת ב לשערי המטבע מלפני
27:36שנייה וחצי אין בעצם משמעות
27:39אז צריך להשמיד את המידע לא להסתמך עליו
27:42אנחנו מחכים עכשיו לשידור חדש של שערי
27:45מטבע עדקניים
27:48או שבמקרים אחרים למשל מערכת כוח הדם
27:51משדרת בממשק למערכת
27:53שכר נתונים.
27:57אז כמובן שנצטרך להשאיר ב איזשהו מאגר
28:02ביניים את נתוני כוח האדם כדי שכשנעושש את
28:06מערכת השכר, כשהיא תעלה מחדש ותוכל לפעול,
28:11יחכה למאגר שבעצם אומר הנה יש פה נתוני
28:14כוח הדם, הם חיקו לך מערכת ב', מערכת
28:19נתוני השכר, חישוב השכר.
28:22ועכשיו תשאבי אותם באופן תקין כיוון
28:26שהתאושת
28:29והכל מגובה כמובן במערכות של הודעות, של
28:31תקינות, של איקינות, של צורך לשדר, של
28:35צורך לשדר מחדש, של בקשת נתונים, של מענה
28:39לנתונים ועוד ועוד ועוד.
28:44אז הנושא הזה בעצם של ממשקים לא רק בהיבט
28:47של סיכונים
28:49הוא גם יקר מאוד להקמה ותפעול. זאת אומרת
28:53זה גם מסוכן מבחינה טכנולוגית. יש המון
28:56סיכונים טכנולוגיים בממשמקים כמו שטארתי
29:00והם גם מאוד יקרים בגלל זה להקמה ולטפעול
29:04כי אנחנו חייבים לכסות את כל הספקטרום של
29:09האפשרויות השונות של שיבושים בעברת נתונים
29:12ממערכת אחת לשנייה עכשיו הדוגמה שתארתי על
29:16כל הבעיות על כל המורכבות שלה מדברת רק על
29:19שתי מערכות
29:22עוד לא דיברתי גם על איך אני מתאים את
29:24הפורמט של הנתונים
29:25בין המערכות
29:27איך אני משנה אותם באמצע ועוד ועוד ועוד
29:31לפני שאני קורא אותם למערכת המקבלת.
29:35זה חלק מהתמונה אבל בגדול
29:40הנושא של ממשקים הוא מאוד יקר. לכן
29:46דהס
29:48שמדבר עם הרבה מערכות מצד אחד הוא פותר
29:52להם בעיה של ממשקים. למשל בין מערכת א' לב
29:56וג וד בין מערכת ב' לג' בין ד' ל לב וכולי
30:02וכולי אתם רואים זה מין קערת ספגטי כזו של
30:05ממשקים בין מערכות לא הכל
30:09בסופו של דבר מגיע לאותו דטאare מתנקז
30:13אליו ושם אפשר לאבד את כל הנתונים
30:18אז עצם הקמת הדטה זה גם מוצר מאוד יקר הוא
30:23גם חייב רמות אמינות מאוד גבוהות אז הוא
30:26מאוד יקר מבחינת המשקים מול עשרות המערכות
30:30הארגוניות או מאות המערכות הארגוניות הוא
30:33דורש תפעול צריך להקים צוות של אנשי דיטה
30:37וareהס שיתחזקו אותו שיבדקו אותו שיראו
30:41האם הוא חשוף לסיכונים האם צריך להגדיל את
30:44שטחי האחסון ועוד ועוד ועוד אלמנטים
30:48אז הוא מאוד יקר גם לתפעול יומ יומי
30:51הוא דורש תחזוקה של בסיס נתונים
30:55שאני קורא לו גדול, אבל בעצם אפשר להגיד
30:57שברוב המוחלט של המקרים מדובר בבסיסי
31:00נתונים ענקיים
31:02גם כמידע מובנה, גם כrctured
31:06דה הם עדיין ענקיים בהקפים של מיליארדי או
31:11מאות מיליארדי רשומות שלא לדבר על יותר.
31:15ונדרשת השאלה שהיא בעצם בבסיס הניתוח,
31:19בבסיס התהליך של הקמת.
31:22מה נחליל בו? אם יש בארגון מאות מערכות
31:26שונות של תחומים שונים, של תתי תחומים
31:30שונים וכדומה, האם את כולם נקשר לדatawar
31:34או שזו פעילות מיותרת? כי בסופו של דבר
31:38מבחינת מקבלי ההחלטות או הדרישה לתחקר
31:41נתונים, ללמוד מהם ולבדוק, מאוד יכול
31:45להיות שהרבה מערכות
31:47לא ממש צריך להצליב את המידעים מידע
31:50ממערכות אחרות ובהרבה מערכות בארגון בהחלט
31:54כן. זאת אומרת יש פה החלטה איפה נשקיע
31:57בהקמת נמשקים, איפה נשקיע בהקמת מנגנונים
32:01לעברה של נתונים ממערכות טיפעוליות כאלו
32:04ואחרות עד לרמת הDA
32:08או במילים אחרות מה בדיוק נאסוף, איזה
32:12מידע, מה נעביר, מאיפה נעביר,
32:16לאן נעביר, לאיזה טבלאות בדהוס, תכף נדבר
32:20גם על זה. אז זה חלק מהשיקולים והבעיות
32:23והסוגיות
32:25וגם האתגרים
32:27שמהנדסי תעשייה וניהול
32:31בעיקר בתחום של מינה עסקית, של מערכות
32:34מידע, של תשתיות נתונים וכדומה, הם
32:38מתחבטים בו מדי יום ביומו. יש פה גם
32:43החלטות ניהוליות. כלומר, אם אני מחליט שלא
32:47להקים ממשק למערכת מסוימת, לוותר על
32:49הנתונים שנכללים בה כמה אני חוסך מבחינה
32:53כלכלית, כי חסכתי הוצאות הקמה של המשק, של
32:57החיבור, של ניהול נתונים, של הרבה
32:59אלמנטים.
33:01ומה המחיר הניהולי שאני מוותר על הכללת
33:04הנתונים הללו בדה, על האפשרות לאבד אותם,
33:09להצליב אותם עם נתונים, עם מערכות אחרות
33:12ולקבל אולי החלטות ניהוליות הרבה יותר
33:16מושכלות.
33:18אז אם אתם רוצים לצאת עם איזשהו מסר מרכזי
33:22ככה מהשקף, מעבר ליתרונות ולחסרונות, המסר
33:25הוא א נע להיזהר עם ממשקים. אתם רוצים
33:30מינימום של ממשקים,
33:32לא תמיד זה אפשרי לרדת למספר מאוד מועט של
33:36ממשקים. יש גם פתרונות טכנולוגיים כמו
33:39למשל הקמה של בס. בס זה מין אוטוסטרדת
33:43מידע שאליה אנחנו מממשקים את המערכות.
33:47אנחנו פותרים פה חצי מהבעיה כי עדיין
33:51אנחנו צריכים לפתח ממשק מידע למערכת
33:55הטפעולית. אבל בצד של האוטוסטרדה הזו קל
33:59מאוד להתחבר עם השביל הזה שאנחנו או הכביש
34:03הזה של המידה אל תוך האוטוסטרדה. זה בעצם
34:07האנלוגיה של בס שמאפשר להוציא נתונים
34:12אליה וממנה למערכות אחרות כולל לדata. אז
34:17יש פתרונות טכנולוגיים שמפשטים את הבעיה.
34:21עדיין המסר שלי ממשקים הם לטעמי
34:27אחד האלמנטים הכי מסוכנים מבחינת סיכון
34:31טכנולוגי בפרויקטים של מערכות מידע ואחד
34:34מהאלמנטים היקרים ביותר שקיימים. אז בואו
34:38נמשיך הלאה עם המסר הזה ונבין בעצם איך
34:42עובדה.
34:44אז כמו שוודאי ניחשתיהם מהתיאור שלי, יש
34:48לנו חיבור בין הרבה מאוד מערכות טפעוליות.
34:51במקרה הזה תארתי רק ארבע מחוסר מקום. אז
34:55מערכת כמו למשל CRM, customary
34:57relationship management, מערכת ניהול
34:59קשרי לקוחות, ERP, enerprise resource
35:04planning, מערכות
35:07תפעול ארגוני, כולל
35:11א בilling שזה מערכות
35:15של חיוב לקוחות, כל הנושא של הוצאת
35:18חשבונות, קבלת תשלומים, סליקות של תשלומים
35:22וכדומה. זה בעצם מערכות הבילינ כל התנועות
35:25הכספיות
35:27וספליצן
35:28שאלה מערכות ניהול המלי
35:31אלו צריכות להתחבר בדרך כלשהי
35:36שזה קודם כל המשק זה החץ השחור
35:39אל הדה
35:41אבל בדרך באמצע יש לנו
35:45אוסף של כלים או טכנולוגיה שאנחנו קוראים
35:49לה ETL et ETL ראשי תיבות של extract
35:53‏transform
35:55load
35:56והכינוי השני שלה זה data פייפלין זאת
36:00אומרת צינור הנתונים
36:02עכשיו זה לא שאנחנו פשוט מעתיקים את
36:05הטבלאות את הרשומות בCRM מעתיקים את
36:08הטבלאות והרשומות בP מעתיקים את הטבלאות
36:12בבילדינ בבילינג מעתיקים את כל הרשומות
36:16בספליי צן ופשוט מכניסים את זה איךשהוא
36:19איפהשהוא בדata זה לא עובד ככה אנחנו
36:23צריכים באמצע
36:26לשים טכנולוגיה
36:28שהיא תחליט
36:31ותבצע כל מיני פרמטרים למשל מה התדירות
36:35האם זה פעם ביום האם זה כל רגע ורגע מה
36:39התדירות שאנחנו מעתקנים את הדיטה
36:44מאיזה טבלאות אנחנו שואבים מידע איך אנחנו
36:47קוראים לטבלאות האלה לשדר לנו את המידע זה
36:51בעצם התהליכים של אסטר
36:53הטרנספורמ האם נדרש איזשהו שינוי מבני
36:56בדיקה של איכות הנתונים אולי יש נתונים
37:00שהם משובשים בגלל השידור או בגלל שמישהו
37:03הקליד לא נכון אנחנו לא רוצים להכניס
37:07בהזדמנות הזו נתונים לדהס שהם מזובלים
37:13מסיבה כלשהי מאוד יכול להיות שבמערכות
37:16הטפעוליות יש טעויות יש תקלות אבל אנחנו
37:19לא רוצים למשוך את התקלה הזו לתוך הדטה.
37:23אנחנו רוצים לבדוק את התקינות של הנתונים
37:25כי אחרי זה נעלים מקבלים החלטות אסטרטגיות
37:30לגבי הנתונים הללו. ובסופו של דבר הלad.
37:33זאת אומרת עצם זה שמשכתי נתונים שעשיתי
37:36עליהם איזשהיא טרנספורמציה, שינויים
37:38במבנה, שינויים קצת בערכים, כל מה שנדרש
37:42בשביל הדיטה, איך אני דוחף אותם, איך אני
37:46מכניס אותם, איך אני כותב אותם לדטה,
37:49לאיזה טבלאות, לאיזה מקומות, איפה אני
37:51מאחסן אותם במחסן נתונים הגדול הזה שלי.
37:58אז זה למעשה מה שתהליך הETL
38:02הtract transform וload מבצע כפי שציינתי
38:06קוראים לזה דה פייפלין שזה שם פחות מוצלח
38:09לטעמי כי הוא לכאורה אומר בוא פשוט נעביר
38:14נתונים דרך מין צינור למשל מהCRM
38:19לתוך הדטה כן נעתיק ונעביר ונשדר זה לא
38:24עובד ככה התהליך הוא הרבה יותר מורכב כפי
38:27שאנחנו נראה עכשיו.
38:33אם כך
38:34כלי הl או הטכנולוגיות המשובוקות על ידי
38:38חברות רבות et זה משהו שקיים בשוק מאז
38:42בעצם שהארכיטקטורה
38:44של דטה קיימת סכל מסביבות שנות ה-70 והש80
38:49אז גם היה פיתוח של כלי ויש הרבה חברות
38:52טובות ותיקות
38:54ובעלות התמחות בתחום של
38:57יש גם כלים של open source שתומכים בך כך
39:02אבל בגדול חשוב לציין שהתהליך של
39:08extractטform
39:09וload
39:11הוא תהליך שכל כלי וכלי נותן אותו
39:14בשלמותו. זאת אומרת אני לא צריך כלים כלי
39:17אחד שיעשה אקסטרקט השני טרנספורם השלישי
39:20load. לא. יש ממש חבילות כלים שנות את כל
39:24התהליך, תומכות בקשת מאוד רחבה של יצרנים
39:28של מחסני נתונים, של מערכות
39:33ומאפשרות לעשות גם את הלad לתוכן.
39:37גם בתחום של האקסטרract הן תומכות בסוגי
39:40מסדי נתונים שומעים למשל פוסק SQL MSSQL
39:46MySQL כמובן הידוע ועוד ועוד ועוד על מנת
39:50לתת את הקישור לקצה שמאפשר גם מצד אחד
39:56להוציא את הנתונים לשאוב אותם מתוך מסדי
40:00נתונים טבלאיים ובקצה השני גם לרשום אותם
40:05לתוך הדטהס
40:07אז מתוך זה אנחנו בעצם זקוקים לבחור כלי
40:11ETL1 שישרט את שתי נקודות הקצה שתארתי.
40:17האתגר בייסום תהליכי ETL
40:21הוא נוגע למספר אספקטים. כשהאספקט הראשון
40:25הוא מאיזה מערכות אנחנו נאסוף נתונים. האם
40:28אני צריך באמת
40:30להשקיע בחיבור של הדטה על מנת שכל המערכות
40:35בארגון, כל מערכות המידע ישדרו לי נתונים?
40:39האם אני זקוק לאסוף נתונים מכל מערכות
40:42המידה וארגון, מכל המערכות הקיימות לכל
40:45צורך וצורך? כנראה שלא.
40:49זאת אומרת, מתוך ניתוח הסביבה העסקית,
40:52התהליכים, הצרכים של המנהלים ושל כל
40:55הרמות, כל המדרגים בארגון,
40:58של נתונים, של אנליטיקה, של קבלת החלטות,
41:02כי בסופו של דבר את הבינה העסקית, את
41:05המערכות שאנחנו נכיר,
41:07את הויזואליזציות, את הגרפים, את הדוחות,
41:10אנחנו נבסס על נתונים. אז אנחנו צריכים
41:13להבין איזה נתונים חייבים להיות נגישים
41:17לרמות שונות נרחבות בארגון
41:21ואיזה מערכות צריכות לספק את כל הנתונים
41:25או את חלקם או בכלל לא? אז זו ההחלטה
41:28הראשונה.
41:31השאלה השנייה היא איך אנחנו נאסוף נתונים
41:33עם מערכות שונות? איזה סוגים של ממשק
41:37אנחנו צריכים להקים מול כל מערכת ומערכת?
41:40האם ניתן להשתמש בכלי ETL סטנדרטים שיעשו
41:43את האקסטרctט
41:45מבסיסי הנתונים של המערכת? האם אני צריך
41:48לבצע תהליך שונה קצת?
41:51איך אני צריך לתחזק את המשקים או את
41:54התוכנות שמעבירים לי נתונים ששואבים אותם
41:58וכדומה? שאלה הבאה היא שאלת התדירות.
42:03אחת לכמה זמן אני נדרש לאסוף ולשדר את
42:07הנתונים ממערכת התפעול, מכל מערכת טפעול
42:12למערכת
42:13הדארה.
42:15אז יש נתונים שאנחנו נבצע תהליך בץ'.
42:20מערכת הטפעול תפעל כרגיל, כן? למשל מערכות
42:24בנקאיות מבצעות טרנזקציות של העברות.
42:27אנשים מעבירים כספים מחשבון לחשבון ועוד.
42:33אבל בלילה
42:37זמן שבעצם לא עובדים אז אפשר לעצור את
42:40הפעילות של המערכות הטפעוליות על מנת
42:43לעדכן את משדי הנתונים את הדטה
42:46אנחנו נריץ תהליך פעם ביום בלילה שיקח את
42:51כל התנועות היומיות שכפי שציינתי בישראל
42:54זה יכול להגיע למיליוני תנועות במדינות
42:57אחרות מדובר בכני מידה
43:02פי מאות או אלפים של תנועות
43:05והוא יקח וישדר ויעדכן את הדטה
43:09במהלך לידלי שיכול גם וימשך כמה שעות לכן
43:13עושים אותו בלילה כי אחרת הוא פשוט מקפיא
43:16או משביט את המערכות הפעילות בלילה לא
43:19עובדים
43:21התהליך יכול להתבצע גם מספר פעמים ביום
43:24הפסקת צהריים
43:26לילה בבוקר לפני העבודה זה במקרים שהיקפי
43:31שידור הנתונים והעדכון הם יותר פחוטים.
43:36ויש גם תהליכים שתורשים תמונת מצב עכשוית
43:40בדata.
43:42אנחנו קוראים לזה near real time, כלומר
43:46מאוד קרוב
43:48למצב במציאות.
43:51מדי חלקיקי שנייה. אם הייתה תנועה במערכת
43:53הטפעול, היא מיד משדרת את הנתונים לדה.
43:57למשל, אם אנחנו זקוקים לנתוני מלא
44:00עדקניים, אנחנו לא יכולים לקבל
44:04תמונה באחת המערכות שהיא עדקנית, זה
44:07המערכת התפעולית של ניהול המלא בארגון
44:11ובמערכת השנייה שזה הדare, תמונה שהיא
44:15משובשת.
44:17אם אנחנו נעשה את זה בתהליך בצ'י אז רוב
44:21יום העבודה
44:23הנתונים של המלאי במערכת התפעולית שזה
44:27בעצם תמונת המצב תמונת העולם האמיתית יו
44:31שונים ממערכת הדארה
44:35ואז לא נוכל לקבל החלטות אמינות נצטרך כל
44:38הזמן על כל פרית ופריט לדלג למערכת התפעול
44:42ובכך בעצם מערכת הדה לא תשמש אותנו לכלום
44:46אז במצבים שאנחנו צריכים התאמה מלאה בין
44:50מערכות הטפעול בכל רגע ורגע למערכת הדאה
44:55אנחנו נבצע שידור כל פעם שמתבצעת
44:59תנועה או נקלטת תנועה במערכת הטיפול היא
45:02מיד תשודר למערכת הדה
45:07ואז בהבדל
45:09של בין שנייה לעלפיות שנייה
45:14זה בעצם הפרש הזמן של חוסר ההתאמה בין שתי
45:18המערכות. מערכת הדאוס בעצם תתעתקן תוך סדר
45:21גודל של זמן שהוא בין על פיות שנייה
45:25לשנייה אחת.
45:27עכשיו למה אנחנו קוראים לזה near real
45:30time? מכיוון שרט time הוא מדבר באמת על
45:35מערכות שזקוקות להיות מעודקנות בנתונים
45:40ברמה של מיליוניות שנייה. כמו למשל טיל
45:43שמנוות צריך לשנות את המקום את המיקום שלו
45:47המהירות של הטיל כל כך מהירה שהוא למעשה
45:50אוסף נתונים מהסביבה שלו מבצע את החישובים
45:54מעדכן את הנתונים משנה את הנתיב בהתאם
45:58בסדרי גודל של מיליוניות שנייה מאוד מאוד
46:02מהיר כי הוא גם חייב להיות מאוד תגובתי
46:06ומערכות מחשוב ארגוניות לא צריכות להיות
46:10מעודקנות עד רמת מיליונית השנייה,
46:14אלא אפשר להסתפק גם ברמה של עדכון של עד
46:19שנייה. לא יקרה שום דבר. אם תחלוף שנייה
46:21ושתי המערכות לא היו מאודקנות, הם תתעדכנה
46:24והנתונים תעדקנו.
46:27זאת אומרת השוני בין מצב המציאות כמו שהוא
46:32משתכף במערכת התפעולית
46:36לבין מצב המציאות בדה
46:39יכול להשתנות
46:42בהפרש של בין יום במקרה שאנחנו עושים
46:45עדכוני פעם ביום בלילה ואז המערכת של
46:49הדיטה לא מעודקנת להיום היא מעודקנת
46:53לאתמול
46:55ויכול להיות שאפשר להסתפק בזה זה שזה בסדר
46:57גמור.
46:59למשל במכירות של ציוד מאוד יקר כן אין
47:02הרבה מכירות כאלה אז לא נורא עם המכירות
47:06של ארבעה שעות האחרונות לא תיכנס לה כי יש
47:10מעט מכירות הציוד הוא מאוד יקר אבל אפשר
47:13להסתמך על מכירות
47:15של החודשים האחרונים השנים האחרונות
47:17והכדומה
47:20הדרמה של מדי מספר שעות אנחנו נעדכן זה
47:24מספר פעמים ביום והדרמה שההפרש
47:28של E עדקניות יהיה בין סדר גודל של עלפיות
47:31השנייה לשנייה. כלומר, הן יהיו מסונכרנות
47:35זו עם זו המערכת הטיפולית והדאה.
47:41השאלה באיזה תדירות נובעת מהשאלה הבאה? מה
47:45היא רמת הדקניות הנתונים
47:47שאנחנו מחזיקים?
47:49כלומר האם מספק לעדכן בבץ' או האם מספק
47:54לעדכן מספר פעמים ביום או האם אני צריך
47:56לפעול בנירט time שזה רמת עדכון אחרת היא
48:01גם יש בה אתגרים אחרים לעומת בץ' או מספר
48:05פעמים ביום
48:08זה לא שהעלות
48:11של עדכוני בץ' ונרלתם היא זהה אלא יש פה
48:16איזושהיא עלות נוספת תחזוקה וכדומה האלה
48:19realט time כן זה טיפה יותר מורכב
48:23אבל האם רמת העדקניות של הנתונים כשאני
48:26עובד למשל בבת שהיא מספקת
48:30לי יצא למשל לעבוד א בארגון
48:36בתקופת השירות הצבאי שלי ששם עדכון של
48:40מערכות עמלי היו בבץ' האפשרות לקבל
48:45החלטות למשל משל
48:48איזה ציוד להשיר ברמת מלא ביטחון כלומר לא
48:52לגעת בו איזה ציוד זמין לניפוק וכולי היו
48:57משובשות היה צריך כל הזמן לדלג בין רמת
49:01הדטה
49:03לרמת המערכות הטפעוליות כי העדכון היה
49:05בצ'י כי העדכון נעשה פעם בלילה ולכן תמונת
49:11המצב של מקבלי ההחלטות הייתה נכון לאתמול
49:15לא נכון
49:16להרגע ולא נכון להיום.
49:19והדברים השתנו כי ציוד נופק, ציוד התקבל,
49:23ערכי המלאי, כן? מספר הפריטים במלאי בפועל
49:28ירד או גדל. ועכשיו כשצריך להוציא למשל
49:32הוצאה
49:34הוצאת הזמנת רכש מאוד יקרה
49:38אם הסתמכו על הדיטה וarehסתמכו על אתמול
49:41אבל מאוד יכול להיות שציוד כבר הגיע הגדיל
49:44את המלאי ולכן כבר לא צריך להוציא את
49:47הזמנת הרכש כלומר תמונת המצב ברגע שיש לנו
49:51בץ' היא לא מסונכרנת
49:55אפשר לחיות עם זה בהרבה מקרים בהרבה
49:58ארגונים שהצרכים שלהם יותר ארוכי טווח,
50:01אבל ארגונים שצריכים לקבל החלטות ברמה
50:04יומיומית על סמך נתוני הדטה וareאוס
50:07מאוד קשה לעבוד כשהסמחון הוא ברמה בצ'יט
50:12פעם ביום במהלך הלילה כי אז בעצם אני
50:16מסתמך על נתוני האתמול ולא נתוני על מה
50:20המציאות היום הרגע
50:23זה לגבי רמת העתקניות של הנתונים
50:27לא תמיד רצוי להתמיד ני התהליכים של
50:30נירילטי מבחינת התדירות עדכון כי זה יקר
50:34יקר יותר זה דורש יותר תחסוקה צריך לבחון
50:38את זה מבחינת הצרכים של קבלת ההחלטות של
50:41המנהלים בארגון
50:45האם צריך לבצע כשאנחנו בעצם שואבים
50:49ומעבירים נתונים לדאה ממערכות הטיפול האם
50:52צריך לבצע איזושהיא אמרה של נתונים כדי
50:56לאחד ביניהם
50:59לדוגמה, החברה הבינלאומית שעובדת גם
51:01בארצות הברית וגם באירופה
51:05יכולה לנהל שתי מערכות שבהן מבנה התאריכים
51:08מוגדר באופן שונה.
51:11בארצות הברית מגדירים תאריך כשם החוד או
51:15מספר החודש, מספר היום בחודש
51:20ובארבע ספרות את השנה. זאת אומרת החודש,
51:23היום והשנה.
51:25כמובן שבישראל, גם באירופה וחלקים נרחבים
51:28מהעולם, אנחנו שומרים את זה כיום,
51:32חודש ושנה.
51:34עכשיו זה יכול להביא לשיבושים ובלבולים
51:39מבחינת קבלת החלטות, מבחינת חישובים,
51:42מבחינת כל אלמנט שדורש החלטה מבוססת
51:46נתונים. אם אני מסתכל למשל על תאריך כמו
51:4904 051
51:54האם מדובר פה ברביעי למאי 2011 או שמדובר
51:59פה בחמישי לאפריל 2011?
52:03כלומר, אנחנו נדרשים לקבוע מבנה אחיד
52:07ואחוד
52:09לנתונים, כמו למשל התאריכים.
52:12חייבים להחליט האם
52:15התאריך במבנה אמריקאי יומר למבנה אירופאי
52:18או המבנה אירופאי יומר למבנה אמריקאי
52:22וכמובן דורש דיונים והחלטות
52:25והשפעות של האירופאים על האמריקאים או
52:28האמריקאים על האירופאים. אבל זה חייב
52:31להעשות.
52:33וזו אחת הדוגמאות הפשוטות ביותר שקיימת
52:38לאלמנט של הטרנספורם של המרת נתונים על
52:43מנת שנאחד אותם ונוכל לאבד אותם בלי לאבד
52:47בא' את המשמעות בדרך בלי לשבש אותה אז
52:52בואו נראה אם כך לעומק את המרכיבים השונים
52:57של ה
52:59אתגרים שמעורבים באקסטרctט בטנספורם ובלוד
53:03של נתונים. כשאנחנו שואבים אותם ממערכות
53:07טיפעול, צריכים אולי לבצע המרה או בדיקה
53:10של הנתונים ומכניסים אותן, טוענים אותם
53:14לתוך מערכות הדאה.
53:19כשאני מסתכל על אלמנט האקסטרctט, כלומר
53:23אלמנט של יבוא הנתונים, פריקת הנתונים
53:27מהמערכות הטפעוליות
53:30בדרכן אל הדare,
53:33אז אני חייב לקבוע מה בעצם יעורר את
53:37הפעולה של הפריקה הזו. זאת אומרת למה
53:41שעכשיו ניקח ונשאב את הנתונים מהמערכות
53:44הטיפעוליות.
53:46ויש שני קריטריונים. יש יותר. כמובן שזה
53:49הולך ומורכב, אבל בגדול בבסיס יש שני
53:53קריטריונים.
53:54אם היה שינוי במערכת הטפעולית, כלומר
53:58רשמנו רשומה חדשה, שינינו רשומה קיימת או
54:01מחקנו רשומה, לדוגמה הזמנו הזמנת רכש חדשה
54:07מלקוח,
54:09שינינו הזמנת רכש קיימת, הלקוח אולי הוריד
54:12את הכמות, הגדיל את הכמות או ביטל נועה
54:16הלקוח התחרט על הרכש.
54:19אז זה שינוי למשל
54:22שהוא שינוי שמעורר בריקה. כלומר
54:27אנחנו מיד נשאב את הנתונים החדשים, את
54:32הרשומה החדשה, את הרשומה המתוקנת, את
54:35ההודעה שהייתה מחיקה של רשומה מהמערכת
54:38הטפעולית
54:40ונעדכן,
54:42נשלח את הנתונים הללו, את הרשומות הללו
54:45שהודקנו אל הדטה. זה המשמעות של אירוע
54:48מעורר ואז אנחנו מקבלים עדכון מסוגר real
54:53time כי בעצם על כל שינוי של נתונים
54:55במערכת התפעולית אנחנו מיד ניצור תנועה
54:59שמעבירה את הנתונים האלו אל הדטה.
55:04הסוג השני הוא אירוע מתוזמן.
55:07אירוע מתוזמן למשל יכול להגיד
55:11אל תעדכן את הדare בכל שינוי ושינוי. כן?
55:15אבל בואו לא נשגע את הדus, לא צריך אין
55:19לחץ בואו נעדקן את הדare כשהצטברו
55:23מהרשומות לעדכון
55:26נצבור אותם ברגע שנגיע למונה במערכות
55:30הטפעוליות במערכת הטפעולית של 100 נשלח את
55:33הנתונים זה אירוע מעורר
55:37אירוע נוסף
55:39זה ליצור schedulerar skedדular זה שעון
55:43מעורר למשל אחת בלי לילה
55:46הסקדולר שלנו מתעורר
55:49שולח פקודה
55:51למערכות ה לא סליחה תמשוך נתונים מתוך
55:56המערכות הטפעוליות השעה עכשיו אח בלילה
55:59בואו נעשה עדכון ב'
56:02אז זה למשל פעולה נוספת
56:05אפשרות שלישית
56:07מנהל יושב מול הדאה רוצה לראות את תקפי
56:12המכירות 12 חודש אחורה
56:14המנהל נכנס למערכת לאפליקציה
56:18שקורת לדata warehouse הדa
56:22עכשיו לא רק יציג לו את הנתונים אלא הוא
56:25יגיד בואו עכשיו נריץ תהליך של על פי
56:29שנייה נפעיל את הl נראה מה קרה היום נמשוך
56:33את הנתונים הכי עדקניים ממערכת הטיפעול
56:36ממערכת המכירות הם ימשכו
56:39יעובדו יקראו בעל פית שנייה לתוך הדטה
56:43הוהס ואז המנהל כתוצאה
56:46מהתחברות למערכת
56:50עורר תהליך
56:52של שאיבת נתונים עדכון ואז הוא יקבל את
56:55הנתונים נכון לעכשיו כי עצם הפנייה שלו
57:00לדata דרך האפליקציה דרך הייסום למשל
57:04מערכת Businesselligence
57:08גרמה לכך שהמערכת ככה לרגע קפעה לא מיד
57:12מיד הגיבה לא מיד הציגה לו את התוצאות של
57:16מה שקורה בדה אלה הפעילה תהליך של עדכון
57:18מהיר ואז הוא מקבל תמונת מצב התקנית
57:23במהלך היום אף מנהל לא רצה להפעיל את
57:27מערכת הביאה לא הייתה פנייה בסדר אז נחכה
57:30ללילה ובלילה נריץ תהליך בצ'י מסודר
57:35ונעביר את הנתונים כי אף אחד בעצם לא היה
57:38צריך לראות אותם אז זו למשל עוד אפשרות
57:43של מי מעורר את הפריקה או מי מפעיל את כלי
57:47הl על מנת שהוא ישאב נתונים ממערכות
57:49הטיפול.
57:52אנחנו גם צריכים להבין מה הם זמני הפריקה,
57:55מה הם הקפי הנתונים, האם הם מאוד
57:57משמעותיים, האם הם קטנים יחסית. זה מיד
58:00משפיע לנו על קביית האסטרטגיה
58:05של פריקה מסוג בו מסוג ניר אונליין או כל
58:09אלמנטה אחר, כל מודל אחר שאנחנו חושבים
58:12עליו וכמובן על מה שמעורר, האירוע שמעורר
58:17את הפריקה של הנתונים מהמערכת הטפעולית או
58:21מהמערכות השונות לתוך הדה.
58:25שאלה נוספת בקטר.
58:28מה בדיוק אני עושה כשאני מקבל ברשומה שדות
58:32ריקים או רשומות חלקיות?
58:35האם המשמעות היא שהפריקה הייתה משובשת?
58:39האם חלק מהענתונים לא הוזנו?
58:42האם בהמשך בטרנספורם שאנחנו תכף נדבר אני
58:46אצטרך לטפל אבל כעיקרון העובדה שיש סדות
58:49מסוימים ריקים או רשומות שאין חלקיות זה
58:53בסדר זה תקין אבל צריך לטפל בזה על ידי
58:57תהליכים יותר חכמים אבל לא מדובר פה
59:00בשיבוש או לחילופין שהעובדה שיש לי שדה
59:04מסוים שהוא ריק הגיע ריק או שהרשומה היא
59:08חלקית קטועה
59:10מדובר פה בעיה של פריקה וצריך להריץ מחדש
59:15את תהליך הפריקה אולי להוציא הודעה לצוות
59:19של הl של הדטה
59:22ולייד אותם שיש פה תקלה טכנית וכדאי לבדוק
59:25את הנושא כלומר גם התגובה במקרה של שדות
59:29ריקים ורשומות חלקיות היא על פי אופי
59:34הנתונים שהיו אמורים או לא היו אמורים כי
59:39יכול להיות שזה מותר שיהיו ערכים ריקים א
59:43להיות בתוחה רשובה.
59:48המימד השני או התהליך השני של כלי ITL זה
59:51כמובן הטנספורם העמרה של הנתונים למבנה
59:55שהוא נדרש ואותה מרה יכולה להתבצע באחת
59:59משתי שיטות.
1:00:02אנחנו יכולים לבצע multiage
1:00:04transformation שהמשמעות שלה שאנחנו נפרוק
1:00:07את הנתונים מתוך מערכות הטפעול.
1:00:11למסדי נתונים משניים.
1:00:13זה מה שקראו סטיג'ingנ עדיין לא לתוך
1:00:16הדטה.
1:00:18נבצע עליהם פעולות של בדיקה, של תקינות,
1:00:21של טרנספורמציה, של שינוי. למשל, כמו
1:00:24שתארתי, שינוי במבנה תאריך, כן? מחליפים
1:00:27בין המיקום של היום והחודש, בין הפורמט
1:00:31האמריקאי והאירופאי.
1:00:34ואז נכתוב את הנתונים כשהם שימו את כל
1:00:36הבדיקות והטרנספורמציות
1:00:38לתוך הדטה וareאוס.
1:00:41המבנה השני הוא inwarehouse
1:00:43transformation.
1:00:45כלומר אנחנו לא נצטרך
1:00:48מסד נתונים משני.
1:00:51לא צריך להחזק אותו, לא צריך ממשק אליו
1:00:54וממנו, אלא בתוך הדיטה יש מין משק ממש א
1:01:00סליחה מסד נתוני ביניים כזה בתוכו.
1:01:05אנחנו נפרוק את הנתונים, נבצע את
1:01:07הטרנספורמציה ואז נרשום אותם לטבלאות
1:01:11הקבועות, כמו למשל טבלת ההזמנות, טבלת
1:01:14הרכש, טבלת המליי. א אחרי שהמרנו וביצענו
1:01:18את הכל בתוך הדטה כרכיב בתוך הדטה.
1:01:25אז צריך להחליט עם איזה אלטרנטיבה אנחנו
1:01:28הולכים. יכול להיות שהmultiage
1:01:31transformation
1:01:32מבחינה כספית הוא פתרון זול יותר כי in
1:01:37warehus transformation בעצם יכלול את
1:01:39הרכיב הזה בתוך הדata warehouse ואז המוצר
1:01:42שלטה כולו יהיה יותר יקר זאת אומרת צריך
1:01:46לבדוק פה איך זה גם משתלב עם כלי ATL איך
1:01:50זה משתלב עם ממשקים כמו שציינתי ושיקולים
1:01:55כאלה
1:01:57נושא של החידות פורמט הנתונים גם הוא חשוב
1:02:01א צריך לוודא שגודל השדה הוא כנדרש אם
1:02:05צריך לקצץ
1:02:07את הסוף של השדה וגם פה יש שאלה אם פשוט
1:02:10מקצים כמו בשמות משפחה ארוכים כמו שאנחנו
1:02:14לפעמים מקבלים בדואר
1:02:17או שאנחנו עושים טרנספורמציה מסוג חכם
1:02:21יותר
1:02:22א סוגי השדה יכול להיות שאנחנו שומרים
1:02:27מספר מסוים גם בפורמט של מחרוזת ואנחנו
1:02:30רוצים לנהל אותו בדata
1:02:33כמשתנה שלם או משתנה אפילו מסוג ריל, מסוג
1:02:39מספר עסרוני. אז גם זה צריך להיבחן. ההמרה
1:02:43בעצם בין סוג שדה אחד לסוג שדה אחר.
1:02:48כמובן הנושא של ניקוי שדות, בדיקה של
1:02:51הנתונים
1:02:53והמראה שינוי כנדרש. יכול להיות שהמערכת
1:02:56הטיפעולית
1:02:58היא שומרת את ערכי ימין גבר אישה כ01
1:03:03ואנחנו עובדים עם עוד מערכות אחרות שרובן
1:03:08משדרות לדata
1:03:10את נתוני המין כמלפי
1:03:13MF אז מכאן אני צריך להעמיר את ה01 למיל
1:03:18MF נושא של א תאריך נושא של זמן גם שעה
1:03:23יכולה להיחתב כ אה שעה
1:03:29מתוך 24 שעות כלומר
1:03:3221.200
1:03:36יכולה להיחתב גם במבנה של AMPM, כלומר
1:03:4009נ.
1:03:43‏PM והם מקבילות זו לזו ומערכות שונות
1:03:47יכולות לנהל גם זמנים
1:03:51בסטנדרטים שונים שאנחנו צריכים להאחיד
1:03:54אותן.
1:03:56שמירה בשדה יחיד המשמעות שלה שאני שומר את
1:04:00הנתונים בתוך שדה אחד או מחלק אותו. למשל
1:04:04במערכות מיושנות היו שומעים את הכתובת
1:04:06כשדה אחד.
1:04:09רחוב, מספר בית ועיר. ואנחנו רוצים לפרק
1:04:13את זה בצורה חכמה, אפילו להעזר באינדקס של
1:04:17שמות רחובות, שמות ערים א וכמובן לזהות את
1:04:22מספר הבית כזיהוי נומרי, כזיהוי מספרי,
1:04:26ולחלק את זה בצורה מסודרת לשדה של שם
1:04:29רחוב, שדה של מספר בית, שדה של
1:04:34א שם עיר.
1:04:37לכך אנחנו יכולים גם להעשיר את הנתונים
1:04:40בדataסנטר אחר כך סליחה בדata אחר כך
1:04:45א בכך שאנחנו נרכוש מהדואר
1:04:49את קובץ המיקוד ואז אם יש לנו שם של עיר
1:04:53שם מספר של בית ושם רחוב אז נוכל גם
1:04:57להתאים מתוך הנתונים של קובץ המיקוד גם את
1:05:01המיקודים ולרשום אותם כערך שדה נוסף
1:05:06לכל אפשרות שאני אזדקק לה.
1:05:11התהליך של טרנספורם גם נותן פתרון לערכים
1:05:17חסרים או שגויים.
1:05:19למשל בדיקה של איות. האם באמת יש שם רחוב
1:05:23כזה? מה שם הרחוב הדומה ביותר אליו שאני
1:05:28יכול לתקן?
1:05:30השלמה של נתונים ואת זה באמצעות למשל
1:05:35סופרפולציה
1:05:36יכול להתבסס על נתונים היסטוריים ולראות
1:05:39על סמך סט הערכים המסוים ועל סמך סט
1:05:42הערכים ההיסטורי מה ההסתברות
1:05:46שהנתון החסר הוא יהיה מספר כזה או אחר
1:05:50בקירוב
1:05:51ואני יכול גם להשמיט רשומה זאת אומרת
1:05:53רשומה שנתוני החסרים נתוני שדה קריטי
1:05:57חסרים בה אני בכלל לא לוקח אותה בחשבון.
1:06:00גם לזה יש משמעות של עובדן המידע שבכל זאת
1:06:04היה ברשומה.
1:06:06אני בודק את התקינות ברשומה של כל שדה
1:06:09ושדה מול סט הערכים המותר
1:06:12ומבצע המרה ושינויים כמו שתיארתי במימד של
1:06:16תאריכים, של זמנים, אולי שערי מטבע אפילו
1:06:21וכולי.
1:06:23ובסופו של דבר מתאים את זה למבנה רשומה
1:06:27שמוסכם מבחינת הדטה
1:06:30טוענים את הרשומות פנימה ומדווחים למערכת
1:06:34הl על בעיות זאת אומרת טעינה חוזרת נדרשת
1:06:39או על בדיקת כינות שהטעינה הוא שלמה כנדרש
1:06:45המימד השלישי שכלי ATL מבצאים זה הלות זה
1:06:49הטעינה עצמה
1:06:51ופה אנחנו אנחנו בטעינה משלימים שדות,
1:06:54שינויים כנדרש,
1:06:56טוענים את הרשומות פנימה, מכניסים אותן,
1:07:00מזריקים אותן לתוך הדטה וareאוס, כמו
1:07:02שנדרש,
1:07:04בודקים שהטעינה לא הייתה משובשת,
1:07:08שכל השדות נכנסו כראוי למקומות שלהם
1:07:12ואחר כך אנחנו מבצעים עליהם סכימת ערכים
1:07:16עבור הדהמרס, שזה בדיוק אותה דוגמה
1:07:19שדיברתי עליה שעכשיו תארו לעצמכם שהיינו
1:07:23טוענים מיליון רשומות של טרנזקציות של
1:07:27העברות כספיות ביום
1:07:30ומנהל הארגון הפיננסי רוצה בסך הכל לדעת
1:07:34מה סך הכל העברות שנעשו היום. זאת אומרת
1:07:39מה צריך לעשות? רק לסכם לו את סכומי
1:07:43העברות מתוך אותם מיליון רשומות ולשים את
1:07:47זה כמספר אחד, כרשומה אחת של התאריך ושל
1:07:51הסך הכל בתוך דת המרט. זאת אומרת אנחנו
1:07:55הורדנו את מימד החיפוש והעיבוד ממיליון
1:07:57רשומות לרשומה אחת. זו רק דוגמה.
1:08:01כמובן שיש דוגמאות הרבה יותר מורכבות. מי
1:08:05אחראי כעיקרון לבצע את כל התהליכים של הl,
1:08:10של ההתמאה של הכלים, של האקסטרract, של
1:08:12הטנספורם, של הלad, של האפיונים מה נדרש
1:08:16לקחת, מאיפה נדרש לקחת, איך להעמיר לאיפה
1:08:19ליתון. זו פונקציה שקרויה דהר.
1:08:24זה איש הנדסת תעשייה וניהול עם ניסיון, עם
1:08:28יכולות בתחום האורחות המידע.

About this transcript

This page contains the full transcript of Lesson 6 by EH, generated from the public captions YouTube serves with the video. The transcript has 6,687 words across 1,151 segments, with the original timestamps preserved so you can click any line to jump to that moment in the embedded player.

What you can do with it

Use the transcript to take notes, quote the speaker, build a study guide, generate a summary with ChatGPT or Claude via the YouTube Summary tool, or export it as a timed subtitle file with YouTube to SRT. You can also re-open it in the transcriber to translate the transcript into 100+ languages.

Free YouTube transcript tool

YouTube2Text is a free YouTube transcript generator — no signup, no daily limit. Paste any YouTube link and get the full transcript instantly, with timestamps, click-to-jump, translation to 100+ languages, AI prompts for ChatGPT, Claude, and Gemini, and exports to TXT, SRT, VTT, or Markdown.