כך תשתמשו ב-AWS Redshift בצורה יעילה, ועל הדרך תחסכו גם כסף

שימוש נכון בשירות ה-Data warehouse של אמזון יכול להוזיל את התשלום בסוף החודש ולשפר את הביצועים שלכם

מקור: Pixabay

מאת: תמר פישר ואילון מועלם

RedShift הוא שירות Data warehouse מבית היוצר של AWS) Amazon) שנמצא בשימוש נרחב בקרב משתמשי aws. מבחינה טכנית, RedShift הוא אשכול (cluster) הבנוי משרתים (nodes) רבים, כאשר כל שרת מורכב מכח עיבוד (compute) ומשטח אחסון (storage). 

Redshift מאפשר לתשאל פטה-בייטים של דאטה במהירות גבוהה ובמחיר נמוך, אך כמו כל דבר, עם היתרונות מגיעים גם חסרונות. מכיוון ש-Redshift הוא cluster, כח העיבוד והזיכרון שלו משולבים ולא ניתנים להפרדה, שכן הם נקבעים עפ״י כמות ה-nodes, וכך גם המחיר. כאשר נרצה להגדיל ולשפר את הביצועים, הפתרון הטבעי יהיה להגדיל את מספר ה-nodes, כלומר scale out.

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

ייעול וצמצום נפח האגירה

Encoding

ניתן לכווץ את גודל הטבלאות בצורה ניכרת, כל שצריך לעשות זה שימוש נכון בקידוד. ברירת המחדל של העמודות בכל טבלה שנוצרת היא raw data, כלומר המידע נשמר בצורתו המלאה בטבלה ובזיכרון. בפעולה פשוטה ניתן להוסיף קידוד עבור העמודות, אשר מכווץ את גודל הטבלה בצורה משמעותית.  לדוגמא, ניתן להוסיף את ה-encoding במעמד יצירת הטבלה בלבד.

בנוסף, מצאנו שניתן לבצע encoding לכל העמודות בטבלה, כולל ה-sorting keys, מבלי שזה יגרע משמעותית בביצועים, מה שחסך לנו כמה מאות גיגה-בייטים ב-storage.




CREATE TABLE IF NOT EXISTS public.test

(

clienttag VARCHAR(15) ENCODE zstd

, domain VARCHAR(40) ENCODE zstd

, sessionid VARCHAR(40) ENCODE zstd

)

DISTSTYLE KEY

DISTKEY (sessionid)       

SORTKEY (

clienttag

,"domain"

);

Elastic resize

התשלום עבור Redshift מחושב לפי שעה ועפ״י מספר ה-nodes שהוגדרו באותו פרק זמן.
אנחנו למשל התמודדנו עם הבעיה שהחזקנו cluster עצום בגודלו 24/7, רק בגלל צורכי compute גבוהים, במשך מספר שעות ביום. הפתרון לכך היה שימוש בפונקציה של AWS המאפשרת שינוי גודל (מספר ה-nodes) במהירות – elastic resize. בניגוד ל-resize רגיל, ה-elastic resize מאפשר לשנות את מספר ה-nodes במספר דקות בודדות וללא downtime משמעותי, דבר שאינו מתאפשר כאשר מבצעים resize רגיל. וכך במקום להחזיק cluster גדול במשך כל שעות היממה, אנו מעלים את מספר ה-nodes לפני פעולות המצריכות compute גבוה (לדוגמא ה-ETL היומי), ומורידים מיד לאחר מכן. בפועל אנו משלמים על מספר שעות בודדות ביום של צריכה גבוהה, וביתר הזמן משלמים עבור הצריכה הממוצעת שמספיקה לפעילות השוטפת.

חשוב לדעת, כאשר מבצעים elastic resize, ניתן לשנות את גודל הcluster רק בכפולות של 2 (כלומר לצמצם בחצי, או להכפיל), אם רוצים יותר דינאמיות בבחירת הגודל יש לבצע resize רגיל.

קיצור זמני אגירה

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

  1. טבלאות אגרגטיביותבעוד המידע הגולמי הוא רחב ומקיף, הוא גם תופס נפח מאוד גודל, וגם קשה לתשאל עליו מפני שהוא מכיל כל כך הרבה רבדים. בNamogoo מצאנו פתרון לדבר זה, ובמקום לשמור את הדאטה הגולמי, אנו שומרים טבלאות של דאטה אגרגרטיבי. הטבלאות האגרגטיביות הן קטנות יותר, מסודרות יותר ומכילות מידע מסוכם ופשוט. את הטבלאות הללו ניתן לשמור לפרקי זמן ארוכים הרבה יותר, שיאפשרו לערוך עליהן אנליזות שונות. וע״י כך לשחרר משאבים באגירת כל המידע הגולמי, ואותו לשמור רק לפרקי זמן קצרים יותר. כך הרווחנו פעמים, גם חסכנו storage, וגם שיפרנו ביצועים ע״י תשאול טבלאות שהן כבר מסוכמות.
  2. Redshift spectrum: שירות ה-Redshift Spectrum מאפשר גמישות רבה, באמצעותו אפשר לשמור מידע בקבצים בS3 ולתשאל את redshift ישירות אותו. כך אנחנו נהנים משני העולמות, מצד אחד דאטה שאנו שומרים לתקופה מצומצמת אך מתשאלים בתדירות גבוהה לצורכי אגרגציות ואנליזה, והוא נמצא ישרות על redshift. ומצד שני דאטה אשר זמין לצורכי מחקר, אך לא נמצא בשימוש יומיומי, ואנו שומרים בקבצים בs3 (שם הstorage זול משמעותית). באמצעות תכנון נכון, ושמירה של הדאטה העדכני בלבד על redshift ומערכת העברת קבצים הצלחנו לשמור על יציבות בstorage, מבלי לאבד יכולות מחקר.

שיפור ביצועים

  1. Sort key – זוהי בעצם הדרך בה Redshift קובע את הסדר שבו המידע ישמר עבור כל טבלה. באמצעות שימוש נכון נוכל להגיע למידע הרצוי במהירות, ובפועל, הדאטה בייס יצטרך לסרוק הרבה פחות מידע בהרצת השאילתה. ניתן לבחור מספר sort keys, ולהחליט על סדר חשיבותם. כל אחד מכיר את אופן התשאול שלו בצורה הטובה ביותר, ולכן בחירת ה-sort key תעשה באופן אינדיבידואלי לכל טבלה בהתאם. Sort key נכון יעזור לפעולות where, group by ו-order by, וכדאי לבחור אותו על העמודות עליהן עושים פעולות אלו.
  2. Distribution key – ה-Distribution key מחליט היכן נשמר הדאטה. כדי לנצל את כל יכולות הDB, נרצה להשתמש בכל שטח האיחסון שלו, ובכל ה-compute. בשביל זה נרצה לשמור את המידע באופן דיי זהה בין ה-nodes שלנו, ושלא יקרה מצב שיש node אחד עמוס במיוחד, ואחרים ריקים. הגדרת distribution key מגדירה היכן לשמור וכיצד לשמור את הדאטה בין העמודות. צורה אחת, EVEN, אומרת לשמור באופן זהה בין כל הnodes. צורת הKEY אומרת שעבור העמודה שנבחרה, כל הערכים הזהים בה יישמרו באותו ה-node. דבר זה טוב בעיקר למטרות join, קח הם נעשות ברמת הnode עצמו, ונחסך זמן ריצה.

בונוס:

  1. Reserved instances – תארו לכם שאתם גרים במרכז תל אביב ויש חניון בעלות 50 שקלים ללילה או מנוי חודשי של 400 שקלים. האם הייתם משלמים כל לילה 50 שקלים? אז Reserved instances זו בדיוק האופציה של ה-400 שקלים. Amazon מאפשרת לנו לשלם מראש על השרתים שמהם מורכב ה-cluster, לשנה או שלוש שנים, בכדי לזכות בהנחה משמעותית. 
  2. לאחרונה אמזון השיקה node מסוג חדש, RA3. סוג חדש זה מאפשר לפצל בין compute ל-storage. והוא מומלץ בעיקר עבור מי שמחזיק באופן מקביל יותר מ-10TB של דאטה.

הכותבים הם מפתחי Data Infrastructure בחברת Namogoo

Avatar

כתב אורח

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

הגב

3 תגובות על "כך תשתמשו ב-AWS Redshift בצורה יעילה, ועל הדרך תחסכו גם כסף"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

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

סידור לפי:   חדש | ישן | הכי מדורגים
מושון
Guest

האם זה עדיף על bigquery של גוגל?

דולב
Guest

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

משה
Guest
האם עדיף להגיד לאילת בטיסה מברכב פרטי? הכל תלוי בצרכים שלך – כמה אנשים, כמה פעמים בשנה, כמה זמן אתה מוכן שזה ייקח וכו’. redshift מחייב אותך להחזיק קלאסטר שהוא בד”כ כל הזמן למעלה ולשלם עליו, פעולות של הגדלה והקטנה לוקחות זמן ומשפיעות על זמינות המערכת. בגלל שיש sort key אחד יש מקרים בהם תמצא את עצמך משכפל את אותו מידע מספר פעמים בכדי להגיע לביצועים הנדרשים. בbig query אתה מגיע לביצועים טובים מאוד עד לגדלים של TB מבלי צורך לדאוג ל sort key, dist key וגודל קלאסטר כמובן. כמות המידע שלך בBQ יכולה לגדול ולגדול ולא תרגיש הבדל בביצועים.… Read more »
wpDiscuz

תגיות לכתבה: