Data Engineering Design Patterns, глава 1: Введение в паттерны

Главная мысль: Design pattern в data engineering - это готовый шаблон решения типовой проблемы. Он не привязан к инструменту. Его нужно адаптировать, и у него есть цена.

Что такое design pattern

Автор объясняет идею на примере рецепта. Рецепт - это шаблон: список шагов и ингредиентов. Его можно менять, например заменить один сахар другим. У паттерна те же свойства.

Свойство	Что значит
Шаблон	Готовая последовательность шагов. Её можно настроить
Контекст	Паттерн отвечает на конкретную проблему
Повторное использование	Не нужно изобретать решение заново
Последствия	У каждого паттерна есть цена. Её нужно знать заранее
Общий язык	Команда быстрее договаривается, если все знают названия

Пример: Dead-Letter

Проблема: одна битая запись роняет всю задачу.
Шаблон: обернуть рискованную трансформацию в try-catch. Плохие записи отправить в отдельное место для анализа.
Адаптация: можно не сохранять такие записи, а только считать их.
Повторное использование: тот же подход работает в ELT и в хранилище.
Цена: в код добавляется логика, он становится сложнее.

Этот паттерн разобран в главе 3.

Почему не хватает паттернов GoF

Паттерны Gang of Four (например, Singleton) помогают писать поддерживаемый код.
Для data engineering этого мало. Нужно думать о данных.
Особые темы: ошибки, backfilling, idempotency, корректность данных.

Карта книги

Главы идут по пути данных: от загрузки до мониторинга.

Глава	Тема	О чём
2	Data ingestion	Как принести данные в систему
3	Error management	Как жить с ошибками в коде и в данных
4	Idempotency	Как безопасно делать повторные запуски и `backfill`
5	Data value	Как сделать данные полезными: агрегация, обогащение
6	Data flow	Как связать пайплайны друг с другом
7	Data security	Как защитить данные и соблюсти требования приватности
8	Data storage	Как хранение ускоряет доступ к данным
9	Data quality	Как проверить, что данные годны
10	Data observability	Как следить за данными и получать алерты

Учебный проект книги

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

Проект состоит из трёх частей:

Загрузка online и offline. Online: события посетителей блогов (посещения страниц). Offline: статичные наборы от провайдеров, например справочники. Они обновляются реже, скажем раз в час.
Real-time слой. Streaming-задачи читают события из брокера. Есть бизнес-задачи, например агрегация сессий. Есть технические, например синхронизация данных в хранилище для ad hoc запросов.
Слой организации данных. Это Medallion architecture.

Medallion: Bronze, Silver, Gold

Слой	Что хранит
Bronze	Сырые данные как есть. Возможны проблемы качества
Silver	Очищенные и обогащённые данные
Gold	Данные в формате для потребителей: витрины, справочники

Паттерны, которые влияют на бизнес-ценность, обычно отдают данные в Gold. Остальные работают в Bronze и Silver. В описании проблем автор часто ссылаются на эти слои. Над всем стоят оркестратор и observability.

В каждом паттерне есть раздел Examples. Там показаны реализации на разных технологиях.

Ключевые термины

Термин	Значение
Design pattern	Готовый шаблон решения типовой проблемы
Contextualization	Привязка паттерна к проблеме
Consequences	Цена и риски паттерна
Backfilling	Повторная обработка прошлых данных
Medallion architecture	Слои Bronze, Silver, Gold
Dead-Letter	Отправка плохих записей в отдельное место

Что это значит на практике

Называйте решения паттернами. Так проще обсуждать дизайн в команде и в код-ревью.
Перед выбором паттерна читайте его последствия. Бесплатных паттернов нет.
Привязывайте паттерн к слою: Bronze, Silver или Gold. Требования к ним разные.
Не копируйте паттерн слепо. Адаптируйте под свой контекст.

Вопросы для самопроверки

Какие пять свойств рецепта автор переносит на design pattern?
Почему паттернов GoF недостаточно для data engineering?
Чем отличаются слои Bronze, Silver и Gold?
Какие у паттерна Dead-Letter последствия?

Предыдущая: Обзор книги. Следующая: Паттерны загрузки данных.