company_banner

Data Engineer or die: история одного разработчика

    В начале декабря я совершил роковую ошибку принял поворотное решение в своей жизни разработчика и перешёл в команду Data Engineering (DE) внутри компании. В статье я поделюсь некоторыми наблюдениями, которые я сделал за два месяца работы в команде DE.




    Почему 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.

    Если что, я там буду, сможете мне лично в лицо сказать, как я не прав насчёт разработчиков.
    Полезные ссылки:

    Dodo Engineering
    О том, как разработчики строят IT в Dodo

    Похожие публикации

    Комментарии 17

    • НЛО прилетело и опубликовало эту надпись здесь
        +1
        Сбежать? Опять писать мапперы? Да ну. Это шутка, конечно. Нет, совсем не хочется. Хочется разобраться, как правильно работать с данными. И еще хочется, чтобы то, что мы делаем, не было таким таинством для разработчиков. Так что тут большое поле для деятельности и познания.
        Какие направления развития? Я думаю, что эта область меня еще займет на долгое время, а там будет видно. Я пока только на спринт планироваться умею. В ближайшие две недели точно останусь в DE :)

        • НЛО прилетело и опубликовало эту надпись здесь
            +1

            по идее у DE самые широкие возможности приносить реальную пользу бизнесу (data driven бизнес и так далее), потому что чистые, правильные данные, на которые можно опираться и принимать управленческие решения стоят очень дорого и высоко ценятся.

            • НЛО прилетело и опубликовало эту надпись здесь
                0
                Все так думают, в том числе и ключевые бизнес-заказчики. А потом приходят с тупыми вопросами «а как это правильно интерпретировать?». Не знаю, как у Вас, но компания в которой я работаю (телеком) без красивых самопрезентаций — data driven company, ибо рынок суперконкурентный. И да, у нас DE/ETL-разработчики не на обочине, а в самом центре жизни компании)

                UPD: попробуйте сменить работодателя на того у кого данные имеют похожую ценность, думаю только так можно будет понять о чем я и автор говорили.
              0
              У вас же .net в профиле, а там автомаппер всё решает, одно удовольствие.

              Про мапперы я шутил, конечно. Хотя у нас в монолитном проекте достаточно много мапперов сделано вручную и на то была причина: у автомаппера были проблемы в свое время, он, если я не ошибаюсь, падал в рантайме иногда.

              Про цели и заказчика — очень хороший вопрос. Цель: интеграция данных компании в одном месте. Данных, которым можно доверять. В это понятие включается: очистка, полнота, разложение в удобном для последующей аналитики виде.
              Заказчиков у нас несколько. С одной стороны у нас есть большая система Dodo IS, в которой большое количество отчетов для наших партнеров. Это один наш заказчик. С другой стороны есть наша Управляющая Компания, есть команда BI, которым тоже нужна аналитика и ad-hoc запросы, это второй заказчик.

              Нужно определить понятие Data Engineering и сферу деятельности. Конкретно в нашей компании сейчас это такой зонтичный бренд, включающий в себя проектирование архитектуры хранилища, моделирование данных, пайплайны, совместную работу с командами разработки над сбором состояния их сервиса, а еще просто накопление экспертизы по работе различных (в том числе и OLTP) баз данных в целом.
              Конечно, если рассматривать DE как запускаторов ETL/ELT пайплайнов, то это довольно грустно. Но у нас, к счастью, есть много других задач.

              А что касается карьеры. Если быть предельно откровенным, то я сейчас в таком ключе про это не думаю, просто занимаюсь тем, что интересно на данный момент и полезно для компании, дальше будет видно :)
              Кстати, нельзя сказать, что мы больше не разрабатываем вообще. У нас есть свои внутренние сервисы, которые мы сами написали и поддерживаем.
                +1
                Как разработчик написавший не один маппер в Додо во времена монолита могу сказать, что просто не знал тогда об Automapper:) Это единственная причина по которой он не юзался. Кое где мы по-моему начали юзать его. Проблем у него особых не было на тот момент, 14-15 год.
                90 процентов классов там мапится один к одному, поэтому какие там проблемы то могут быть)
          0
          на наш первый митап сообщества
          Жаль, что не в Санкт-Петербурге. Было бы интересно.
            +1
            Мы планируем делать прямую трансляцию. Ссылочку на неё пришлём в день митапа в чат по DE. И потом планируем выложить запись.
              +1
              Лично мне интереснее вживую задавать вопросы и в кулуарах пообщаться, поэтому редко смотрю трансляции. Но Вам в любом случае спасибо за вариант.
                0
                Давай замутим в Питере, какая проблема =)
            +1
            Эх, жаль не смогу побывать на митапе. Сам недавно сделал такой же переход fullstack -> DE. С автором соглашусь, что действительно начинаешь смотреть на дизайн бекенда с другой стороны, ну и сразу учишься проектировать бд и внутренние структуру микросервисов с оглядкой на то, как это будет использовано в ETL/BI.
              +2
              Мы планируем сделать прямую трансляцию и выложить потом запись (ссылку на чат выше написала как раз). Ну и надеюсь это будет не последний митап по этой теме. :)
                +1
                Благодарю, обязательно посмотрю трансляцию.
              0
              Книги – это единственное спасение
              а можете пожалуйста список порекомендовать?
                +1
                Скорее могу порекомендовать подписку на O'Reilly :)
                Если серьезно, то часто приходится читать что-то под задачу или технологию, с которой работаешь. Например, здесь я открыл для себя Spark, с которым не работал ранее. Сейчас изучаю его в том числе по книге:
                • Spark: The Definitive Guide by Matei Zaharia, Bill Chambers


                Из материалов, не привязанных к конкретным технологиям или базам, я бы рекомендовал посмотреть на:
                • Designing Data-Intensive Applications by Martin Kleppmann
                • Building a Scalable Data Warehouse with Data Vault 2.0 by Daniel Linstedt, Michael Olschimke


                Вот еще, что успел полистать, мне понравилось и это в шорт-листе на чтение:
                • Database Internals by Alex Petrov
                • Designing Event-Driven Systems by Ben Stopford
                • Event Streams in Action by Alexander Dean, Valentin Crettaz


                И пара рекомендаций от коллег:
                • Data Architecture: A Primer for the Data Scientist, 2nd Edition by W.H. Inmon, Daniel Linstedt, Mary Levins
                • DAMA-DMBOK: Data Management Body of Knowledge (2nd Edition) by DAMA International


                Еще можно доклады со Strata Data Conference by O'Reilly посмотреть.

              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

              Самое читаемое