Команда VK Cloud перевела статью, в которой автор кратко излагает основные мысли книги Джо Рейса и Мэтта Хаусли Fundamentals of Data engineering. Здесь приводится краткий конспект глав и самые важные моменты, которые полезно знать любому человеку, работающему с данными.

О чём эта книга

Fundamentals of Data engineering — это фундаментальный труд, который рекомендуют множество опытных дата-инженеров. Он помогает понять, как применять концепции создания данных, подключения источников данных, оркестрации, преобразования, хранения и Governance — критически важные в любой среде данных вне зависимости от технологий, на которых она строится.


Изображение О’Рейли

Глава 1. Что такое Data engineering

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

Глава 2. Жизненный цикл дата-инжиниринга

Жизненный цикл дата-инжиниринга состоит из пяти этапов:

1. Генерирование (исходные системы). Исходная система — это место происхождения данных, используемых в жизненном цикле дата-инжиниринга. Дата-инженер должен знать, как работают исходные системы, как и какие именно данные они генерируют, насколько часто и быстро это происходит.
   
2. Хранение. Правильное решение для хранения данных — это ключ к успеху всего жизненного цикла обработки. Выбор системы хранения определяется сценариями использования, объёмами, периодичностью поступления, форматом и размером данных.
   
3. Приём. Пакетный или потоковый приём данных. Учитывайте сценарии использования и преимущества потокового режима, оптимальные инструменты для этих ситуаций и бизнес-кейсы, способные компенсировать недостатки выбранного подхода. Потоковый приём данных не всегда легко организовать, постоянно возникают дополнительные расходы и осложнения. Пакетный режим отлично подходит для многих распространённых задач — например, для обучения моделей и рассылки еженедельных отчётов.
   
4. Преобразование. На этапе преобразования данные начинают представлять ценность для потребления пользователями на следующих этапах работы. Обычно данные преобразуются в исходных системах или во время приёма. Главный фактор, определяющий ход преобразования, — это бизнес-логика.
   
5. Предоставление данных. Ценность данных возникает, когда они используются для практических целей. К популярным сценариям использования относится аналитика (в том числе бизнес-аналитика, операционная и встроенная аналитика), машинное обучение и Reverse ETL.
   

Изображение из книги

Глава 3. Проектирование хорошей архитектуры данных

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

Принципы проектирования хорошей архитектуры данных:

• Вдумчиво выбирайте общие компоненты.
  
• Учитывайте возможные сбои.
  
• Создавайте масштабируемую архитектуру.
  
• Архитектура — это форма управления.
  
• Постоянно работайте над архитектурой.
  
• Создавайте системы со слабыми связями.
  
• Принимайте обратимые решения.
  
• Ставьте безопасность на первое место.
  
• Не забывайте о FinOps.
  

Глава 4. Технологии для жизненного цикла дата-инжиниринга

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

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

Глава 5. Генерирование данных в исходных системах

Данные могут поступать из следующих источников:

• файлы и неструктурированные данные;
  
• API;
  
• базы данных приложений (OLTP-системы);
  
• системы аналитической обработки (OLAP);
  
• отслеживание изменённых данных (Change Data Capture) — метод извлечения каждого изменения (вставки, обновления, удаления), которое происходит в базе данных;
  
• логи: фиксируют информацию о событиях, которые происходят в системе;
  
• логи базы данных;
  
• CRUD (Create, Read, Update и Delete).
  

Глава 6. Хранение

Хранение — самая важная часть процесса дата-инжиниринга. Это фундамент трёх основных этапов: приёма, преобразования и обслуживания.

1. Локальное или распределённое хранилище. В распределённом хранилище для хранения, извлечения и обработки данных используется множество серверов. Они выполняют эти задачи быстрее, справляются с большими масштабами и поддерживают избыточность в случае сбоя сервера.
   
2. Согласованность в конечном счёте или строгая согласованность (Eventual vs Strong Consistency). В распределённых системах есть два распространённых паттерна: согласованность в конечном счёте и строгая согласованность. Согласованность в конечном счёте позволяет получать данные быстро, но в этом случае система не проверяет, точно ли вы получили  самую последнюю версию. Это распространённый компромисс в крупномасштабных распределённых системах. Строгая согласованность в распределённой базе данных работает так: при распространении данных для операций записи на каждом узле сначала достигается консенсус, так что каждая операция чтения возвращает согласованные результаты. Строгая согласованность используется, когда имеет смысл примириться с относительно высоким временем задержки при выполнении запроса ради того, чтобы каждый раз получать корректные данные.
   
3. Файловое хранилище. Файл — это тип элемента данных, с помощью которого операционные системы и программное обеспечение читают, записывают данные и ссылаются на них.
   
4. Блочное хранилище. Это тип хранилища необработанных данных, реализуемый в SSD и магнитных дисках.
   
5. Объектное хранилище. Содержит объекты всех форм и размеров. Это может быть файл любого типа: TXT, CSV, JSON, изображение, видео или аудио. Как правило, объектные хранилища не поддерживают in-place-обновления объектов.
   
6. Системы хранения на базе кэша и памяти. Системы на базе RAM отличаются высокой пропускной способностью и скоростью доступа к данным. Если дата-инженеру нужно сверхбыстро извлечь данные, ему на помощь приходят эти системы с кэшем.
   
7. Распределённая файловая система Hadoop. Для обработки данных в распределённой файловой системе Hadoop, созданной на основе Google File System (GFS), используется модель программирования MapReduce. Hadoop похож на объектное хранилище, но с одним большим отличием: он сохраняет и обрабатывает данные на одних и тех же узлах, а у объектного хранилища обычно такой возможности нет.
   
8. Потоковое хранилище. Потоковые данные нужно хранить особенным образом. В очереди сообщений хранящиеся данные являются временными: они исчезают через какое-то время. Сегодня распределённые масштабируемые потоковые системы типа Apache Kafka обеспечивают чрезвычайно длительное хранение данных.
   
9. Индексы, секционирование и кластеризация. Индексы создают схему таблицы для отдельных полей и позволяют очень быстро находить конкретные записи. Без индексов базе данных понадобилось бы сканировать всю таблицу, чтобы найти записи, удовлетворяющие условию WHERE. С помощью кластеров можно организовать очень продуманное размещение данных по партициям. Схема кластеризации, применяемая в столбчатой базе данных, сортирует информацию по одному или нескольким полям, размещая похожие значения рядом.
   

Абстракции хранилища

Идея абстракции хранилища сводится к нескольким соображениям:

• цель и сценарии использования;
  
• паттерны обновления;
  
• стоимость;
  
• разделение слоёв хранения и вычисления;
  

Типы абстракций

1. Облачное хранилище. Оно может работать с огромными объёмами текстовых и сложных JSON-документов. В отличие от озёр данных, облачные хранилища не могут обрабатывать неструктурированные данные, такие как фотографии, видео и аудио.
   
2. Озеро данных. Изначально задумывалось как массивное хранилище необработанных данных.
   
3. Data lakehouse. Data lakehouse — это архитектура, в которой сочетаются свойства хранилища и озера данных. Это уровень метаданных и управления файлами, развёртываемый вместе с инструментами для управления и преобразования. Основное преимущество Data lakehouse по сравнению с проприетарными инструментами — интероперабельность.
   

Глава 7. Приём данных

Это процесс перемещения данных из одного места в другое. Основные моменты, которые следует учитывать на этапе приёма:

• Bounded vs. unbounded. Unbounded-данные — это данные в том виде, в каком они существуют в реальности, когда происходят события: спорадические или постоянные, непрерывные и текущие. Bounded-данные — это удобный способ группировки через определённую границу, например временную. Все данные являются Unbounded, пока им не присвоили определённые ограничения.
  
• Частота. Пакет (часто), микропакет (реже) или в реальном времени (очень часто).
  
• Синхронно или асинхронно. При синхронном приёме данных у источника, приёма и пункта назначения есть сложные зависимости, к тому же они тесно связаны между собой. При асинхронном приёме данных зависимости могут функционировать на уровне индивидуальных событий, примерно так, как они работали бы в бэкенде программы на основе микросервисов.
  

Синхронный приём данных (изображение из книги)


Асинхронный приём данных (изображение из книги)

• Сериализация и десериализация. Сериализация — это кодирование данных из источника и подготовка структур данных для передачи и хранения на промежуточных этапах. При подключении источников убедитесь, что в пункте назначения можно выполнить десериализацию поступивших данных.
  
• Пропускная способность и масштабируемость. Используйте PaaS или SaaS, поддерживающие масштабирование пропускной способности.
  
• Надёжность и устойчивость. Надёжность подразумевает высокое время доступности и надлежащую отработку отказа для систем приёма данных; устойчивость подразумевает, что данные не будут потеряны или испорчены.
  
• Полезная рабочая нагрузка. Речь идёт о датасете с определёнными характеристиками, такими как вид, форма, размер, схема и типы, а также с метаданными.
  
• Push vs Pull vs Polling. Исходная Push-система отправляет данные в  целевую систему. В случае Pull целевая система считывает данные непосредственно из источника, а Polling периодически проверяет изменения в источнике данных.
  

Приём сообщений и потоковых данных

• Эволюция схемы. Можно добавлять или удалять поля, менять типы значений — использовать реестр схем, очередь недоставленных сообщений и эффективно сообщать о возможных изменениях схемы.
  
• Порядок доставки и одновременная доставка. Платформы потоковой обработки данных обычно строятся на основе распределённых систем, что может вызвать некоторые осложнения. Сообщения могут доставляться вне очереди и по несколько раз (по принципу «как минимум однократная доставка»).
  
• Обработка ошибок и очереди недоставленных сообщений. Очередь недоставленных сообщений отделяет проблемные события от событий, которые можно доставить потребителю.
  
• Размещение в облаках. Чем приём данных ближе к месту их возникновения, тем выше пропускная способность и тем меньше время задержки. Но здесь нужно обеспечить баланс со стоимостью перемещения данных между регионами, в которых анализируется объединённый датасета.
  

Глава 8. Запросы, моделирование и преобразование

Запрос позволяет извлекать данные и выполнять с ними действия.

Повышение производительности запросов

1. Оптимизируйте стратегию и схему JOIN. Создавайте pre-joined-таблицы и учите пользователей работать с ними или объединять таблицы в материализованных представлениях, повышайте эффективность Complex joins, используйте обобщённые табличные выражения (CTE) вместо вложенных запросов или временных таблиц.
   
2. Придерживайтесь Explained plan — отображения процесса выполнения вашего запроса в БД. И анализируйте производительность ваших запросов.
   
3. Избегайте полного сканирования таблиц.
   
4. Выясните, как ваша база данных обрабатывает коммиты. Например, какие различия в работе PostgreSQL, BigQuery, MongoDB.
   
5. Удаляйте неиспользуемые записи в процессе очистки.
   
6. Используйте результаты кэшированных запросов.
   

Медленно меняющееся измерение (SCD)

Медленно меняющееся измерение (SCD) позволяет отслеживать изменения в измерениях.

Тип 1. Затирает имеющиеся в измерении записи. При этом не сохраняется доступ к удалённым записям измерения за прошедшие периоды.

Тип 2. Сохраняется полная история записей измерения. Когда в запись вносятся изменения, напротив неё ставится пометка «Изменено», и в измерении создается новая запись, которая отражает текущий статус атрибутов.

Тип 3. SCD типа 3 похоже на SCD типа 2, но вместо новой строки в изменении SCD типа 3 создаётся новое поле.

Пакетное преобразование — JOIN

• Distributed join. Нужно разбить логическую операцию JOIN на гораздо меньшие операции JOIN на уровне узла, которые работают на отдельных серверах в кластере.
  
• Broadcast join. Как правило, асимметричная операция с одной большой таблицей, распределённой по узлам, и одной маленькой таблицей, которая легко умещается на одном узле.
  
• Shuffle hash join. Если все таблицы слишком велики, чтобы уместиться на одном узле, то механизм обработки запросов будет использовать shuffle hash join.
  

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

Глава 9. Обслуживание данных для аналитики, машинного обучения и Reverse ETL

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

Главы 10 и 11. Безопасность, конфиденциальность и будущее дата-инжиниринга

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

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

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