Желтоқсан айының басында мен қателесіп, әзірлеуші ретінде өмірімде бетбұрыс жасадым және компанияның Data Engineering (DE) командасына ауыстым. Бұл мақалада мен DE тобында екі ай жұмыс істеген кездегі кейбір бақылауларыммен бөлісемін.
Неліктен Data Engineering?
Менің DE-ге сапарым 2019 жылдың жазында басталды, біз сол кезде барайық , сонда мен ағартушылыққа қол жеткіздім. Мен тақырыпқа қызығушылық таныта бастадым, алгоритмдерді және тіпті олар туралы оқи бастадым , содан кейін қолдану аясы туралы ойландық және біздің компаниядағы практикалық қолдану деректер базасы таратылатынын тез білді.
Біздің команда нақты не істейді? Біз, барлық сәнді ұлдар мен қыздар сияқты, Data Driven Company болғымыз келеді. Бұл мүмкін болу үшін, кем дегенде, компанияға қажет кез келген есептерді құру үшін пайдалануға болатын сенімді сақтау орнын салу керек. Бірақ ең бастысы, бұл қоймадағы деректерге сенімді болу керек. Сонымен қатар, осы деректерді пайдалана отырып, сіз t уақытында жүйенің күйін қалпына келтіре алуыңыз керек. Мұның бәрі біз микросервистердің батыл жаңа әлемінде өмір сүріп жатқанымызбен қиындатады және бұл идеология әрбір қызмет өзінің шағын функционалдығын жүзеге асыратынын, оның дерекқоры жеке бизнес екенін және оны кем дегенде күн сайын жоя алатынын білдіреді, бірақ сол уақытта біз қызметтің күйін қабылдауға және өңдеуге қабілетті болуымыз керек.
Деректерге негізделген болғыңыз келсе, алдымен оқиғаға негізделген болыңыз
Қарапайым емес. Оқиғалар әртүрлі және әзірлеуші мен деректер инженері оларға басқаша қарайды. Оқиғалар туралы айту - бұл бөлек мақаланың тақырыбы, сондықтан мен бұл жерде оны қозғамаймын. Сонымен қатар, мұндай мақала қазірдің өзінде бар белгілі Мартин Фаулер, мен оның жетістіктерін алып тастамаймын, ол да танымал болсын.
Жалпы, ойланатын нәрсе көп, сондықтан бұл аймақ тартымды. Біздің компанияда деректер инженері ETL/ELT құбырларын жазатын адамға қарағанда әлдеқайда кеңірек жауапкершілік саласы болып табылады (егер сіз бұл қысқартулардың нені білдіретінін білмесеңіз, келіңіз. . Контекстік жарнама ретінде).
Біз, әрине, сақтау архитектурасымен, деректерді модельдеумен, деректер қауіпсіздігіне қатысты мәселелермен және құбырлардың өздерімен айналысамыз. Біз сондай-ақ, бір жағынан, біздің қатысуымыз өнімді әзірлеушілер үшін өте ауыр емес екеніне және жүйеге жаңа мүмкіндіктерді кесу кезінде олар біздің талаптарымызға мүмкіндігінше аз алаңдауы керек екеніне көз жеткізуіміз керек, ал екінші жағынан, біз талдаушылар мен BI командасы үшін деректерді сақтауда ыңғайлы түрде қамтамасыз ету қажет. Біз осылай өмір сүреміз.
Дамудан өту кезіндегі қиындықтар
Алғашқы жұмыс күнінде мен бірқатар қиындықтарға тап болдым, оны сіздермен бөліскім келеді.
1. Бірінші байқағаным, тюлинг пен кейбір тәжірибелердің жоқтығы. Мысалы, тесттермен кодты қамтуды алайық. Бізде жүздеген сынақ құрылымдары әзірленуде. Деректермен жұмыс істегенде бәрі күрделірек. Иә, біз ETL құбырларын сынақ деректерінде тексере аламыз, бірақ біз мұның бәрін қолмен орындауымыз керек және әрбір нақты жағдай үшін шешімдер іздеуіміз керек. Нәтижесінде сынақтың қамтылуы әлдеқайда нашар. Бақытымызға орай, бақылау және журналдар түріндегі кері байланыстың басқа қабаты бар, бірақ бұл қазірдің өзінде бізден белсенді емес, реактивті әрекет етуді талап етеді, бұл ашуландырады және алаңдатады.
2. DE тұрғысынан әлем кәдімгі өнімді әзірлеушіге мүлдем ұқсамайды (әрине, оқырман олай емес және ол бәрін біледі, бірақ мен білмедім, енді мен бұрысамын. көтерілді). Әзірлеуші ретінде мен өз микросервисімді жасаймын, деректерді [сіздің таңдауыңыз бойынша дерекқорға] орналастырамын, сол жерде күйімді сақтаймын, идентификатор бойынша бірдеңе аламын және бәрі жақсы. Қызмет баяу, тапсырыстар шатастырады, бәрі осы. Олар менің күйімді басқа қызметтен іздеуімді сұрайды, сондықтан мен RabbitMQ-ге оқиға жіберемін, және солай. Міне, біз тағы да жоғарыда сипатталған оқиғалар мәселесіне оралдық.
Операциялық жұмыс үшін қызметке қажет нәрсе бізге тарихи деректерге сәйкес келмейді, сондықтан сервистік келісімшарттарды қайта өңдеу және әзірлеу топтарымен тығыз жұмыс жасау мәселесі басталады. Келісуге қанша сағат кеткенімізді елестете алмайсыз: ол біздің компанияда қандай оқиғаға негізделген.
3. Баспен ойлау керек. Жоқ, мен әзірлеушілер ойламайды дегенді білдірмеймін (бірақ мен барлығы үшін сөйлейтін кіммін), бұл жай ғана өнімді әзірлеуде сізде архитектураның қандай да бір түрі бар және сіз артта қалудан әртүрлі араласуларды алып тастайсыз. Әрине, бұл жоспарлауды және ойлануды қажет етеді, бірақ бұл ағынды жұмыс, мұнда негізгі мәселе оны жақсы және тиімді орындау болып табылады.
Біз үшін бұл оңай емес, өйткені әртүрлі жүйе құрамдастарын жылы және жайлы монолиттен жабайы микросервис джунгли әлеміне көшіру оңай емес. Қызмет оқиғаларды тарата бастағанда, жадты толтыру логикасын қайта қарау керек, себебі деректер енді басқаша көрінеді. Мұнда әзірлеуші ретінде емес, деректер инженері ретінде көп және мұқият ойлану керек. Сіз дәптер мен қаламмен немесе тақтада маркермен күн өткізсеңіз, бұл қалыпты оқиға. Бұл өте қиын, мен ойлағанды ұнатпаймын, мен де өндірісті жақсы көремін.
4. Мүмкін ең маңыздысы – ақпарат. Білім жетіспесе не істейміз? Стекверфласт деп кім айтты? Бұл адамды бөлмеден шығарыңыз. Біз құжаттарды, тақырып бойынша кітаптарды оқимыз, сонымен қатар форумдар, кездесулер мен конференциялар ұйымдастыратын қауымдастық бар. Құжаттама өте жақсы, бірақ, өкінішке орай, ол толық емес болуы мүмкін. Біз бірқатар жобаларда Cosmos DB пайдаланамыз. Осы өнімнің құжаттамасын оқуда сәттілік тілейміз. Кітаптар - жалғыз құтқару; бақытымызға орай, олар бар және табуға болады, оларда көптеген іргелі білім бар және сіз көп және үнемі оқуыңыз керек. Бірақ мәселе қоғамда.
Қазір біздің ауданда кем дегенде бір сәйкес конференция немесе кездесу табу қиын. Жоқ, әрине, Data сөзімен кездесулер өте көп, бірақ бұл сөздің жанында әдетте ML немесе AI сияқты біртүрлі аббревиатуралар бар. Сонымен, бұл біз үшін емес, біз нейрондарды қалай жағу емес, сақтау қоймаларын қалай салу туралы айтып отырмыз. Бұл хипстер барлығын басып алды. Соның салдарынан қоғамсыз қалдық. Айтпақшы, егер сіз деректер инженері болсаңыз және жақсы қауымдастықтарды білсеңіз, түсініктемелерде жазыңыз.
Жиналыс туралы қорытынды және хабарландыру
Біз немен бітеміз? Менің алғашқы тәжірибем маған деректер инженерінің орнында болу әрбір әзірлеушіге пайдалы болатынын айтады. Бұл жай ғана нәрселерге басқаша қарауға мүмкіндік береді және әзірлеушілердің деректеріне қалай қарайтынын көргенде, көзіміз қансырап кеткеніне таң қалмау керек. Сонымен, егер сіздің компанияңызда DE болса, осы жігіттермен сөйлесіңіз, сіз көптеген жаңа нәрселерді (өзіңіз туралы) үйренесіз.
Соңында, хабарландыру. Күндізгі уақытта біздің тақырып бойынша кездесулерді табу қиын болғандықтан, біз өзіміздің кездесуімізді жасауды шештік. Неліктен біз нашармыз? Бақытымызға орай, бізде керемет бар және біздің достарымыз , олар біз сияқты деректер инженерлерінің назардан әділетсіз айырылғанын сезінеді.
Осы мүмкіндікті пайдалана отырып, мен 27.02.2020 жылдың XNUMX ақпанында Dodo Pizza кеңсесінде өтетін «DE немесе DIE» атты келешегі зор атаулы қауымдастықтың алғашқы кездесуіне келуге ниет білдіргендердің барлығын шақырамын. Толығырақ мына жерде .
Егер бірдеңе болса, мен сонда боламын, сіз маған әзірлеушілер туралы қаншалықты қателескенімді айта аласыз.
Ақпарат көзі: www.habr.com