В начале декабря я совершил роковую ошибку принял поворотное решение в своей жизни разработчика и перешёл в команду Data Engineering (DE) внутри компании. В статье я поделюсь некоторыми наблюдениями, которые я сделал за два месяца работы в команде DE.
Мой путь в DE начался летом 2019 года, когда мы с Xneg поехали на Школу по распределёнными вычислениям, и там я достиг просветления. Начал интересоваться темой, изучать алгоритмы и даже про них писать, а после задумался об области применения и быстро выяснил, что практическое применение в нашей компании – это распределённые базы данных.
Чем же вообще занимается наша команда? Мы, как и все модные пацаны и девчонки, хотим стать Data Driven Company. А для того, чтобы это стало возможным, нам нужно как минимум построить надёжное хранилище, по которому можно будет строить любые отчеты, необходимые компании. Но самое главное – данным в этом хранилище должны доверять. Более того, по этим данным нужно уметь восстанавливать состояние системы на момент времени t. Всё это осложняется тем, что мы же живём в дивном новом мире микросервисов, а эта идеология подразумевает, что каждый сервис реализует свою маленькую функциональность, его база данных – его личное дело, и он может удалять её хоть каждый день, но при этом мы должны уметь получать и обрабатывать состояние сервиса.
Не всё так просто. 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, просто пообщайтесь с этими ребятами, узнаете много нового (о себе).
И, наконец, анонс. Так как митапов по нашей теме днём с огнем не сыскать, то мы решили сделать свой. А что, чем мы хуже? К счастью, у нас есть удивительная Schvepsss и наши друзья из New Professions Lab, которым, как и нам, кажется, что дата инженеры несправедливо обделены вниманием.
Пользуясь случаем, приглашаю всех неравнодушных приходить на наш первый митап сообщества с многообещающим названием «DE or DIE», который состоится 27.02.2020 в офисе компании Dodo Pizza. Подробности на TimePad.
Если что, я там буду, сможете мне лично в лицо сказать, как я не прав насчёт разработчиков.
Почему Data Engineering?
Мой путь в DE начался летом 2019 года, когда мы с Xneg поехали на Школу по распределёнными вычислениям, и там я достиг просветления. Начал интересоваться темой, изучать алгоритмы и даже про них писать, а после задумался об области применения и быстро выяснил, что практическое применение в нашей компании – это распределённые базы данных.
Чем же вообще занимается наша команда? Мы, как и все модные пацаны и девчонки, хотим стать 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, просто пообщайтесь с этими ребятами, узнаете много нового (о себе).
И, наконец, анонс. Так как митапов по нашей теме днём с огнем не сыскать, то мы решили сделать свой. А что, чем мы хуже? К счастью, у нас есть удивительная Schvepsss и наши друзья из New Professions Lab, которым, как и нам, кажется, что дата инженеры несправедливо обделены вниманием.
Пользуясь случаем, приглашаю всех неравнодушных приходить на наш первый митап сообщества с многообещающим названием «DE or DIE», который состоится 27.02.2020 в офисе компании Dodo Pizza. Подробности на TimePad.
Если что, я там буду, сможете мне лично в лицо сказать, как я не прав насчёт разработчиков.
somebody4
Сбежать из DE не хочется? Какие направления развития видятся из DE?
Ceridan Автор
Сбежать? Опять писать мапперы? Да ну. Это шутка, конечно. Нет, совсем не хочется. Хочется разобраться, как правильно работать с данными. И еще хочется, чтобы то, что мы делаем, не было таким таинством для разработчиков. Так что тут большое поле для деятельности и познания.
Какие направления развития? Я думаю, что эта область меня еще займет на долгое время, а там будет видно. Я пока только на спринт планироваться умею. В ближайшие две недели точно останусь в DE :)
somebody4
Оно конечно интересно пару месяцев ETL позаниматься для общего развития, но в долгосрочной перспективе быть в команде которая на обочине бизнеса, как мне кажется это для карьеры не очень. Хотя если всё настроено и само летает, то времени будет много оставаться и это плюс. Тем более процессы в ETL мире обычно не очень быстрые, запустил на исполнение и можно полчаса чай пить.
somurzakov
по идее у DE самые широкие возможности приносить реальную пользу бизнесу (data driven бизнес и так далее), потому что чистые, правильные данные, на которые можно опираться и принимать управленческие решения стоят очень дорого и высоко ценятся.
somebody4
Пользу бизнесу не данные приносят, а анализ этих данных, отчёты или предсказания на их основе. Не данные сами по себе. Поэтому DE, хоть и важная, но достаточно второстепенная роль.
McKinseyBA
Все так думают, в том числе и ключевые бизнес-заказчики. А потом приходят с тупыми вопросами «а как это правильно интерпретировать?». Не знаю, как у Вас, но компания в которой я работаю (телеком) без красивых презентаций по факту — data driven company ибо рынок суперконкурентный. И да, у нас DE/ETL-разработчики не на обочине, а в самом центре жизни компании)
UPD: попробуйте сменить работодателя на того у кого данные имеют похожую ценность, думаю только так можно будет понять о чем я и автор говорили.
Ceridan Автор
Про мапперы я шутил, конечно. Хотя у нас в монолитном проекте достаточно много мапперов сделано вручную и на то была причина: у автомаппера были проблемы в свое время, он, если я не ошибаюсь, падал в рантайме иногда.
Про цели и заказчика — очень хороший вопрос. Цель: интеграция данных компании в одном месте. Данных, которым можно доверять. В это понятие включается: очистка, полнота, разложение в удобном для последующей аналитики виде.
Заказчиков у нас несколько. С одной стороны у нас есть большая система Dodo IS, в которой большое количество отчетов для наших партнеров. Это один наш заказчик. С другой стороны есть наша Управляющая Компания, есть команда BI, которым тоже нужна аналитика и ad-hoc запросы, это второй заказчик.
Нужно определить понятие Data Engineering и сферу деятельности. Конкретно в нашей компании сейчас это такой зонтичный бренд, включающий в себя проектирование архитектуры хранилища, моделирование данных, пайплайны, совместную работу с командами разработки над сбором состояния их сервиса, а еще просто накопление экспертизы по работе различных (в том числе и OLTP) баз данных в целом.
Конечно, если рассматривать DE как запускаторов ETL/ELT пайплайнов, то это довольно грустно. Но у нас, к счастью, есть много других задач.
А что касается карьеры. Если быть предельно откровенным, то я сейчас в таком ключе про это не думаю, просто занимаюсь тем, что интересно на данный момент и полезно для компании, дальше будет видно :)
Кстати, нельзя сказать, что мы больше не разрабатываем вообще. У нас есть свои внутренние сервисы, которые мы сами написали и поддерживаем.
Sm1le291
Как разработчик написавший не один маппер в Додо во времена монолита могу сказать, что просто не знал тогда об Automapper:) Это единственная причина по которой он не юзался. Кое где мы по-моему начали юзать его. Проблем у него особых не было на тот момент, 14-15 год.
90 процентов классов там мапится один к одному, поэтому какие там проблемы то могут быть)