Ցածր կոդի կիրառում վերլուծական հարթակներում

Հարգելի ընթերցողներ, բարի օր:

Տվյալների հավաքագրման և վերլուծության համար ՏՏ հարթակներ կառուցելու խնդիրը վաղ թե ուշ առաջանում է ցանկացած ընկերության համար, որի բիզնեսը հիմնված է ինտելեկտուալ բեռնված ծառայությունների մատուցման մոդելի կամ տեխնիկապես բարդ արտադրանքի ստեղծման վրա: Վերլուծական հարթակներ կառուցելը բարդ և ժամանակատար խնդիր է: Այնուամենայնիվ, ցանկացած խնդիր կարելի է պարզեցնել: Այս հոդվածում ես ուզում եմ կիսվել ցածր կոդով գործիքների օգտագործման իմ փորձով, որոնք կօգնեն ստեղծել վերլուծական լուծումներ: Այս փորձը ձեռք է բերվել Neoflex ընկերության Big Data Solutions ուղղությամբ մի շարք նախագծերի իրականացման ընթացքում։ 2005 թվականից Neoflex-ի Big Data Solutions ուղղությունը զբաղվում է տվյալների պահեստների և լճերի կառուցման, տեղեկատվության մշակման արագության օպտիմալացման խնդիրների լուծման և տվյալների որակի կառավարման մեթոդաբանության վրա աշխատելու հարցերով:

Ոչ ոք չի կարողանա խուսափել թույլ և/կամ ուժեղ կառուցվածքային տվյալների գիտակցված կուտակումից: Թերևս նույնիսկ եթե խոսքը փոքր բիզնեսի մասին է։ Ի վերջո, բիզնեսը ծավալելիս խոստումնալից ձեռներեցը կկանգնի հավատարմության ծրագրի մշակման հետ կապված խնդիրների առաջ, կցանկանա վերլուծել վաճառքի կետերի արդյունավետությունը, կմտածի նպատակային գովազդի մասին և կտարակուսի ուղեկցող ապրանքների պահանջարկից։ . Առաջին մոտավորությամբ խնդիրը կարող է լուծվել «ծնկների վրա»: Բայց քանի որ բիզնեսն աճում է, վերլուծական հարթակ գալը դեռևս անխուսափելի է:

Այնուամենայնիվ, ո՞ր դեպքում տվյալների վերլուծության առաջադրանքները կարող են վերածվել «Rocket Science» դասի խնդիրների: Թերևս այն պահին, երբ մենք խոսում ենք իսկապես մեծ տվյալների մասին։
Հրթիռային գիտությունը հեշտացնելու համար դուք կարող եք կտոր առ մաս ուտել փղին:

Որքան ավելի դիսկրետ և ինքնավար լինեն ձեր հավելվածները/ծառայությունները/միկրոծառայությունները, այնքան ավելի հեշտ կլինի ձեր, ձեր գործընկերների և ամբողջ բիզնեսի համար մարսել փղին:

Մեր գրեթե բոլոր հաճախորդները եկել են այս պոստուլատին՝ վերակառուցելով լանդշաֆտը՝ հիմնվելով DevOps թիմերի ինժեներական պրակտիկայի վրա:

Բայց նույնիսկ «առանձին, փղային» դիետայի դեպքում մենք ՏՏ լանդշաֆտի «գերհագեցման» լավ հնարավորություններ ունենք: Այս պահին արժե կանգ առնել, արտաշնչել և կողք նայել ցածր կոդով ինժեներական հարթակ.

Շատ ծրագրավորողներ վախեցած են իրենց կարիերայի փակուղու հեռանկարից, երբ հեռանում են կոդ ուղղակի գրելուց դեպի ցածր կոդային համակարգերի UI ինտերֆեյսներում «քաշելու» սլաքները: Բայց հաստոցների հայտնվելը չհանգեցրեց ինժեներների անհետացմանը, այլ նրանց աշխատանքը հասցրեց նոր մակարդակի:

Եկեք պարզենք, թե ինչու:

Տվյալների վերլուծությունը լոգիստիկայի, հեռահաղորդակցության արդյունաբերության, մեդիա հետազոտությունների, ֆինանսական հատվածի ոլորտում միշտ կապված է հետևյալ հարցերի հետ.

• Ավտոմատացված վերլուծության արագություն;
• Փորձեր անցկացնելու ունակություն՝ առանց ազդելու տվյալների արտադրության հիմնական հոսքի վրա.
• Պատրաստված տվյալների հուսալիություն;
• Փոխել հետագծումը և տարբերակումը;
• Տվյալների ծագումը, Տվյալների տոհմը, CDC;
• Նոր հնարավորությունների արագ առաքում արտադրական միջավայր;
• Իսկ տխրահռչակը՝ զարգացման և աջակցության արժեքը:

Այսինքն՝ ինժեներներն ունեն հսկայական թվով բարձր մակարդակի առաջադրանքներ, որոնք կարելի է բավարար արդյունավետությամբ կատարել միայն իրենց գիտակցությունը մաքրելով ցածր մակարդակի զարգացման խնդիրներից։

Ծրագրավորողների համար նոր մակարդակի անցնելու նախադրյալներն էին բիզնեսի էվոլյուցիան և թվայնացումը: Մշակողի արժեքը նույնպես փոխվում է. կա ծրագրավորողների զգալի պակաս, ովքեր կարող են ընկղմվել ավտոմատացված բիզնեսի հայեցակարգերի մեջ:

Եկեք անալոգիա կազմենք ցածր և բարձր մակարդակի ծրագրավորման լեզուների հետ։ Ցածր մակարդակի լեզուներից դեպի բարձր մակարդակի լեզուների անցումը անցում է «ուղղակի հրահանգներ ապարատային լեզվով» գրելուց դեպի «մարդկանց լեզվով դիրեկտիվներ»: Այսինքն՝ աբստրակցիայի ինչ-որ շերտ ավելացնելով։ Այս դեպքում բարձր մակարդակի ծրագրավորման լեզուներից ցածր կոդային հարթակների անցումը «մարդկանց լեզվով դիրեկտիվներից» անցում է դեպի «բիզնեսի լեզվով դիրեկտիվներ»: Եթե ​​կան ծրագրավորողներ, որոնց տխրեցնում է այս փաստը, ապա նրանք տխրել են, հավանաբար, այն պահից, երբ ծնվել է Java Script-ը, որն օգտագործում է զանգվածների տեսակավորման ֆունկցիաներ։ Եվ այս գործառույթները, իհարկե, ունեն ծրագրային ապահովման իրականացում նույն բարձր մակարդակի ծրագրավորման այլ միջոցներով:

Հետևաբար, ցածր կոդը պարզապես վերացականության մեկ այլ մակարդակի տեսք է:

Կիրառական փորձ՝ օգտագործելով ցածր կոդ

Ցածր կոդերի թեման բավականին լայն է, բայց հիմա ես կցանկանայի խոսել «ցածր կոդի հասկացությունների» գործնական կիրառման մասին՝ օգտագործելով մեր նախագծերից մեկի օրինակը:

Neoflex-ի Big Data Solutions բաժինը մասնագիտացած է բիզնեսի ֆինանսական հատվածում՝ կառուցելով տվյալների պահեստներ և լճեր և ավտոմատացնելով տարբեր հաշվետվություններ: Այս խորշում ցածր կոդի օգտագործումը վաղուց դարձել է ստանդարտ: Ցածր կոդով այլ գործիքներից կարելի է նշել ETL գործընթացների կազմակերպման գործիքներ՝ Informatica Power Center, IBM Datastage, Pentaho Data Integration։ Կամ Oracle Apex-ը, որը գործում է որպես ինտերֆեյսերի արագ զարգացման միջավայր տվյալների մուտք գործելու և խմբագրելու համար: Այնուամենայնիվ, ցածր կոդերի մշակման գործիքների օգտագործումը միշտ չէ, որ ներառում է բարձր նպատակաուղղված հավելվածների ստեղծում առևտրային տեխնոլոգիաների փաթեթի վրա, որը հստակ կախված է վաճառողից:

Օգտագործելով ցածր կոդային հարթակներ, դուք կարող եք նաև կազմակերպել տվյալների հոսքերի կազմակերպում, ստեղծել տվյալների գիտության հարթակներ կամ, օրինակ, տվյալների որակը ստուգելու մոդուլներ:

Ցածր կոդերի մշակման գործիքների օգտագործման փորձի կիրառական օրինակներից է Neoflex-ի և Mediascope-ի համագործակցությունը՝ ռուսական մեդիա հետազոտությունների շուկայի առաջատարներից մեկը: Այս ընկերության բիզնես նպատակներից մեկն այն տվյալների արտադրությունն է, որի հիման վրա գովազդատուները, ինտերնետային հարթակները, հեռուստաալիքները, ռադիոկայանները, գովազդային գործակալությունները և ապրանքանիշերը որոշումներ են կայացնում գովազդ գնելու և պլանավորում իրենց մարքեթինգային հաղորդակցությունը:

Մեդիա հետազոտությունը բիզնեսի տեխնոլոգիապես ծանրաբեռնված ոլորտ է: Տեսահոլովակների հաջորդականության ճանաչում, դիտումը վերլուծող սարքերից տվյալների հավաքում, վեբ ռեսուրսների վրա ակտիվությունը չափող այս ամենը ենթադրում է, որ ընկերությունն ունի մեծ ՏՏ անձնակազմ և վերլուծական լուծումներ ստեղծելու հսկայական փորձ: Սակայն տեղեկատվության քանակի, դրա աղբյուրների քանակի և բազմազանության էքսպոնենցիալ աճը ստիպում է ՏՏ տվյալների արդյունաբերությանը մշտապես առաջընթաց ունենալ: Արդեն գործող Mediascope վերլուծական հարթակի մասշտաբավորման ամենապարզ լուծումը կարող է լինել ՏՏ անձնակազմի ավելացումը: Սակայն շատ ավելի արդյունավետ լուծում է զարգացման գործընթացի արագացումը: Այս ուղղությամբ տանող քայլերից մեկը կարող է լինել ցածր կոդային հարթակների օգտագործումը։

Ծրագրի մեկնարկի ժամանակ ընկերությունն արդեն ուներ գործող արտադրանքի լուծում: Այնուամենայնիվ, 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 գործիքներ չեն բառի լայն իմաստով: Ցածր կոդով գործիքները կարող են չունենալ կոդերի կատարման իրենց միջավայրը: Այսինքն՝ գեներացված կոդը կկատարվի այն միջավայրում, որը գոյություն ուներ կլաստերի վրա նույնիսկ մինչև ցածր կոդ լուծումը տեղադրելը։ Եվ սա թերևս ևս մեկ պլյուս է ցածր կոդային կարմայի համար: Քանի որ ցածր կոդերի թիմին զուգահեռ կարող է աշխատել «դասական» թիմը, որն իրականացնում է ֆունկցիոնալությունը, օրինակ՝ մաքուր Scala կոդով։ Երկու թիմերից էլ բարելավումներ բերելը արտադրության մեջ կլինի պարզ և անխափան:

Թերևս հարկ է նշել, որ բացի ցածր կոդից, կան նաև առանց կոդերի լուծումներ: Եվ դրանց հիմքում սրանք տարբեր բաներ են: Low-code-ը ծրագրավորողին թույլ է տալիս ավելի շատ միջամտել ստեղծված կոդի հետ: Datagram-ի դեպքում հնարավոր է դիտել և խմբագրել ստեղծված Scala կոդը, no-code-ը չի կարող նման հնարավորություն տալ։ Այս տարբերությունը շատ նշանակալից է ոչ միայն լուծման ճկունության, այլեւ տվյալների ինժեներների աշխատանքում հարմարավետության ու մոտիվացիայի առումով։

Լուծման ճարտարապետություն

Փորձենք ճշգրիտ պարզել, թե ինչպես է ցածր կոդով գործիքն օգնում լուծել տվյալների հաշվարկման ֆունկցիոնալության մշակման արագության օպտիմալացման խնդիրը: Նախ, եկեք նայենք համակարգի ֆունկցիոնալ ճարտարապետությանը: Այս դեպքում օրինակ է մեդիա հետազոտության համար տվյալների արտադրության մոդելը:

Տվյալների աղբյուրները մեր դեպքում շատ տարասեռ են և բազմազան.

• Մարդկանց հաշվիչները (հեռուստաչափերը) ծրագրային և ապարատային սարքեր են, որոնք կարդում են օգտատերերի վարքագիծը հեռուստատեսային վահանակի հարցվողներից. ով, երբ և ինչ հեռուստաալիք է դիտվել հետազոտությանը մասնակցող տնային տնտեսությունում: Տրամադրված տեղեկատվությունը հեռարձակման դիտման ընդմիջումների հոսք է, որը կապված է մեդիա փաթեթի և մեդիա արտադրանքի հետ: Տվյալների լճի մեջ բեռնման փուլում տվյալները կարող են հարստացվել ժողովրդագրական հատկանիշներով, գեոստրաֆիկացմամբ, ժամային գոտիով և այլ տեղեկություններով, որոնք անհրաժեշտ են որոշակի մեդիա արտադրանքի հեռուստադիտումը վերլուծելու համար: Կատարված չափումները կարող են օգտագործվել գովազդային արշավներ վերլուծելու կամ պլանավորելու, լսարանի ակտիվությունն ու նախասիրությունները գնահատելու և հեռարձակման ցանցը կազմելու համար.
• Տվյալները կարող են ստացվել հեռուստատեսային հեռարձակումների մոնիտորինգի համակարգերից և ինտերնետում վիդեո ռեսուրսների բովանդակության դիտումը չափելու համար.
• Չափիչ գործիքներ վեբ միջավայրում, ներառյալ ինչպես կայքակենտրոն, այնպես էլ օգտատիրոջ վրա հիմնված հաշվիչները: Data Lake-ի տվյալների մատակարարը կարող է լինել հետազոտական ​​բար բրաուզերի հավելումը և բջջային հավելվածը ներկառուցված VPN-ով:
• Տվյալները կարող են ստացվել նաև կայքերից, որոնք համախմբում են առցանց հարցաթերթիկների լրացման արդյունքները և ընկերությունների հարցումներում հեռախոսային հարցազրույցների արդյունքները.
• Տվյալների լճի լրացուցիչ հարստացումը կարող է տեղի ունենալ գործընկեր ընկերությունների տեղեկամատյաններից տեղեկատվություն ներբեռնելու միջոցով:

Աղբյուրային համակարգերից որպես հումքի բեռնման իրականացումը հում տվյալների առաջնային փուլավորման մեջ կարող է կազմակերպվել տարբեր ձևերով: Եթե ​​այս նպատակների համար օգտագործվում է ցածր կոդ, ապա հնարավոր է մետատվյալների հիման վրա բեռնվող սկրիպտների ավտոմատ ստեղծում: Այս դեպքում կարիք չկա իջնել զարգացող աղբյուրի մակարդակին՝ քարտեզագրումները թիրախավորելու համար։ Ավտոմատ բեռնում իրականացնելու համար մենք պետք է կապ հաստատենք աղբյուրի հետ, այնուհետև բեռնման միջերեսում սահմանենք բեռնվող օբյեկտների ցանկը: HDFS-ում գրացուցակի կառուցվածքը կստեղծվի ավտոմատ կերպով և կհամապատասխանի աղբյուրի համակարգի տվյալների պահպանման կառուցվածքին:

Այնուամենայնիվ, այս նախագծի համատեքստում մենք որոշեցինք չօգտագործել ցածր կոդերի հարթակի այս հնարավորությունը, քանի որ Mediascope ընկերությունն արդեն ինքնուրույն սկսել է աշխատել Nifi + Kafka կոմբինացիայի միջոցով նմանատիպ ծառայություն արտադրելու վրա:

Արժե անմիջապես նշել, որ այս գործիքները փոխանակելի չեն, այլ ավելի շուտ փոխլրացնող: Նիֆին և Կաֆկան կարողանում են աշխատել ինչպես ուղիղ (Nifi -> Kafka), այնպես էլ հակադարձ (Kafka -> Nifi) կապով: Մեդիա հետազոտական ​​հարթակի համար օգտագործվել է փաթեթի առաջին տարբերակը։

Մեր դեպքում NayFi-ին անհրաժեշտ էր մշակել տարբեր տեսակի տվյալներ աղբյուր համակարգերից և ուղարկել դրանք Kafka բրոքերին: Այս դեպքում հաղորդագրություններն ուղարկվել են Կաֆկայի կոնկրետ թեմայի՝ PublishKafka Nifi պրոցեսորների միջոցով: Այս խողովակաշարերի կազմակերպումն ու սպասարկումն իրականացվում է տեսողական միջերեսով: Nifi գործիքը և Nifi + Kafka համակցության օգտագործումը կարելի է անվանել նաև մշակման ցածր կոդային մոտեցում, որն ունի ցածր խոչընդոտ Մեծ տվյալների տեխնոլոգիաներ մուտք գործելու համար և արագացնում է հավելվածների մշակման գործընթացը։

Ծրագրի իրականացման հաջորդ փուլը մանրամասն տվյալները մեկ իմաստային շերտի ձևաչափի բերելն էր: Եթե ​​կազմակերպությունն ունի պատմական ատրիբուտներ, ապա հաշվարկը կատարվում է տվյալ բաժանման համատեքստում: Եթե ​​սուբյեկտը պատմական չէ, ապա ընտրովի հնարավոր է կամ վերահաշվարկել օբյեկտի ամբողջ բովանդակությունը, կամ ամբողջությամբ հրաժարվել այս օբյեկտի վերահաշվարկից (փոփոխությունների բացակայության պատճառով): Այս փուլում բանալիները ստեղծվում են բոլոր սուբյեկտների համար: Բանալիները պահվում են հիմնական օբյեկտներին համապատասխան Hbase դիրեկտորիաներում, որոնք պարունակում են համապատասխանություն վերլուծական հարթակի բանալիների և սկզբնաղբյուր համակարգերի բանալիների միջև: Ատոմային սուբյեկտների համախմբումն ուղեկցվում է վերլուծական տվյալների նախնական հաշվարկի արդյունքներով հարստացմամբ։ Տվյալների հաշվարկման շրջանակը Spark-ն էր: Տվյալները մեկ իմաստաբանության մեջ բերելու նկարագրված ֆունկցիոնալությունը նույնպես իրականացվել է ցածր կոդով Datagram գործիքի քարտեզագրումների հիման վրա:

Թիրախային ճարտարապետությունը պահանջում էր SQL մուտք դեպի տվյալներ բիզնես օգտագործողների համար: Այս տարբերակի համար օգտագործվել է փեթակ: Օբյեկտները ինքնաբերաբար գրանցվում են Hive-ում, երբ դուք միացնում եք «Registr Hive Table» տարբերակը ցածր կոդերի գործիքում:

Հաշվարկային հոսքի վերահսկում

Datagram-ն ունի ինտերֆեյս աշխատանքային հոսքի ձևավորումներ ստեղծելու համար: Քարտեզագրումները կարող են գործարկվել՝ օգտագործելով Oozie ժամանակացույցը: Հոսքի մշակողի ինտերֆեյսում հնարավոր է ստեղծել զուգահեռ, հաջորդական կամ կատարումից կախված տվյալների փոխակերպումների սխեմաներ: Աջակցություն կա shell սցենարների և java ծրագրերի համար: Հնարավոր է նաև օգտագործել Apache Livy սերվերը: Apache Livy-ն օգտագործվում է ծրագրերն անմիջապես մշակման միջավայրից գործարկելու համար:

Եթե ​​ընկերությունն արդեն ունի իր սեփական գործընթացների նվագախումբը, հնարավոր է օգտագործել REST API-ն՝ քարտեզագրումները գոյություն ունեցող հոսքի մեջ ներկառուցելու համար: Օրինակ, մենք բավականին հաջող փորձ ունեինք Scala-ում քարտեզագրումներ ներդնելու PLSQL և Kotlin լեզուներով գրված նվագարկիչների մեջ: Ցածր կոդով գործիքի REST API-ն ներառում է այնպիսի գործողություններ, ինչպիսիք են՝ քարտեզագրման նախագծման հիման վրա կատարվող տարվա ստեղծումը, քարտեզագրման կանչը, քարտեզագրումների հաջորդականությունը կանչելը և, իհարկե, URL-ին պարամետրեր փոխանցելը քարտեզագրումներ գործարկելու համար:

Oozie-ի հետ մեկտեղ հնարավոր է կազմակերպել հաշվարկային հոսք Airflow-ի միջոցով: Թերևս երկար չանդրադառնամ Oozie-ի և Airflow-ի համեմատության վրա, այլ պարզապես կասեմ, որ մեդիա հետազոտական ​​նախագծի վրա աշխատանքի համատեքստում ընտրությունը ընկավ Airflow-ի օգտին: Այս անգամ հիմնական փաստարկներն էին արտադրանքը մշակող ավելի ակտիվ համայնքը և ավելի զարգացած ինտերֆեյսը + API:

Օդի հոսքը նույնպես լավ է, քանի որ այն օգտագործում է սիրելի Python-ը հաշվարկման գործընթացները նկարագրելու համար: Եվ ընդհանրապես, բաց կոդով աշխատանքային հոսքի կառավարման հարթակներն այնքան էլ շատ չեն։ Գործընթացների (ներառյալ Գանտի գծապատկերի) գործարկումը և վերահսկումը միայն միավորներ է ավելացնում Airflow-ի կարմային:

Ցածր կոդով լուծումների քարտեզագրման գործարկման համար կազմաձևման ֆայլի ձևաչափը դարձել է spark-submit: Սա տեղի ունեցավ երկու պատճառով. Նախ, spark-submit-ը թույլ է տալիս ուղղակիորեն գործարկել jar ֆայլը վահանակից: Երկրորդ, այն կարող է պարունակել բոլոր անհրաժեշտ տեղեկությունները աշխատանքային հոսքը կարգավորելու համար (որը հեշտացնում է Dag-ի ստեղծող սցենարներ գրելը):
Մեր դեպքում Airflow աշխատանքային հոսքի ամենատարածված տարրը SparkSubmitOperator-ն էր:

SparkSubmitOperator-ը թույլ է տալիս գործարկել բանկաներ՝ փաթեթավորված Datagram-ի քարտեզագրումներ՝ դրանց համար նախապես ստեղծված մուտքային պարամետրերով:

Հարկ է նշել, որ յուրաքանչյուր Airflow առաջադրանք աշխատում է առանձին թեմայում և ոչինչ չգիտի այլ առաջադրանքների մասին: Հետևաբար, առաջադրանքների միջև փոխազդեցությունն իրականացվում է կառավարման օպերատորների միջոցով, ինչպիսիք են DummyOperator-ը կամ BranchPythonOperator-ը:

Միասին, Datagram-ի ցածր կոդային լուծման օգտագործումը կոնֆիգուրացիայի ֆայլերի ունիվերսալացման հետ համատեղ (ձևավորելով Dag) հանգեցրեց տվյալների բեռնման հոսքերի մշակման գործընթացի զգալի արագացման և պարզեցման:

Ցուցափեղկի հաշվարկ

Վերլուծական տվյալների արտադրության մեջ թերևս ամենաինտելեկտուալ բեռնված փուլը ցուցափեղկեր կառուցելու քայլն է: Հետազոտական ​​ընկերության տվյալների հաշվարկային հոսքերից մեկի համատեքստում, այս փուլում տվյալները վերածվում են հղման հեռարձակման՝ հաշվի առնելով ժամային գոտիների ուղղումները և կապված հեռարձակման ցանցին: Հնարավոր է նաև հարմարեցվել տեղական հեռարձակման ցանցին (տեղական նորություններ և գովազդ): Ի թիվս այլ բաների, այս քայլը խախտում է մեդիա արտադրանքի շարունակական դիտման միջակայքերը՝ հիմնվելով դիտման ընդմիջումների վերլուծության վրա: Անմիջապես դիտման արժեքները «կշռվում են»՝ հիմնվելով դրանց նշանակության մասին տեղեկատվության վրա (ուղղման գործոնի հաշվարկ):

Ցուցափեղկերի պատրաստման առանձին քայլ է տվյալների վավերացումը: Վավերացման ալգորիթմը ներառում է մի շարք մաթեմատիկական գիտության մոդելների օգտագործում: Այնուամենայնիվ, ցածր կոդերի պլատֆորմի օգտագործումը թույլ է տալիս բարդ ալգորիթմը բաժանել մի շարք առանձին տեսողական ընթեռնելի քարտեզների: Քարտեզագրումներից յուրաքանչյուրը կատարում է նեղ խնդիր: Արդյունքում հնարավոր է միջանկյալ կարգաբերում, գրանցում և տվյալների պատրաստման փուլերի վիզուալիզացիա:

Որոշվեց վավերացման ալգորիթմը բաժանել հետևյալ ենթափուլերի.

• Հեռուստատեսային ցանցերի դիտման կախվածության ռեգրեսիաների ստեղծում տարածաշրջանում` տարածաշրջանի բոլոր ցանցերի դիտումով 60 օր:
• Ուսանողական մնացորդների հաշվարկ (փաստացի արժեքների շեղումներ ռեգրեսիոն մոդելի կողմից կանխատեսված արժեքներից) բոլոր ռեգրեսիոն կետերի և հաշվարկված օրվա համար:
• Տարածաշրջան-ցանցային անոմալ զույգերի ընտրություն, որտեղ հաշվարկային օրվա ուսանողական մնացորդը գերազանցում է նորման (նշված է գործառնական պարամետրերով):
• Տարածաշրջանում ցանցը դիտած յուրաքանչյուր հարցվողի համար անոմալ շրջան-հեռուստատեսային ցանցերի համար ուղղված ուսանողական մնացորդի վերահաշվարկ՝ որոշելով այս պատասխանողի ներդրումը (ուսանողական մնացորդի փոփոխության չափը)՝ այս պատասխանողի դիտումը ընտրանքից բացառելիս։ .
• Որոնեք թեկնածուների, որոնց բացառումը վերադարձնում է աշխատավարձի օրվա ուսանողական հաշվեկշիռը նորմալ:

Վերոնշյալ օրինակը հաստատում է այն վարկածը, որ տվյալների ինժեներն արդեն չափազանց շատ բան ունի իր մտքում... Եվ, եթե սա իսկապես «ինժեներ» է և ոչ թե «կոդավորող», ապա ցածր կոդով գործիքներ օգտագործելիս պրոֆեսիոնալ դեգրադացիայի վախը նա ունի։ վերջապես պետք է նահանջել.

Էլ ի՞նչ կարող է անել ցածր կոդը:

Ցածր կոդով գործիքի կիրառման շրջանակը խմբաքանակի և հոսքային տվյալների մշակման համար՝ առանց Scala-ում կոդ ձեռքով գրելու անհրաժեշտության, դրանով չի ավարտվում:

Դատալեյքի մշակման մեջ ցածր կոդի օգտագործումն արդեն չափանիշ է դարձել մեզ համար։ Հավանաբար, կարելի է ասել, որ Hadoop stack-ի վրա հիմնված լուծումները հետևում են դասական DWH-ների զարգացման ուղուն, որոնք հիմնված են RDBMS-ի վրա: Hadoop stack-ի ցածր կոդով գործիքները կարող են լուծել ինչպես տվյալների մշակման խնդիրները, այնպես էլ վերջնական BI ինտերֆեյս ստեղծելու խնդիրը: Ընդ որում, պետք է նշել, որ BI-ն կարող է նշանակել ոչ միայն տվյալների ներկայացում, այլև դրանց խմբագրում բիզնես օգտատերերի կողմից։ Մենք հաճախ օգտագործում ենք այս ֆունկցիոնալությունը ֆինանսական հատվածի համար վերլուծական հարթակներ կառուցելիս:

Ի թիվս այլ բաների, օգտագործելով ցածր կոդ և, մասնավորապես, Datagram-ը, հնարավոր է լուծել ատոմականությամբ տվյալների հոսքի օբյեկտների ծագումը հետևելու խնդիրը մինչև առանձին դաշտեր (տոհմ): Դա անելու համար ցածր կոդով գործիքն իրականացնում է ինտերֆեյս Apache Atlas-ի և Cloudera Navigator-ի հետ: Ըստ էության, մշակողը պետք է գրանցի մի շարք օբյեկտներ Atlas բառարաններում և հղում կատարի գրանցված օբյեկտներին քարտեզներ կառուցելիս: Տվյալների ծագմանը հետևելու կամ օբյեկտների կախվածությունը վերլուծելու մեխանիզմը խնայում է շատ ժամանակ, երբ անհրաժեշտ է կատարելագործումներ կատարել հաշվարկների ալգորիթմներում: Օրինակ՝ ֆինանսական հաշվետվություններ պատրաստելիս այս հատկությունը թույլ է տալիս ավելի հարմարավետ գոյատևել օրենսդրական փոփոխությունների շրջանը։ Ի վերջո, որքան լավ հասկանանք միջձևային կախվածությունը մանրամասն շերտի օբյեկտների համատեքստում, այնքան քիչ կհանդիպենք «հանկարծակի» թերությունների և կնվազեցնենք վերամշակումների քանակը:

Տվյալների որակ և ցածր կոդ

Mediascope նախագծի վրա ցածր կոդ գործիքի կողմից իրականացված մեկ այլ առաջադրանք էր Data Quality դասի առաջադրանքը: Հետազոտական ​​ընկերության նախագծի համար տվյալների ստուգման խողովակաշարի իրականացման առանձնահատուկ առանձնահատկությունն այն էր, որ ազդեցության բացակայությունը հիմնական տվյալների հաշվարկման հոսքի կատարման և արագության վրա: Որպեսզի կարողանանք կազմակերպել անկախ տվյալների ստուգման հոսքերը, օգտագործվել է արդեն ծանոթ Apache Airflow-ը: Քանի որ տվյալների արտադրության յուրաքանչյուր քայլ պատրաստ էր, զուգահեռաբար գործարկվեց DQ խողովակաշարի առանձին հատված:

Լավ պրակտիկա է համարվում տվյալների որակի վերահսկումը վերլուծական հարթակում դրա ստեղծման պահից: Ունենալով տեղեկատվություն մետատվյալների մասին՝ մենք կարող ենք ստուգել համապատասխանությունը հիմնական պայմաններին այն պահից, երբ տեղեկատվությունը մտնում է առաջնային շերտ՝ ոչ զրոյական, սահմանափակումներ, օտար բանալիներ: Այս գործառույթն իրականացվում է Datagram-ում տվյալների որակի ընտանիքի ինքնաբերաբար գեներացված քարտեզագրումների հիման վրա: Կոդի ստեղծումն այս դեպքում նույնպես հիմնված է մոդելային մետատվյալների վրա: Mediascope նախագծում ինտերֆեյսն իրականացվել է Enterprise Architect արտադրանքի մետատվյալներով:

Ցածր կոդով գործիքը Enterprise Architect-ի հետ զուգակցելով՝ ավտոմատ կերպով ստեղծվեցին հետևյալ ստուգումները.

• «ոչ զրոյական» փոփոխիչով դաշտերում «null» արժեքների առկայության ստուգում.
• Ստուգում է առաջնային բանալին կրկնօրինակների առկայությունը.
• Կազմակերպության արտաքին բանալիների ստուգում;
• Ստուգելով տողի եզակիությունը՝ հիմնված մի շարք դաշտերի վրա:

Տվյալների առկայության և հուսալիության ավելի բարդ ստուգումների համար ստեղծվել է Scala Expression-ով քարտեզագրում, որն ընդունում է որպես մուտքագրում Zeppelin-ի վերլուծաբանների կողմից պատրաստված արտաքին Spark SQL ստուգման կոդը:

Իհարկե, ստուգումների ավտոմատ ստեղծմանը պետք է հասնել աստիճանաբար։ Նկարագրված նախագծի շրջանակներում դրան նախորդել են հետևյալ քայլերը.

• DQ ներդրված Zeppelin նոութբուքերում;
• DQ ներկառուցված քարտեզագրման մեջ;
• DQ առանձին զանգվածային քարտեզագրումների տեսքով, որոնք պարունակում են ստուգումների մի ամբողջ շարք առանձին սուբյեկտի համար.
• Ունիվերսալ պարամետրացված DQ քարտեզագրումներ, որոնք ընդունում են տեղեկատվություն մետատվյալների և բիզնես ստուգումների մասին որպես մուտքագրում:

Թերևս պարամետրացված ստուգման ծառայության ստեղծման հիմնական առավելությունը ֆունկցիոնալությունը արտադրական միջավայր հասցնելու համար պահանջվող ժամանակի կրճատումն է: Որակի նոր ստուգումները կարող են շրջանցել մշակման և փորձարկման միջավայրերի միջոցով կոդերի անուղղակի առաքման դասական օրինակը.

• Բոլոր մետատվյալների ստուգումները ավտոմատ կերպով ստեղծվում են, երբ մոդելը փոփոխվում է EA-ում;
• Տվյալների առկայության ստուգումները (որոշելով ցանկացած տվյալների առկայությունը ժամանակի մի կետում) կարող են ստեղծվել գրացուցակի հիման վրա, որը պահպանում է օբյեկտների համատեքստում հաջորդ տվյալների հայտնվելու սպասվող ժամկետները.
• Բիզնեսի տվյալների վավերացման ստուգումները ստեղծվում են վերլուծաբանների կողմից Zeppelin նոթատետրերում: Այնտեղից դրանք ուղղակիորեն ուղարկվում են արտադրական միջավայրում DQ մոդուլի տեղադրման աղյուսակներին:

Սցենարները արտադրություն ուղղակիորեն առաքելու ռիսկեր չկան: Նույնիսկ շարահյուսական սխալի դեպքում մեզ սպառնացող առավելագույնը մեկ ստուգում չկատարելն է, քանի որ տվյալների հաշվարկման հոսքը և որակի ստուգման գործարկման հոսքը առանձնացված են միմյանցից:

Ըստ էության, DQ ծառայությունը մշտապես աշխատում է արտադրական միջավայրում և պատրաստ է սկսել իր աշխատանքը այն պահին, երբ հայտնվում է տվյալների հաջորդ մասը:

Փոխարենը մի եզրակացության

Ցածր կոդ օգտագործելու առավելությունն ակնհայտ է. Մշակողները կարիք չունեն հավելվածը զրոյից մշակելու։ Իսկ լրացուցիչ առաջադրանքներից ազատված ծրագրավորողն ավելի արագ արդյունք է տալիս: Արագությունն իր հերթին լրացուցիչ ժամանակ է ազատում օպտիմալացման խնդիրների լուծման համար: Հետեւաբար, այս դեպքում դուք կարող եք ապավինել ավելի լավ եւ արագ լուծմանը:

Իհարկե, ցածր ծածկագիրը համադարման չէ, և կախարդանքն ինքնին տեղի չի ունենա.

• Ցածր կոդերի արդյունաբերությունն անցնում է «ուժեղանալու» փուլ, և դեռևս չկան միասնական արդյունաբերական ստանդարտներ.
• Շատ ցածր կոդային լուծումներ անվճար չեն, և դրանք գնելը պետք է լինի գիտակցված քայլ, որը պետք է կատարվի դրանց օգտագործման ֆինանսական օգուտների նկատմամբ լիակատար վստահությամբ.
• Ցածր կոդով շատ լուծումներ միշտ չէ, որ լավ են աշխատում GIT/SVN-ի հետ: Կամ դրանք անհարմար են օգտագործել, եթե ստեղծված կոդը թաքնված է.
• Ճարտարապետությունը ընդլայնելիս կարող է անհրաժեշտ լինել կատարելագործել ցածր կոդային լուծումը, որն իր հերթին առաջացնում է «կցվածության և կախվածության» ազդեցությունը ցածր կոդային լուծումների մատակարարի վրա:
• Անվտանգության համապատասխան մակարդակը հնարավոր է, բայց դա շատ աշխատատար է և դժվար է կիրառել ցածր կոդային համակարգի շարժիչներում: Ցածր կոդերի հարթակները պետք է ընտրվեն ոչ միայն դրանց օգտագործումից օգուտներ փնտրելու սկզբունքով։ Ընտրելիս արժե հարցեր տալ մուտքի վերահսկման գործառույթի առկայության և նույնականացման տվյալների պատվիրակման/բարձրացման վերաբերյալ կազմակերպության ամբողջ ՏՏ լանդշաֆտի մակարդակին:

Այնուամենայնիվ, եթե ընտրված համակարգի բոլոր թերությունները ձեզ հայտնի են, և դրա օգտագործումից օգուտները, այնուամենայնիվ, գերակշռող մեծամասնություն են կազմում, ապա առանց վախենալու անցեք փոքր կոդի: Ավելին, դրան անցումը անխուսափելի է, ինչպես որ ցանկացած էվոլյուցիա է անխուսափելի։

Եթե ​​ցածր կոդով պլատֆորմի վրա մեկ ծրագրավորող իր գործն ավելի արագ է կատարում, քան երկու ծրագրավորողներ առանց ցածր կոդերի, ապա դա ընկերությանը բոլոր առումներով առաջին մեկնարկ է տալիս: Ցածր կոդային լուծումների մուտքի շեմն ավելի ցածր է, քան «ավանդական» տեխնոլոգիաներին, և դա դրականորեն է ազդում կադրերի պակասի հարցում։ Ցածր կոդով գործիքներ օգտագործելիս հնարավոր է արագացնել փոխգործակցությունը ֆունկցիոնալ թիմերի միջև և ավելի արագ որոշումներ կայացնել տվյալների գիտության հետազոտության ընտրված ուղու ճիշտության վերաբերյալ: Ցածր մակարդակի հարթակները կարող են խթանել կազմակերպության թվային վերափոխումը, քանի որ ստեղծված լուծումները կարող են հասկանալի լինել ոչ տեխնիկական մասնագետների (մասնավորապես՝ բիզնես օգտագործողների համար):

Եթե ​​դուք ունեք սեղմ ժամկետներ, բեռնված բիզնես տրամաբանություն, տեխնոլոգիական փորձաքննության պակաս, և դուք պետք է արագացնեք շուկա դուրս գալու ձեր ժամանակը, ապա ցածր ծածկագիրը ձեր կարիքները բավարարելու ճանապարհներից մեկն է:

Չի կարելի հերքել ավանդական զարգացման գործիքների կարևորությունը, սակայն շատ դեպքերում ցածր կոդային լուծումների օգտագործումը լավագույն միջոցն է լուծվող խնդիրների արդյունավետությունը բարձրացնելու համար:

Source: www.habr.com