פלטפורמות מחסני הנתונים – סוף עידן ותחילתו של חדש?

מאת: מוטי פנחס, סמנכ”ל טכנולוגיות,  מלם תים.

השנים האחרונות היו סוערות בעולם ה-Data Warehouse (מחסני נתונים). כלים חדשים כמו redshift, Snowflake ו synapse הופיעו, הבהירו שגם מחסן נתונים יכול להיות ענני, וצברו פופולריות. מודל ההיבריד התפתח וכמובן שגם הכלים המוכרים כמו Teradata, Informatica, Vertica ואחרים המשיכו להתפתח. אם בעבר ההחלטה על פתרון  DWH הייתה מקבוצה קטנה של כלים ייעודיים ויקרים, היום כמות הכלים עלתה, כמו גם המודלים לפרישת השירות.

כששואלים אותי מה הכי מומלץ: On prem, Cloud or Hybrid?  אני נזכר באמר אוודללה (שהיה ה-CTO של קלאודרה) שכשהיה נשאל “מה יותר טוב, הדופ או SQL” הוא היה עונה “זה כמו לשאול מה יותר טוב משאית או למבורגיני” והתשובה? תלוי לאיזה שימוש. השאלה הראשונה צריכה להיות מה הפתרונות הזמינים לי, למשל אם יש רגולציה המונעת ממני לעבור לענן, מן הסתם ניתן לבחור רק פתרונות און פרם, אם רגולציות פרטיות כמו GDPR רלוונטיות יתכן שאצטרך לבחור פתרון ענן בגיאוגרפיה מסוימת. אם אין מגבלות קשיחות כאלו, יש לשקול את החסרונות והיתרונות של כל אחד מהפתרונות.

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

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

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

חישוב עליות

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

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

רישיונות לכל מערכות ההפעלה והכלים המעורבים בתהליך, בדרך כלל כלי און פרם ידרשו גם רישיון וגם Setup fee, לפעמים שירותי ענן ידרשו Setup fee. אמנם עלויות אלו בדרך כלל אינן עצומות אך יש להתחשב בהם כדי להימנע מהפתעות.

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

אז מה לבחור?

פתרונות כמו Teradata, IBM Netezza ו- Informatica יודעים היום לעבוד במודלי היבריד וחלקם אפילו תומכים במודל ענן מלא, לעומתם יש מוצרי ענן ‘טהורים’ כמו Snowflake, Redshift ו Synapse

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

היתרונות של DWH בענן:

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

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

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

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

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

התמחור של מכונות וירטואליות סטנדרטיות בענן זול בהרבה משל מפלצות עם עשרות ליבות וג’יגות רבות של זיכרון. עקרון העיבוד של Spark ה RDD, מאפשר גמישות עצומה out of the box במיוחד בהשוואה לאקרובטיקה שצריך לעשות לפתרונות SQL סטנדרטיים  כדי לדאוג שהביזור לא יפגע בביצועים. מעבר לכך בSpark קיימת תמיכה בSQL  וב HiveQL, ריבוי קונקטורים ועוד, מה שמקטין הן את עלות האינטגרציה והן את עקומת הלמידה לחברות בעלות פתרון מסורתי הרוצות לעבור לענן.

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

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

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

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

אז למה בכל זאת לבחור ב DWH מקומי (און פרם)?

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

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

סיכום

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