https://medium.com/free-code-camp/the-rise-of-the-data-engineer-91be18f1e603

В 2011 году я присоединился к Facebook в качестве инженера по бизнес-аналитике. К моменту моего ухода в 2013 году я уже был инженером по данным.
Меня не повысили и не перевели на новую должность. Вместо этого в Facebook поняли, что наша работа выходит за рамки классической бизнес-аналитики. Роль, которую мы создали для себя, представляла собой совершенно новую дисциплину.
Моя команда была на переднем крае этой трансформации. Мы разрабатывали новые навыки, новые способы ведения работы, новые инструменты и, как правило, отказывались от традиционных методов.
Мы были первопроходцами. Мы были инженерами по данным!
Инженерия данных?
Наука о данных как дисциплина проходила свой период подросткового самоподтверждения и самоопределения. В то же время инженерия данных была немного младшей сестрой, но проходила через что-то похожее. Дисциплина инженерии данных брала подсказки от своей старшей сестры, определяя себя также в противопоставлении и находя свою уникальную идентичность.
Как и у данных ученых, у инженеров по данным есть кодирование. Они высокоаналитичны и интересуются визуализацией данных.
В отличие от данных ученых и вдохновленные более зрелым родителем, программной инженерией, инженеры по данным строят инструменты, инфраструктуру, фреймворки и сервисы. Фактически можно утверждать, что инженерия данных ближе к программной инженерии, чем к науке о данных.
В отношении ранее существовавших ролей область инженерии данных может рассматриваться как суперсет бизнес-аналитики и хранилища данных, внедряя более многоэлементные элементы программной инженерии. Эта дисциплина также интегрирует специализацию вокруг операций так называемых распределенных систем “больших данных”, концепций расширенной экосистемы Hadoop, потоковой обработки и вычислений в масштабе.
В малых компаниях, где еще не формализована команда по инфраструктуре данных, роль инженера по данным может также включать в себя нагрузку по настройке и обслуживанию инфраструктуры данных организации. К этим задачам относятся установка и обслуживание платформ, таких как Hadoop/Hive/HBase, Spark и подобных.
В более крупных средах часто происходит специализация и создание формальной роли для управления этой нагрузкой, по мере роста потребности в команде инфраструктуры данных. В этих организациях автоматизация некоторых процессов инженерии данных ложится на руки как команде по инженерии данных, так и команде по инфраструктуре данных, и часто эти команды сотрудничают для решения более высокоуровневых проблем.
В то время как инженерный аспект роли расширяется, другие аспекты исходной роли бизнес-инженера становятся второстепенными. Области, такие как создание и поддержание портфелей отчетов и панелей, не являются первостепенным вниманием инженера по данным.
ETL меняется
Мы также наблюдаем общий отход от инструментов ETL с интерфейсом перетаскивания и редактирования в сторону более программного подхода. Знание продуктовых платформ, таких как Informatica, IBM Datastage, Cognos, AbInitio или Microsoft SSIS, не так распространено среди современных инженеров

по данным и заменяется более общими навыками программной инженерии, а также пониманием программных или конфигурационно-управляемых платформ, таких как Airflow, Oozie, Azkabhan или Luigi. Также довольно распространено, что инженеры разрабатывают и управляют своими собственными оркестраторами/планировщиками заданий.
Есть множество причин, почему сложные программы не разрабатываются с использованием инструментов перетаскивания и редактирования: в конечном итоге код – это лучшая абстракция для программного обеспечения. Хотя за пределами этой статьи сложно спорить на эту тему, легко предположить, что те же самые причины применимы к написанию ETL, как и к любому другому программному обеспечению. Код позволяет использовать произвольные уровни абстракции, работает с любыми логическими операциями знакомым способом, хорошо интегрируется с контролем версий, легко версионируется и сотрудничает. Факт того, что инструменты ETL эволюционировали в сторону графических интерфейсов, кажется каким-то отклонением в истории обработки данных и, безусловно, заслуживает собственного интересного блога.
Давайте подчеркнем тот факт, что абстракции, предлагаемые традиционными инструментами ETL, являются нецелевыми. Конечно, есть необходимость в абстрагировании сложности обработки данных, вычислений и хранения. Но я бы утверждал, что решение не заключается в предоставлении примитивов ETL (таких как источник/цель, агрегации, фильтрация) в форме перетаскивания и редактирования. Нужны абстракции более высокого уровня.
Например, примером нужной абстракции в современной среде данных является конфигурация экспериментов в рамках структуры тестирования A/B: какие все эксперименты? какие связанные обработки? какой процент пользователей должен быть выставлен? какие метрики ожидается, что каждый эксперимент повлияет? когда вступает в силу эксперимент? В этом примере у нас есть структура, которая получает точный, высокоуровневый ввод, выполняет сложные статистические вычисления и предоставляет вычисленные результаты. Мы ожидаем, что добавление нового эксперимента приведет к дополнительным вычислениям и результатам. Важно отметить в этом примере, что входные параметры этой абстракции не соответствуют параметрам, предлагаемым традиционным инструментом ETL, и что создание такой абстракции в интерфейсе перетаскивания и редактирования было бы невозможно.
Для современного инженера по данным традиционные инструменты ETL в значительной степени устарели, потому что логику нельзя выразить с помощью кода. В результате необходимые абстракции не могут быть выражены интуитивно в этих инструментах. Учитывая, что роль инженера по данным в значительной степени заключается в определении ETL, и зная, что для этого нужен совершенно новый набор инструментов и методологии, можно утверждать, что это заставляет дисциплину перестраиваться с нуля. Новый стек, новые инструменты, новый набор ограничений и, во многих случаях, новое поколение специалистов.

Меняющаяся модель данных

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

Вот несколько изменений, замеченных в методиках моделирования данных:

• Дальнейшая денормализация: поддержание заменителей ключей в измерениях может быть трудным и делает фактические таблицы менее читаемыми. Использование естественных, понятных человеку ключей и атрибутов измерений в фактических таблицах становится более общим, уменьшая необходимость в дорогостоящих объединениях, которые могут быть сложными для распределенных баз данных. Также следует отметить, что поддержка кодирования и сжатия в сериализационных форматах, таких как Parquet или ORC, или в базах данных, таких как Vertica, решает большинство проблем с производительностью, которые обычно сопутствуют денормализации. Эти системы научились нормализовывать данные для хранения самостоятельно.
• BLOB: современные базы данных имеют растущую поддержку для BLOB через встроенные типы и функции. Это открывает новые возможности в арсенале моделировщика данных и может позволять фактическим таблицам хранить несколько зерен одновременно, когда это необходимо.
• Динамические схемы: с появлением MapReduce, растущей популярностью хранилищ документов и поддержкой BLOB в базах данных становится проще эволюционировать схемы базы данных без выполнения DML. Это упрощает итеративный подход к хранилищу данных и устраняет необходимость в полном консенсусе и согласовании до разработки.
• Систематическое создание снимков измерений (хранение полной копии измерения для каждого цикла ETL, обычно в отдельных разделах таблицы) в качестве общего способа обработки измерений со скользящим изменением (SCD) – простой универсальный подход, требующий небольших усилий инженерии и который, в отличие от классического подхода, легко понимается при написании ETL и запросов. Также легко и относительно дешево денормализовать атрибут измерения в фактическую таблицу, чтобы отслеживать его значение в момент транзакции. В ретроспективе сложные техники моделирования SCD не интуитивны и снижают доступность.
• Соответствие, как в соответствующих измерениях и метриках, по-прежнему чрезвычайно важно в современной среде данных, но с необходимостью хранилищ данных двигаться быстро и с привлечением большего числа команд и ролей для участия в этом усилии, это менее императивно и скорее является компромиссом. Согласование и сходимость могут происходить как фоновый процесс в областях, где болевая точка расхождения становится неприемлемой.
• Также, в более общем смысле, можно утверждать, что с товаризацией циклов вычислений и с более продвинутыми пользователями данных, чем раньше, становится менее необходимым предварительное вычисление и сохранение результатов в хранилище данных. Например, можно использовать сложные задания Spark, которые могут вычислять сложный анализ по требованию, а не планироваться для включения в хранилище данных.

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

ие аспекты его создания и эксплуатации. Фокус инженера по данным – это хранилище данных, и он вращается вокруг него.

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

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

Также роль команды по инженерии данных заключается в том, чтобы быть “центром компетенции” через определение стандартов, bewt-практик и процессов сертификации для объектов данных. Команда может эволюционировать, чтобы принимать участие или лидировать программу образования, предоставляя свои основные компетенции для помощи другим командам в становлении лучшими участниками хранилища данных. Например, у Facebook есть программа образования “Data Camp”, а Airbnb разрабатывает аналогичную программу “Data University”, где инженеры данных ведут занятия, обучая людей, как быть компетентными в области данных.

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

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

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

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

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

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

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

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

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

• ввод данных: сервисы и инструменты для “парсинга” баз данных, загрузки журналов, извлечения данных из внешних хранилищ или API, …
• вычисление метрик: фреймворки для вычисления и суммирования метрик, связанных с участием, ростом или сегментацией
• обнаружение аномалий: автоматизация потребления данных для оповещения о нештатных событиях или существенных изменениях тенденций
• управление метаданными: инструменты для генерации и потребления метаданных, упрощающие поиск информации в хранилище данных и вокруг него
• экспериментирование: фреймворки тестирования A/B и экспериментов часто являются ключевой частью аналитики компании с существенным компонентом инженерии данных
• инструментирование: аналитика начинается с регистрации событий и атрибутов, связанных с этими событиями, инженеры данных имеют заинтересованность в том, чтобы убедиться, что высококачественные данные захватываются вверх по потоку
• сессионизация: конвейеры, специализированные в понимании последовательности действий во времени, позволяющие аналитикам понимать поведение пользователя
  Как и программисты, инженеры данных должны постоянно стремиться автоматизировать свои рабочие нагрузки и создавать абстракции, позволяющие им подниматься по лестнице сложности. Хотя характер рабочих процессов, которые можно автоматизировать, различается в зависимости от окружения, необходимость в автоматизации обща для всех.

Навыки, необходимые для работы

Владение SQL: если английский язык — это язык бизнеса, то SQL — язык данных. Как успешно может быть предприниматель, не зная хорошо английский? Несмотря на то что технологии приходят и уходят, SQL по-прежнему стоит крепко, как лингва франка в мире данных. Инженер по данным должен быть способен выражать любую степень сложности на SQL, используя техники, такие как “коррелированные подзапросы” и оконные функции. Основы SQL/DML/DDL настолько просты, что не должны оставаться тайной для инженера по данным. Помимо декларативной природы SQL, он/она должны уметь читать и понимать планы выполнения запросов в базе данных, иметь представление о том, как работают индексы, различные алгоритмы объединения и распределенное измерение в плане выполнения.

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

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

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

В целом
За последние 5 лет, работая в Силиконовой долине в Airbnb, Facebook и Yahoo!, и взаимодействуя обширно с командами по данным различных компаний, таких как Google, Netflix, Amazon, Uber, Lyft и десятки компаний разных размеров, я замечаю растущий консенсус относительно того, каким образом “инженерия данных” развивается, и почувствовал необходимость поделиться некоторыми из моих наблюдений.
Я надеюсь, что этот материал может служить своего рода манифестом для инженерии данных, и я надеюсь вызвать реакции от сообщества, работающего в связанных областях!

Перевел chatGPT