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

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

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

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

В качестве основы выступают фоновые процессы (рисунок 2-1, низ), которые пересекают несколько этапов жизненного цикла инженерии данных: безопасность, управление данными, DataOps, архитектура данных, оркестрация и программная инженерия. Ни одна часть жизненного цикла инженерии данных не может адекватно функционировать без этих фоновых процессов.

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

Исходная система (source system) — это источник данных, используемых в жизненном цикле инженерии данных. Например, исходной системой может быть устройство IoT, очередь сообщений приложения или транзакционная база данных. Инженер данных поглощает данные из исходной системы, но обычно не владеет и не контролирует саму исходную систему. Он должен обладать пониманием работы исходных систем, генерации данных, частоты и скорости данных, а также разнообразия данных, которые они генерируют.

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

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

Рисунок 2-3 иллюстрирует традиционную исходную систему с несколькими серверами приложений, поддерживаемыми базой данных. Этот шаблон исходной системы стал популярным в 1980-х годах с взрывным успехом систем управления реляционными базами данных (СУРБД). Паттерн приложение + база данных остаётся популярным и сегодня с различными современными эволюциями практик разработки программного обеспечения. Например, приложения часто состоят из множества небольших пар сервис/база данных с микросервисами, а не из одного монолита.

Давайте рассмотрим ещё один пример исходной системы. Рисунок 2-4 иллюстрирует группу IoT: флот устройств (круги) отправляет сообщения с данными (прямоугольники) в центральную систему сбора. Эта исходная система IoT становится всё более распространенной, поскольку устройства IoT, такие как датчики, интеллектуальные устройства и многое другое, становятся всё более распространёнными.

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

• Каковы основные характеристики источника данных? Это приложение? Группа устройств IoT?
• Как данные сохраняются в исходной системе? Данные хранятся долгосрочно или временно и быстро удаляются?
• С какой скоростью генерируются данные? Сколько событий в секунду? Сколько гигабайт в час?
• Какого уровня согласованности могут ожидать инженеры данных от выходных данных? Если вы проводите проверки качества выходных данных, как часто возникают несоответствия — нулевые значения там, где их не ожидают, плохое форматирование и т. д.?
• Как часто возникают ошибки?
• Будут ли данные содержать дубликаты?
• Будут ли некоторые значения данных поступать с опозданием, возможно, намного позже, чем другие сообщения, созданные одновременно?
• Какова схема принимаемых данных? Нужно ли инженерам данных объединять несколько таблиц или даже несколько систем, чтобы получить полную картину данных?
• Если схема изменяется (например, добавляется новый столбец), как это обрабатывается и сообщается заинтересованным сторонам нижестоящего уровня?
• Как часто следует извлекать данные из исходной системы?
• Для систем с отслеживанием состояния (например, базы данных, отслеживающей информацию об учётных записях клиентов) предоставляются ли данные в виде периодических снимков или событий обновления из сбора данных об изменениях (CDC)? Какова логика выполнения изменений и как они отслеживаются в исходной базе данных?
• Кто/что является поставщиком данных, который будет передавать данные для последующего поглощения?
• Влияет ли чтение из источника данных на его производительность?
• Имеет ли исходная система зависимости от исходных данных? Каковы характеристики этих исходных систем?
• Проводятся ли проверки качества данных на предмет наличия опаздывающих или отсутствующих данных?

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

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

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

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

Более подробно мы рассмотрим исходные системы в Главе 5; также мы рассмотрим схемы и моделирование данных в Главах 6 и 8 соответственно.

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

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

Вот несколько ключевых инженерных вопросов, которые следует задать при выборе системы хранения данных для хранилища данных, озёра данных, базы данных или объектного хранилища:

• Совместимо ли это решение для хранения данных с требуемыми для архитектуры скоростями записи и чтения?
• Станет ли хранение узким местом для последующих процессов?
• Понимаете ли вы, как работает эта технология хранения? Используете ли вы систему хранения оптимально или совершаете неестественные действия? Например, применяете ли вы высокую частоту случайных обновлений доступа в системе хранения объектов? (Это антишаблон со значительными издержками производительности.)
• Будет ли эта система хранения обрабатывать ожидаемый будущий масштаб? Вам следует учитывать все ограничения ёмкости системы хранения: общий доступный объём хранилища, скорость операций чтения, объём записи и т. д.
• Смогут ли последующие пользователи и процессы извлекать данные в соответствии с требуемым соглашением об уровне обслуживания (SLA)?
• Вы собираете метаданные об эволюции схемы, потоках данных, происхождении данных и т. д.? Метаданные оказывают значительное влияние на полезность данных. Метаданные представляют собой инвестиции в будущее, значительно повышая обнаруживаемость и институциональные знания для оптимизации будущих проектов и изменений архитектуры.
• Является ли это решением для чистого хранения данных (объектное хранилище) или оно поддерживает сложные шаблоны запросов (например, облачное хранилище данных)?
• Является ли система хранения схемонезависимой (объектное хранилище)? Гибкая схема (Cassandra)? Принудительная схема (облачное хранилище данных)?
• Как вы отслеживаете основные данные, качество данных «золотых записей» и происхождение данных для управления данными? (Более подробную информацию об этом можно найти в разделе «Управление данными» на стр. 50.)
• Как вы справляетесь с соблюдением нормативных требований и суверенитетом данных? Например, можете ли вы хранить свои данные в определенных географических точках, но не в других?

Не все данные одинаково доступны. Шаблоны извлечения будут сильно различаться в зависимости от хранимых и запрашиваемых данных. Это приводит к понятию «температуры» данных. Частота доступа к данным будет определять температуру ваших данных.
Данные, к которым чаще всего обращаются, называются горячими данными. Горячие данные (hot data) обычно извлекаются много раз в день, возможно, даже несколько раз в секунду, например, в системах, обслуживающих запросы пользователей. Эти данные должны храниться для быстрого извлечения, где «быстро» относится к варианту использования. К теплым данным (lukewarm data) можно обращаться время от времени, например, каждую неделю или месяц.

Холодные данные (cold data) редко запрашиваются и подходят для хранения в архивной системе. Холодные данные часто сохраняются в целях сравнения или в случае катастрофического сбоя в другой системе. В «старые времена» холодные данные хранились на лентах и ​​отправлялись в удалённые архивные хранилища. В облачных средах поставщики предлагают специализированные уровни хранения с очень низкой ежемесячной стоимостью хранения, но высокой стоимостью извлечения данных.

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

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

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

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

При подготовке к проектированию или созданию системы необходимо задать себе несколько вопросов об этапе поглощения:

• Каковы сценарии использования данных, которые мы поглощаем? Могу ли я повторно использовать эти данные, а не создавать несколько версий одного и того же набора данных?
• Надёжно ли системы генерируют и обрабатывают эти данные, и доступны ли они, когда они мне нужны?
• Куда направляются данные после поглощения?
• Как часто мне понадобится доступ к данным?
• В каком объёме обычно поступают данные?
• В каком формате находятся данные? Могут ли мои последующие системы хранения и преобразования обрабатывать этот формат?
• Находятся ли исходные данные в хорошем состоянии для немедленного использования в дальнейшем? Если да, то как долго и что может привести к тому, что они станут непригодными для использования?
• Если данные из потокового источника, нужно ли их преобразовывать перед тем, как они достигнут пункта назначения? Будет ли уместным преобразование на лету, когда данные преобразуются внутри самого потока?

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

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

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

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

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

• Если поглощать данные в режиме реального времени, смогут ли нижестоящие системы хранения данных справиться со скоростью потока данных?
• Нужно ли поглощение данных в режиме реального времени за миллисекунды? Или подойдет подход с микропакетами, накапливающий и поглощающий данные, скажем, каждую минуту?
• Каковы мои сценарии использования потокового поглощения? Какие конкретные преимущества я получу, внедрив его? Если я получаю данные в режиме реального времени, какие действия, лучшие в сравнении с пакетным поглощением, я могу предпринять с этими данными?
• Будет ли мой подход, ориентированный на потоковое поглощение, стоить больше с точки зрения времени, денег, обслуживания, простоя и издержек упущенных возможностей, чем просто пакетное поглощение?
• Надежны ли и избыточны ли мой потоковый конвейер и система в случае сбоя инфраструктуры?
• Какие инструменты наиболее подходят для этого сценария использования? Следует ли мне использовать управляемый сервис (Amazon Kinesis, Google Cloud Pub/Sub, Google Cloud Dataflow) или поддерживать собственные экземпляры Kafka, Flink, Spark, Pulsar и т. д.? Если я сделаю последнее, кто будет управлять этим? Каковы затраты и компромиссы?
• Если я развёртываю модель машинного обучения, какие преимущества я получу от онлайн-прогнозирования и, возможно, непрерывного обучения?
• Получаю ли я данные из реального работающего экземпляра? Если да, то каково влияние моего процесса поглощения на эту исходную систему?

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

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

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

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

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

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

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

При рассмотрении преобразования данных в рамках жизненного цикла инженерии данных полезно учитывать следующее:

• Каковы стоимость и окупаемость инвестиций (ROI) преобразования? Какова сопутствующая ценность для бизнеса?
• Является ли преобразование максимально простым и самоизолированным?
• Какие бизнес-правила поддерживают преобразование?

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

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

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

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

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

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

Данные имеют ценность (value), когда они используются в практических целях. Данные, которые не потребляются или не запрашиваются, просто инертны. Бесполезные проекты данных представляют собой серьезный риск для компаний. Многие компании занимались бесполезными проектами в эпоху больших данных, собирая огромные наборы данных в озёрах данных, которые никогда не использовались каким-либо полезным образом. Эпоха облаков запускает новую волну таких проектов, построенных на новейших хранилищах данных, системах хранения объектов и потоковых технологиях. Проекты данных должны иметь цель на протяжении всего жизненного цикла. Какова конечная бизнес-цель данных, которые так тщательно собираются, очищаются и хранятся?

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

Аналитика (analytics) — это смысл ​​большинства усилий по работе с данными. После того, как ваши данные сохранены и преобразованы, вы готовы создавать отчёты или панели мониторинга и проводить специальный анализ данных. В то время как основная часть аналитики раньше охватывала BI, теперь она включает другие аспекты, такие как операционная аналитика и встроенная аналитика (рисунок 2-5). Давайте кратко рассмотрим эти разновидности аналитики.

Бизнес-аналитика (Business Intelligence). BI упорядочивает собранные данные для описания прошлого и текущего состояния бизнеса. BI требует использования бизнес-логики для обработки необработанных данных. Обратите внимание, что обслуживание данных для аналитики — это ещё одна область, где этапы жизненного цикла инженерии данных могут запутаться. Как мы упоминали ранее, бизнес-логика часто применяется к данным на этапе преобразования жизненного цикла инженерии данных, но подход «логика при чтении» становится всё более популярным. Данные хранятся в чистой, но довольно сырой форме с минимальной постобработкой бизнес-логики. Система BI поддерживает репозиторий бизнес-логики и определений. Эта бизнес-логика используется для запросов к хранилищу данных, чтобы отчеты и панели мониторинга соответствовали бизнес-определениям.

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

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

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

При использовании встроенной аналитики частота запросов на отчёты и соответствующая нагрузка на аналитические системы резко возрастают; контроль доступа становится значительно сложнее и критичнее. Компании могут предоставлять отдельные данные и аналитику тысячам или более клиентов. Каждый клиент должен видеть свои и только свои данные. Внутренняя ошибка доступа к данным в компании, скорее всего, приведет к процедурной проверке. Утечка данных между клиентами будет считаться серьёзным нарушением доверия, что приведет к вниманию СМИ и значительной потере клиентов. Минимизируйте радиус поражения, связанный с утечками данных и уязвимостями безопасности. Применяйте безопасность на уровне арендатора или данных в вашем хранилище и везде, где есть вероятность утечки данных.

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

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

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

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

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

Ниже приведены некоторые особенности этапа предоставления данных, характерные для машинного обучения:

• Достаточно ли качественны данные для надёжного проектирования функций? Требования к качеству и оценки разрабатываются в тесном сотрудничестве с командами, использующими данные.
• Могут ли учёные по данным и инженеры машинного обучения легко находить ценные данные?
• Где лежат технические и организационные границы между инженерией данных и машинным обучением? Этот организационный вопрос имеет значительные архитектурные последствия.
• Отражает ли набор данных истинную действительность? Является ли он несправедливо предвзятым?

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

Обратный ETL уже давно стал практической реальностью в данных, рассматриваемой как антипаттерн, о котором мы не хотели говорить и удостаивать его упоминанием. Обратный ETL берёт обработанные данные со стороны вывода жизненного цикла инженерии данных и возвращает их в исходные системы, как показано на рисунке 2-6. В действительности этот поток полезен и часто необходим; обратный ETL позволяет нам брать аналитику, оценочные модели и т. д. и возвращать их в производственные системы или платформы SaaS.

Маркетинговые аналитики могли рассчитывать ставки в Microsoft Excel, используя данные из своего хранилища данных, а затем загружать эти ставки в Google Ads. Этот процесс часто был полностью ручным и примитивным.
Пока мы писали эту книгу, несколько поставщиков приняли концепцию обратного ETL и создали продукты вокруг неё, такие как Hightouch и Census. Обратный ETL пока ещё только зарождается как практика, но мы подозреваем, что он останется.

Обратный ETL стал особенно важным, поскольку компании всё больше полагаются на SaaS и внешние платформы. Например, компании могут захотеть перенести определённые показатели из своего хранилища данных на платформу клиентских данных или CRM-систему. Рекламные платформы — ещё один повседневный вариант использования, как в примере с Google Ads. Вы увидите больше активности в обратном ETL, как в инженерии данных, так и в инженерии машинного обучения.

Пока не решено, приживется ли термин «обратный ETL». И практика может развиваться. Некоторые инженеры утверждают, что мы можем устранить обратный ETL, обрабатывая преобразования данных в потоке событий и отправляя эти события обратно в исходные системы по мере необходимости. Реализация широкого внедрения этого шаблона в бизнесе — это другой вопрос. Суть в том, что преобразованные данные необходимо будет каким-то образом вернуть в исходные системы, в идеале с правильной родословной и бизнес-процессом, связанным с исходной системой.

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

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

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

Давайте пользователям только тот доступ, который им нужен для выполнения их работы сегодня, ничего больше. Не работайте из оболочки root, когда вы просто ищете файлы, видимые с доступом обычного пользователя. При запросе таблиц с низкой ролью не используйте роль суперпользователя. Принятие принципа минимальных привилегий может предотвратить случайный ущерб и привить вам мышление, ориентированное на безопасность.
Люди и организационная структура всегда являются самыми большими уязвимостями безопасности в любой компании. Когда мы слышим о крупных нарушениях безопасности в СМИ, часто оказывается, что кто-то в компании проигнорировал основные меры предосторожности, стал жертвой фишинговой атаки или действовал безответственно. Первая линия защиты данных — это создание культуры безопасности, которая охватывает всю организацию. Все лица, имеющие доступ к данным, должны понимать свою ответственность за защиту конфиденциальных данных компании и её клиентов.

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

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

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

Вы, вероятно, думаете, что управление данными звучит
очень... корпоративно. «Старые» методы управления данными проникают в инженерию данных и машинное обучение. То, что было старым, снова становится новым. Управление данными существует уже несколько десятилетий, но до недавнего времени не получало особого развития в инженерии данных. Инструменты данных становятся проще, и инженерам данных становится всё легче управлять ими. В результате инженер данных переходит вверх по цепочке важности к следующей ступени передовых методов. Передовые методы работы с данными, которые когда-то были доступны только крупным компаниям — руководство данными, управление основными данными, управление качеством данных, управление метаданными — теперь проникают в компании всех размеров и уровней зрелости. Как мы любим говорить, инженерия данных становится «корпоративной». В конце концов, это здорово!

The Data Management Association International (DAMA) Data Management Body of Knowledge (DMBOK), который мы считаем основополагающим документом по управлению корпоративными данными, предлагает следующее определение:

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

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

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

Управление данными имеет довольно много аспектов, включая следующие:

• Руководство данными, включая возможность обнаружения и подотчетность;
• Моделирование и проектирование данных;
• Происхождение данных;
• Хранение и эксплуатация;
• Интеграция и совместимость данных;
• Управление жизненным циклом данных;
• Системы данных для расширенной аналитики и машинного обучения;
• Этика и конфиденциальность.

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

Согласно Data Governance: The Definitive Guide, «Руководство данными — это, прежде всего, функция управления данными, призванная обеспечить качество, целостность, безопасность и удобство использования данных, собираемых организацией».

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

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

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

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

Обнаруживаемость (discoverability). В компании, ориентированной на данные, данные должны быть доступны и обнаруживаемы. Конечные пользователи должны иметь быстрый и надёжный доступ к данным, необходимым им для выполнения своей работы. Они должны знать, откуда берутся данные, как они соотносятся с другими данными и что они означают.
Некоторые ключевые области обнаружения данных включают управление метаданными и управление основными данными. Давайте кратко опишем эти области.

Метаданные (metadata). Метаданные — это «данные о данных», и они лежат в основе каждого раздела жизненного цикла инженерии данных. Метаданные — это именно те данные, которые нужны для того, чтобы сделать данные обнаруживаемыми и управляемыми.

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

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

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

Данные имеют социальный элемент; каждая организация накапливает социальный капитал и знания вокруг процессов, наборов данных и конвейеров. Ориентированные на человека системы метаданных фокусируются на социальном аспекте. Это то, что Airbnb подчёркивал в своих различных сообщениях в блоге об инструментах данных, в частности в своей оригинальной концепции Dataportal. Такие инструменты должны предоставлять место для раскрытия владельцев данных, потребителей данных и экспертов в предметной области. Документация и внутренние вики-инструменты обеспечивают важную основу для управления метаданными, но эти инструменты также должны интегрироваться с автоматизированной каталогизацией данных. Например, инструменты сканирования данных могут генерировать вики-страницы со ссылками на соответствующие объекты данных.

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

• Бизнес-метаданные
• Технические метаданные
• Операционные метаданные
• Справочные метаданные

Давайте кратко опишем каждую категорию метаданных.

Бизнес-метаданные (Business metadata) относятся к способу использования данных в бизнесе, включая определения бизнеса и данных, правила и логику данных, как и где используются данные, а также владельца(ев) данных.
Инженер данных использует бизнес-метаданные для ответа на нетехнические вопросы о том, кто, что, где и как. Например, инженеру по данным может быть поручено создать конвейер данных для анализа продаж клиентов. Но что такое клиент? Это тот, кто купил за последние 90 дней? Или тот, кто купил в любое время действия бизнеса? Инженер данных будет использовать правильные данные для ссылки на бизнес-метаданные (словарь данных или каталог данных), чтобы узнать определение «клиента». Бизнес-метаданные предоставляют инженеру данных правильный контекст и определения для правильного использования данных.

Технические метаданные (Technical metadata) описывают данные, созданные и используемые системами на протяжении жизненного цикла инженерии данных. Они включают модель и схему данных, происхождение данных, сопоставление полей и рабочие процессы конвейера. Инженер данных использует технические метаданные для создания, подключения и мониторинга различных систем на протяжении жизненного цикла инженерии данных.

Вот некоторые распространенные типы технических метаданных, которые будет использовать инженер данных:
• Метаданные конвейера (часто создаваемые в системах оркестрации);
• Линия данных;
• Схема.

Оркестрация — это центральный хаб, который координирует рабочий процесс в различных системах. Метаданные конвейера (Pipeline metadata), собранные в системах оркестрации, содержат сведения о графике рабочего процесса, зависимостях системы и данных, конфигурации, сведения о подключении и многое другое.

Метаданные линии данных (Data-lineage metadata) отслеживают происхождение и изменения данных, а также их зависимости с течением времени. По мере того, как данные проходят через жизненный цикл инженерии данных, они развиваются посредством преобразований и комбинаций с другими данными. Линия данных обеспечивает аудиторский след эволюции данных по мере их перемещения через различные системы и рабочие процессы.

Метаданные схемы (Schema metadata) описывают структуру данных, хранящихся в системе, такой как база данных, хранилище данных, озеро данных или файловая система; это одно из ключевых отличий между различными системами хранения. Например, объектные хранилища не управляют метаданными схемы; вместо этого они должны управляться в метахранилище. С другой стороны, облачные хранилища данных управляют метаданными схемы внутри.

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

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

Справочные метаданные (Reference metadata) — это данные, используемые для классификации других данных. Их также называют данными поиска. Стандартными примерами справочных данных являются внутренние коды, географические коды, единицы измерения и внутренние календарные стандарты. Обратите внимание, что большая часть справочных данных полностью управляется внутренне, но такие элементы, как географические коды, могут поступать из стандартных внешних ссылок. Справочные данные по сути являются стандартом для интерпретации других данных, поэтому если они изменяются, это изменение происходит медленно с течением времени.

Подотчётность данных (Data accountability). Подотчётность данных означает назначение лица для руководства частью данных. Далее ответственное лицо координирует деятельность по руководству других заинтересованных сторон. Управление качеством данных становится сложным, если никто не несёт ответственности за соответствующие данные.

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

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

Качество данных (Data quality) — это оптимизация данных в направлении желаемого состояния, которая вращается вокруг вопроса: «Что вы получаете по сравнению с тем, что ожидаете?» Данные должны соответствовать ожиданиям в бизнес-метаданных. Соответствуют ли данные определению, согласованному бизнесом?

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

Согласно руководству «Data Governance: The Definitive Guide», качество данных определяется тремя основными характеристиками:
Точность
Являются ли собранные данные фактически правильными? Имеются ли повторяющиеся значения? Являются ли числовые значения точными?
Полнота
Являются ли записи полными? Все ли обязательные поля содержат допустимые значения?
Своевременность
Являются ли записи доступными своевременно?

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

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

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

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

Чтобы извлечь бизнес-информацию из данных с помощью бизнес-аналитики и науки о данных, данные должны быть в пригодной для использования форме. Процесс преобразования данных в пригодную для использования форму известен как моделирование и проектирование данных. В то время как мы традиционно думаем о моделировании данных как о проблеме администраторов баз данных (DBA) и разработчиков ETL, моделирование данных может происходить практически в любом месте организации. Инженеры встроенного ПО разрабатывают формат данных записи для устройства IoT, а разработчики веб-приложений проектируют ответ JSON на вызов API или схему таблицы MySQL — всё это примеры моделирования и проектирования данных.

Моделирование данных стало более сложным из-за разнообразия новых источников данных и сценариев использования. Например, строгая нормализация не работает правильно с данными событий. К счастью, новое поколение инструментов данных повышает гибкость моделей данных, сохраняя логическое разделение мер, измерений, атрибутов и иерархий. Облачные хранилища данных поддерживают поглощение огромных объёмов денормализованных и полуструктурированных данных, при этом по-прежнему поддерживая общие шаблоны моделирования данных, такие как Kimball, Inmon и Data Vault. Фреймворки обработки данных, такие как Spark, могут принимать весь спектр данных, от плоских структурированных реляционных записей до необработанного неструктурированного текста. Мы обсудим эти шаблоны моделирования и преобразования данных более подробно в Главе 8.

С учётом большого разнообразия данных, с которыми приходится иметь дело инженерам, возникает соблазн сдаться и отказаться от моделирования данных. Это ужасная идея с ужасающими последствиями, которые становятся очевидными, когда люди бормочут о шаблоне доступа write once, read never (WORN) или ссылаются на болото данных (data swamp). Инженерам данных необходимо знать лучшие практики моделирования, а также развивать гибкость для применения соответствующего уровня и типа моделирования к источнику данных и сценарию использования.

Как узнать, какая система повлияла на данные, когда они проходят через жизненный цикл, или из чего состоят данные, когда они передаются и преобразуются? Линия данных (Data lineage) ведет запись контрольного следа данных на протяжении их жизненного цикла, отслеживая как системы, обрабатывающие данные, так и данные, от которых они зависят.

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

Линия данных уже давно существует в крупных компаниях со строгими стандартами соответствия. Однако теперь она всё шире применяется в небольших компаниях, поскольку управление данными становится общепринятым. Мы также отмечаем, что концепция разработки на основе наблюдения за данными (DODD — Data Observability Driven Development) Энди Петрелла тесно связана с линией данных. DODD наблюдает за данными по всей их линии. Этот процесс применяется во время разработки, тестирования и, наконец, производства для обеспечения качества и соответствия ожиданиям.

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

Все чаще интеграция происходит через API общего назначения, а не через пользовательские соединения с базами данных. Например, конвейер данных может извлекать данные из Salesforce API, сохранять их в Amazon S3, вызывать Snowflake API для загрузки в таблицу, снова вызывать API для выполнения запроса, а затем экспортировать результаты в S3, где Spark может их использовать.

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

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

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

Во-вторых, законы о конфиденциальности и хранении данных, такие как GDPR и CCPA, требуют от инженеров данных активно управлять уничтожением данных, чтобы уважать «право пользователей быть забытыми». Инженеры данных должны знать, какие данные потребителей они хранят, и должны иметь процедуры для уничтожения данных в ответ на запросы и требования соответствия.

Уничтожение данных в облачном хранилище данных осуществляется просто. Семантика SQL позволяет удалять строки, соответствующие условию where. Уничтожение данных было более сложным в озёрах данных, где шаблоном хранения по умолчанию была запись один раз, чтение много раз. Такие инструменты, как Hive ACID и Delta Lake, позволяют легко управлять транзакциями удаления в масштабе. Новые поколения инструментов управления метаданными, происхождения данных и каталогизации также упростят завершение жизненного цикла инженерии данных.

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

Как этика и конфиденциальность влияют на жизненный цикл инженерии данных? Инженеры данных должны гарантировать, что наборы данных скрывают персональные данные (PII) и другую конфиденциальную информацию; предвзятость может быть выявлена ​​и отслежена в наборах данных по мере их преобразования. Нормативные требования и штрафы за несоблюдение требований только растут. Убедитесь, что ваши активы данных соответствуют растущему числу нормативных актов, таких как GDPR и CCPA. Пожалуйста, отнеситесь к этому серьёзно. Мы даем советы на протяжении всей книги, чтобы убедиться, что вы встраиваете этику и конфиденциальность в жизненный цикл инженерии данных.

DataOps сопоставляет лучшие практики Agile-методологии, DevOps и статистического управления процессами (SPC) с данными. В то время как DevOps нацелен на улучшение выпуска и качества программных продуктов, DataOps делает то же самое для продуктов данных.

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

Как и DevOps, DataOps многое заимствует из бережливого производства и управления цепочками поставок, смешивая людей, процессы и технологии для сокращения времени получения ценности. Как описывает это Data Kitchen (эксперты в DataOps):

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

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

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

DataOps имеет три основных технических элемента: автоматизация, мониторинг и наблюдаемость, а также реагирование на инциденты (рисунок 2-8). Давайте рассмотрим каждый из этих элементов и то, как они соотносятся с жизненным циклом инженерии данных.

Автоматизация обеспечивает надежность и согласованность в процессе DataOps и позволяет инженерам данных быстро развёртывать новые функции продукта и улучшения в существующих рабочих процессах. Автоматизация DataOps имеет схожую структуру и рабочий процесс с DevOps, состоящий из управления изменениями (среда, код и контроль версий данных), непрерывной интеграции/непрерывного развертывания (CI/CD) и конфигурации как кода. Как и DevOps, практики DataOps отслеживают и поддерживают надёжность технологий и систем (конвейеры данных, оркестровка и т. д.) с дополнительным измерением проверки качества данных, дрейфа данных/моделей, целостности метаданных и т. д.

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

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

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

Один из принципов DataOps Manifesto — «Примите изменения». Это не означает изменения ради изменений, а скорее целенаправленные изменения. На каждом этапе нашего пути к автоматизации существуют возможности для операционного улучшения. Даже на высоком уровне зрелости, который мы описали здесь, остаётся ещё много места для улучшения. Инженеры могут принять структуру оркестрации следующего поколения, которая встраивает лучшие возможности метаданных. Или они могут попытаться разработать структуру, которая автоматически создаёт DAG на основе спецификаций линии передачи данных. Главное, что инженеры постоянно стремятся внедрять в автоматизацию улучшения, которые сократят их рабочую нагрузку и увеличат ценность, которую они приносят бизнесу.

Как мы говорим нашим клиентам: «Данные — это молчаливый убийца». Мы видели бесчисленные примеры плохих данных, которые оставались в отчётах месяцами или годами. Руководители могут принимать ключевые решения на основе этих плохих данных, обнаруживая ошибку лишь гораздо позже. Результаты обычно плохие, а иногда и катастрофические для бизнеса. Инициативы подрываются и уничтожаются, годы работы тратятся впустую. В некоторых из худших случаев плохие данные могут привести компании к финансовому краху.

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

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

Метод DODD Петреллы, упомянутый ранее в этой главе, обеспечивает прекрасную основу для размышлений о наблюдаемости данных. DODD во многом похож на разработку через тестирование (TDD) в программной инженерии:

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

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

Высокофункциональная команда по работе с данными, использующая DataOps, сможет быстро поставлять новые продукты данных. Но ошибки неизбежно будут происходить. Система может простаивать, новая модель данных может нарушить последующие отчёты, модель МО может устареть и давать плохие прогнозы — бесчисленные проблемы могут прерывать жизненный цикл инженерии данных. Реагирование на инциденты заключается в использовании возможностей автоматизации и наблюдения, упомянутых ранее, для быстрого выявления основных причин инцидента и его максимально надёжного и быстрого устранения.

Реагирование на инциденты касается не только технологий и инструментов, хотя они и полезны; это также открытая и безупречная коммуникация, как в команде по инженерии данных, так и во всей организации. Как сказал Вернер Фогельс, технический директор Amazon Web Services, «Всё постоянно ломается». Инженеры данных должны быть готовы к катастрофе и готовы отреагировать максимально быстро и эффективно.

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

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

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

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

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

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

Оркестрация — это не только центральный процесс DataOps, но и важнейшая часть процесса проектирования и развёртывания для заданий по работе с данными. Итак, что такое оркестрация?

Оркестрация (Orchestration) — это процесс координации множества заданий для максимально быстрого и эффективного выполнения по запланированному графику. Например, люди часто называют инструменты оркестрации, такие как Apache Airflow, планировщиками. Это не совсем точно. Чистый планировщик, такой как cron, учитывает только время; механизм оркестрации встраивает метаданные в зависимости заданий, как правило, в форме направленного ациклического графа (DAG). DAG может быть запущен один раз или запланирован для запуска с фиксированным интервалом ежедневно, еженедельно, каждый час, каждые пять минут и т. д.

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

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

Оркестрация долгое время была ключевой возможностью для обработки данных, но часто была не на первом месте и не была доступна никому, кроме крупнейших компаний. Предприятия использовали различные инструменты для управления потоками работ, но они были дорогими, недоступными для небольших стартапов и, как правило, не расширяемыми. Apache Oozie был чрезвычайно популярен в 2010-х годах, но он был разработан для работы в кластере Hadoop и был сложен для использования в более гетерогенной среде. Facebook разработал Dataswarm для внутреннего использования в конце 2000-х годов; это вдохновило на создание таких популярных инструментов, как Airflow, представленного Airbnb в 2014 году.

Airflow был проектом с открытым исходным кодом с самого начала и получил широкое распространение. Он был написан на Python, что делает его чрезвычайно расширяемым практически для любого вообразимого сценария использования. Хотя существует множество других интересных проектов оркестрации с открытым исходным кодом, таких как Luigi и Conductor, Airflow, возможно, является лидером по интересу на данный момент. Airflow появился как раз тогда, когда обработка данных становилась всё более абстрактной и доступной, и инженеры всё больше интересовались координацией сложных потоков между несколькими процессорами и системами хранения, особенно в облачных средах.

На момент написания статьи несколько зарождающихся проектов с открытым исходным кодом стремятся имитировать лучшие элементы базовой конструкции Airflow, одновременно улучшая его в ключевых областях. Некоторые из наиболее интересных примеров — Prefect и Dagster, которые направлены на улучшение переносимости и тестируемости DAG, чтобы инженеры могли легче переходить от локальной разработки к производству. Argo — это движок оркестрации, построенный на примитивах Kubernetes; Metaflow — это проект с открытым исходным кодом от Netflix, направленный на улучшение оркестрации науки о данных.

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

Программная инженерия всегда была центральным навыком для инженеров данных. На заре современной инженерии данных (2000–2010 гг.) инженеры данных работали над низкоуровневыми фреймворками и писали задания MapReduce на C, C++ и Java. На пике эпохи больших данных (середина 2010-х гг.) инженеры начали использовать фреймворки, которые абстрагировали эти низкоуровневые детали.

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

Хотя он стал более абстрактным и более простым в управлении, основной код обработки данных всё ещё необходимо писать, и он появляется на протяжении всего жизненного цикла инженерии данных. Будь то поглощение, преобразование или пердоставление данных, инженеры должны быть высококвалифицированными и продуктивными в таких фреймворках и языках, как Spark, SQL или Beam; мы отвергаем представление о том, что SQL — это не код.

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

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

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

Например, Airflow доминировал в пространстве оркестрации с 2015 года до начала 2020-х годов. Теперь появилась новая группа конкурентов с открытым исходным кодом (включая Prefect, Dagster и Metaflow), чтобы исправить предполагаемые ограничения Airflow, обеспечив лучшую обработку метаданных, переносимость и управление зависимостями. Куда будет развиваться будущее оркестрации, можно только гадать.

Прежде чем инженеры данных начнут разрабатывать новые внутренние инструменты, им стоит изучить ландшафт общедоступных инструментов. Следите за совокупной стоимостью владения (TCO) и альтернативными издержками, связанными с внедрением инструмента. Есть большая вероятность, что для решения проблемы уже существует проект с открытым исходным кодом, и стоит сотрудничать, а не изобретать велосипед.

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

Например, задачи обработки данных, такие как объединения, которые мы принимаем как должное в мире пакетной обработки, часто становятся более сложными в реальном времени, требуя более сложной программной инженерии. Инженеры также должны писать код для применения различных методов окон. Оконные методы позволяют системам реального времени вычислять ценные метрики, такие как конечная статистика. Инженеры могут выбирать из множества фреймворков, включая различные функциональные платформы (OpenFaaS, AWS Lambda, Google Cloud Functions) для обработки отдельных событий или выделенные потоковые процессоры (Spark, Beam, Flink или Pulsar) для анализа потоков для поддержки отчетности и действий в реальном времени.

Инфраструктура как код (Infrastructure as code — IaC) применяет методы разработки программного обеспечения к настройке и управлению инфраструктурой. Нагрузка на управление инфраструктурой в эпоху больших данных снизилась, поскольку компании перешли на управляемые системы больших данных, такие как Databricks и Amazon Elastic MapReduce (EMR), и облачные хранилища данных. Когда инженерам данных приходится управлять своей инфраструктурой в облачной среде, они всё чаще делают это через фреймворки IaC, а не вручную запускают экземпляры и устанавливают программное обеспечение. Несколько универсальных и специфичных для облачных платформ фреймворков позволяют автоматизировать развёртывание инфраструктуры на основе набора спецификаций. Многие из этих фреймворков могут управлять облачными сервисами, а также инфраструктурой. Существует также понятие IaC с контейнерами и Kubernetes, использующее такие инструменты, как Helm.

Эти практики являются важной частью DevOps, позволяя контролировать версии и повторяемость развёртываний. Естественно, эти возможности жизненно важны на протяжении всего жизненного цикла инженерии данных, особенно по мере того, как мы внедряем практики DataOps.

Контейнеры как код (Pipelines as code) — это основная концепция современных систем оркестрации, которая затрагивает каждый этап жизненного цикла инженерии данных. Инженеры данных используют код (обычно Python) для объявления задач данных и зависимостей между ними. Механизм оркестрации интерпретирует эти инструкции для выполнения шагов с использованием доступных ресурсов.

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

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

Мы делим жизненный цикл инженерии данных на следующие этапы:

• Генерация (Generation)
• Хранение (Storage)
• Поглощение (Ingestion)
• Преобразование (Transformation)
• Предоставление (Serving)

Несколько тем также пересекают жизненный цикл инженерии данных. Это фоновые процессы жизненного цикла. На высоком уровне фоновые процессы следующие:

• Безопасность
• Управление данными
• DataOps
• Архитектура данных
• Оркестрация
• Программная инженерия

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

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