7 הפרויקטים הנפוצים ביותר של Hadoop ו- Spark

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

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

פרויקט מס '1: איחוד נתונים

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

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

פרויקט מס '2: ניתוח מיוחד

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

בעולמות Hadoop ו- Spark, מערכות אלו נראות בערך כמו מערכות איחוד נתונים, אך לרוב יש יותר HBase, קוד שאינו SQL מותאם אישית ופחות מקורות נתונים (אם לא רק אחד). יותר ויותר, הם מבוססי ניצוצות.

פרויקט מס '3: Hadoop כשירות

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

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

פרויקט מס '4: ניתוח סטרימינג

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

במקרים מסוימים מדובר בסוג חדש של מערכת עסקאות המנתחת נתונים מעט טיפה תוך כדי העברתם למערכת אנליטית במקביל. מערכות כאלה מתבטאות כ- Spark או Storm עם HBase כחנות הנתונים הרגילה. שים לב כי ניתוח סטרימינג אינו מחליף את כל צורות הניתוח; אתה עדיין רוצה לגלות מגמות היסטוריות או להסתכל בנתוני העבר על משהו שמעולם לא שקלת.

פרויקט מס '5: עיבוד אירועים מורכב

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

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

פרויקט מס '6: סטרימינג בתור ETL

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

פרויקט מס '7: החלפה או הגדלה של SAS

SAS בסדר; SAS זה נחמד. SAS הוא גם יקר ואנחנו לא קונים תיבות עבור כל מדעני הנתונים והאנליסטים שלך כדי שתוכל "לשחק" עם הנתונים. חוץ מזה, רצית לעשות משהו אחר ממה ש- SAS יכול לעשות או ליצור גרף יפה יותר. הנה אגם הנתונים הנחמד שלך. הנה מחברת iPython (עכשיו) או Zeppelin (מאוחר יותר). אנו נזין את התוצאות ב- SAS ונאחסן תוצאות מ- SAS כאן.

אמנם ראיתי פרויקטים אחרים של Hadoop, Spark או Storm, אך אלה הם הסוגים "הרגילים" היומיומיים. אם אתה משתמש ב- Hadoop, אתה בטח מזהה אותם. חלק ממקרי השימוש במערכות אלה יישמתי לפני שנים, בעבודה עם טכנולוגיות אחרות.

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