Как современный стек меняет инжиниринг данных

Автор оригинала: Maxime Beauchemin

Перевод

Перевод подготовлен при поддержке сообщества аналитического курса DataLearn и телеграм-канала Инжиниринг Данных

В 2017 году я написал два поста о роли инженера данных в то время. В The Rise of the Data Engineer подробно описаны роль и обязанности, а в Downfall of the Data Engineer - проблемы роли.

Сейчас, спустя почти 5 лет, хорошее время для проверки и изучения того, как изменилась ситуация. Как изменились вещи? Каковы основные тенденции около этой роли? Куда мы движемся?

Не смотря на то, что я сейчас являюсь основателем и СЕО стартапа, я все еще использую данные, которые задействованы в процессах организации. Это позволило мне понять, как проблемы, связанные с данными, могут быть решены в небольших организациях с нуля. Интересно, что доступность для небольших команд является одним из трендов, о котором я расскажу в этой статье.

Основные тренды, влияющие на инженеров данных

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

Вот тренды, которые я хотел бы выделить:

Инфраструктура данных как сервис

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

Snowflake, BigQuery, Firebolt и другие предлагают управляемые хранилища данных с оплатой по мере использования, и это действительно выглядит как будущее. Помимо хранилищ данных, появляются сервисы для решения практически любой проблемы с инфраструктурой данных. Даже для Apache Airflow существует 3 коммерческих решения (Astronomer, Amazon MWASS и Google Cloud Composer).

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

Учитывая этот тренд, появляются новые потребности для команд инженеров данных:

Современные команды инженеров данных все чаще участвуют в выборе инструментов, их интеграции и контроле затрат.

Сервисы по интеграции данных

Значительная часть времени и усилий инженера данных в 2017 году заключалась в изучении различных REST API для извлечения данных с последующей загрузкой в хранилище. Сегодня с ростом качества и популярности таких сервисов, как Fivetran, и коллег с открытым исходным кодом, таких как Meltano и Airbyte, эта проблема становится менее затратной. Многие организации решили избавиться от своих сомнительных скриптов в пользу управляемого сервиса, который может просто синхронизировать разрозненные данных с вашим хранилищем.

Учитывая доступность и/или цену подобных решений, было бы неправильно строить с нуля. В 2021 году проще использовать сервис для интеграции данных, подобный одному из вышеперечисленных.

Разворот ETL

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

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

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

Спасибо Astasia Myers за эту схему!

ELT > ETL

Хотя подход к трансформации на основе ELT не является новым (лично я чаще предпочитаю ELT, чем ETL в течении последних двух десятилетий), он все чаще воспринимается как основной. Informatica, DataStage, Ab Initio и SSIS становятся все чаще отдаленными воспоминаниями для большинства использующих. Просто имеет смысл отложить вычисления до того места, где требуются данные. Распределенная облачная база данных - это чудо технологии распределённой системы, и в итоге имеет смысл использовать высокооптимизированные механизмы запросов для создания датасетов.

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

Несмотря на сдвиг этой парадигмы, кажется, что все еще сложно сложно определить произвольные встроенные/процедурные вычисления, которые будут проводиться внутри баз данных, но это обеспечивает прогресс, а он неизбежен. Я лично не пытался использовать UDF(пользовательские функции) и анализировать рабочие нагрузки в BigQuery или Snowflake, но могу только предположить, что таким хранилищам данных становится легче поддерживать внешние рабочие нагрузки. Также предполагаю, что спектр функций расширяется, хорошим примером этого являются геопространственные функции в BigQuery.

DBT смог популяризировать ELT и инжиниринг

Множество однотипных SQL и YAML

Индустрия преумножает однотипные SQL и YAML как способ управления «Т» в ELT. Для общего понимания, это направление уже сформировалось, когда я создал Airflow в 2014 году, то многие думали, что мы перейдем к подобию API (как Spark Dataframe API или документации Apache Beam). Из моего представления экосистемы Airflow однотипные SQL - это большая часть того, с чем работают DAG Airflow, и распространенность DBT также является явным сигналом о том, что большая часть логику ELT реализована таким образом.

Для этого направления есть много веских причин: SQL - это сформированный стандарт, хорошо зарекомендовавший, хорошо известный, простой в освоении и декларативный. Используйте это с шаблонизатором, таким как Jinja, и вы сможете сделать его параметризованным и гораздо более динамичным. Учитывая этот способ выражения, его можно использовать в системе управления версиями, а также можно применять для непрерывной интеграции и внедрения, что является значительным прогрессом по сравнению с предыдущими методами, не ориентированными на код. В докладе Коннора Макартура 2018 года “KISS: Keep it SQL, Stupid” хорошо продемонстрировано почему этот подход имеет смысл.

С другой стороны, для сравнения, которое большинство инженеров данных могут не до конца понять, кажется, что раньше был популярен PHP для веб-разработки. Ранний PHP по сути будет выражен как фрагменты кода PHP, живущие внутри HTML-файлов, и приводил к неоптимальным решениям. Это был явно отличный способ придать немного динамики статичным веб-страницам, но шаблон ломался по мере того, как страницы и приложения становились более динамичными. Аналогично в SQL+Jinja некоторые вещи все больше разрушаются, так как появляется все больше необходимости в сложной логике или более абстрактный формах. Это не соответсвует некоторым намерениям более гибкой модели программирования. Если вы используете подход, ориентированным на датафреймы, у вас будет гораздо больше «правильных» объектов, а также костылей и семантики вокруг датасетов, атрибутов и преобразований.

Это сильно отличается от подхода SQL+Jinja, где мы по сути жонглируем с фрагментами SQL-кода как строками. Еще одна основная проблема заключается в том, что эта модель программирования решает вопросы диалекта, присущие SQL. Логика SQL+Jinja на самом деле не может быть повторно использована внутри баз данных, или она очень быстро устаревает, что затрудняет создание кросс-двигательной многоразовой логики.

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

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

Развитие инженер-аналитиков

Было удивительно наблюдать, как аналитики совершенствуют SQL и изучают такие инструменты, как Git и Jinja, но что это значит для инженеров данных. Очевидно, что управление множеством шаблонов SQL было в зоне ответственности инженеров данных с самого начала, так означает ли это, что инженеры данных передают это инженер-аналитику? Я не думаю, что это так: инженеры данных остаются и будут оставаться востребованными в процессе трансформации.

Есть несколько интересных замечаний о специфики роли. В частности, я имею в виду, какой спектр задач покрывает деятельность:

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

Вот полезная диаграмма из поста Клэр Кэрролл на сайте dbt Labs:

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

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

Важность грамотности данных и специфики

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

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

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

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

Экстраполируя на эту тенденцию, возможно, это всего лишь вопрос времени, прежде чем кто-то напишет о «инженере по метаданным».

Демократизация аналитического процесса

Демократизация доступа к данным на данный момент является устаревшей новостью и похожу на клише. Более интересный тренд заключается в том, как весь процесс аналитики (сбор, накопление, преобразование и потребление данных) становится все более доступным для большого количества людей.

Мы видим, как менеджер проекта становится все более знающим и ориентирующимся в инструментах, все больше людей изучают SQL и вносят вклад в трансформационный уровень, используют решения, созданные инженерами данных для точечных вычислений.

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

Вычислительные фреймворки

Мы видим все больше решений для работы в преобразовательном слое. Множество для метрик (популярный Minerva, Transform.co и MetriQL Airbnb), инженерные фреймворки (ближе в MLOps), фреймворки для А/В - тестов и неконтролируемый взрыв самописных вычислительных фреймворков всех форм и вкусов.

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

Доступность

На основе других трендов, и особенно учитывая вышеупомянутую «Инфраструктуру данных как сервис», появляется возможность для небольших организаций к широкому использованию данных. Это во многом связано с доступностью решений SAAS с оплатой по мере использования. Гарантированно вы можете иметь эквивалент отличной команды по данным как услугу, которые как правило довольно хорошо интегрируются друг с другом, соответствуют нормативным документам (SOC2, HiPAA, GDPR/CCPA и тд), а также приятное время окупаемости, возможность масштабирования практически до бесконечности и очень дешевы для небольшого объема данных.

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

Разрушение семантического слоя в BI

В качестве быстрого введения, вот хорошее определение того, что такое семантический слой (не стыдно копировать/вставить из этой замечательной статьи):

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

Первый вызов с этой абстракцией заключается в том, что большинство компаний используют несколько инструментов и что эта ценная информация должна храниться в нескольких системах. Поддержка такого слоя требует глубокого знания архитектуры данного инструмента. Например, LookML Looker сложен, и с ним знакома лишь небольшая группа специалистов. Аналогично и исторически важные проекты MicroStrategy или OLAP Microsoft являются очень сложными и трудно передаваемыми навыками. Как человек, работающий с данными, я не могу однозначно сказать хотел бы я быть причастным к семантическому слою. Очевидно, что существует необходимость в «универсальном семантическом слое» в качестве открытого стандарта на который могут опираться инструменты, но это не реализовано по целому ряду причин, по которым я воздержусь о размышлении в этой статье.

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

Объекты семантического слоя до того, как данные были крутыми - скриншот из одного из инструментов

По всем этим и многим другим причинам семантический слой превращается в слой преобразования (DBT, Airflow, другие ETL/ELT), где современные специалисты, как правило, используют точечные настройки, для создания легко используемых структур данных. Эти богатые структуры данных (таблицы или представления) более самодостаточные и в большинстве случаев требуют меньше или вообще не требуют джойнов и, как правило, меньше семантического слоя, чтобы использовать их.

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

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

Децентрализованное управление

Долгое время централизованная команда данных отвечала за обслуживание систем данных и предоставление информации остальной части организации. Все чаще средние и крупные организации испытывают боль от централизации (бюрократия данных!).

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

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

Одна из больших проблем заключается в том, как команды относятся к предметным областям и как разграничить ответственность, это чрезвычайно важно. Оказывается, не всегда ясно, кто должен владеть чем, так как здесь все запутано в паутине интересов и зависимостей. Рисовать четкие линии совсем не легко, но при возможности лучше стараться этому следовать.

Это огромная структура!

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

Каждый продукт становится продуктом данных

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

Передовые компании, такие как Hubspot, Stripe, GitHub, Slack и другие лидируют в отрасли, предоставляя аналитические продукты для своих клиентов. Однако здесь подводный камень заключается в том, что объем усилий здесь колоссальный. Этим организациям удалось создать целую команду для создания и обслуживания продуктов для обработки данных, ориентированных на клиента, часто приходилось нанимать фронт-энд и бек-энд инженеров, аналитиков и инженеров данных и менеджеров продукта.

Говоря на будущее, создание интегрированных информационных продуктов станет намного легче. Независимо от того, называете ли это BI или продуктовой аналитикой, я с нетерпением жду будущего, когда такие инструменты, как Superset, облегчит командам быстрое создание и итерации продуктов для обработки данных, ориентированных на клиента.

Заключение

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

Наш первый пост глубокого погружения будет охватывать инфраструктуру данных как услугу и услуги по интеграции данных. Оставайтесь с нами!