איך ארגנו DataLake יעיל וזול במיוחד ומדוע זה כך

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

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

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

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

ניתוח טכני בסיסי ב-Bitrix24

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

אצבע על הדופק - ניתוח טכני מתקדם

הרצון לקבל מידע על בעיות "כמה שיותר מהר" הוביל אותנו לניסויים פעילים בכלים פשוטים ומובנים - pinba ו-xhprof.

פינבה שלחה לנו נתונים סטטיסטיים בחבילות UDP על מהירות הפעולה של חלקים מדפי אינטרנט ב-PHP, ויכולנו לראות באינטרנט באחסון MySQL (פינבה מגיעה עם מנוע MySQL משלה לניתוח אירועים מהיר) רשימה קצרה של בעיות ולהגיב ל אוֹתָם. ו-xhprof אפשרה לנו אוטומטית לאסוף גרפים של ביצוע דפי PHP הכי איטיים מלקוחות ולנתח מה יכול להוביל לכך - ברוגע, למזוג תה או משהו חזק יותר.

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

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

• כמה שגיאות PHP היו ללקוח Bitrix24 בפורטל p1 בשעה האחרונה ואיזה? להבין, לסלוח ולתקן במהירות.
• כמה שיחות וידאו בוצעו בפורטלים בגרמניה ב-24 השעות הקודמות, באיזו איכות והיו קשיים בערוץ/רשת?
• עד כמה פועלת פונקציונליות המערכת (תוסף C שלנו עבור PHP), שהורכבה מהמקור בעדכון השירות האחרון והושקה ללקוחות? האם יש תקלות?
• האם נתוני לקוחות מתאימים לזיכרון PHP? האם יש שגיאות לגבי חריגה מהזיכרון שהוקצה לתהליכים: "חסר זיכרון"? למצוא ולנטרל.

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

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

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

ניתוח עסקי בסיסי

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

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

במשך די הרבה זמן הפתרון הגמיש הזה עזר מאוד, אבל לאט לאט התחילה להגיע ההבנה ש-ClickHouse הוא לא גומי ואי אפשר ללעוג ככה.

כאן חשוב להבין היטב ש-ClickHouse, כמו Druid, כמו Vertica, כמו Amazon RedShift (המבוססת על postgres), הם מנועים אנליטיים המותאמים לניתוח נוח למדי (סכומים, צבירה, מינימום-מקסימום לפי עמודות וכמה הצטרפות אפשריות ), כי מאורגן לאחסון יעיל של עמודות של טבלאות יחסים, בניגוד ל-MySQL ומסדי נתונים אחרים (מוכווני שורות) המוכרים לנו.

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

ביקוש לפיתון ואנליסטים

לחברה שלנו יש מפתחים רבים שכותבים קוד כמעט כל יום במשך 10-20 שנה ב-PHP, JavaScript, C#, C/C++, Java, Go, Rust, Python, Bash. ישנם גם מנהלי מערכת מנוסים רבים שחוו יותר מאסון אחד מדהים לחלוטין שאינו מתאים לחוקי הסטטיסטיקה (לדוגמה, כאשר רוב הדיסקים ב-raid-10 נהרסים על ידי מכת ברק חזקה). בנסיבות כאלה, במשך זמן רב לא היה ברור מה זה "אנליטיקאי פיתון". Python הוא כמו PHP, רק השם קצת יותר ארוך ויש קצת פחות עקבות של חומרים משנים תודעה בקוד המקור של המתורגמן. עם זאת, ככל שנוצרו יותר ויותר דוחות אנליטיים, מפתחים מנוסים החלו להבין יותר ויותר את החשיבות של התמחות צרה בכלים כמו numpy, pandas, matplotlib, seaborn.
את התפקיד המכריע, ככל הנראה, מילאה התעלפות פתאומית של עובדים משילוב המילים "רגרסיה לוגיסטית" והפגנת דיווח יעיל על נתונים גדולים באמצעות, כן, כן, pyspark.

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

ניסיונות נוספים של Apache Spark/Hadoop להמריא ומה לא ממש הלך לפי התסריט

עם זאת, מהר מאוד התברר שמשהו מערכתית לא ממש תקין עם Spark, או שפשוט היה צורך לשטוף את הידיים טוב יותר. אם ערימת Hadoop/MapReduce/Lucene נוצרה על ידי מתכנתים מנוסים למדי, וזה ברור אם מסתכלים מקרוב על קוד המקור ב-Java או ברעיונות של Doug Cutting ב- Lucene, אז Spark, פתאום, נכתב בשפה האקזוטית Scala, שהיא מאוד שנוי במחלוקת מנקודת מבט של פרקטיות וכרגע אינו מתפתח. והירידה הקבועה בחישובים באשכול Spark עקב עבודה לא הגיונית ולא מאוד שקופה עם הקצאת זיכרון לצמצום פעולות (מפתחות רבים מגיעים בבת אחת) יצרה סביבו הילה של משהו שיש לו מקום לגדול. בנוסף, המצב הוחמר על ידי מספר רב של יציאות פתוחות מוזרות, קבצים זמניים שגדלו במקומות הכי לא מובנים ותלות בגיהנום של צנצנת - מה שגרם למנהלי מערכת לתחושה אחת שהייתה מוכרת היטב מילדות: שנאה עזה (או אולי הם היו צריכים לשטוף ידיים עם סבון).

כתוצאה מכך, "שרדנו" מספר פרויקטים אנליטיים פנימיים המשתמשים באופן פעיל ב- Apache Spark (כולל Spark Streaming, Spark SQL) ובמערכת האקולוגית של Hadoop (וכן הלאה וכן הלאה). למרות העובדה שעם הזמן למדנו להתכונן ולנטר את "זה" די טוב, ו"זה" כמעט הפסיק לקרוס פתאום בגלל שינויים באופי הנתונים וחוסר האיזון של גיבוב RDD אחיד, הרצון לקחת משהו כבר מוכן , עודכן ומנוהל איפשהו בענן התחזק יותר ויותר. בתקופה זו ניסינו להשתמש במכלול הענן המוכן של שירותי האינטרנט של אמזון - EMR ולאחר מכן ניסו לפתור בעיות באמצעותו. EMR הוא Apache Spark שהוכן על ידי אמזון עם תוכנה נוספת מהמערכת האקולוגית, בדומה לבניית Cloudera/Hortonworks.

אחסון קבצי גומי לניתוח הוא צורך דחוף

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

רציתי גם שעדכון התוכנה של הפלטפורמה הזו לא יהפוך לסיוט של השנה החדשה עם קריאת עקבות Java של 20 עמודים וניתוח יומנים מפורטים באורך קילומטרים של האשכול באמצעות Spark History Server וזכוכית מגדלת עם תאורה אחורית. רציתי שיהיה לי כלי פשוט ושקוף שלא מצריך צלילה קבועה מתחת למכסה המנוע אם בקשת ה- MapReduce הסטנדרטית של המפתח תפסיק לפעול כאשר עובד ה-reduce data נפל מהזיכרון בגלל אלגוריתם חלוקת נתוני מקור שלא נבחר היטב.

האם אמזון S3 מועמדת ל-DataLake?

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

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

מה אם תאחסנו קבצים באחסון הענן הניתן להרחבה המוכר והידוע Amazon S3, מבלי שתצטרכו להכין צלעות משלכם מ-Hadoop?

ברור שהנתונים האישיים "נמוכים", אבל מה לגבי נתונים אחרים אם אנחנו מוציאים אותם לשם ו"מניעים אותם ביעילות"?

מערכת אקולוגית של Cluster-bigdata-analytics של Amazon Web Services - במילים פשוטות מאוד

אם לשפוט על פי הניסיון שלנו עם AWS, Apache Hadoop/MapReduce נמצא בשימוש פעיל שם כבר זמן רב תחת רטבים שונים, למשל בשירות DataPipeline (אני מקנא בעמיתיי, הם למדו להכין אותו נכון). כאן הגדרנו גיבויים משירותים שונים מטבלאות DynamoDB:


והם פועלים באופן קבוע על אשכולות Hadoop/MapReduce משובצים כמו שעון כבר כמה שנים. "קבע את זה ושכח מזה":

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

וכן, אתה יכול להרים מחשב נייד לעצמך או לאנליסט בענן ולצרף אותו לאשכול Hadoop/Spark, לעשות את החישובים ואז למסמר הכל:

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

דבק AWS - ארוז בקפידה אפאצ'י ספארק על סטרואידים

התברר של-AWS יש גרסה משלה של ערימת "כוורת/חזיר/ניצוץ". תפקידה של כוורת, כלומר. קטלוג הקבצים וסוגיהם ב-DataLake מבוצע על ידי שירות "קטלוג נתונים", שאינו מסתיר את תאימותו לפורמט Apache Hive. עליך להוסיף מידע לשירות זה לגבי היכן ממוקמים הקבצים שלך ובאיזה פורמט הם נמצאים. הנתונים יכולים להיות לא רק ב-s3, אלא גם במסד הנתונים, אבל זה לא הנושא של הפוסט הזה. כך מאורגנת ספריית הנתונים של DataLake שלנו:

הקבצים רשומים, מעולה. אם הקבצים עודכנו, אנו משיקים סורקים באופן ידני או על פי לוח זמנים, שיעדכנו מידע עליהם מהאגם וישמרו אותם. לאחר מכן ניתן לעבד את הנתונים מהאגם ולהעלות את התוצאות למקום כלשהו. במקרה הפשוט ביותר, אנו מעלים גם ל-s3. עיבוד נתונים יכול להיעשות בכל מקום, אך מומלץ להגדיר את העיבוד באשכול Apache Spark באמצעות יכולות מתקדמות דרך AWS Glue API. למעשה, אתה יכול לקחת את קוד הפיתון הישן והטוב והמוכר באמצעות ספריית pyspark ולהגדיר את הביצוע שלו על N צמתים של אשכול בעל קיבולת כלשהי עם ניטור, מבלי לחפור במעיים של Hadoop ולגרור קונטיינרים של docker-smoker ולבטל התנגשויות תלות .

שוב, רעיון פשוט. אין צורך להגדיר את Apache Spark, אתה רק צריך לכתוב קוד python עבור pyspark, לבדוק אותו באופן מקומי על שולחן העבודה שלך ואז להפעיל אותו על אשכול גדול בענן, תוך ציון היכן נמצאים נתוני המקור והיכן לשים את התוצאה. לפעמים זה הכרחי ושימושי, והנה איך מגדירים את זה:

לפיכך, אם אתה צריך לחשב משהו על אשכול Spark באמצעות נתונים ב-s3, אנו כותבים קוד ב-python/pyspark, בודקים אותו, ובהצלחה לענן.

מה עם התזמור? מה אם המשימה תיפול ותיעלם? כן, מוצע לעשות צינור יפה בסגנון Apache Pig ואפילו ניסינו אותם, אבל בינתיים החלטנו להשתמש בתזמור המותאם אישית שלנו ב-PHP ו-JavaScript (אני מבין, יש דיסוננס קוגניטיבי, אבל זה עובד, עבור שנים וללא שגיאות).

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

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

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

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

AWS Athena - הג'ק-in-the-box

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

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

גם התמחור לבקשות לאתנה מעניין. אנחנו משלמים עבור נפח הנתונים הסרוקים. הָהֵן. לא עבור מספר המכונות באשכול לדקה, אלא... עבור הנתונים שנסרקו בפועל על 100-500 מכונות, רק הנתונים הדרושים להשלמת הבקשה.

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

אגב, כך אנו מחלקים את הנתונים שלנו ב-s3:

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

אבל הלכנו רחוק יותר והתחלנו ללכת לענן כדי לקבל תשובות דרך מנהל התקן ODBC: אנליסט כותב שאילתת SQL בקונסולה מוכרת, שב-100-500 מכונות "בגרושים" שולחת נתונים ל-s3 ומחזירה תשובה בדרך כלל תוך מספר שניות. נוֹחַ. ומהר. אני עדיין לא מאמין.

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

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

ממצאים

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

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

בתחילת הדרך ראשי התפצל מגני החיות הפראיים הרבים של תוכנות פתוחות וסגורות ומהבנת נטל האחריות על הצאצאים. פשוט התחל לבנות את ה-DataLake שלך ​​מכלים פשוטים: nagios/munin -> elastic/kibana -> Hadoop/Spark/s3..., איסוף משוב והבנה עמוקה של הפיזיקה של התהליכים המתרחשים. כל דבר מורכב ועכור - תנו אותו לאויבים ולמתחרים.

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

מקור: www.habr.com