Как быть data driven. С самого начала
Цифры много значат для нас. Мы инвестируем в данные, слушаем и понимаем их. Мы руководствуемся ими при принятии решений. Несмотря на то, что в плане инфраструктуры работы с данными у нас еще многое впереди, сам data driven подход был с нами всегда. В этом тексте — рассказ о том, какой путь мы прошли, какие уроки выучили и какие грабли собрали.
Меня зовут Андрей Сыцко, я руководитель продуктового направления в финтех-компании ID Finance. Как я уже сказал, нам еще предстоит пройти большой путь с точки зрения методов и инструментов работы с данными. Кратный рост, который компания переживает с момента своего основания, задает недостижимый темп для аналитической инфраструктуры. Однако, вполне вероятно, что ожидания от data driven подхода просто растут опережающими темпами. В конечном итоге, как мы все понимаем, важны не какие-то конкретные инструменты и технологии, а подход, культура и мировоззрение.
Что такое data driven культура?
Что мы понимаем под data-driven культурой в компании? На мой взгляд, это когда мы внутри договорились о том, что данные могут дать хороший ответ или совет в рамках той или иной бизнес-дилеммы. Можно выделить несколько следствий такой договоренности:
Первые инфраструктурные шаги
Первое, с чем вы столкнетесь на пути к своему идеалу data driven decision making — это то, что у вас не хватает данных. В целом, их всегда будет не хватать по объективным причинам, но с чего-то надо начинать.
Для начала вы строите инфраструктуру по сбору и хранению метрик. В подавляющем большинстве проектов для бекенд данных (а у нас это, например, информация о клиентах, их кредитах и платежам по ним) сначала просто используется реплика продакшн базы. При этом придется всецело насладиться внутренней структурой данных вашего софта, которую разработчики создали без мысли о том, чтобы данные было удобно анализировать. Но зато имеем информацию, так сказать, из первых рук. В начале, обычно есть одна база данных, а структура данных относительно проста, так же как и вопросы, которые к этим данным вы захотите задать, так что это вполне рабочий вариант и инвестировать во что-то более сложное не имеет смысла.
Для фронтенд данных (просмотры страниц, взаимодействие с контролам, скроллинг, клики, ввод) можно использовать классические инструменты типа Google Analytics или Яндекс.Метрика и, например, HotJar для записи сессий. Базового функционала хватает для задач маркетинга, а для продуктовых отчетов по воронкам и а/б тестам мы достаточно быстро перешли на работу через Google Reporting API. Мы уже раньше рассказывали об этом на Хабре. Здесь и здесь.
После того, как вы выстроили базовую инфраструктуру и начали собирать основную статистику необходимо убедиться, что продукт будет развиваться синхронно с его метриками.
Т.е. когда вы собираетесь реализовать новую фичу в продукте вам нужно ответить примерно на такие вопросы:
Дальше нужно убедиться, что подсистема сбора и хранения статистики имеет достаточную важность для вашей команды разработки и IT команды. Ее важность должна быть практически равна важности продакшн системы. Например, у нас в начале была постоянная проблема с пропаданием трекинга Google Analytics с разных страниц, пока мы не обсудили важность этих вещей с разработчиками. После чего появились необходимые общие библиотеки, QA гайдлайны и т.п.
Аналитика для аналитиков
Наличие данных еще не означает их эффективное использование. Обычно возникают следующие проблемы/задачи:
Оказывается, что это достаточно объемная работа, требующая специальных навыков и умений, а, главное, времени. Так возникает потребность в создании отдела аналитики.
Наш отдел аналитики достаточно большой, по количеству людей он почти равен мидл-менеджменту. В нем есть как вчерашние студенты с хорошим знанием SQL, так и профессионалы, которые хорошо понимают, как и какие данные нужно достать, чтобы можно было принимать бизнес-решения. Поток запросов к ним традиционно превосходит их возможности.
Озера и склады данных
Одна из проблем, с которой вы наверняка столкнетесь, когда данных будет становиться все больше, это то, что они лежат в разных местах и одни аналитики умеют работать с одними хранилищами, другие — с другими. А с какими-то БД, возможно, сходу никто не умеет работать. Также становится сложно сопоставлять эти данные между собой.
Решением этой задачи могут стать системы типа data warehouse (DWH). В нашем случае, мы задумались об этом в первый раз, когда нам захотелось объединить данные о поведении пользователя на сайте и данные о его поведении как заемщика. Принципы построения DWH далеко выходят за рамки данной статьи, скажу только, какие в нашем случае были сложности/особенности:
Обычно на этом этапе в компании появляется выделенная роль data engineers — т.е. людей, отвечающих за инфраструктуру по работе с данными. На них возлагается задача поддержания и развития DWH.
Лучше сразу нанять правильных людей
С ростом компании выясняется, что не все сотрудники сходу понимают важность данных и умеют с ними работать. Возникает два вопроса: внутренний промоушн и найм правильных людей.
Что касается внутреннего промоушна, то, как говорилось выше, если основатели компании являются носителями дата-культуры, то дальше это спускается на топ-менеджемент, миддл-менеджмент и так далее. Я, например, требую от своих продакт-менеджеров рассчитать потенциальный эффект в деньгах или изменении ключевых метрик до реализации, и посмотреть план факт после реализации нового функционала. Или, скажем, для приоритизации работы, руководствоваться этими же оценками “business value”.
К насаждению data-driven культуры мы подходим с двух сторон. Наше IT подразделение может требовать от бизнес-менеджеров, чтобы в постановке задач была указана оценка эффекта в деньгах. Причем это относится ко всем подразделениям: маркетинг, саппорт, бухгалтерия. К этому мы недавно добавили требование, чтобы бизнес явно описывал метрики, по которым он будет отслеживать результаты внедряемых изменений, а IT должно проследить, чтобы эти метрики можно было достать понятным образом.
Важно, конечно, сразу при найме людей проверять, привыкли ли они ориентироваться на цифры в своей работе или нет, умеют ли они это делать. Мои любимые вопросы на собеседовании, когда мы обсуждаем опыт кандидата: как вы рассчитывали, какой эффект даст фича, как вы померили, какой эффект она по факту дала, и почему вы считаете, что этот эффект нужно отнести именно к этой фиче, а не к чему-то еще. Хороший кандидат всегда сможет логически обосновать почему он делал так, а не иначе.
С ростом бизнеса и объемов данных становится осмысленным применение более продвинутых статистических методик и более продвинутых прикладных библиотек — что-то из того, что сейчас принято называть data science.
Если говорить о data science в более широком смысле нежели нейросети и machine learning, то у нас, например, был успешный опыт перехода от классических пакетов типа SAS для построения логистической регрессии на самописный инструментарий на питоне. Это сократило время на разработку кредитного скоринга в 5 раз.
В какой-то момент поняли, что логистическая регрессия и кластерный анализ на определенных объемах так же оправдывают свое применение в маркетинге и продакт-менеджменте для задач связанных с сегментацией клиентов и определением оптимальной продуктовой или скидочной стратегии индивидуально под каждого клиента.
Учиться предсказывать будущее
Особенность кредитного бизнеса заключается в том, что мало продать товар — деньги в кредит, нужно управлять будущим денежным потоком. Соответственно, роль различных предсказательных моделей и их объединение в прогноз будущего P&L выходит на первый план. Примеры таких моделей: будущие сборы исходя из ранних данных о просрочке, средний чек исходя из данных о сегментации клиентов, количество кредитов исходя из данных о возврате и тому подобное.
Это вообще очень вдохновляет, когда есть инструментарий, который позволяет оценить влияние твоей фичи на различные ключевые метрики бизнеса и предсказать увеличение выручки компании.
Для разработки, поддержания и внедрения подобных инструментов мы сейчас развиваем отдел финансового планирования и анализа (FP&A), задачей которого будет сделать принятие бизнес-решений еще более подкрепленным данными, анализом и моделированием.
Впереди нам предстоит еще много всего интересного: дальнейшее развитие BI инфраструктуры, создание отделов, которые ее поддерживают и процессов, которые ее используют.
Подытоживая, можно выделить следующие принципы развития data-driven подхода, которых я бы придерживался:
Data Driven-подход
Data Driven-подход — это способ принимать управленческие решения, основываясь на больших данных. Его используют для построения бизнес-модели или маркетинговой стратегии, при составлении плана продаж, в программировании и даже в дизайне.
Для каждой сферы выбирают конкретный тип информации, например данные о покупках, геолокации мобильных устройств, количестве поисковых запросов по теме. При поиске помещения под новую кофейню владелец может проанализировать трафик людей на улицах и выбрать место с наибольшей проходимостью.
Полное название этого подхода — Data Driven Decision Making (DDDM), то есть информационно обоснованные решения (или data driven decisions). Он стал альтернативой устаревшему подходу HiPPO (Highest Paid Person’s Opinion) — принятию решений на основе мнения руководства. Проблема этого подхода в том, что руководитель или менеджер не могут быть объективными и компетентными во всех вопросах и знать все особенности аудитории.
Melbourne Business School проводила исследование того, как компании в 46 странах используют аналитику, и выяснилось, что только 6% из них могут считаться лидерами в этом направлении. Это тот бизнес, в котором проработана аналитическая стратегия и в нее включены все подразделения, высший менеджмент принимает решения исключительно на основе данных, а также в реальном времени мониторится ситуация на рынке.
Еще 49% компаний отнесли к категории «Исследователи», так как они частично используют данные для принятия решений, но не до конца развили инфраструктуру для полноценного Data Driven. Остальные компании отнесли к «Подражателям» и «Отстающим», так как они используют данные только в одной конкретной области или не развивают аналитику вообще.
Data Driven-подход полезен на разных этапах развития:
Например, агентство RUSFAIR GROUP проводит исследования для запуска новых продуктов на рынке электронной коммерции в Китае. Они делают анализ инфополя бренда и конкурентов, затем — анализ потенциальных площадок, исследование аудитории в WeChat — самом популярном социальном приложении в Китае, Douyin — китайском аналоге TikTok и других социальных сетях. Такие исследования позволяют определить объем необходимых инвестиций и грамотно выбрать площадки для продвижения.
Фитнес-клуб в Перми через 7 месяцев после открытия поставил перед собой задачу выйти в лидеры рынка. Для доработки продающей концепции маркетологи изучили опыт конкурентов в городе, собрали данные о том, почему люди не ходят в фитнес-клубы, что их удерживает и почему бросают занятия. В результате изменений, основанных на данных, клуб увеличил выручку в два раза.
Альфа Банк в прошлом году проанализировал всю воронку продаж и поведение клиентов, которые в итоге подали заявку на карту и получили ее на руки. На основе этих данных рекламу стали таргетировать на пользователей, которые с наибольшей вероятностью заинтересуются продуктом, благодаря чему число заявок выросло в 1,6 раза.
Решения на основе данных
Для использования Data Driven-подхода требуются навыки работы с аналитикой. Во-первых, нужно уметь считывать данные из таблиц, графиков и диаграмм, потому что иначе даже на основе самых верных данных можно сделать неверные выводы. Во-вторых, нужно критически относиться к самим данным и задавать аналитику правильные вопросы:
Управление на основе данных включает в себя три подготовительных шага:
Недостатки Data Driven-подхода
Как стать Data Driven-компанией
Data Driven-организация корректно собирает, проверяет и обрабатывает данные и использует их на пользу бизнеса. Такие компании имеют отлаженный механизм работы с данными, в котором все сотрудники четко понимают задачи: data-аналитик собирает данные, отдел маркетинга умеет ставить четкое ТЗ на сбор конкретной информации, а руководство соотносит это с бизнес-целью.
Мария Михеева, продуктовый аналитик AliExpress, считает, что организация Data Driven-подхода затрагивает такие аспекты работы компании, как миссия, идеология и обучение сотрудников. Но в основе подхода все-таки лежат качественные данные — достоверные и очищенные от лишней информации, ненужной компании. На этих данных как раз выстраивается data-менеджмент. Кроме них, есть другие важные аспекты:
Главный критерий успеха в Data Driven-подходе — понимание сотрудниками компании того, зачем нужны данные. Поэтому работу над этой управленческой стратегией стоит начинать с внутреннего PR, презентации и обучения.
В каких профессиях используется Data Driven-подход
Менеджмент
Управление на основе данных — одна из причин роста компаний. Оно помогает оптимизировать расходы, повысить клиентоориентированность, отслеживать изменения на рынке и, как результат, увеличить прибыль. Пока полноценно такой подход реализуют только крупные игроки уровня Google, так как внедрение культуры Data Driven в компании — это ресурсозатратный процесс, который не всем по карману.
Маркетинг
Data Driven-маркетинг позволяет продвигать продукт на ту аудиторию, которой он интересен, что значительно сокращает рекламные расходы. Этим инструментом пользуются, например, маркетплейсы, которые собирают информацию об истории поиска своих клиентов, их покупках и интересах, чтобы предлагать им нужные категории товаров.
Веб-разработка
Разработчики опираются на данные взаимодействия пользователей и сервиса, чтобы зацепить и удержать пользователя. Например, в одной из компаний исследовали, как внутри приложения влияет на вовлечение пользователей лента, предлагающая контент на основе машинного обучения.
Кейсы компаний, которые реализуют Data Driven-подход
Управление
Управление на основе данных позволило компании «Сибур» перестроить работу отделов и избавиться от принципа «глубокого колодца», когда специалисты имеют доступ только к информации, необходимой для выполнения их обязанностей. Автоматизация отделов происходила разрозненно, большой пласт информации скрывали, мотивируя это коммерческой тайной, поэтому у менеджмента разных сегментов было недостаточно данных для анализа работы предприятия.
Внедрение Data Driven-подхода позволило открыть доступ к 80% ранее скрытой информации, сотрудники начали самостоятельно проверять гипотезы на данных, составлять интерактивные дашборды. С помощью бизнес-симуляторов компания начала моделировать различные ситуации на рынке и рассчитывать целесообразность инвестиций или запуска новых продуктов.
Разработка маркетинговых продуктов
На туристическом рынке технологию Data Driven используют, чтобы продвигать путешествия на ту аудиторию, у которой есть интерес к направлению, а также отслеживать реальную эффективность рекламы. Например, если человек интересовался турами в Испанию, смотрел билеты или отели, то он обязательно увидит таргетированную рекламу.
Анализ аудитории
Сбербанк уже несколько лет использует Data Driven для анализа поведения заемщиков. Интерактивная анкета, которую использует банк для сбора информации, позволяет выявить один из важных психологических параметров — уравновешенность или импульсивность клиента. Для банка это важно, так как рассудительные люди являются более добросовестными заемщиками, чем импульсивные. Вопросы в анкете для заемщиков помогают определить уровень финансовой грамотности, их стабильность, опыт работы и трезвое восприятие своего финансового положения.
Получите реальные знание и навыки, необходимые для работы. Обучение на основе практики и помощь в трудоустройстве. Скидка 45% по промокоду BLOG.
От «data-driven» к «data-driving» в инжиниринге данных
Всем привет! Это мой дебют на хабре с переводом классной статьи по теме инжиниринга данных.
Для тех кто уже имеет общее представление об инжиниринге данных и его типах, можно сразу прыгнуть на Тег.
От «управляемости данными» к «управлению данными» – ошибки инжиниринга данных
Это определённо не тот пост о дата инжиниринге, который вы искали.
Мы не будем говорить о том, как настроить 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. Эти люди на самом деле не очень-то рады этому, но эй, по крайней мере это солидно смотрится в резюме.
Органичное развитие роли Инженера данных
Для всех этих типов есть общий паттерн, определённое органическое развитие (известное любому представителю ИТ-сферы как «бардак»), которые сформировали эту роль. Всё начинается в каких-нибудь отделах компании, недовольных своей (не)способностью работать с данными. Дальнейший анализ высвечивает пробел – имеются наборы задач, которые никто не хочет делать, потому что это не их работа – и компания приступает к найму, чтобы закрыть его. Специфика роли дата инженера, которого наймут, по большей части зависит от отдела, который первым выскажет свою потребность.
Если первым оказывается лид разработчиков/архитекторов, который хочет перейти с монолитной на микро-сервисную архитектуру, вы приходите к типу #1 дата инженера. Если аналитики (или, более вероятно, управленцы высшего звена) недовольны недостатком инсайтов в операционной деятельности компании, начинается рекрутинг инженера типа #2. Но сейчас, в большинстве случаев, это свежесформированная команда Data Science, обвиняющая в отсутствии бизнес-ценности их последнего проекта недостаточно развитую инфраструктуру – и тогда вы приходите к типу #3 или #4.
Теперь, поговорим о различных сложностях при таком подходе. Начнём с очевидного: что происходит, когда второй и третий департаменты начинают приходить со своими запросами на «больше свободы для данных»? Предположим, что Data Scientist-ы первыми были услышаны, и у компании дата инженер типа #3. И теперь лид разработчиков решает разбить PHP/Java монолит на маленькие аккуратные микро-сервисы – и им вероятно требуется Kafka для чего-нибудь называемого CQRS или DDD. Теперь инженер машинного обучения будет вынужден выстраивать Сервисную шину предприятия (ESB) для Ваших разработчиков? Лид разработчиков пытается убедить команду поддержки операций (Ops) развернуть и поддерживать кластер Kafka для них? Вы нанимаете другого дата инженера, чтобы закрыть эту новую потребность? И что происходит, когда BI-аналитики решают, что они хотят создать классные дашборды, основанные на ивентах, рассылаемых Вашей микро-сервисной архитектурой, или на моделях, которые Ваши Data Scientist-ы построили? В конце концов, анализ данных это про то, как управляемые данными компании решают, что делать дальше.
Ценность интеграции
Это тупик, в котором многие компании оказались прямо сейчас: Шаг интеграции. Неважно, с какой стороны вы подступились к инжинирингу данных вначале – со стороны Разработки, Исследования данных или BI/аналитики – у вас всё равно возникнут проблемы с интеграцией этого с оставшимися двумя направлениями.
Эта интеграция определённо самая сложная часть в инжиниринге данных. И так уж совпало, что это как раз источник настоящей ценности дата инжиниринга. Это не только про мощное ускорение для каждой команды, работающей с данными. Это также про декомпозицию организационных зависимостей, про потенциальные новые возможности, и про различия между Командами Разработки и Усиленными Продуктовыми Командами.
Уходи, Саурон, можешь оставить своё кольцо себе.
Истинная сквозная себестоимость
К сожалению, каждый кто бывал в такой ситуации знает, что это нелегко. Одна вещь, которая зачастую игнорируется, это реальные сквозные время и усилия на монетизацию данных. Это происходит не намеренно, а как следствие возрастающих специализации и сложности. Если у Вас компания с 5 сотрудниками (трое из которых – работающие студенты), всё что Вам нужно – это ежедневный экспорт в Excel ваших четырёх MySQL-таблиц для отчётности. Ваш «целеуказатель» — это набор if-else условий, отрабатывающих в операционной базе данных. Каждый знает все процессы и системы, и нет нужды в изысках инженерии для Ваших потоков данных.
Когда компания растёт, кусочек за кусочком добавляются новые процессы, инструменты и команды, специализирующиеся в них. В какой-то момент, Вы попытаетесь определить, откуда появляется специфическая метрика, KPI или рекомендация, и Вы оказываетесь в удивительно долгом путешествии. От бизнес-департамента, который делает расчёты KPI, к аналитикам, от администраторов БД к разработчикам, ответственным за компонент. И вот Вы уже звоните когда-то работавшему студенту (вероятно, уже покинувшему компанию года два назад), который изначально внедрял первую версию этого бизнес-процесса. В какой-то момент Вы опускаете руки с выяснением «почему?», и просто переименовываете Ваш KPI так, чтобы он отражал своё реальное значение. Средняя стоимость корзины теперь называется Средняя стоимость корзины (за вычетом синих ручек) и в итоге Вы пристально пялитесь на вентилятор под потолком каждый раз, когда кто-то спрашивает Вас об том. Вдалеке слышны звуки вертолёта..
Как бы предсказуемо это не было, эти типы потоков данных продолжают появляться и исчезать. Это другой тип органичного роста. На этот раз не для названий должностей, а для архитектур данных, пайплайнов, пакетных процессов и воркфлоу. А процесс работы с данными всё продолжает и продолжает замедляться.
Инжиниринг данных как продуктовая команда
Моя гипотеза о главной причине этого: Дата инженеры зачастую воспринимаются как сервисная команда. Некая команда разработчиков нуждается в Kafka-интеграции? Отправляем емайл дата инженерам! Аналитикам нужен новый пайплайн? Создаём тикет в Jira, тегаем Дата Инжиниринг, ставим высокий приоритет – надеемся они выполнят это быстро. Да, дата инженеры как правило выступают в роли подмастерья для других отделов, зачастую просто отвечая на запросы от внешнего пользователя. Но дата инженеры могут работать намного лучше, если Вы даёте им больше ответственности: как Продуктовой Команде.
Если Вы подумаете о классической структуре продуктовой команды, на ум приходит что-то по типу вездесущих примеров «Команды клиентского сервиса». Это команды, работающие с конечными пользователями, дизайнерами, разработчиками фронта и бэка, может быть даже с вкраплениями SRE (инженерии по отказоустойчивости) и DevOps.
Но продуктовая команда дата инженеров имеет несколько иную анатомию, более схожую с B2B-командой, или продуктовой командой, ориентированной на внутреннего заказчика. Разным людям нравятся разные заумные словечки, но лично я предпочитаю термин Платформенная команда. Подумайте о команде в AWS, которая занимается разработкой Redshift, или в любом другом облачном провайдере, разрабатывающем аналитический облачный продукт – вот как внутренняя команда инженеров данных тоже может работать. Им не нужно выстраивать облачный продукт, который будет работать хорошо для каждой компании. Вместо этого они могут использовать инструменты опенсорса и публичного облака, чтобы выстроить платформу данных, которая классно работает непосредственно для Вашей компании, включая все Ваши странноватые структуры коммуникаций, воркфлоу, нормативы индустрии, и предпочитаемую гендиректором цветовую схему.
В сравнении с сервисной командой, которая бы владела всеми 100 потоками данных для различных департаментов, команда платформенного инжиниринга данных бы просто владела ключевым продуктом, создающим потоки данных. И этот продукт обязан позволять каждому департаменту самостоятельно создавать и управлять их потоками данных.
Если определённый пайплайн с данными (либо отчёт) падает, конкретная команда, которая использует этот поток должна чинить его самостоятельно. Они не могут? Что ж, тогда команда дата инженеров должна сделать более качественный инструмент для своих пользователей, чтобы они могли управлять своими пайплайнами и восстанавливать их самостоятельно. В конце концов, платформа – это их продукт, и они отвечают за его успех.
Инверсия ответственности
Это – инверсия ответственности, и в общих чертах идентична идеям, стоящим за DevOps. Дата инженеры больше не несут прямую ответственность за то, как быстро они могут построить новый пайплайн. Теперь, они отвечают за то, как быстро другие команды могут построить новые пайплайны на их платформе. Это даёт разработчикам, аналитикам и исследователям данных больше ответственности (и контроля) за своей работой, а дата инженерам больше свободы для выстраивания масштабируемых селф-сервис решений для целой компании. Вместо того, чтобы увязнуть в болоте многих десятков сервисных задач, они теперь фокусируются на выстраивании интегрированной платформы данных.
Если другая команда обращается к дата инженерам с запросом, их первым вопросом должно быть: «Что требуется добавить в нашу платформу, чтобы Вы смогли сделать это самостоятельно?». Их ключевая метрика успеха должна отражать, как быстро новые пользователи могут построить пайплайны и отчёты самостоятельно. Они должны писать пресс-релизы для значительных улучшений их платформы данных во внутренней системе коммуникаций, и осуществлять внутренний маркетинг, и обучающие воркшопы чтобы учить пользователей бест-практикам работы с их платформой.
Это не простой путь, особенно если они уже оформились в структуру «Инженеры данных как сервисная команда». Объяснение другим командам, что нет, дата инженеры больше не будут делать ваши дашборды, но будут учить вас, как их делать самостоятельно… создаст некоторое ощутимое сопротивление внутри компании. Но, с определённым энтузиазмом, чётким видением и хорошими коммуникациями, это всегда можно преодолеть. И в конце концов, вы шаг за шагом идёте навстречу более селф-сервис-ориентированному пользованию данными для вашей компании. И никому не будет дела до того, храните ли вы их в ORC-е или Parquet-е.
Спасибо за внимание, приму любую конструктивную критику, включая обоснованные пожелания больше не контрибьютить на Хабр 🙂
