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

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

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

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

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

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

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

В небольших экосистемах люди, как правило, пользуются услугами хостинга, например, 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 крепко стоит на ногах, как Лингва франка мира данных. Дата-инженер должен быть в состоянии с помощью SQL выразить такие вещи, как «корреляция подзапросов» и оконные функции любой сложности. SQL/DML/DDL примитивны и достаточно просты для того, чтобы не иметь никаких секретов от дата-инженера. Помимо декларативного характера SQL, инженер должен быть в состоянии прочитать и понять планы выполнения БД, а также иметь представление о том, как работают все этапы, индексы и различные алгоритмы соединения и распределенного измерения в рамках этого плана.

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

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

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

В заключение

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