מה הביג-דיל ב-Big Data?

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

cc-by torkildr. flickr

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

פעם (לפני כעשור), מערכות ה High Scale היו בעיקר מערכות ה Enterprise המיועדות לארגונים גדולים. לחברת Siemens יש 120,000 משתמשים (users)? וואהו – אתגר ארכיטקטוני מרשים. מערכת המסחר של וול סטריט מבצעת מאות פעולות (transactions) בשנייה אחת? – בלתי נתפס!

חברות ענק כמו SAP, Oracle ו IBM הן אלו שבד”כ התמודדו עם אותם scales , בעיקר בזכות העובדה שאותם לקוחות-ענק קנו מערכות מורכבות שיצרנים אלו סיפקו. יצרן קטן – scale קטן, יצרן גדול – scale גדול.

מאז שנת 2000 האינרטנט פרץ למיינסטרים. מוצרים כמו MySpace ו-SecondLife ואחר-כך Facebook ו-Youtube עקפו בסיבוב את חברות הענק וטיפלו במיליוני משתמשים, petabytes של שטחי איכסון ואלפי (tps (transactions per second. בהדרגה, יותר ויותר חברות קטנות נאלצו להתמודד עם scales אדירים. הכלים להתמודד עם כמויות גדולות של נתונים (כמו פתרונות של Teradata וOracle) גם היו יקרים מדי עבור אותן חברות קטנות, וגם לעיתים לא עמדו בקיבולת המבוקשת – וכך אותם אירגונים החלו לייצר חלופות זולות ויעילות יותר להתמודדות עם scale ענק.

לא סתם Facebook, Amazon או Twitter שרדו מבין חברות דומות (שלעולם לא שמענו או נשמע עליהן). מלבד הרעיון המגניב, היה צריך להתמודד עם אתגרים טכנולוגיים יוצאי-דופן. רעיון מגניב + ניהול נכון + מצוינות טכנולוגית הוא שילוב נדיר אשר היה דרוש להצלחה.

בסולם ה Scale הוגדר ערך חדש הגבוה מהערך הגבוה הקודם (“High Scale”). מעתה, אמרו “Internet Scale”.

הבעיות

הערה: כמו שצויין למעלה, ב-Big Data יש עניין מוצהר – טיפול בכמויות אדירות של נתונים, ועניין לא מוצהר, אך לא פחות חשוב – פתרון זול המתאים גם לחברות קטנות. עדיף Open Source, עדיף מאוד Commodity Hardware (שרתים במחיר של, נאמר, עד 10K$ כל אחד).

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

הגדילה בכמות הבקשות באתר Netflix. מקור: אתר החברה.

כאשר יש לכם כמויות גדולות של נתונים, אתם צריכים:

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

למרות ש-MySql (או כל בסיס נתונים רלציוני) הוא מוצלח, ישנו גבול של נתונים שהוא יכול לטפל בו. הגדילה הראשונה היא כנראה לקנות שרת יותר חזק (vertical scalability הקרוי גם scale-up). השרת יטפל בפי “n” כמויות מידע ויעלה לרוב משמעותית יותר מפי-n.
השלב הבא, ברוב בסיסי הנתונים, הוא ליצור cluster של בסיסי נתונים (horizontal scalability הקרוי גם scale-out), בחוות שרתים שלכם או ב-Cloud.

כיצד מטפלים בכפילות מידע?

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

הדרך השנייה היא Partitioning של המידע, שהוא בעצם מצב שבו אתם מאחסנים על כל בסיס נתונים (או cluster כמתואר למעלה) פלח מידע שונה, לדוגמא: פילוח ע”פ מדינות, אות ראשונה בשם המשתמש וכו”

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

חשוב לציין כי בשיטת ה-Partitioning יש שתי בעיות עקרוניות:

  1. אם מפצלים נתונים לשרתים שונים, יש להתפשר או על זמינות (availability) או על עקביות הנתונים (consistency) – עקרון הידוע כ CAP Theorism (כלומר – אין יותר ACID).
  2. שאילתות הכוללות יותר מבסיס נתונים אחד הן מורכבות למימוש ואיטיות ביותר (במיוחד אם דורשות נעילות). למרות שלספקי בסיסי הנתונים היו שנים רבות ללא תחרות קשה בתחום – הם לא פיתחו את התחום בצורה משמעותית.

Big Data

אותן חברות סטארט-אפ שלא יכלו לשלם על פתורונות יקרים ונזקקו לכלים לטפל בכמויות אדירות של נתונים פיתחו כמה מהפלטפורמות הבאות שרובן הגדול זמין כיום כ-Open Source (מסודר ע”פ תחום):

  • CPU – לרוב אין צורך בפתרון מיוחד. מקימים Cluster עם שרתים זהים ובעזרת Load Balancer מחלקים לכל אחד מנה מהתעבורה. פיתרון שקיים כבר שנים.
  • אכסון פיזי: S3 של אמזון, GFS של גוגל או HDFS (שיטת ניהול הקבצים הנקראת  Hadoop Distributed File System ושייכת לפרוייקט העל Hadoop של אפאצ’י, היחידי שזמין לקהל הרחב).
  • איכסון לוגי: אלו בסיסי הנתונים המפורסמים (הסבר בהמשך) השייכים לאחת מארבע קטגוריות:
    • Document Oriented
    • Columnar DB
    • Graph Database
    • Key-Value DB
  • יכולת לבצע שאילתות מבוזרות – פתרונות כגון: Hive, Hadoop Map-Reduce, Cascading, MrJob ועוד.

מקור: neotechnology

בסיסי נתונים NoSQL

פירוש השם NoSql התחיל כ “לא צריך יותר SQL”, אולם עם הזמן התפכחו הדוברים והבינו שאין כאן Silver Bullet – לרוב המקרים בסיס נתונים רלציוני עדיין מתאים. היום ההסבר השגור לשם הוא: “Not Only SQL”.
הרעיון שעומד מאחורי NoSql הוא פשוט למדי: בסיסי הנתונים הרלציונים הם עשירים ומורכבים: הם מאפשרים שאילתות SQL מורכבות (שאילתות מקוננות, סיכומים סטטיסטים ועוד), הבטחת פעולות ACID (ראשי תיבות של  Atomic, Consistent, Isolated and Durable), אכיפה של constraints, טריגרים ו- Stored Procedures ועוד. מה היה קורה אם היינו מוותרים על רוב היכולות ומתמקדים רק במערכת היכולה לטפל ב Scale מרבי למקרה הספציפי?

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

Document Oriented DB

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

אם נלך לפי העקרון האקדמי של בסיס נתונים רלציוני ומנורמל תהיה לנו כנראה טבלת סניפים (נאמר 20) המקושרת לטבלת עסקאות (נאמר מיליון בשנה, עשר שנים = 10 מיליון), המקושרת לטבלת פריטים בעסקה (Line Item), נאמר 20 בממוצע בעסקה.

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

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

פיתרון קיים (יצא לי פעם להתנסות בו) הוא לייצר במקום טבלת הפריטים, בטבלת העסקאות עמודה מסוג “string” המכילה XML או JSON עם פרטי העסקה. זהו שיפור משמעותי ב-scale, מכיוון שיש לנו פחות rows, פחות אינדקסים לתחזק ופחות joins להריץ.

מצד שני יש יותר custom code שצריך לכתוב – עבור דברים שהיינו מקבלים קודם בשאילתא. יתרונות אחרים של גישת ה-Document Oriented DB הן שניתן לשנות את הסכמה מבלי לבצע Alter table יקר ואם ישנן עמודות דלילות ב-DB – לא נבזבז עליהן מקום מיותר (מה שנקרא Semi-structured data).

בסיסי נתונים Document Oriented נותנים פיתרון מובנה לעקרון זה שכולל לרוב API פשוט לשימוש וכלי שאילתות מבוזר נוסח Map-Reduce. דוגמאות הן MongoDB ו-CouchDB. במקום להמציא את הגלגל – קחו Open Source.

Columnar DB

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

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

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

דוגמאות בולטות מהסוג הזה הן Vertica או InfoBright. חברת SAP זכתה לתשואות כאשר באופן מפתיע הצטרפה לחגיגה עם HANA – גירסה In-Memory של בסיס נתונים columnar. כל הפתרונות המצויינים כאן כדוגמה, אינם פתרונות open source.

Graph DB

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

ישנו כלל מקל האומר שכל שני אנשים מקושרים על-ידי שרשרת של 6 הכרויות. מה נעשה? Join משושה של 100 מיליון משתמשים? קחו טיול חצי שנה לדרום אמריקה לפני שהשאילתה תסתיים (למרות שסביר להניח שה-DB יקרוס לפני שהשאילתה תסתיים).

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

Key-Value DB

האם הייתם רוצים להשתמש ב-HashTable בגודל של מיליארדי רשומות או יותר – שגם יאפשר מקבילות גבוהה? אין ספק שמדובר בפתרון נוח. Key-Value DB יספקו זאת, רק אל תבנו על (O(1 בזכרון, אלא קצת יותר. זוהי פרדיגמה פופולארית במיוחד בקרב חברות אינטרנט:

גוגל יצרה את BigTable ושחררה מסמך מפורסם החושף ארכיטקטורה מהפכנית, אמזון יצרה את Dynamo ושחררה מסמך מפורסם אחר – לא פחות מרשים. פרוייקט Hadoop מימש את התכנון של גוגל ויצר את HBase ו-LinkedIn מימשו את התכנון של אמזון ויצרו את Voldemort (כן, אותו אחד מהארי פוטר). פייסבוק ערבבה רעיונות של גוגל ואמזון ויצרה את Cassandra שזוכה כיום להצלחה רבה ויש גם את Redis שהוא In-Memory Database המבוסס על אותה פרדיגמה.

סיכום

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

הפוסט פורסם במקור בבלוג Software Archiblog

ליאור בר-און

ליאור בר-און הוא Chief Architect בחברת סטארטאפ ישראלית גדולה.

הגב

10 תגובות על "מה הביג-דיל ב-Big Data?"

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

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

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

תודה. כתבה חשובה
תחום שאין עליו הרבה מידע בעברית.

ישר כוח

רועי
Guest

אהבתי את הכתבה! מאוד רלוונטי לסטארטאפים

Raviv
Guest

סוף סוף יש בארץ תכנים ברמה

יקיר
Guest

ב Document DBs איך פספסת את RavenDB שפותח על ידי חברה ישראלית (ואחד המפתחים הטובים בארץ, איינדה), הפרויקט הוא OS בתנאים מגבילים אך נהדרת לעבודה עם .NET.

ripper234
Guest

Intro נחמד לעולם הזה … מה שהייתי שם בפתיחה למאמר כזה שאסור להתאהב בטכנולוגיות וב-“Big data”.

פגשתי יותר מדי אנשים שהחלום הרטוב שלהם זה Big Data / NoSql / Technology Buzzwords, אבל שוכחים בדרך את האג’יליות ואת העבודה שבסטארט-אפ עובדים בשביל ליצור value אמיתי, כמה שיותר מהר, ולא מערכת מטורפת שתחזיק 100 מיליון יוזרים 5 שנים קדימה אבל תיקח שנתיים לפתח.

ישי סמיט
Guest

למען הסר ספק, Redis ו Cassandra מאוד שונים בפונקציונליות וארכיטקטורה. לעוד מידע הרשמו למפגש: http://www.meetup.com/ILTechTalks/events/39982902

חברות שצריכות להתמודד עם גרפים גדולים במיוחד (סופק ענקיים) יוצרות מבני נתונים מבוזרים בזיכרון הניזונים מבסיס נתונים “סטנדרטי”. למשל גרף הקשרים של LinkedIn שכל קריאה לדף מצריכה Joining מטורפים עליו בזמן אמת, או גרף הסרטים-ז’נרים-שחקנים-מפיקים… של Netflix. שאילתות זמן אמת יקראו רק מהשרתים הייעודיים.

מושון
Guest

יש פתרונות ל BIG DATA כמו DMExpress שמטפלים בצווארי הבקבוק בצורה ראויה,
ראו סרטון שממחיש את הקונספט המכונה ETL 2.0
http://www.youtube.com/watch?v=uG2J4XWTtts
או אם תרצה, אותו סרט בגרסה בעברית

Nessy
Guest

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

בנצי
Guest

כתבה מעולה, תודה!

wpDiscuz

תגיות לכתבה: