В начале декабря я совершил роковую ошибку принял поворотное решение в своей жизни разработчика и перешёл в команду 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.
Если что, я там буду, сможете мне лично в лицо сказать, как я не прав насчёт разработчиков.
Полезные ссылки:
