Как стать автором
Обновить

От «data-driven™» к «data-driving» в инжиниринге данных™

Управление разработкой *Data Engineering *
Из песочницы
Перевод
Автор оригинала: MrTrustworthy

Всем привет™! Это мой дебют на хабре с переводом классной статьи™ по теме инжиниринга данных™.

Оригинал статьи™:

From Data Driven™ to Driving Data— The dysfunctions of Data Engineering

Для тех кто уже имеет общее представление об инжиниринге данных™ и его типах, можно сразу прыгнуть на Тег.


От "управляемости данными" к "управлению данными" – ошибки™ инжиниринга данных™

Это определённо не тот пост о дата инжиниринге, который вы искали™.

Мы не будем говорить о том, как настроить Spark, или какое отличие у HDFS-ноды от Datanode. Эти вещи не важны. Я никогда не видел, чтобы проект™ дата инжиниринга провалился из-за того, что кто-то выбрал™ ORC вместо™ Parquet. Скорее™ наоборот: множество «data-driven™» инициатив проваливаются, даже несмотря на то, что их задачи™ выполняют лучшие™ дата инженеры, и используется «лучший™» технологический стэк.

Проблемы, с которыми мы сталкиваемся в дата инжиниринге – не в технологиях. Конечно, всей экосистеме не помешало бы еще несколько лет созревания, консолидации и исправления ошибок™. Но не это является причиной, по которой так много инициатив в дата инжиниринге завершаются в статусе «проверка гипотезы о технологии по заоблачной цене». Для слишком многих™ организаций, их Big Data кластер с дюжинами виртуальных машин можно назвать эффективным, только™ если их целью является распараллелить траты их облачного бюджета.

Мы так много говорим об «управляемых данными» компаниях, которые базируют все их важные™ решения на методичном анализе данных™. Мы восхищаемся компаниями типа Facebook(и проклинаем их!), за превращение пользовательских данных™ в оборачиваемый актив. Полно статей™, объявляющих, что данные™ теперь™ — это самый важный™ ресурс™ в мире. И всё это звучит™ довольно убедительно в теории™… но всё же сильно™ оторвано от действительности. Если опросить компании, предпочли бы они ещё несколько терабайт данных™ чемоданчику с золотом, полагаю, что большинство выбрало бы чемоданчик. По крайней-мере, с золотом, они бы знали, как обернуть его в деньги™.

  Да, много компаний делают™ всё правильно. У них есть команда аналитики и какие-никакие, но дашборды с KPI-ми. Разработчики порой запускают ивенты™ и логи через что-то наподобие Kafka. Команда Data Science делает™ какие-то забавные Нейро-Машино™-Что-То-Там… Никто из высшего руководства на самом деле не понимает, что с этим делать™, но команды выглядят довольными своей работой – и это хороший знак, разве не так? Да, это все неплохо, но мы должны™ бы уже делать™ всё намного лучше, чем сейчас™.

  Чтобы быть успешными в будущем, мы должны™ двигаться дальше™. Быть «управляемым данными» недостаточно. Данные™ – это и двигатель, и топливо, на которых наш бизнес™ движется вперёд™. Их поток формирует компанию, начиная с процессов доставки ценностей и заканчивая путями™ межличностного взаимодействия её сотрудников. И чтобы реализовать потенциал данных™ в полной™ мере, мы должны™ сесть за руль. Нам нужен дата инжиниринг – но не просто™ в форме команды специалистов-разработчиков – а как методический подход™ к переосмыслению того, как компания обращается с данными, процессами и проектами на фундаментальном уровне™.

  Пристегните ремни, потому™ что этот пост будет как путешествие. Оно начнётся в Шире, где Дата Инженеры живут в маленьких норах в земле. Оно пройдёт через огромные долины™, где Разработчики и Devops™ инженеры сражаются за превосходство над Kubernetes. Вместе™, они поплывут к берегам озёр данных™, где бизнес™-аналитики и исследователи данных™ плавают в унисон™. И закончится путешествие в Мордоре, где мы бросим™ проклятое кольцо™ бизнес™-ценностей в огни Горы Судьбы™ (где, по совпадению, живёт большинство Product Owner-ов)

Что есть Дата Инженер?

Джефф Хоул провёл™ анализ™ навыков, требуемых в вакансиях для Дата Инжиниринга, и написал замечательный пост о своих находках некоторое время назад. Кликнув на некоторые вакансии на Indeed™, Вы можете™ влегкую увидеть те же самые паттерны, что он обнаружил в своём исследовании. Если Вы знакомы с индустрией, Вы не найдёте ничего™ удивительного просматривая эти объявления. SQL, ETL, Spark… Если Вы дата инженер, все эти вещи как минимум должны™ звучать знакомыми для Вас. 

Нарезка из описаний обязанностей DE

  Здорово звучит™, правда™? Некто, кто может делать™ работу™ как минимум четырёх разных™ спецов™! Зачем нанимать разработчиков или инженеров по облачным технологиям, когда Дата Инженер может делать™ и их работу™? Раз уж такие дела, почему™ бы не заменить ещё и бухгалтерию, маркетинг и HR-ов нашими™ Дата Инженерами, несущими золотые яйца?

Различные типы дата инженеров

Очевидно, что это абсурд™. И снова посмотрев на конкретные объявления по трудоустройству, мы можем быстро™ увидеть причину: нет должностей, требующих, чтобы Вы имели все упомянутые выше навыки™, вместо™ этого все они требуют разный™ набор навыков. Сложность со всеми этими объявлениями о вакансиях в том, что у нас нет единого определения роли дата инженера. На самом деле есть четыре™ разные™ роли, которые компании стремятся объединить вместе™ под широким зонтиком «Дата Инжиниринга».

  Тип #1. Специалисты по разработке ПО. Разработчик, который фокусируется на «ведомых данными» приложениях. Постоянно требуется компаниям, которые вступили на путь микро-сервисной архитектуры, и полагаются на стриминговые платформы типа Kafka для межсервисной коммуникации. Типовые задачи™ это и написание сервисов, которые производят потоки™ ивентов, и сервисов, которые улавливают эти ивенты™, чтобы производить некие действия. Временами, такие разработчики также обслуживают Kafka/RabbitMQ кластеры, подобно тому, как команды Поиска™ часто самостоятельно обслуживают свои Solr/Elasticsearch настройки.

Тип #2. BI-разработчики. Сильно™ упрощённо, есть два разных™ сегмента на поприще BI-разработки: первый™ бизнес™-ориентирован и направлен на определение KPI и на дашборды, второй™ больше™ по технической части и отвечает за хранилища данных™ и ETL процессы. Сложнее найти людей, чтобы делать™ второе™, вот почему™ (как я полагаю) некоторые компании пытаются сделать такие вакансии более привлекательными, переименовывая их в инжиниринг данных™. В конце концов™, ваши ETL- джобы оперируют уже половиной терабайта данных™ – это ведь считается за инжиниринг больших данных™, так?

Тип #3. Data Scientist в сфере системной аналитики. Часто также скрывается под именем™ Machine Learning инженер (MLE), тоже роль без однозначной дефиниции. По мере возрастания золотой лихорадки Data Science, компании быстро™ смекнули, что если вы хотите™ обрабатывать терабайты данных™, вам нужны не только™ алгоритмы, но и инфраструктура, способная масштабироваться до таких объёмов. Развёртывание и обслуживание Spark и/или Hadoop™ кластеров – типичная работа™, подразумевающаяся для этого типа вакансий. С удивительным постоянством команды Data Science просто™ выбирают среди кандидатов тех, кто наименее боится™ скриптов на Bash, и назначают этих персонажей на роль MLE. Эти люди на самом деле не очень-то рады этому, но эй, по крайней мере это солидно смотрится в резюме™.

Тип #4. Администратор хранилищ больших данных™. Когда компании начинают нанимать Data Scientists, они сначала пытаются заставить Ops/DBA/SysAdmin команду принять на себя работу™ по управлению Data Science инфраструктурой. Ops команда будет пытаться убедить CTO, что у них реально нет времени на это, потому™ что разработчики продолжают ломать™ MySQL записыванием туда логов. Если Ops команде удастся, эта ответственность будет передана команде Data Science, которые в свою очередь начнут™ нанимать MLE, чтобы избавиться от этой нагрузки, и в итоге получат спеца из типа #3. Поскольку у Ops команды как правило полно практики в противодействии чему-угодно™, это наиболее частый™ сценарий. Если же Ops команде каким-то образом не удалось достичь успеха™ в убеждении CTO, вы в итоге получите эту роль - Администратор БД, который управляет HDFS и Hive вместо™ MySQL и MongoDB.

Органичное развитие роли Инженера данных™

Для всех этих типов есть общий паттерн, определённое органическое развитие (известное любому™ представителю ИТ-сферы как «бардак™»), которые сформировали эту роль. Всё начинается в каких-нибудь™ отделах компании, недовольных своей (не)способностью работать с данными. Дальнейший анализ™ высвечивает пробел™ – имеются наборы™ задач, которые никто не хочет делать™, потому™ что это не их работа™ – и компания приступает к найму, чтобы закрыть его. Специфика роли дата инженера, которого наймут™, по большей части зависит от отдела™, который первым™ выскажет свою потребность.

  Если первым™ оказывается лид разработчиков/архитекторов, который хочет перейти с монолитной на микро-сервисную архитектуру, вы приходите к типу #1 дата инженера. Если аналитики (или, более вероятно, управленцы высшего звена) недовольны недостатком инсайтов в операционной деятельности компании, начинается рекрутинг инженера типа #2. Но сейчас™, в большинстве случаев, это свежесформированная команда Data Science, обвиняющая в отсутствии бизнес™-ценности их последнего проекта недостаточно развитую инфраструктуру – и тогда вы приходите к типу #3 или #4.

Теперь™, поговорим о различных сложностях при таком подходе. Начнём™ с очевидного: что происходит, когда второй™ и третий™ департаменты начинают приходить со своими™ запросами на «больше™ свободы для данных™»? Предположим, что Data Scientist-ы первыми были услышаны, и у компании дата инженер типа #3. И теперь™ лид разработчиков решает™ разбить PHP/Java монолит на маленькие аккуратные микро-сервисы – и им вероятно требуется Kafka для чего-нибудь™ называемого CQRS или DDD. Теперь™ инженер машинного обучения будет вынужден выстраивать Сервисную шину предприятия (ESB) для Ваших разработчиков? Лид разработчиков пытается убедить команду поддержки операций (Ops) развернуть и поддерживать кластер Kafka для них? Вы нанимаете другого дата инженера, чтобы закрыть эту новую потребность? И что происходит, когда BI-аналитики решают™, что они хотят создать классные дашборды, основанные на ивентах, рассылаемых Вашей микро-сервисной архитектурой, или на моделях, которые Ваши Data Scientist-ы построили? В конце концов™, анализ™ данных™ это про то, как управляемые данными компании решают™, что делать™ дальше™.

Ценность интеграции

Это тупик, в котором многие™ компании оказались прямо сейчас™: Шаг интеграции. Неважно, с какой стороны вы подступились к инжинирингу данных™ вначале – со стороны Разработки, Исследования данных™ или BI/аналитики – у вас всё равно возникнут проблемы с интеграцией этого с оставшимися двумя направлениями.

Эта интеграция определённо самая сложная часть в инжиниринге данных™. И так уж совпало, что это как раз источник настоящей ценности дата инжиниринга. Это не только™ про мощное™ ускорение для каждой™ команды, работающей с данными. Это также про декомпозицию организационных зависимостей, про потенциальные новые возможности, и про различия между Командами Разработки и Усиленными Продуктовыми Командами.

Сделать всех счастливыми в одно и то же время - звучит™ как сложная задача™. Но почему™ мы вообще™ должны™ об этом беспокоиться? У нас есть три группы™ с их отдельными потребностями – создание трёх специализированных, кастомных платформ звучит™ намного лучшей™ идеей. Разработчики получат немного Kafka Brokers, исследователи данных™ получат выделенный Spark кластер где-то в облаке™, а для аналитиков мы просто™ купим Tableau или Looker™ как у всех остальных. Три кольца™ для эльфийских королей поднебесья.

Уходи, Саурон™, можешь™ оставить своё кольцо™ себе.

Истинная сквозная себестоимость

К сожалению, каждый™ кто бывал в такой ситуации знает, что это нелегко. Одна вещь, которая зачастую игнорируется, это реальные сквозные время и усилия™ на монетизацию данных™. Это происходит не намеренно, а как следствие возрастающих специализации и сложности. Если у Вас компания с 5 сотрудниками (трое из которых – работающие студенты), всё что Вам нужно – это ежедневный экспорт в Excel ваших четырёх MySQL-таблиц™ для отчётности. Ваш «целеуказатель» — это набор if-else условий, отрабатывающих в операционной базе данных™. Каждый™ знает все процессы и системы, и нет нужды в изысках инженерии для Ваших потоков данных™.

Когда компания растёт™, кусочек за кусочком добавляются новые процессы, инструменты и команды, специализирующиеся в них. В какой-то момент™, Вы попытаетесь определить, откуда™ появляется специфическая метрика, KPI или рекомендация, и Вы оказываетесь в удивительно долгом™ путешествии. От бизнес™-департамента, который делает™ расчёты KPI, к аналитикам, от администраторов БД к разработчикам, ответственным за компонент. И вот Вы уже звоните когда-то работавшему студенту (вероятно, уже покинувшему компанию года два назад), который изначально внедрял первую™ версию™ этого бизнес™-процесса. В какой-то момент™ Вы опускаете руки с выяснением «почему™?», и просто™ переименовываете Ваш KPI так, чтобы он отражал своё реальное значение. Средняя стоимость корзины теперь™ называется Средняя стоимость корзины (за вычетом синих ручек) и в итоге Вы пристально пялитесь на вентилятор под потолком каждый™ раз, когда кто-то спрашивает Вас об том. Вдалеке слышны™ звуки вертолёта..

Как бы предсказуемо это не было, эти типы потоков данных™ продолжают появляться и исчезать. Это другой™ тип органичного роста. На этот раз не для названий должностей, а для архитектур данных™, пайплайнов, пакетных процессов и воркфлоу. А процесс работы™ с данными всё продолжает и продолжает замедляться.

Инжиниринг данных™ как продуктовая команда

Моя гипотеза о главной причине этого: Дата инженеры зачастую воспринимаются как сервисная команда. Некая команда разработчиков нуждается в Kafka-интеграции? Отправляем емайл дата инженерам! Аналитикам нужен новый пайплайн? Создаём тикет в Jira, тегаем™ Дата Инжиниринг, ставим™ высокий приоритет – надеемся они выполнят это быстро™. Да, дата инженеры как правило выступают в роли подмастерья для других™ отделов, зачастую просто™ отвечая на запросы от внешнего пользователя. Но дата инженеры могут работать намного лучше, если Вы даёте им больше™ ответственности: как Продуктовой Команде.

Если Вы подумаете о классической структуре продуктовой команды, на ум приходит что-то по типу вездесущих примеров «Команды клиентского сервиса». Это команды, работающие с конечными пользователями, дизайнерами, разработчиками фронта™ и бэка, может быть даже с вкраплениями SRE (инженерии по отказоустойчивости) и DevOps™.

Но продуктовая команда дата инженеров имеет несколько иную анатомию, более схожую™ с B2B-командой, или продуктовой командой, ориентированной на внутреннего заказчика. Разным™ людям нравятся разные™ заумные словечки, но лично я предпочитаю термин™ Платформенная команда. Подумайте о команде в AWS, которая занимается разработкой Redshift, или в любом другом™ облачном провайдере, разрабатывающем аналитический облачный продукт – вот как внутренняя команда инженеров данных™ тоже может работать. Им не нужно выстраивать облачный продукт, который будет работать хорошо™ для каждой™ компании. Вместо™ этого они могут использовать инструменты опенсорса и публичного облака™, чтобы выстроить платформу данных™, которая классно работает непосредственно для Вашей компании, включая все Ваши странноватые структуры коммуникаций, воркфлоу, нормативы индустрии, и предпочитаемую гендиректором цветовую схему.

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

Если определённый пайплайн с данными (либо отчёт) падает™, конкретная команда, которая использует этот поток должна™ чинить™ его самостоятельно. Они не могут? Что ж, тогда команда дата инженеров должна™ сделать более качественный инструмент для своих пользователей, чтобы они могли управлять своими™ пайплайнами и восстанавливать их самостоятельно. В конце концов™, платформа – это их продукт, и они отвечают за его успех.

Инверсия ответственности

Это – инверсия ответственности, и в общих чертах™ идентична идеям, стоящим за DevOps™. Дата инженеры больше™ не несут прямую™ ответственность за то, как быстро™ они могут построить новый пайплайн. Теперь™, они отвечают за то, как быстро™ другие™ команды могут построить новые пайплайны на их платформе. Это даёт разработчикам, аналитикам и исследователям данных™ больше™ ответственности (и контроля) за своей работой, а дата инженерам больше™ свободы для выстраивания масштабируемых селф-сервис™ решений для целой компании. Вместо™ того, чтобы увязнуть в болоте™ многих™ десятков сервисных задач, они теперь™ фокусируются на выстраивании интегрированной платформы данных™.

Если другая™ команда обращается к дата инженерам с запросом, их первым™ вопросом должно™ быть: «Что требуется добавить в нашу платформу, чтобы Вы смогли™ сделать это самостоятельно?». Их ключевая метрика успеха™ должна™ отражать, как быстро™ новые пользователи могут построить пайплайны и отчёты™ самостоятельно. Они должны™ писать™ пресс-релизы™ для значительных улучшений их платформы данных™ во внутренней системе коммуникаций, и осуществлять внутренний маркетинг, и обучающие воркшопы чтобы учить пользователей бест-практикам работы™ с их платформой.

Это не простой путь, особенно если они уже оформились в структуру «Инженеры данных™ как сервисная команда». Объяснение другим™ командам, что нет, дата инженеры больше™ не будут делать™ ваши дашборды, но будут учить вас, как их делать™ самостоятельно… создаст некоторое ощутимое сопротивление внутри™ компании. Но, с определённым энтузиазмом, чётким™ видением и хорошими коммуникациями, это всегда™ можно преодолеть. И в конце концов™, вы шаг за шагом идёте навстречу более селф-сервис™-ориентированному пользованию данными для вашей компании. И никому™ не будет дела до того, храните ли вы их в ORC-е или Parquet-е.


Спасибо за внимание, приму любую конструктивную критику, включая обоснованные пожелания больше™ не контрибьютить на Хабр :)

p.s. Хочу поблагодарить участников коммьюнити DataLearn за помощь™ с переводом некоторых особенно "скользких" buzzwords :)

Теги:
Хабы:
Всего голосов 3: ↑3 и ↓0 +3
Просмотры 1.6K
Комментарии Комментарии 7