System Design Space

    Глава 97

    Обновлено: 15 февраля 2026 г. в 08:07

    Data Pipeline / ETL / ELT Architecture

    Прогресс части0/21

    Как проектировать data pipeline: batch + streaming, ETL vs ELT, orchestration, data quality, recovery, cost control и операционная надежность.

    База

    Streaming Data

    Фундамент по batch/stream thinking, delivery semantics и уровню обработки данных.

    Открыть главу

    Data Pipeline / ETL / ELT Architecture - это проектирование контура, который reliably и предсказуемо превращает сырые события и записи в полезные витрины для аналитики, ML и продуктовых API. Ключевая инженерная задача здесь не только в трансформациях, но и в надежности пайплайнов: idempotency, replay, data quality, observability, cost governance и восстановление после сбоев.

    ETL vs ELT: как выбрать

    ETL

    Transform до загрузки в целевое хранилище.

    Когда подходит

    • Строгие требования к качеству данных до попадания в DWH.
    • Ограниченные ресурсы целевого хранилища.
    • Нужна предсказуемая схема данных на входе.

    Риски

    • Сложнее переиспользовать сырые данные для новых кейсов.
    • Изменение бизнес-логики часто требует переобработки upstream-слоя.

    ELT

    Сырые данные сначала грузятся в storage/warehouse, transform позже.

    Когда подходит

    • Нужна высокая скорость ingestion и гибкость аналитики.
    • Команда активно экспериментирует с моделями и витринами.
    • Есть мощный compute-слой в DWH/Lakehouse.

    Риски

    • Без governance и cost-control легко получить дорогой хаос.
    • Нужны строгие политики качества и контроля доступа к raw-слою.

    Reference architecture data pipeline

    1

    Ingestion

    CDC, API pull, events, файловые загрузки. Важно контролировать schema drift и idempotency.

    2

    Raw / Bronze

    Immutable слой с сырыми данными для replay и аудитов. Минимум бизнес-логики.

    3

    Transform / Silver

    Очистка, дедупликация, стандартизация времени, enrichment и согласование ключей.

    4

    Serving / Gold

    Доменные витрины и агрегаты под BI, ML, API и operational workloads.

    5

    Orchestration + Quality

    Планировщик DAG, dependency graph, retries, SLA/SLO, data tests, lineage и alerting.

    Hybrid Lakehouse

    Гибридный режим: stream обновляет serving быстро, batch делает контрольные пересчеты и backfill для консистентности.

    Плюсы

    • Комбинирует низкую задержку и высокую точность.
    • Удобно для incremental + periodic full recalculation.
    • Один raw слой для replay и обеих стратегий обработки.

    Ограничения

    • Наиболее сложная операционная модель.
    • Требует дисциплины в orchestration и cost governance.
    Подходит для: Крупные data platform контуры с mixed workload.

    Incoming Jobs

    JOB-201
    batch
    Orders DB
    orders_daily
    JOB-202
    stream
    Payments Kafka
    payments_rt
    JOB-203
    batch
    CRM API
    crm_sync
    JOB-204
    stream
    Mobile Events
    product_events

    Pipeline Engine

    Batch и stream работают совместно поверх общего raw.

    Готово к симуляции пайплайна. Можно запустить авто-режим или пройти шаги вручную.

    Последнее решение

    Активный шаг: idle

    Ingestion

    0

    CDC / API / events

    Raw / Bronze

    0

    Immutable landing zone

    Transform

    0

    Batch + stream transform

    Serving / Gold

    0

    BI, ML, APIs

    Control Plane

    Orchestration + Quality + Lineage + Cost

    Этот контур активен всегда и определяет надежность пайплайна независимо от профиля.

    Processed Counters

    Ingested: 0 | Landed: 0 | Transformed: 0 | Served: 0

    Следите, чтобы скорость ingest/transform/serve не расходилась на длинных интервалах.

    Data Contracts Checklist

    Schema versioning
    Freshness / completeness
    Idempotent replay

    Related

    Observability & Monitoring Design

    Как строить метрики, алерты и runbooks для production-пайплайнов.

    Открыть главу

    Надежность и эксплуатация

    • Exactly-once не всегда реалистичен: закладывайте at-least-once + idempotent processing.
    • Для backfill задавайте отдельный контур, чтобы не ломать online SLA.
    • Каждый pipeline должен иметь owner, runbook и SLO по freshness/completeness.
    • Храните checkpoint/offset state в отказоустойчивом backend-е.
    • Учитывайте data contracts между producer и consumer и версионируйте схемы.

    Частые ошибки

    Один гигантский DAG на всю компанию без доменных границ.

    Скрытая бизнес-логика в SQL-скриптах без тестов и code review.

    Отсутствие наблюдаемости: есть только 'job failed', но нет data quality сигналов.

    Смешение batch и streaming без стратегии late-arriving events.

    Непрозрачная стоимость: нет budget guardrails на compute и storage.

    Связанные главы

    References