Восхождение дата-инженера

Я присоединился к команде Facebook в 2011 году в качестве инженера бизнес-аналитика. К моменту, когда я покинул команду в 2013 году я уже был дата-инженером.

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

Дата-инжиниринг?

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

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

В связи с ранее установившимися ролями, дата-инжиниринг можно было бы рассматривать как надмножество бизнес-аналитики и баз данных, которая привносит больше элементов программирования. Эта дисциплина включает в себя специализацию по работе с распределенными системами Big Data, расширенную экосистему Hadoop, потоковую обработку данных и работу со Scale.

В небольших компаниях, где до сих пор нет окончательной инфраструктуры для хранения данных, на инженеров возлагается роль на ее создание и поддержку внутри организации. Это включает в себя задачи по поддержке платфорт на Hadoop/Hive/HBase, Spark или чего-то подобного.

В небольших экосистемах люди, как правило, пользуются услугами хостинга ^[1], например, Amazon или Databricks, или получают поддержку от таких компаний как Cloudera или Hortonworks, которые, по существу, играют роль посредников между другими компаниями.

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

Сейчас у нас есть отличный набор инструментов для самообслуживания, где аналитики, ученые и сферический «информационный работник» работают более осмысленно и могут оперировать данными в автономном режиме.

ETL меняется

Мы наблюдали массовый уход от практики drag-and-drop ETL (Extract Transform and Load) к программному подходу. Продукты, основанные на ноу-хау платформах вида Informatica, IBM DataStage, Cognos, AbInitio или Microsoft SSIS не распространены среди современных дата-инженеров и заменяются более общим программным обеспечением и навыками программирования, наряду с пониманием программных или конфигурируемых платформ вида Airflow, Oozie, Azkabhan или Luigi. Это довольно распространенная практика среди дата-инженеров, которые управляют своим рабочим процессом через, например, планировщик.

Существует множество причин, почему сложные элементы программного обеспечения не разрабатываются по принципу «drag and drop»-инструментов: в конечном счете самописный код является лучшим решением для ПО. Хоть рассуждения на эту тему и выходят за рамки данной публикации, легко сделать вывод, что все вышеописанное применимо и к написанию ETL, как применимо и к любому другому программному обеспечению.

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

Необходимо подчеркнуть, что абстракции под влиянием традиционных ETL-инструментов отклонились от своей первоначальной цели. Несомненно необходимость в абстрактной сложности обработки данных существует, как и в вычислении и хранении. Но я замечу, что данные решения не стоит упрощать посредством ETL (например связка источник/таргет, фильтрация и т.д) из-за моды использовать drag-and-drop подход. Абстракциям необходимо иметь более высокий уровень. Например, необходимой абстракцией современной среды данных является конфигурация для экспериментов с фреймворками A/B-тестирования.

Что за эксперименты? Как они будут проходить? С какими связанными процедурами? Какой процент пользователей должен принимать участие в тесте? Когда ожидается получение результатов? Что мы будем измерять? В данном случае мы имеем конкретный фреймворк, при помощи которого мы можем с высокой точностью определить входные данные, выгрузить статистику и получить конечные расчеты. Мы ожидаем, что добавление новых данных приведет просто к дополнительным вычислениям и данные обновятся. Важно понимать, что в этом примере параметры абстракции не определяются традиционным ETL-инструментарием и что задание такой абстракции не происходило при помощи drug-and-drop'a.

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

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

Моделирование данных меняется

Типичные методы моделирования — как схема «звезда» — они определяют наш подход к моделированию данных для анализа рабочих нагрузок, связанных с хранилищем данных, но все менее и менее значимы для нас. Лучшие традиционные практики работы с хранилищами данных теряют почву под ногами, когда речь заходит о смене стека. При этом хранить и обрабатывать данные сейчас дешевле, чем когда либо, а появление распределенных баз и линейного масштабирования экономит такой дефицитный ресурс, как «время инженера». Вот некоторые изменения, которые наблюдаются в методах моделирования данных:

• Дополнительная денормализация (поддержку суррогатных ключей можно использовать как хитрость, но это делает таблицы менее читаемыми), использование реальных (человеческих) читаемых ключей и атрибутов изменения таблиц становится все более распространенным снижая потребность в дорогостоящих соединениях, которые могут быть слишком тяжелыми для распределенных баз данных. Также обратите внимание, что поддержка кода и сжатия в формате сериализации, например Parquet или ORC, или в рамках СУБД при помощи Vertica, приводит к серьезной потере производительности, которую обычно связывают с денормализацией. Эти системы были созданы для нормализации данных, а хранения уже по желанию.
• BLOBs: современные базы данных создавались с учетом поддержки «Блобов» через собственные типы и функции. Это открывает новые возможности в моделировании обработки данных и может позволить хранить в таблице сразу несколько функциональных гранул (grains — прим. пер.) схемы БД, когда требуется динамическая схема.
• Динамические схемы: с момента появления map reduce и с ростом популярности документации по поддержке «блобов» и баз данных, развивать схемы БД без выполнения DML стало заметно проще. Это упрощает итеративный подход к хранению данных и устраняет необходимость достижения полного консенсуса между продажами и разработкой.
• Систематический снапшутинг размерности (сохранение полной копии размера таблицы для каждого графика ETL-цикла, производится, как правило, в различных разделах таблицы) используется в качестве простого способа справиться с SCD (slowly changing dimension). При этом он требует мало усилий и его, в отличие от классического подхода, легко понять при написании ETL и запросов. С его помощью также можно легко и относительно дешево денормировать атрибут размерности и таблицу, чтобы отследить ее показания на момент завершения операции. В ретроспективе, сложные методы моделирования SCD не интуитивны и снижают доступность.
• Соответственно, согласованность измерений и метрик все еще чрезвычайно важны в среде современных баз данных, но кроме этого нам нужна еще и скорость взаимодействия с большой командой, включающую в себя множество специалистов, также вносящих свой вклад в работу, и тут необходим определенный компромисс.

Роли и обязанности

Хранилище данных

«Хранилище данных представляет собою копию всех переданных данных, которая специально структурирована для запросов и анализа», — Ральф Кимбалл.

«Хранилище данных является предметно-ориентированным, интегрированным, вариативным по времени и энергонезависимым способом сбора данных и помощником руководства в принятии решений», — Билл Инмон.

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

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

Дата-инженеры компаний часто проходят внутреннюю сертификацию, для повышения квалификации в области работы с хранилищами данных. В Airbnb, например, есть набор «основных» схем, которые управляются командой дата-инженеров в рамках соглашения на обслуживание (SLA), где четко определены параметры, которые четко соблюдаются. Речь идет о бизнес-метаданных и документации самого высокого уровня, для обслуживания которых необходим четкий набор лучших практик.

Часто подобное хранилище данных становится для команды инженеров «центром передовых разработок», на котором определяются стандарты и применяются лучшие решения и процессы для сертификации объектов БД. Такая команда может принять участие в образовании других специалистов, делясь своими лучшими решениями. Все это делается для того, чтобы другие инженеры совершенствовались в области работы с хранилищами данных. Например, Facebook имеет собственную образовательную программу «Data camp», а у Airbmb это «Data University». Там инженеры проходят обучение по работе с БД.

Дата-инженеры — это «библиотекари» хранилища данных, люди, которые каталогизируют и организуют метаданные, определяющие рабочие процессы. В быстрорастущем и отчасти хаотичном мире данных, управление метаданными и инструментарием становится жизненно важным компонентом любой современной платформы.

Производительность и оптимизация

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

Зная огромную сложность инженерного стека работы с БД, мы можем предположить, что оптимизация подобного стека тоже непростая задача. Как правило, принимаются решения, требующие минимум затрат и приносящие при этом большую выгоду.

Безусловно, в интересах инженера создавать масштабируемую инфраструктуру. Это позволяет компании сэкономить ресурсы на всех этапах.

Интеграция данных

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

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

Сервисы

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

Вот несколько примеров услуг, которые могут создать дата-инженеры и инженеры по обслуживанию инфраструктуры БД, которые можно эксплуатировать.

• Поглощение данных: сервисы и инструменты построенные вокруг «выскабливания» БД, загрузки логов, извлечения данных из внешних источников или API…
• Вычисление метрик: фреймворки для вычисления и суммирования участия, роста или связанных с сегментацией показателей.
• Обнаружение аномалий: автоматизация потребления данных и система предупреждения нужных людей об аномальных событиях или появлении тенденций к существенным изменениям.
• Управление метаданными: инструменты построенные вокруг генерации и потребления метаданных, что позволяет легко найти информацию как внутри, так и за пределами хранилища.
• Экспериментирование: написание экспериментальных A/B-тестов и фреймворков часто является важной составляющей аналитики компании со значительным объемом инженерных данных.
• Инструментарий: аналитика начинается с регистрации событий и атрибутов, связанных с этими событиями. Дата-инженеры шкурно заинтересованы в том, чтобы высококачественные данные поднимались вверх.
• Сессионализация: создание источников информации, которые специализируются на выстраивании действий в хронологии, что позволяет аналитикам понять поведение пользователя.

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

Требуемые навыки

Знание SQL: если английский является языком мирового бизнеса, то SQL является языком данных. Насколько успешным бизнесменом вы хотите быть, если не говорите хорошо по-английски? Сменяются технологии и поколения, но SQL крепко стоит на ногах, как Лингва франка ^[2] мира данных. Дата-инженер должен быть в состоянии с помощью SQL выразить такие вещи, как «корреляция подзапросов» и оконные функции любой сложности. SQL/DML/DDL примитивны и достаточно просты для того, чтобы не иметь никаких секретов от дата-инженера. Помимо декларативного характера SQL, инженер должен быть в состоянии прочитать и понять планы выполнения БД, а также иметь представление о том, как работают все этапы, индексы и различные алгоритмы соединения и распределенного измерения в рамках этого плана.

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

Дизайн ETL: способность написания эффективной, гибкой и «эволюционирующей» ETL является ключевым фактором. Я планирую более широко затронуть эту тему в будущих публикациях.

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

В заключение

За последние пять лет работы в Кремниевой долине и компаниях FAcebook, Airbnb и Yahoo!, плюс косвенно взаимодействуя с командами дата-инженеров из Google, Netflix, Amazon, Uber, LYFT и еще десятками из организаций всех размеров, я наблюдал за эволюцией дата-инжиниринга и почувствовал, что мне нужно поделиться некоторыми выводами. Я надеюсь, что эта статья может послужить своего рода манифестом для этой сферы. Я надеюсь, что она найдет отклик со стороны сообщества, со стороны специалистов, работающих в смежных областях!

Автор: Inoventica Services

Источник ^[3]