Развитие Data Engineering

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

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

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

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

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

ETL меняется

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

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

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

Например, примером необходимой абстракции в современной среде данных является конфигурация для экспериментов в рамках A/B тестирования: что такое все эксперименты? что такое соответствующие процедуры? какой процент пользователей должен быть подвержен воздействию? какие метрики, на которые ожидается влияние каждого эксперимента? когда эксперимент вступает в силу? В данном примере мы имеем фреймворк, который получает точные данные высокого уровня, выполняет сложные статистические вычисления и выдает вычисленные результаты. Мы ожидаем, что добавление записи для нового эксперимента приведет к дополнительным вычислениям и получению результатов. В этом примере важно отметить, что входные параметры этой абстракции не соответствуют тем, которые предлагает традиционный инструмент ETL, и что построение такой абстракции в интерфейсе "перетащи и брось" было бы невозможным.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хуже того, руководители компаний часто заключают сделки с SaaS-провайдерами, не задумываясь о проблемах интеграции данных.
не задумываясь о проблемах интеграции данных. Объем работы по интеграции систематически преуменьшается поставщиками для облегчения продаж, в результате чего инженеры по обработке данных застревают на неучтенной, недооцененной работе. Не говоря уже о том, что типичные SaaS API часто плохо разработаны, нечетко документированы и "подвижны": это означает, что вы можете ожидать их изменения без предупреждения.

Сервисы

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

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

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

Необходимые навыки
Владение SQL: если английский - это язык бизнеса, то SQL - это язык данных.

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

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

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

Итоги

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

Последние материалы

18 февраля 2024 107
18 февраля 2024 108
Все материалы