Data Engineer or die. մեկ մշակողի պատմություն

Դեկտեմբերի սկզբին ես ճակատագրական սխալ թույլ տվեցի և շրջադարձ կատարեցի իմ կյանքում որպես ծրագրավորող և տեղափոխվեցի ընկերության Data Engineering (DE) թիմ: Այս հոդվածում ես կկիսվեմ որոշ դիտարկումներով, որոնք արել եմ DE թիմում աշխատելու երկու ամիսների ընթացքում։

Ինչու՞ տվյալների ճարտարագիտություն:

Իմ ճանապարհորդությունը դեպի DE սկսվեց 2019 թվականի ամռանը, երբ մենք Xneg գնանք դեպի Բաշխված հաշվողական դպրոց, և այնտեղ ես հասա լուսավորության։ Ես սկսեցի հետաքրքրվել թեմայով, ուսումնասիրել ալգորիթմները և նույնիսկ դրանց մասին գրեք, այնուհետև մտածեցի կիրառման շրջանակի մասին և արագ պարզեցի, որ մեր ընկերությունում գործնական կիրառումը բաշխված տվյալների բազաներ է:

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

Եթե ​​ցանկանում եք լինել տվյալների վրա հիմնված, նախ դարձեք իրադարձությունների առաջնորդ

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

Ընդհանրապես մտածելու շատ բան կա, և այդ պատճառով այս տարածքը գրավիչ է։ Պարզապես պատահում է, որ մեր ընկերությունում Data Engineer-ը պատասխանատվության շատ ավելի լայն ոլորտ է, քան պարզապես այն մարդը, ով գրում է ETL/ELT խողովակաշարերը (եթե չգիտեք, թե ինչ են նշանակում այս հապավումները, եկեք հանդիպել. Որպես համատեքստային գովազդ).

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

Զարգացումից անցում կատարելու դժվարություններ

Աշխատանքային առաջին օրը ես հանդիպեցի մի շարք դժվարությունների, որոնք ուզում եմ կիսվել ձեզ հետ։

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

2. Աշխարհը DE-ի տեսանկյունից ամենևին այն չէ, ինչ թվում է սովորական արտադրանք մշակողին (դե, իհարկե, ընթերցողն այդպիսին չէ, և նա արդեն գիտի ամեն ինչ, բայց ես չգիտեի, և հիմա ես խաբում եմ. այն վեր է): Որպես ծրագրավորող՝ ես ստեղծում եմ իմ սեփական միկրոսերվիսը, տեղադրում եմ տվյալները [ձեր ընտրած տվյալների բազայում], պահպանում եմ իմ վիճակը այնտեղ, ինչ-որ բան ստանում եմ ID-ով, և դա լավ է: Ծառայությունը դանդաղ է, պատվերները շփոթեցնող են, այսքանը: Նրանք ինձ խնդրում են փնտրել իմ պետությունը մեկ այլ ծառայության մեջ, այնպես որ ես միջոցառում կանցկացնեմ RabbitMQ-ի մեջ և վերջ: Եվ ահա մենք կրկին վերադարձանք վերը նկարագրված իրադարձությունների խնդրին։

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

3. Պետք է գլխով մտածել։ Ոչ, ես նկատի չունեմ, որ մշակողները չեն մտածում (չնայած, թե ով եմ ես, որ խոսեմ բոլորի փոխարեն), պարզապես արտադրանքի մշակման մեջ շատ հաճախ դուք արդեն ունեք ինչ-որ ճարտարապետություն, և դուք կտրում եք տարբեր խառնաշփոթներ ետքից: Իհարկե, սա պլանավորում և մտածողություն է պահանջում, բայց սա հոսքային աշխատանք է, որտեղ հիմնական խնդիրը պարզապես լավ և արդյունավետ անելն է։

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

4. Ամենակարևորը, թերևս, տեղեկատվությունն է։ Ի՞նչ ենք անում, երբ գիտելիքի պակաս ունենք: Ո՞վ ասաց stackoverflow-ը: Այս մարդուն դուրս հանեք սենյակից: Մենք գնում ենք փաստաթղթեր, գրքեր կարդում թեմայի վերաբերյալ, և կա նաև համայնք, որը կազմակերպում է ֆորումներ, հանդիպումներ և կոնֆերանսներ: Փաստաթղթերը հիանալի են, բայց, ցավոք, այն կարող է թերի լինել: Մենք օգտագործում ենք Cosmos DB մի շարք նախագծերում: Հաջողություն այս ապրանքի համար փաստաթղթերը կարդալիս: Գրքերը միակ փրկությունն են, բարեբախտաբար, դրանք կան և կարելի է գտնել, շատ հիմնարար գիտելիքներ են պարունակում և պետք է շատ ու անընդհատ կարդալ։ Բայց խնդիրը համայնքի մեջ է։

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

Եզրակացություններ և հանդիպման մասին հայտարարություն

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

Եվ վերջապես հայտարարությունը. Քանի որ օրվա ընթացքում դժվար է մեր թեմայի վերաբերյալ հանդիպումներ գտնել, մենք որոշեցինք մերը ստեղծել: Ինչո՞ւ ենք մենք ավելի վատ: Բարեբախտաբար, մենք ունենք զարմանալի Schvepsss և մեր ընկերները Նոր մասնագիտությունների լաբորատորիա, ովքեր մեզ նման զգում են, որ տվյալների ինժեներները անարդարացիորեն զրկված են ուշադրությունից։

Օգտվելով այս առիթից՝ ես հրավիրում եմ բոլոր նրանց, ովքեր ցանկանում են գալ մեր համայնքի առաջին հանդիպմանը՝ խոստումնալից «DE or DIE» խորագրով, որը տեղի կունենա 27.02.2020 թվականի փետրվարի XNUMX-ին Dodo Pizza-ի գրասենյակում: Մանրամասները՝ հասցեում TimePad.

Եթե ​​ինչ-որ բան պատահի, ես այնտեղ կլինեմ, դուք կարող եք անձամբ իմ դեմքին ասել, թե որքան սխալ եմ ես մշակողների հարցում:

Source: www.habr.com