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

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

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

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 :)