Нужен ли вашей команде Data Engineer?

Мы часто находим классные англоязычные статьи, которые кажутся полезными нашей команде, и решили, что было бы здорово делиться с читателями Хабры их переводом. Сегодня мы подготовили перевод статьи Тристана Хэнди, основателя компании Fishtown Analytics.

Роль дата-инженера в современных стартапах быстро меняется. Вы уверены, что хорошо понимаете, когда и зачем вашей команде может быть нужен такой специалист?

Я часто общаюсь с ведущими представителями мира аналитики и замечаю, что их понимание роли дата-инженера в команде не соответствует действительности. Это может создавать трудности для всей команды анализа данных, и мне хотелось бы, чтобы компании научились избегать подобных проблем.

В этой статье я хочу поделиться своими идеями о том когда, как и для чего стоит нанимать дата-инженера. Мои рассуждения основаны на опыте работы в Fishtown Analytics, где я работал с более чем сотней стартапов с поддержкой венчурного капитала и помогал им строить команды анализа и обработки данных, а также на знаниях, полученных в ходе общения с представителями различных компаний по обработке данных.

Если вы возглавляете команду специалистов по данным, этот пост – для вас.

Роль дата-инженера меняется

Современное ПО позволяет все больше автоматизировать скучную работу, связанную с анализом и обработкой данных.

В 2012 году для анализа всего массива данных в венчурно профинансированном стартапе требовался минимум один дата-инженер. Такой специалист должен был извлекать данные из разных систем, чтобы дальше с ними могли работать аналитики и корпоративные клиенты. Часто нужно было каким-то образом преобразовывать данные, чтобы их проще было анализировать. Без дата-инженера у специалистов по анализу и обработке данных просто не было бы данных, с которыми они могли бы работать, поэтому часто именно с дата-инженера начиналось формирование команды.

К 2019 году большую часть из этого можно осуществить с помощью готовых решений. В большинстве случаев вы с командой аналитиков можете построить пайплайн обработки данных самостоятельно, без помощи человека с огромным опытом в data science. И этот пайплайн вовсе не будет плохим – современные готовые инструменты прекрасно подходят решения таких задач.

Возможность самим строить пайплайны появилась у аналитиков и data scientists недавно – всего 2–3 года назад. Это произошло в основном благодаря трем продуктам: Stitch, Fivetran и dbt (стоит сказать, что dbt – это продукт моей компании, Fishtown Analytics). Они были выпущены почти сразу после Amazon Redshift, когда команды аналитиков в стартапах поняли, что им нужно создавать хранилища данных. Ушло еще несколько лет на то, чтобы сделать эти продукты качественными, – в 2016 году мы все еще были первопроходцами.

Сейчас пайплайн, построенный с использованием Stitch, Fivetran или dbt, гораздо надежнее того, что разработан специально с использованием Airflow. Я знаю это не из теории, а из собственного опыта. Я не говорю, что невозможно построить надежную инфраструктуру с Airflow, просто большинство стартапов так не делают. В Fishtown Analytics мы работали более чем с сотней команд аналитиков в разных стартапах, и этот сценарий повторялся много раз. Мы постоянно помогаем людям перейти с собственных пайплайнов на готовые решения, и каждый раз эффект оказывается положительным.

Инженер данных не должен писать ETL

В 2016 году Джеф Магнуссон написал фундаментальный пост «Инженеры данных не должны писать ETL». Это был первый пост на моей памяти, который призывал к таким изменениям. Вот моя любимая часть оттуда:

*«За последние 5 лет инструменты и технологии обработки данных эволюционировали. Большинство технологий получили уже такое развитие, что могут подстроиться под ваши потребности, если, конечно, вам не нужно обрабатывать петабайты данных или миллиарды событий в день.

Если вам не нужно выходить за рамки возможностей этих технологий, вам, скорее всего, не нужна команда узкоспециализированных программистов, чтобы разрабатывать дополнительные решения.

Если вам удастся нанять их, им вскоре станет скучно. Если им станет скучно, они уйдут от вас в Google, Facebook, LinkedIn, Twitter – места, где их опыт действительно необходим. Если им не скучно, скорее всего, они довольно посредственны. А посредственные программисты действительно преуспели в построении огромного количества сложной, непригодной для нормальной работы ерунды, которую они называют “решениями”».*

Мне очень нравится эта цитата, потому что она не только подчеркивает, что сегодня вам не нужны дата-инженеры для решения большинства проблем ETL, но и объясняет, почему вам лучше не просить их решать эти проблемы вообще.

Если вы наймете дата-инженеров и попросите их построить пайплайн, они подумают, что их задача – строить пайплайны. Это будет означать, что такие инструменты, как Stitch, Fivetran и dbt, будут для них угрозой, а не мощным источником силы. Они найдут причины, почему готовые пайплайны не соотвуют вашим индивидуальным потребностям в работе с данными и почему аналитики не должны самостоятельно заниматься преобразованием данных. Они напишут код, который будет хрупким, сложным в обслуживании и неэффективным. И вы будете полагаться на этот код, потому что он лежит в основе всего остального, что делает ваша команда.

Бегите от таких специалистов, как от чумы. Темпы роста в вашей команде аналитиков резко снизятся, и все свое время вы будете тратить на решение проблем инфраструктуры, а ведь это совсем не то, что приносит доход вашему бизнесу.

Если не ETL, тогда что?

Так нужен ли дата-инженер вашей команде? Да.

Даже при наличии новых инструментов, которые позволяют аналитикам данных и специалистам по data science самим создавать пайплайны, дата-инженеры по-прежнему являются важной частью любой профессиональной команды специалистов по данным. Однако изменились задачи, над которыми им следует работать, и последовательность, в которой стоит нанимать сотрудников для работы с данными. Ниже я расскажу о том, когда это делать, а сейчас давайте поговорим о том, за что отвечают дата-инженеры в современных стартапах.

Дата-инженеры по-прежнему являются важной частью любой профессиональной команды специалистов по данным.

Ваши дата-инженеры не должны создавать пайплайны, для которых уже есть готовые решения, и писать SQL-преобразования данных. Вот на чем им следует сфокусироваться:

• организация и оптимизация базовой инфраструктуры данных,
• построение и поддержка кастомных пайплайнов,
• поддержка команды специалистов по данным путем улучшения дизайна и производительности пайплайнов и запросов,
• построение не-SQL преобразований данных.

Организация и оптимизация базовой инфраструктуры данных

Хоть дата-инженерам в стартапах больше и не нужно управлять кластерами Hadoop или настраивать оборудование для Vertica, в этой области все еще требуется работа. Убедившись, что ваша технология сбора, передачи и обработки данных работает на пике своих возможностей, вы получаете значительное улучшение показателей производительности, затрат или и того и другого сразу. Обычно это подразумевает следующие задачи:

• создание инфраструктуры мониторинга, позволяющей отслеживать статус пайплайнов,
• мониторинг всех задач, влияющих на производительность кластера,
• регулярное техническое обслуживание,
• настройка схем таблиц (партиционирование, компрессия, дистрибуция) для минимизации затрат и увеличения производительности,
• разработка кастомной инфраструктуры данных, когда нет готовых решений.

Эти задачи часто упускают из виду на ранних стадиях развития, но они становятся критически важными по мере роста команды и объема данных. В одном проекте нам удалось постепенно сократить затраты на построение таблицы в BigQuery с 500 долларов до 1 доллара в день за счет оптимизации разделов таблицы. Это на самом деле важно.

Uber – хороший пример компании, которая в этом преуспела. Специалисты по обработке данных в Uber создали инструмент под названием Queryparser, который автоматически отслеживает все запросы к их инфраструктуре данных и собирает статистику об используемых ресурсах и моделях использования. Инженеры Uber Data могут использовать метаданные для соответствующей настройки инфраструктуры.

Дата-инженеры также часто отвечают за построение и обслуживание пайплайна CI / CD, который управляет инфраструктурой данных. В 2012 году у многих компаний была очень слабая инфраструктура для контроля версий, управления и тестирования, но сейчас все меняется, и за этим стоят именно дата-инженеры.

Наконец, дата-инженеры в ведущих компаниях нередко участвуют в создании инструментов, которых не существует в готовом виде. Например, инженеры Airbnb создали Airflow, потому что у них не было способа эффективно генерировать орграфы обработки данных. А инженеры Netflix отвечают за создание и поддержку сложной инфраструктуры для разработки и эксплуатации десятков тысяч Jupyter Notebooks.

Вы можете просто купить большую часть своей базовой инфраструктуры, но кто-то все равно должен ее обслуживать. И если вы действительно прогрессивная компания, вы, вероятно, захотите расширить возможности существующих инструментов. Инженеры данных могут помочь и с тем, и с другим.

Построение и поддержка кастомных пайплайнов

Хотя дата-инженерам больше не нужно вручную переносить данные в Postgres или Salesforce, у поставщиков имеется в наличии «всего» около 100 вариантов интеграции. Большинство наших клиентов могут сразу же охватить от 75 до 90 % источников данных, с которыми они работают.

На практике интеграция осуществляется волнами. Как правило, первый этап включает в себя основную базу данных приложения и отслеживание событий, а второй этап – маркетинговые системы, такие как ESP, и рекламные платформы. На сегодняшний день готовые решения для обоих этапов уже доступны в продаже. Когда вы углубитесь в работу с данными от вендоров SaaS в вашей предметной области, вам понадобятся дата-инженеры, чтобы строить и поддерживать эти более нишевые пайплайны обработки данных.

Например, компании, занимающиеся продажами через интернет, взаимодействуют с массой различных продуктов в области ERP, логистики и доставки. Многие из этих продуктов очень специфичны и почти ни один из них не доступен в продаже. Ждите от ваших дата-инженеров, что они создадут подобные продукты в обозримом будущем.

Построение и обслуживание надежных пайплайнов обработки данных – сложная задача. Если вы решите вложить свои ресурсы в их создание, будьте готовы, что на это понадобится больше средств, чем изначально предусматривалось в бюджете, а обслуживание тоже потребует больше усилий, чем вы планировали. Первую версию пайплайна построить просто, но сложно сделать так, чтобы он поддерживал консистентность данных в вашем хранилище. Не берите на себя обязательства по поддержанию собственного пайплайна обработки данных, пока не убедитесь, что ваш бизнес работает. Как только вы это сделаете, потратьте время на то, чтобы сделать его надежным. Подумайте об использовании Singer, фреймворка с открытым исходным кодом от создателей Stitch, – мы построили около 20 интеграций при помощи него.

Поддержка команды специалистов по данным путем улучшения дизайна и производительности пайплайнов и запросов

Одно из изменений, которые мы наблюдаем в сфере data engineering за последние пять лет, это появление ELT – нового варианта ETL, который преобразует данные после их загрузки в хранилище, а не до того. Суть и причины такого изменения уже хорошо освещены в других источниках. Я же хочу подчеркнуть, что этот сдвиг оказывает огромное влияние на то, кто строит эти пайплайны.

Если вы пишете код на Scalding для сканирования терабайтов данных событий в S3 с последующей загрузкой в Vertica, вам, вероятно, понадобится дата-инженер. Но если ваши данные о событиях (экспортированные из Google Analytics 360) уже находятся в BigQuery, значит, они уже полностью доступны в высокопроизводительной, масштабируемой среде. Разница в том, что эта среда «разговаривает» на SQL. Это означает, что аналитики теперь могут создавать свои собственные пайплайны преобразования данных.

Эта тенденция получила развитие в 2014 году, когда Looker выпустил инструмент PDT. Тренд усилился, когда целые команды специалистов по данным стали строить орграфы обработки данных из 500+ узлов и обрабатывать большие наборы данных с использованием dbt в течение последних двух лет. На этом этапе модель глубоко укоренилась в современных командах и дала аналитикам столько самостоятельности, как никогда раньше.

Переход на ELT означает, что дата-инженерам уже не нужно выполнять большинство задач по преобразованию данных. Это также означает, что команды без инженеров могут пройти долгий путь, используя инструменты преобразования данных, созданные для аналитиков. Однако дата-инженеры все еще играют важную роль в построении пайплайнов преобразования данных. Есть две ситуации, когда их их участие крайне важно:

1. Когда необходимо повысить производительность

Иногда логика бизнес-процесса требует какого-то особенно сложного преобразования, и полезно привлечь дата-инженера, чтобы он оценил, как конкретный подход к созданию таблицы влияет на производительность. Многие аналитики не имеют большого опыта оптимизации производительности в аналитических хранилищах данных, и это отличный повод начать сотрудничать с более узким специалистом.

2. Когда код становится слишком сложны

Аналитики отлично умеют решать бизнес-задачи с использованием данных, но часто не задумываются, как писать расширяемый код. Начать строить таблицы в базе данных на первый взгляд несложно, но все может быстро выйти из-под контроля. Привлеките к работе дата-инженера, который сможет продумать общую архитектуру вашего хранилища и разработать особенно сложные преобразования, иначе вы рискуете оказаться один на один с клубком, который будет практически невозможно распутать.

Построение не-SQL преобразований данных

SQL изначально может удовлетворить большинство потребностей в преобразовании данных, но он не может решить всех проблем. Например, часто бывает нужно добавить в базу гео-данные взяв широту и долготу и привязав их к определенному региону. Многие современные аналитические хранилища пока не могут решить такую задачу (хотя и это начинает меняться!), поэтому лучшим решением может стать построение пайплайна на Python, который дополнит данные в вашем хранилище информацией о регионе.

Другой очевидный случай использования Python (или других языков, отличных от SQL) – для машинного обучения. Если у вас есть персональные рекомендации продуктов, модель прогноза спроса или алгоритм прогнозирования оттока, который берет данные из вашего хранилища и расставляет веса, вы можете добавить их как конечные узлы вашего орграфа SQL-обработки данных.

Большинство современных компаний, которые решают такие задачи с помощью не-SQL, используют Airflow. dbt используется для основанной на SQL части орграфа обработки данных, а в качестве листьев добавляются не-SQL узлы. Этот подход берет лучшее из обоих подходов – аналитики данных все еще могут нести основную ответственность за преобразования на основе SQL, а инженеры данных могут отвечать за ML-код для промышленной эксплуатации.

Когда вашей команде нужен дата-инженер?

Изменение роли дата-инженера также подразумевает переосмысление последовательности найма сотрудников. Ранее считалось, что в первую очередь вам нужны дата-инженеры, потому что аналитикам и специалистам data science не с чем работать без готовой платформы обработки и анализа данных. Сегодня специалисты по анализу и обработке данных могут работать самостоятельно и создавать первую версию инфраструктуры данных с помощью готовых инструментов. Подумайте о найме дата-инженера, когда у вашего стартапа появится какой-либо из 4 признаков масштаба:

1. в вашей команде 3 аналитика / специалиста data science,
2. у вашей BI платформы есть 50 активных пользователей,
3. самая большая таблица в вашем хранилище достигает 1 миллиарда строк,
4. вы знаете, что вам необходимо построить 3 или более кастомных пайплайна обработки данных в течение следующих нескольких кварталов, и все они критически важны.

Если вы еще не столкнулись ни с одной из этих ситуаций, ваша команда специалистов по данным, вероятно, может работать самостоятельно, используя готовые технологии, поддержку внешних консультантов и советы коллег (например, в сообществах Locally Optimistic или dbt в Slack).

Главное, что нужно понимать, – дата-инженер сам по себе не имеет ценности для бизнеса, его главная работа – повысить продуктивность ваших аналитиков. Ваша команда специалистов по данным взаимодействует с заинтересованными сторонами, измеряет KPI и создает отчеты и модели – именно они помогают вашему бизнесу двигаться в правильном направлении каждый день. Нанимайте дата-инженера для усиления уже существующей, большой команды: если после того, как вы наняли дата-инженера, эффективность четырех ваших аналитиков повысилась на 33 %, это, скорее всего, было хорошее решение.

Инженеры по обработке данных приносят пользу бизнесу, помогая вашим аналитикам и data scientist-ам быть более продуктивными.

На мой взгляд, если вы решили расширить свою команду специалистов по данным, наилучшее соотношение – приблизительно 5 к 1: пять аналитиков / специалистов data science на одного дата-инженера. Если вы работаете с особенно большими или необычными наборами данных, возможно, это соотношение изменится, но это хороший ориентир.

Кого стоит нанимать?

По мере изменения роли дата-инженера меняются и требования к идеальному кандидату. Мой уважаемый коллега Майкл Камински очень хорошо сказал об этом в нашей переписке на эту тему, поэтому я процитирую его здесь:

«Я думаю обо всех этих переменах, в первую очередь, о роли дата-инженера в команде. Из создателя инфраструктуры он превратился в поддерживающее звено для более широкой группы специалистов. Это значительное изменение, и некоторые дата-инженеры (которые хотели бы сосредоточиться на создании инфраструктуры) не всегда этому рады.
Я думаю, самое важное для стартапов – нанять дата-инженера, который полон сил и желания создавать инструменты для команды аналитиков / специалистов data science. Если вы нанимаете дата-инженера, который просто хочет копаться в бэкенде и ненавидит работать с людьми, у которых меньше технических навыков, скорее всего, это плохо кончится. Я ищу дата-инженеров, которые рады сотрудничать с аналитиками и исследователями и готовы сказать: “То, что вы делаете, кажется мне абсолютно неэффективным, и я хочу изменить ситуацию к лучшему”».

Я полность согласен с Майклом. Сейчас лучшие дата-инженеры в стартапах – это опора и поддержка команды, они участвуют почти во всем, что делает команда по работе с данными. Им должна нравиться совместная работа и они должны быть замотивированы на достижение успеха всей командой.

Если вы дошли до этого места, спасибо, что прочитали :) Эта тема правда очень меня волнует. Пожалуйста, напишите комментарий, если думаете, что я совершенно не прав, – мне интересно узнать о вашем опыте работы с дата-инженерами в вашей команде.

Наконец, если вы принимаете решение о найме дата-инженера прямо сейчас, моя компания проводит довольно много собеседований с такими специалистами – мы считаем, что это хороший способ держать руку на пульсе в отрасли. Если вы хотите устроить последнюю проверку работоспособности нового потенциального члена команды перед тем, как сделать предложение, мы будем рады провести финальное собеседование с вашими кандидатами, просто напишите нам!

Комментарий от Глеба Сологуба, директора по аналитике Skyeng:

У нас в Skyeng сейчас 30+ аналитиков-фулстеков и пока нет ни одного дата-инженера. Это стало возможным, потому что вся наша инфраструктура данных построена на облачных сервисах, о которых говорит Тристан. Мы используем Amazon Redshift в качестве аналитического хранилища, Stitch и Matillion ETL для сбора данных из 40+ продакшен-баз, Segment для сбора событий, Redash и Tableau для отчетов и дэшбордов, Amazon SageMaker для ML.

Задача аналитика в нашей компании — помочь менеджеру справиться с бизнес-проблемой и принять решение. В начале работы над каждой задачей аналитику нужно разобраться в проблеме, придумать гипотезы и MVP-решения для их проверки, выяснить, какие данные для этого нужны и есть ли они уже в аналитическом хранилище. Если их там нет, то любой из наших аналитиков способен самостоятельно настроить нехитрый пайплайн, регулярно складывающий и обновляющий нужные данные в хранилище, или построить датасорс для Tableau из существующих в хранилище таблиц.

Однако есть и ряд проблем, с которыми мы сталкиваемся при таком подходе, и это как раз то, чем должен заниматься дата-инженер по словам Тристана. Например, сейчас мы решаем проблемы производительности в основном экстенсивным путем, благо все облачные инструменты легко позволяют это делать: нажал пару кнопок и вот у тебя уже добавилось несколько узлов в кластер, выбрал тариф подороже и у тебя уже более часто и быстро льются данные.

Но в какой-то момент становится выгоднее нанять дата-инженера, который займется оптимизацией инфраструктуры и бюджета, оптимизирует пайплайны и схемы хранения данных, настроит всевозможные мониторинги, научится отлавливать и исправлять неоптимальные запросы и будет помогать команде аналитики делать свою работу более эффективно и продуктивно. Сейчас мы как раз подошли к этому моменту и открыли вакансию на 90% соответствующую тому, о чем пишет Тристан. Если вам по душе такая роль и задачи, вот пример такой вакансии в Skyeng.

Автор: Skyeng-Habr

Источник