Redshift : בסיס נתונים גמיש עבור ביצוע בינה עסקית על כמויות עצומות של מידע – האם זה בשבילכם?
חברת Inflow עושה שימוש בבסיס נתונים Redshift כחלק מפתרון בינה עסקית כאשר כמויות הנתונים גדולה מאוד ביג דאטה (big data ). כמו כן אנו שותפים עסקיים של מס' חברות אשר מבצעות אופטימיזציה ותחזוקה – DBA Redshift.
במאמר זה נסביר את המונחים ומהם היתרונות והחסרונות של הכלי.
https://www.youtube.com/watch?v=AUvn49gey8Y
Redshift הינו מוצר של חברת הענק amazon וככזה הוא מתקיים בענן. (cloud) . הינו בסיס נתונים columnar .
ההבדל בין columnar לבין רלציוני הינו פשוט אך יעיל.
בטבלה של בסיס נתונים רלציוני ישנם עמודות ושורות כאשר כל שורה מייצגת אוביקט שלם.
לדוגמא : לקוח הינו רשומה אחת. אם נרצה לתשאל את הטבלה כמה לקוחות ישנם ניאלץ לעבור על כל רשומות הטבלה על מנת לתת תשובה. לעומת זאת בבסיס נתונים columnar כל רשומה מהווה עמודה אחת שלמה לדוגמא: מספרי הלקוח יהיו כולם ברשומה אחת . בשיטה זו אם יש לנו טבלה עם 10 עמודות (רלציוני) נצטרך לעבור רק על עשירית מהרשומות על מנת להגיע לאותה התוצאה.זהו שיפור משמעותי.
אז מה היתרונות של redshift :
המחיר של amazon redshift:
אמזון מאפשרים לאחסן מידע של 1 טרה בפחות מ 1000$ לשנה. כמובן שמדובר בגימיק, כיוון שבפועל אנו זקוקים לשרתים חזקים יותר , ומשאבים עולים יותר כסף, אך עדיין המערכת זולה משעותית מהמתחרות .התמחור הוא על בסיס שרתים לזמן באוויר כאשר לכל סוג שרת , תלוי במעבדים וזיכרון יש מחיר שונה. ניתן גם לרכוש חבילה מראש אשר מקטינה את התשלום באחוזים ניכרים. לינק למחירון של רדשיפט
הענן :
השרתים נמצאים בענן , האחריות לתחזוקה של השרתים , תפקודם והגיבוי הוא באחריות redshift. מעבר לכך כל מידע שנמצא בשרת משולם , נמצא גם בשרת נוסף mirror שאינך משלם עליו.חשבו על עלות ה DBA שנחסך , עלות איש ה IT שאחראי על storage , networking וכו'.
קלות ה scale out
הוספת משאבים היא עניין של מספר קליקים בפאנל הניהול. בניגוד לרכישת חומרה פיסית ואחסונה בחדר שרתים מתאים.
In memory :
Reshift עושה שימוש בזיכרון כך שבנוסף להיותו columnar הוא גם in memory
Parallel :
Redshift משתמש בכל משאבי המערכת במקביל, לדוגמא בטעינת נתונים כל node מבצע חלק מתהליך הטעינה.
אבטחה :
ניתן להגדיר את ה cluster – redshift להצפין את המידע, כולל את הגיבויים.
חסרונות של redshift
הענן :
נתונים ממערכת ארגונית / פנימית נדרשים לטעינה לשרתים מרוחקים (של redshift ) לשם כך יש צורך להוציא אותם למבנה קבצים , לקבוע כמות רשומות בכל קובץ על בסיס כמות ה nodes שיש לנו (לטעינה אופטימלית) , לכווץ את התוצאה . הטעינה היעילה ביותר היא בעזרת פקודת copy על קבצים הנמצאים ב S3. כל התהליך הזה לוקח זמן ודורש מומחיות מסוימת. ניתן לטעון מידע ישירות בעזרת פקודות SQL אך המהירות איטית משמעותית.
Redshift אינו ACID :
טוב, קצת נכנסים לנושאים טכניים, אבל בגדול זה אומר שרשומות עליהן מבוצעות מניפולציות . הכנסה / שינוי / מחיקה אינם חלק מטרנזקציה ולכן במקרה של נפילה או תקלה אין חזרה לאחור למצב התקין של הרשומה לינק להסבר מפורט יותר , למרות שזה נשמע מפחיד , זה רק אומר שכאשר מבצעים שינויים בבסיס הנתונים יש צורך לוודא לאחר השינוי שהוא בוצע בהצלחה.
Upsert :
ל Redshift אין תכונה של זיהוי רשומה על בסיס מפתח ועדכון במידה וקיימת או הוספה אם אינה קיימת על כן במידה ומעוניינים לשנות רשומה בתהליך טעינה , יש צורך לבצע מחיקה של הרשומה וטעינה של החדשה במקומה . מחיקת רשומות יוצר חוסר אופטימיזציה בבסיס הנתונים ולכן יש לבצע תהליכי תחזוקה vacuum ועוד
Redshift מפתחות ואינדקסים
בסיס הנתונים אינו מתנהל עם מפתחות ואינדקסים כל שאילתא תעבור על הטבלה (column) באופן מלא. כמובן כאשר המשאבים מתאימים והפעולות מתבצעות parallel הדבר נעשה מהר מאוד.
עקב כך במידה וכמות הנתונים היא קטנה או שהצורך הוא למבצע שאילתות על סט קטן מתוך בסיס נתונים גדול האם להשתמש בו או בבסיס נתונים רלציוני כגון mysql .
קצת הסבר על מדוע Data warehouse
ראשית, מדוע אנו זקוקים לבסיס נתונים חיצוני שאינו התפעולי ?
בשנים האחרונות כל חברה מחזיקה את הנתונים שלה ב "איים של נתונים". אפילו לחברות קטנות כבר מספר מערכות מידע כגון: ERP ו CRM . בחברות מעט גדולות יותר נמצא גם מרכזיות טלפוניה , מערכות HR , אתרי אינטרנט E-commerce ועוד…
הסיבה ראשונה להעברת המידע מבסיס הנתונים המקורי שלו (לדוגמא נתוני המכירות ממערכת ה ERP ) נובעת מכך שהרצת שאילתות (כלומר הרצת דו"ח) על גבי כמות גדולה של נתונים בטבלאות התפעוליות גורמת לפגיעה בביצועים של המערכת התפעולית. כמו כן מבנה בסיס הנתונים אינו בנוי לניתוח מידע אלא לכתיבה ושליפה של כמות מוגבלת של רשומות בכל פעם על בסיס מפתחות ואינדקסים.
הסיבה השנייה היא שישנם נתונים שיש לאחד ממספר מערכות ( תהליך ETL ) ויש צורך להעביר את המידע למקום אחר: data warehouse
הסיבה השלישית: הנתונים as is אינם מספקים ויש צורך לבצע מניפולציות על הנתונים על מנת שיתאימו לדרישות העסקיות של החברה.
קיימים כלי בינה עסקית (BI ) שטוענים שבשימוש בהם אין צורך בביצוע תהליך ETL והעברה ל data warehouse . אני מסכים שניתן במידה ורמת המורכבות היא נמוכה ביותר. ברוב המקרים יהיה צורך להעביר את המידע ולסדר אותו לפני התחברות עם כלי בינה עסקית
לדוגמא: מרבית כלי הבינה העסקית שיש להם ETL פנימי מאפשרים אופציה של שמירת במידע בזיכרון in memory . אך כאשר רשומות משתנות רטרואקטיבית (הזמנה בסטאטוס הוזמן הופכת מאוחר יותר לשולם) אין להם את מנגנון ה update . לכן במקרה כזה, יש להביא את כל המידע כל פעם. חלקם מאפשרים למחוק מידע X זמן אחורה על מנת להביא מחדש רשומות. אך אם לא ידוע מתי רשומה השתנתה אזי לא ניתן.
מתי כן : כאשר בטבלאות ה fact רק נוספות רשומות, המניפולציות על הנתונים פשוטה , מקור נתונים אחד (על אף שחלקם מאפשרים יותר מאחד, זה קשה יותר לתחזוקה)
סוגים של בסיסי נתונים :
בסיס נתונים רלציוני – הכוונה בסיס נתונים "מסורתי" הבנוי על בסיס של טבלאות וקשרים בינהן.
לדוגמא: mysql, sql server, oracle, postgres . כלים אלו קיימים בשוק שנים רבות והם שולטות בשוק המערכות התפעוליות שברובם הינם ERP ו CRM
בסיס נתונים NoSql – אילו הם בסיסי נתונים שמהדור החדש. אילו נועדו לעבודה תפעולית מול כמויות עצומות של משתמשים כאשר החוזק שלהן הוא בכך שניתן לבזר את הנתונים על מספר שרתים (scale out ) וכן שהכתיבה לתוכם מהירה מאוד.
לדוגמא: mongoDB, Cassandra
נמצאים בשימוש בדרך כלל של אפליקציות WEB אשר אוספות נתונים ממספר רב של משתמשים ויש צורך בגמישות מבנה בסיס הנתונים , מהירות הכתיבה ומיקום המשתמש ביחס לשרתים.
בסיס נתונים columnar – אילו הן בסיסי נתונים שנועדו לביצוע אנליזות על נתונים ו redshift הוא מסוג זה. דוגמאות : HP vertica, vectorwise, redshift
לסיכום:
Reshift הוא בסיס נתונים עבור ביצוע אנליזות , הינו כלי מצוין כאשר מבינים למה הוא נועד ואכן המקרה שלכם קולע לכך. Inflow מבצעת פרויקטי בינה עסקית בעזרת כלים העושים שימוש ב Redshift כמקור הנתונים . כמו כן אנו מבצעים את כל פעולות האינטגרציה לטעינת הנתונים בלוגיקה הנכונה בעזרת כלי ETL וכן את הבדיקות שאכן המידע נכנס בדרך שציפינו ממנו.
