На початку грудня я припустився фатальної помилки прийняв поворотне рішення у своєму житті розробника і перейшов у команду Data Engineering (DE) всередині компанії. У статті я поділюся деякими спостереженнями, які зробив за два місяці роботи в команді DE.
Чому Data Engineering?
Мій шлях у DE почався влітку 2019 року, коли ми з поїхали на і там я досяг просвітлення. Почав цікавитись темою, вивчати алгоритми і навіть про них , а потім задумався про сферу застосування і швидко з'ясував, що практичне застосування в нашій компанії – це розподілені бази даних.
Чим взагалі займається наша команда? Ми, як і всі модні пацани та дівчата, хочемо стати Data Driven Company. А для того, щоб це стало можливим, нам потрібно як мінімум побудувати надійне сховище, яким можна буде будувати будь-які звіти, необхідні компанії. Але найголовніше – даним у цьому сховищі мають довіряти. Більше того, за цими даними потрібно вміти відновлювати стан системи на момент часу t. Все це ускладнюється тим, що ми живемо в чудовому новому світі мікросервісів, а ця ідеологія передбачає, що кожен сервіс реалізує свою маленьку функціональність, його база даних – його особиста справа, і він може видаляти її хоч щодня, але при цьому ми повинні вміти отримувати та обробляти стан сервісу.
Хочеш бути Data Driven, для початку стань Event Driven
Не все так просто. Event'и бувають різні, і дивляться на них розробник та дата інженер по-різному. Розмова про event'и – тема окремої статті, тому тут я в неї не заглиблюватимуся. До того ж, таку статтю вже хтось Мартін Фаулер, не відбиратиму у нього лаври, нехай теж стане відомим.
Загалом тут є над чим подумати і тим приваблива ця область. Так вийшло, що в нашій компанії Data Engineer – це набагато ширша зона відповідальності, ніж просто людина, яка пише ETL/ELT пайплайни (якщо ви не знаєте, що означають ці абревіатури – приходьте на . На правах контекстної реклами).
Ми займаємося і архітектурою побудови сховища, і моделюванням даних, і питаннями, пов'язаними з безпекою даних, і пайплайнами, зрозуміло. А ще нам потрібно зробити так, щоб, з одного боку, продуктовим розробникам була не дуже обтяжлива наша присутність і їм якнайменше доводилося відволікатися на наші вимоги при впилюванні нових фіч в систему, а з іншого боку, нам потрібно надати зручно розкладені в сховище дані для аналітиків та команди BI. Так і живемо.
Труднощі під час переходу з розробки
Першого дня своєї роботи я зіткнувся з низкою труднощів, якими хочу поділитися з вами.
1. Перше, що я побачив, це відсутність тулінгу та деяких практик. Взяти, наприклад, покриття коду тестами. У розробці у нас є стопіцот фреймворків для тестування. Працюючи з даними все складніше. Так, ми можемо тестувати ETL-пайплайни на тестових даних, але все це доводиться робити руками і шукати рішення під кожен конкретний випадок. Як наслідок, покриття тестами набагато гірше. Благо, є ще один шар зворотного зв'язку у вигляді моніторингу та логів, але це вже вимагає від нас реактивного, а не проактивного реагування, що бісить нервує.
2. Світ з позиції DE, зовсім не такий, яким він здається звичайному продуктовому розробнику (ну зрозуміло читач не такий, і він усе вже й так знає, а я не знав і тепер пограбую). Як розробник пилю я свій мікросервіс, поклав дані в [database of your choice], зберіг там свій стан, дістав щось по ID'шке і нормально. Сервіс крутиться, замовлення каламутяться, ось це все. Просять мене в іншому сервісі мій стан пошарити, ну я event закину в якийсь RabbitMQ і все. І ось тут ми знову повернулися до питання event'ів, описаного вище.
Те, що потрібне сервісу для оперативної роботи не підходить нам для історичних даних, починається питання переробки контрактів сервісу і щільна робота з командами розробки. Ви навіть уявити не можете, скільки у нас пішло годин на те, щоб домовитися: а який він цей Event Driven в нашій компанії.
3. Потрібно думати головою. Ні, я ні до того, що розробники не думають (хоча хто я такий, щоб за всіх говорити), просто в продуктовій розробці дуже часто в тебе вже є якась архітектура, і ти пиляєш різні тасочки з беклогу. Зрозуміло це вимагає планування та роздуми, але це потокова робота, де основна проблема просто добре та якісно зробити.
У нас же не так просто тому, що переклад різних компонентів системи з теплого та затишного моноліту у світ диких мікросервісних джунглів не такий простий. Коли сервіс починає сипати event'ами, потрібно переглядати логіку наповнення сховища, тому що дані тепер виглядають по-іншому. Ось тут треба багато і ґрунтовно думати, вже не як розробник, а як інженер даних. Нормальна історія, коли ти днями проводиш із зошитом та ручкою або з маркером біля дошки. Це дуже складно, не люблю думати, люблю фігак-фігак і продакшен.
4. Мабуть, найважливіше – це інформація. Що ми робимо, коли нам бракує знань? Хто сказав stackoverflow? Виведіть цю людину із зали. Ми йдемо читати доку, книги на тему, а ще є спільнота, яка організовує форуми, мітапи та конференції. Документація – це класно, але, на жаль, вона неповна. Ми ось у низці проектів використовуємо Cosmos DB. Успіхів вам з читанням документації по цьому продукту. Книги – це єдиний порятунок, на щастя, вони існують і їх можна знайти, багато фундаментальних знань і доводиться читати багато і постійно. А от із ком'юніті біда.
Зараз у нашому напрямку важко знайти хоча б одну адекватну конференцію чи мітап. Ні, звичайно, мітапів зі словом Data дуже багато, але поруч із цим словом зазвичай виявляються дивні абревіатури типу ML або AI. Так от, це не до нас, ми про те, як будувати сховища, а не як обмазуватися нейронками. Ці хіпстери заполонили все. У результаті ми без ком'юніті. До речі, якщо ви Data Engineer і знаєте гарні спільноти, напишіть, будь ласка, у коментарях.
Висновки та анонс мітапу
Що маємо у результаті? Мій перший досвід підказує мені, що відчути себе в шкурі дата інженера буде корисна для кожного розробника. Це просто дозволяє по-іншому дивитися на речі і не дивуватися, коли у нас наливаються кров'ю очі, побачивши, як розробники звертаються зі своїми даними. Так що, якщо у вашій компанії є DE, просто поспілкуйтеся з цими хлопцями, дізнаєтесь багато нового (про себе).
І, зрештою, анонс. Оскільки митапов на нашу тему вдень з вогнем не знайти, ми вирішили зробити свій. А що, чим ми гірші? На щастя, у нас є дивовижна і наші друзі з , Яким, як і нам, здається, що дата інженери несправедливо обділені увагою.
Користуючись нагодою, запрошую всіх небайдужих приходити на наш перший мітап спільноти з перспективною назвою «DE or DIE», що відбудеться 27.02.2020 в офісі компанії Dodo Pizza. Подробиці на .
Якщо що, я там буду, зможете мені особисто в обличчя сказати, як я не прав щодо розробників.
Джерело: habr.com