Spark в дата-пайплайне: облако, форматы и что дальше

Завершающий урок собирает картину: где Spark живёт в реальном дата-стеке, с чем работает рядом и куда расти дальше.

Дата-пайплайн — конвейер от источников данных через обработку к витринам и потребителям; Spark в нём обычно отвечает за тяжёлую трансформацию (слой T в ETL/ELT).

Где Spark в общей картине

Spark редко стоит особняком — он один из узлов конвейера данных. Типичная схема такова: данные поступают из источников (базы, события, файлы), оркестратор по расписанию запускает обработку, Spark делает тяжёлые трансформации, результат ложится в хранилище (data lake / lakehouse) в виде таблиц, откуда его читают BI, ML и аналитики. Spark здесь — «движок трансформаций», а не вся система.

ETL и ELT: где здесь Spark

Классически конвейер описывают аббревиатурой ETL (Extract — извлечь из источников, Transform — преобразовать, Load — загрузить в хранилище). Spark — это буква T: тяжёлая трансформация. В последние годы популярен вариант ELT — сначала загрузить сырьё как есть (Load), а трансформировать (Transform) уже внутри хранилища/lakehouse. Разница в том, где и когда происходит преобразование, но роль Spark как движка трансформаций сохраняется в обоих подходах. Понимать это полезно, потому что от выбора ETL/ELT зависит, читает ли ваш Spark-джоб сырые данные из источника или уже сложенные в data lake таблицы.

Оркестрация: Airflow и почему Spark сам себя не запускает

Spark выполняет одну задачу обработки. Но реальный пайплайн — это десятки задач с зависимостями («сначала загрузить сырьё, потом очистить, потом построить витрину, при ошибке — повторить, по готовности — уведомить»). Этим управляет оркестратор, чаще всего Airflow: он описывает пайплайн как граф задач (DAG — здесь в смысле графа шагов пайплайна, не путать с DAG вычислений внутри Spark), запускает Spark-джобы по расписанию, следит за успехом/повторами и связывает шаги. Spark — исполнитель отдельного шага; Airflow — дирижёр всего конвейера.

Источник потока: Kafka

Для потоковых пайплайнов главный источник — Apache Kafka, распределённая шина событий. События (клики, транзакции, логи) пишутся в Kafka, а Spark Structured Streaming читает их оттуда и обрабатывает в реальном времени (раздел 6.1). Связка «Kafka → Spark Streaming → таблица» — стандарт потоковой аналитики.

Lakehouse: Delta и Iceberg вместо «просто Parquet»

Мы хвалили Parquet, но у «голого» Parquet в data lake есть слабые места: нет транзакций (одновременная запись и чтение могут увидеть полуготовые данные), нет версионирования, тяжело делать обновления/удаления отдельных строк. Эти проблемы решают табличные форматы поверх Parquet — Delta Lake и Apache Iceberg (а также Hudi). Они добавляют слой метаданных и журнал транзакций, давая:

• ACID-транзакции — атомарность записи, отсутствие «грязного» чтения недописанных данных;
• time travel — чтение состояния таблицы на момент в прошлом (версии);
• UPDATE/DELETE/MERGE и эволюцию схемы — то, чего обычному Parquet не хватает.

Сочетание «data lake + такой табличный формат» называют lakehouse: дёшево и масштабируемо как озеро данных, но с надёжностью таблиц как у хранилища. В современных Spark-пайплайнах целевые таблицы чаще пишут именно в Delta/Iceberg, а не в сырой Parquet.

Облако: Databricks, EMR, Glue

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

• Databricks — платформа от создателей Spark: управляемые кластеры, ноутбуки, оптимизированный рантайм, родной Delta Lake. Самый «богатый» вариант.
• Amazon EMR — управляемые кластеры Spark/Hadoop в AWS; гибко, ближе к «сырому» Spark.
• AWS Glue — serverless-Spark: не управляешь кластером вообще, платишь за выполнение; удобно для нерегулярных ETL.

Выбор — баланс между контролем (EMR), удобством и фичами (Databricks) и отсутствием инфраструктурных забот (Glue).

Что дальше

Куда двигаться, освоив этот курс:

• Практика на реальных данных. Возьмите большой открытый датасет, постройте пайплайн, читайте план в Spark UI, ловите и чините shuffle и перекос — теория закрепляется только так.
• Глубже в производительность. Подробнее AQE, тонкая настройка памяти, продвинутые приёмы против перекоса, бакетирование (bucketing) для повторяющихся join.
• Lakehouse-форматы. Освойте Delta или Iceberg вплотную — это де-факто стандарт целевого слоя.
• Оркестрация и продакшн. Airflow, мониторинг, идемпотентность, обработка сбоев — инженерная зрелость пайплайнов.
• Стриминг. Углубитесь в Kafka + Structured Streaming, состояние, watermarks и доставку exactly-once.

Подводные камни

• «Spark — это весь пайплайн». Spark — движок обработки одного шага; оркестрацию, хранение и доставку обеспечивают другие инструменты.
• Сырой Parquet для изменяемых таблиц. Без транзакций конкурентная запись и обновления строк ненадёжны; для целевых таблиц берите Delta/Iceberg.
• Свой кластер «по привычке». Самостоятельное обслуживание кластера дорого; управляемые сервисы часто выгоднее по совокупной стоимости.

Best practices

• Рассматривайте Spark как один узел конвейера: источники → оркестратор → Spark → lakehouse-таблицы.
• Оркеструйте пайплайны (Airflow), а не запускайте Spark-джобы вручную.
• Целевые таблицы пишите в Delta/Iceberg ради ACID, версионирования и обновлений.
• В продакшне предпочитайте управляемый Spark (Databricks/EMR/Glue) самостоятельному кластеру.
• Закрепляйте знания на реальном датасете, читая планы и метрики в Spark UI.

Итог

• Spark — движок обработки в пайплайне: источники (Kafka, БД) → оркестратор (Airflow) → Spark → таблицы.
• Delta Lake и Iceberg добавляют поверх Parquet ACID, time travel и UPDATE/DELETE — основа lakehouse.
• В облаке Spark берут как сервис: Databricks (богатый), EMR (гибкий), Glue (serverless).
• Дальше — практика на реальных данных, lakehouse-форматы, оркестрация и стриминг.