יישום של קוד נמוך בפלטפורמות אנליטיות

קוראים יקרים, יום טוב!

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

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

עם זאת, באיזה מקרה יכולות מטלות ניתוח נתונים להתפתח לבעיות בכיתה "Rocket Science"? אולי ברגע שאנחנו מדברים על נתונים גדולים באמת.
כדי להקל על מדע הרוקט, אתה יכול לאכול את הפיל חתיכה אחר חתיכה.

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

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

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

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

בואו נבין למה.

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

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

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

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

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

לכן, קוד נמוך הוא רק המראה של רמה נוספת של הפשטה.

ניסיון יישומי באמצעות קוד נמוך

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

חטיבת Big Data Solutions של Neoflex מתמחה יותר במגזר הפיננסי של העסק, בניית מחסני נתונים ואגמים ואוטומציה של דיווחים שונים. בנישה זו, השימוש בקוד נמוך הפך מזמן לסטנדרט. בין שאר הכלים דלי הקוד, ניתן לציין כלים לארגון תהליכי ETL: Informatica Power Center, IBM Datastage, Pentaho Data Integration. או Oracle Apex, הפועלת כסביבה לפיתוח מהיר של ממשקים לגישה ועריכת נתונים. עם זאת, השימוש בכלי פיתוח בקוד נמוך לא תמיד כרוך בבניית יישומים ממוקדים ביותר על ערימת טכנולוגיה מסחרית עם תלות ברורה בספק.

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

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

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

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

המשימה שלפנינו הייתה שאפתנית באמת - Neoflex ו-Mediascope היו צריכים ליצור פתרון תעשייתי תוך פחות משנה, בכפוף לשחרור ה-MVP ברבעון הראשון של תאריך ההתחלה.

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

הכלי Lowe-code בתפיסה זו שימש כדי לייעל את המשימה עתירת העבודה ביותר בבניית פלטפורמה אנליטית - משימת חישוב הנתונים.

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

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

• צפייה בתוכן ובמבנה של מקורות/מקלטים;
• מעקב אחר מקורם של אובייקטי זרימת נתונים לשדות בודדים (שושלת);
• ביצוע חלקי של טרנספורמציות עם צפייה בתוצאות ביניים;
• סקירת קוד המקור והתאמתו לפני הביצוע;
• אימות אוטומטי של טרנספורמציות;
• הורדת נתונים אוטומטית 1 ב-1.

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

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

ארכיטקטורת פתרונות

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

מקורות הנתונים במקרה שלנו הם הטרוגניים ומגוונים מאוד:

• מדי אנשים (מדדי טלוויזיה) הם התקני תוכנה וחומרה הקוראים את התנהגות המשתמשים מהמשיבים בפאנל הטלוויזיה - מי, מתי ואיזה ערוץ טלוויזיה נצפה במשק הבית שמשתתף במחקר. המידע המסופק הוא זרם של מרווחי צפייה בשידורים המקושרים לחבילת המדיה ולמוצר המדיה. ניתן להעשיר את הנתונים בשלב הטעינה ל-Data Lake במאפיינים דמוגרפיים, גיאוסטרטיפיקציה, אזור זמן ומידע אחר הדרוש לניתוח צפייה בטלוויזיה במוצר מדיה מסוים. המדידות שנלקחו יכולות לשמש לניתוח או תכנון קמפיינים פרסומיים, הערכת פעילות והעדפות הקהל, והרכבת רשת השידור;
• הנתונים יכולים להגיע ממערכות ניטור להזרמת שידורי טלוויזיה ומדידת צפייה בתכני משאבי וידאו באינטרנט;
• כלי מדידה בסביבת האינטרנט, כולל מונים ממוקדי אתר וגם מונים ממוקדי משתמש. ספק הנתונים של Data Lake יכול להיות תוסף לדפדפן סרגל מחקר ואפליקציה לנייד עם VPN מובנה.
• נתונים יכולים להגיע גם מאתרים המאגדים את תוצאות מילוי השאלונים המקוונים ואת תוצאות הראיונות הטלפוניים בסקרי חברות;
• העשרה נוספת של אגם הנתונים יכולה להתרחש על ידי הורדת מידע מיומנים של חברות שותפות.

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

עם זאת, בהקשר של פרויקט זה, החלטנו לא להשתמש בתכונה זו של פלטפורמת ה-low-code בשל העובדה שחברת Mediascope כבר החלה לעבוד באופן עצמאי על הפקת שירות דומה באמצעות השילוב של Nifi + Kafka.

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

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

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

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

בקרת זרימת חישוב

ל-Datagram יש ממשק ליצירת עיצובי זרימת עבודה. ניתן להפעיל מיפויים באמצעות מתזמן Oozie. בממשק מפתח הזרם, ניתן ליצור סכמות עבור טרנספורמציות נתונים מקבילות, עוקבות או תלויות ביצוע. יש תמיכה בסקריפטים של מעטפת ותוכניות ג'אווה. אפשר גם להשתמש בשרת Apache Livy. Apache Livy משמש להפעלת יישומים ישירות מסביבת הפיתוח.

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

יחד עם Oozie, ניתן לארגן זרימת חישוב באמצעות Airflow. אולי לא אתעכב זמן רב על ההשוואה בין Oozie ל-Airflow, אלא פשוט אגיד שבהקשר של עבודה על פרויקט מחקר תקשורתי, הבחירה נפלה לטובת Airflow. הטיעונים העיקריים הפעם היו קהילה פעילה יותר שמפתחת את המוצר וממשק מפותח יותר + API.

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

פורמט קובץ התצורה להפעלת מיפויי פתרונות בקוד נמוך הפך ל-spark-submit. זה קרה משתי סיבות. ראשית, spark-submit מאפשר לך להריץ ישירות קובץ jar מהמסוף. שנית, הוא יכול להכיל את כל המידע הדרוש כדי להגדיר את זרימת העבודה (מה שמקל על כתיבת סקריפטים שיוצרים Dag).
המרכיב הנפוץ ביותר של זרימת העבודה של Airflow במקרה שלנו היה SparkSubmitOperator.

SparkSubmitOperator מאפשר לך להפעיל jars - מיפויי Datagram ארוזים עם פרמטרי קלט שנוצרו עבורם מראש.

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

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

חישובי ראווה

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

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

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

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

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

מה עוד יכול קוד נמוך לעשות?

היקף היישום של כלי דל קוד לעיבוד נתונים אצווה וזרם ללא צורך בכתיבת קוד ידנית ב-Scala אינו מסתיים בכך.

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

בין היתר, באמצעות קוד נמוך ובפרט ב-Datagram, ניתן לפתור את בעיית המעקב אחר מקורם של אובייקטי זרם נתונים עם אטומיות עד לשדות בודדים (שושלת). לשם כך, כלי הקוד הנמוך מיישם ממשק עם Apache Atlas ו-Cloudera Navigator. בעיקרו של דבר, המפתח צריך לרשום קבוצה של אובייקטים במילוני אטלס ולהתייחס לאובייקטים הרשומים בעת בניית מיפויים. המנגנון למעקב אחר מקור הנתונים או ניתוח תלות באובייקט חוסך זמן רב כאשר יש צורך לבצע שיפורים באלגוריתמי החישוב. לדוגמה, בעת הכנת דוחות כספיים, תכונה זו מאפשרת לך לשרוד בצורה נוחה יותר את תקופת השינויים בחקיקה. אחרי הכל, ככל שנבין טוב יותר את התלות הבין-צורנית בהקשר של אובייקטים של שכבה מפורטת, כך פחות נפגוש פגמים "פתאומיים" ונפחית את מספר העיבודים החוזרים.

איכות נתונים וקוד נמוך

משימה נוספת שיושמה על ידי הכלי דל-קוד בפרויקט Mediascope הייתה משימת הכיתה Data Quality. מאפיין מיוחד ביישום צינור אימות הנתונים עבור פרויקט חברת המחקר היה היעדר השפעה על הביצועים והמהירות של זרימת חישוב הנתונים העיקרית. כדי להיות מסוגל לתזמן זרימות אימות נתונים עצמאיות, נעשה שימוש ב-Apache Airflow המוכר ממילא. מכיוון שכל שלב של ייצור נתונים היה מוכן, חלק נפרד מצינור DQ הושק במקביל.

זה נחשב נוהג טוב לנטר את איכות הנתונים מרגע תחילתו בפלטפורמה האנליטית. עם מידע על מטא נתונים, נוכל לבדוק עמידה בתנאים בסיסיים מרגע שהמידע נכנס לשכבה הראשית - לא null, אילוצים, מפתחות זרים. פונקציונליות זו מיושמת על סמך מיפויים שנוצרו אוטומטית של משפחת איכות הנתונים ב-Datagram. יצירת הקוד במקרה זה מבוססת גם על מטא נתונים של המודל. בפרויקט Mediascope, הממשק בוצע עם המטא נתונים של המוצר Enterprise Architect.

על ידי התאמה של הכלי עם קוד נמוך ל-Enterprise Architect, הבדיקות הבאות נוצרו אוטומטית:

• בדיקת נוכחותם של ערכי "null" בשדות עם השינוי "לא null";
• בדיקת נוכחות של כפילויות של המפתח הראשי;
• בדיקת מפתח זר של ישות;
• בדיקת הייחודיות של מחרוזת על סמך קבוצת שדות.

לבדיקות מורכבות יותר של זמינות ואמינות נתונים, נוצר מיפוי עם Scala Expression, שמקבל כקלט קוד בדיקת Spark SQL חיצוני שהוכן על ידי אנליסטים ב-Zeppelin.

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

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

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

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

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

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

במקום מסקנה

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

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

• תעשיית קוד נמוך עוברת שלב "מתחזק", ואין עדיין סטנדרטים תעשייתיים אחידים;
• פתרונות קוד נמוך רבים אינם חינמיים, ורכישתם צריכה להיות צעד מודע, שצריך להיעשות מתוך ביטחון מלא ביתרונות הכספיים של השימוש בהם;
• פתרונות רבים עם קוד נמוך לא תמיד עובדים טוב עם GIT/SVN. או שהם לא נוחים לשימוש אם הקוד שנוצר מוסתר;
• כאשר מרחיבים את הארכיטקטורה, ייתכן שיהיה צורך לחדד את פתרון ה-low-code - אשר בתורו מעורר את ההשפעה של "התקשרות ותלות" על הספק של פתרון ה-low-code.
• רמת אבטחה נאותה אפשרית, אך היא עתירת עבודה וקשה ליישום במנועי מערכות דלי קוד. יש לבחור פלטפורמות בעלות קוד נמוך לא רק על פי העיקרון של חיפוש יתרונות מהשימוש בהן. בעת הבחירה כדאי לשאול שאלות לגבי זמינות הפונקציונליות לבקרת גישה והאצלה/הסלמה של נתוני זיהוי לרמת כל נוף ה-IT בארגון.

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

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

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

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

מקור: www.habr.com