נישת ה High Scale Data בתוך Backend

סימבה8881

New member
נישת ה High Scale Data בתוך Backend

הי חברים,

שמתי לב שהרבה משרות בקאנד דורשות ידע ספיציפי בכלי Big Data. אני מתכוון לכלים כמו Spark, Hadoop, היכרות עם הרבה סוגים של databases (SQL, NoSQL). נאמר במפורש במודעות הדרושים ש"דרוש ניסיון עם מערכות high scale data".

מה שאני מנסה להבין זה האם הניסיון ב high scale/big data הוא התמחות בפניי עצמה (ממש כמו front-end או devops), כך שמפתח backend שלא התנסה בדברים האלה כנראה שלא ייכנס למשרות האלה? או שמא backend זה backend והדרישות האלה שקולות לדרישה של ידע של שפת תכנות או היכרות עם פריימוורק מסוים (אלה דברים די פלואידיים)?
 

choo

Active member
יש משמעות לנסיון, אבל ברור לך שניתן ללמוד את זה

&nbsp
כשצריך להרים מערכת סקיילאבילית, ניגשים לתיכנון ולפיתוח שלה בצורה שונה לגמרי מאשר למערכת שעוסקת בכמויות ידועות מראש של נתונים ושאינן צפויות לגדול משמעותית. אדם שמעולם לא עשה את הדברים הללו לא ידע לאמר "כלים מהסוג הזה טובים למטרה א וב', אבל כלים מהסוג ההוא טובים למטרות ג ו-ד". הוא יוכל לקראו ברשת ולאמר מה אחרים אמרו - אבל קיים סיכוי סביר שהוא יטעה, או שיבחר בכלים לא אופטימליים מבחינת עלות/תועלת ביחס לדרישות של החברה "שלו" והמוצר "שלו".
&nbsp
מעבר לזה, אדם בעל נסיון יוכל לאמר "בתחום א אנחנו חייבם לבחור מראש כלי מתאים יותר גם אם הוא יעלה יותר או ייקח יותר זמן לפיתוח באמצעותו, כי החלפה שלו בעוד שנתיים תעלה ב-X חודשי עבודה. לעומת זאת בתחום ב אפשר להתחיל עם כלי פשוט יותר להטמעה (או זול יותר) כי אפשר להגדיר ממשק מאוד פשוט ולהחליף אותו ייקח רק מספר שבועות גם בעוד כמה שנים". הוא ידע לאמר לך באילו אורים בארכיטקטורה חייבים להשקיע מההתחלה בצורה מעמיקה, והיכן אפשר להסתדר עם פחות העמקה עד שיגיע הצורך לשפר אותם או עד שנלמד מספיק על השוק". הוא ידע לאמר לך גם "בחברה ההיא השקענו הרבה מאוד זמן וכסף בנושא ד, אבל בדיעבד זה היה מיותר ולא בא לידי ביטוי בגלל סיבות 1, 2 ו-3, ואם הייתי עובד על זה היום, הייתי במקום זה לוקח מוצר מדף כמו Z, ומשקיע את הזמן במקום זה בנושא ה - שכלל לא נתתם עליו את הדעת, אבל בפועל הרבה חברות נופלות בו".
&nbsp
כמובן- אפשר ללמוד הכל ולהתגלח על חשבון החברה, המשקיעים והלקוחות - אבל אותם משקיעים ומנהלים כבר הבינו שזה נושא שבו ההבדל בין אדם עם נסיון לאדם ש"קרא על זה, יודע הרבה דברים והוא מאוד חכם" יכול להיות ההבדל שבין להצליח או ליפול מבחינה טכנולוגית (שלא לדבר על מבחינה עסקית).
&nbsp
&nbsp
 

סימבה8881

New member
מה שאתה אומר זה נכון לאנשים בתפקידים בכירים

אני בספק כמה החלטות כאלה מקבל בן אדם עם 3-4 שנות ניסיון.
&nbsp
השאלה היא האם בדרגים היחסית זוטרים, מפתח בקאנד (שהוא לא big data) עלול למצוא את עצמו מתויג כ"לא מתאים" למשרה.
 

choo

Active member
זה תלוי בשלב שבו החברה המחפשת נמצאת

&nbsp
אם הם בהתחלה - הם יחפשו אנשים עם נסיון רלוונטי חובה. בשלב מסוים הם יתחילו לקלוט גם אנשים עם פחות נסיון, ובשלב מסויים גם אנשים ללא שום רקע רלוונטי בסקיילאביליות. זה נכון לכל תחום - ככל שהחברה גדלה, אפשר לקחת יותר אנשים חסרי נסיון רלוונטי ולהכניס אותם לתחום - כי יש מי שיתכנן את הארכיטקטורה ויתכנן את המערכת והפיצ'רים השונים וימנע מהם לעשות שטויות.
&nbsp
מצד שני, דרך קשרים ובחברות דלות תקציב ייתכן שיקחו אותך בשלב מוקדם גם אם אין לך נסיון רלוונטי (מישהו פעם ניסה לגייס אותי לחברה שהוא התחיל להקים, כדי לפתח תוכנה בסקיילאביליות של web, כשלי לא היה שום נסיון בסקיילאביליות. מצד שני, זה היה בתקופה שכמעט לא היו בארץ אנשים עם נסיון בסקיילאביליות, ולכן הוא חיפש "משהו קרוב". הבהרתי לו שאין לי את הנסיון הדרוש למשימה מהסוג הזה והפניתי אותו הלאה למישהו "יותר קרוב". יכולתי באותה מידה לאמר כן ולהתגלח על חשבונו וחשבון משקיעיו. האם סיפור כזה עשוי להתרחש היום, כשכבר יש הרבה אנשים עם נסיון בסקיילאביליות? אני מסופק, אבל זה בוודאי מתרחש בגרא'גים בחברות bootstrap).
 
מזכיר לי סיפור אמיתי
כשהחברה הקודמת שלי רק התחילה, הארכיטקט הראשי הבטיח ליזם שהמערכת שהוא כותב היא סקיילבילית.
&nbsp
כשהתחילה הצפה של משתמשים והמערכת קרסה עקב העומס, היזם בא לארכיטקט ואמר לו: "אבל אמרת לי שהמערכת סקיילבילית!" והתשובה היתה: "היא באמת סקיילבילית, אבל לא לכמויות האלו".
 

הפרבולה

New member
אני משתמש ב define כדי לקבל סקלביליות

למשל בקובץ h הראשי יש דבר כזה

#define NUMBER_OF_OBJ 100

אם אחרי שנה הלקוח מבקש להגדיל את מספר האוביקטים ממאה למליון , אז אני משנה את זה כך:
#define NUMBER_OF_OBJ 1000000

מקפמל ושולח לו עידכון גירסה.
 

user32

Well-known member
מנהל
יש גם את גרסת הכרטיס אשראי

קונה שרת חזק יותר.
 

user32

Well-known member
מנהל
במציאות זה הרבה יותר קרוב לתיאור השני שלך

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

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

גם בסקליבליות, ראיתי אנשים שמימשו למשל שרת הודעות שמיועד לסקייל גבוה באמצעות קפקא, או דווקא גישה של תור עם Rabbit או מליון שירותי queue אחרים. כאלה שעשו עם קלאסטרים של ווב סרברים או אפילו מימוש עצמי עם C++, go או erlang. שלא לדבר על כאלה שפשוט לקחו שירותי ענן מנוהל כלשהו של אמזון, גוגל או מיקרוסופט וגם זה עובד טוב.

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

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