В началото на декември направих фатална грешка и направих повратна точка в живота си като разработчик и се преместих в екипа Data Engineering (DE) в компанията. В тази статия ще споделя някои наблюдения, които направих през двата месеца работа в екипа на DE.
Защо Data Engineering?
Пътуването ми до DE започна през лятото на 2019 г., когато ние Хайде да отидем до , и там постигнах просветление. Започнах да се интересувам от темата, да изучавам алгоритми и дори за тях , а след това помислих за обхвата на приложение и бързо разбрах, че практическото приложение в нашата компания са разпределените бази данни.
Какво точно прави нашият екип? Ние, като всички модерни момчета и момичета, искаме да станем компания, управлявана от данни. И за да стане това възможно, ние трябва поне да изградим надеждно хранилище, което може да се използва за създаване на отчети, от които компанията се нуждае. Но най-важното е, че данните в това хранилище трябва да се вярват. Освен това, използвайки тези данни, трябва да можете да възстановите състоянието на системата в момент t. Всичко това се усложнява от факта, че живеем в смел нов свят на микроуслуги и тази идеология предполага, че всяка услуга изпълнява собствена малка функционалност, нейната база данни е неин собствен бизнес и тя може да я изтрива поне всеки ден, но при в същото време трябва да можем да получаваме и обработваме състоянието на услугата.
Ако искате да бъдете управлявани от данни, първо станете управлявани от събития
Не толкова просто. Събитията са различни и разработчикът и инженерът на данни гледат на тях по различен начин. Говоренето за събития е тема за отделна статия, така че няма да се задълбочавам тук. Освен това вече има такава статия известен Мартин Фаулър, няма да му отнема лаврите, нека той също стане известен.
Като цяло има много за какво да се мисли и затова този район е привлекателен. Случи се така, че в нашата компания Data Engineer е много по-широка област на отговорност, отколкото просто човек, който пише ETL/ELT тръбопроводи (ако не знаете какво означават тези съкращения, елате на . Като контекстна реклама).
Ние се занимаваме с архитектура за съхранение, моделиране на данни, проблеми, свързани със сигурността на данните и самите тръбопроводи, разбира се. Също така трябва да се уверим, че от една страна нашето присъствие не е много обременяващо за разработчиците на продукти и те трябва да бъдат разсейвани възможно най-малко от нашите изисквания, когато внедряват нови функции в системата, а от друга страна, ние трябва да ги предоставите удобно разположени в данни за съхранение за анализатори и BI екип. Така си живеем.
Трудности при преход от развитие
В първия си работен ден се сблъсках с редица трудности, които искам да споделя с вас.
1. Първото нещо, което видях, беше липсата на тулинг и някои практики. Вземете например покритието на кода с тестове. Имаме стотици рамки за тестване в процес на разработка. При работа с данни всичко е по-сложно. Да, можем да тестваме ETL конвейери върху тестови данни, но трябва да го направим ръчно и да търсим решения за всеки конкретен случай. В резултат на това покритието на теста е много по-лошо. За щастие има друг слой обратна връзка под формата на мониторинг и регистрационни файлове, но това вече изисква от нас да реагираме реактивно, а не проактивно, което е вбесяващо и изнервящо.
2. Светът от гледна точка на DE изобщо не е такъв, какъвто изглежда на обикновен разработчик на продукти (е, разбира се, читателят не е такъв и той вече знае всичко, но аз не знаех и сега съм прецаквам го). Като разработчик създавам своя собствена микроуслуга, поставям данните в [база данни по ваш избор], запазвам състоянието си там, получавам нещо по ID и всичко е наред. Обслужването е бавно, поръчките са объркващи, това е всичко. Те ме молят да потърся състоянието си в друга услуга, така че ще пусна събитие в някой RabbitMQ и това е. И тук отново се върнахме към въпроса за събитията, описани по-горе.
Това, от което услугата се нуждае за оперативна работа, не ни подхожда за исторически данни, така че започва въпросът за преработка на договорите за услуги и тясна работа с екипи за разработка. Дори не можете да си представите колко часа ни отне да се съгласим: какъв Event Driven е той в нашата компания.
3. Трябва да мислите с главата си. Не, нямам предвид, че разработчиците не мислят (въпреки че кой съм аз, за да говоря от името на всички), просто при разработването на продукти много често вече имате някакъв вид архитектура и изрязвате различни размествания от изоставането. Разбира се, това изисква планиране и обмисляне, но това е поточна работа, където основният проблем е просто да се направи добре и ефективно.
За нас това не е толкова просто, защото прехвърлянето на различни системни компоненти от топъл и уютен монолит в света на дивата микросервизна джунгла не е толкова просто. Когато услугата започне да бълва събития, трябва да преразгледате логиката за попълване на хранилището, защото данните вече изглеждат различно. Тук трябва да мислите много и задълбочено, вече не като разработчик, а като инженер по данни. Това е нормална история, когато прекарвате дни с тетрадка и химикал или с маркер на дъската. Много е трудно, не обичам да мисля, обичам и продукцията.
4. Може би най-важното е информацията. Какво правим, когато ни липсват знания? Кой каза stackoverflow? Изведете този човек от стаята. Отиваме да четем документи, книги по темата, а също така има общност, която организира форуми, срещи и конференции. Документацията е страхотна, но за съжаление може да е непълна. Използваме Cosmos DB в редица проекти. Успех в четенето на документацията за този продукт. Книгите са единственото спасение, за щастие ги има и се намират, съдържат много фундаментални знания и трябва да се чете много и постоянно. Но проблемът е в общността.
Сега е трудно да се намери поне една адекватна конференция или среща в нашата област. Не, разбира се, има много срещи с думата Data, но до тази дума обикновено има странни съкращения като ML или AI. Така че това не е за нас, ние говорим как да строим складове, а не как да се мажем с неврони. Тези хипстъри са превзели всичко. В резултат оставаме без общност. Между другото, ако сте Data Engineer и познавате добри общности, моля, пишете в коментарите.
Заключения и обявяване на срещата
Какво получаваме в крайна сметка? Първият ми опит ми казва, че усещането в обувките на инженер по данни ще бъде полезно за всеки разработчик. Просто ни позволява да гледаме на нещата по различен начин и да не се изненадваме, когато очите ни се напълнят с кръв, когато видим как разработчиците третират данните си. Така че, ако във вашата компания има DE, просто говорете с тези момчета, ще научите много нови неща (за себе си).
И накрая, съобщението. Тъй като е трудно да се намерят срещи по нашата тема през деня, решихме да направим наши собствени. Защо сме по-лоши? За щастие имаме невероятно и нашите приятели от , които като нас смятат, че инженерите на данни са несправедливо лишени от внимание.
Възползвайки се от възможността, каня всички желаещи да дойдат на първата ни общностна среща с обещаващото заглавие „DE or DIE“, която ще се проведе на 27.02.2020 февруари XNUMX г. в офиса на Dodo Pizza. Подробности на .
Ако нещо се случи, ще бъда там, можете да ми кажете лично в очите колко греша за разработчиците.
Източник: www.habr.com