Мы разобрались, что такое Spark и Kafka по отдельности. Теперь главное: где каждый из них живёт в реальной DE-инфраструктуре, как они взаимодействуют, и какие у них альтернативы. Это даст тебе целостную картину ландшафта инструментов и поможет понимать, какой инструмент в какой роли встретишь на работе.
Spark и Kafka: типичный flow
В большинстве production-стеков Kafka и Spark работают вместе, в разных ролях:
- Kafka — backbone для streaming событий. Принимает поток событий от множества источников, хранит их в append-only логе, отдаёт обработчикам.
- Spark — engine для трансформаций. Читает данные из Kafka (или из S3 для batch), обрабатывает, пишет в DWH или другие топики.
Kafka склеивает источники и обработчики. Spark берёт streaming-данные из Kafka или batch-данные из data lake, трансформирует, пишет результат.
Такой стек типичен в крупных компаниях: Netflix, Uber, Airbnb. У них есть и streaming (Kafka + Spark/Flink), и batch (Spark + Hive/Iceberg), и они работают параллельно для разных сценариев.
Spark в роли batch-engine
Spark batch — самый частый сценарий. Это ежедневный/часовой job, который читает данные из data lake, делает heavy transformations и пишет результат.
Типичные задачи:
- ETL/ELT-пайплайны. Чистка, типизация, агрегация сырых данных в lake.
- ML feature engineering. Расчёт фич для тренировки моделей.
- Backfill. Перепроцессинг исторических данных при изменении логики.
- Ad-hoc-запросы. Аналитики через Spark SQL делают разовые исследования.
Spark batch конкурирует с двумя другими подходами:
- Cloud DWH (Snowflake, BigQuery). Если данные уже в DWH, проще написать dbt-модель и не поднимать Spark-кластер.
- DuckDB/Polars на single node. Если объёмы помещаются на одну машину (десятки ГБ), это в разы быстрее и дешевле Spark.
Spark batch выигрывает на петабайтных объёмах и сложных вычислениях, где DWH-движок не справляется.
Spark в роли streaming-engine
Spark Structured Streaming — streaming-режим Spark. Работает через micro-batches: события из Kafka накапливаются маленькими батчами (например, по 1-30 секунд) и обрабатываются как обычный DataFrame.
# Псевдо-Spark Structured Streaming
stream = spark.readStream \
.format("kafka") \
.option("kafka.bootstrap.servers", "broker:9092") \
.option("subscribe", "orders") \
.load()
result = stream \
.selectExpr("CAST(value AS STRING) as json") \
.select(F.from_json("json", schema).alias("data")) \
.select("data.*") \
.filter("country = 'RU'") \
.groupBy(F.window("event_time", "5 minutes"), "category") \
.count()
result.writeStream \
.format("delta") \
.outputMode("append") \
.start("s3://my-bucket/aggregated/")Главное: тот же DataFrame API, что и в batch. Поэтому Spark Structured Streaming популярен у команд, которые уже работают с Spark — не нужно учить новый фреймворк.
Минус: micro-batches дают латентность в секунды-минуты, а не миллисекунды. Для жёсткой realtime лучше Flink.
Spark Structured Streaming: подробный разбор micro-batch модели и watermarksKafka в роли event-bus и log
Kafka типично играет три роли в стеке:
Event bus. Сервисы общаются через события, не зная друг о друге напрямую. Заказ создан -> событие в orders -> consumer-ы (биллинг, склад, аналитика, уведомления) реагируют независимо. Это event-driven architecture.
Streaming source/sink. Kafka — основной источник данных для streaming-процессоров и место, куда они пишут результаты.
CDC backbone. Debezium читает binlog/WAL из OLTP-баз и пишет каждое изменение в Kafka. Это позволяет реплицировать OLTP в DWH или другие системы near-realtime.
Kafka как append-only лог: архитектура event-bus и CDC backboneАльтернативы Spark
Spark не единственный engine. Конкуренты на 2026 год:
Apache Flink
Flink — engine для настоящего streaming (true streaming, не micro-batch). Обрабатывает события по одному, как только они приходят. Поддерживает сложный state, event-time, watermarks, exactly-once.
Где Flink сильнее Spark:
- Латентность миллисекунды (Spark Structured Streaming — секунды).
- Сложные stateful-операции: stream-stream joins, sessionization, CEP (Complex Event Processing).
- Event-time обработка — Flink родился event-time-first, Spark догнал позже.
Где Spark сильнее:
- Унифицированный API для batch и streaming. В Spark один код, в Flink — два разных API (DataStream и Table API).
- Шире экосистема для batch-ML и ad-hoc-аналитики.
В компаниях, серьёзно работающих со streaming (Netflix, Uber), часто используется Flink для realtime + Spark для batch. У нас есть отдельный flink-course для углубления.
Apache Beam
Beam — это унифицированный API, который компилируется в разные runners: Spark, Flink, Google Dataflow, Samza. Идея — один код, разный engine. На практике встречается реже, потому что универсальные абстракции часто проигрывают нативным API.
Databricks Runtime
Databricks Runtime — оптимизированная версия Spark от создателей Spark (компания Databricks). Поверх open-source Spark добавлен Photon engine (нативный C++ executor), Delta Lake, Unity Catalog, MLflow.
Для крупных enterprise-команд Databricks часто становится дефолтом, потому что закрывает Spark + lakehouse + MLOps + governance в одном продукте.
DataFusion
DataFusion — Rust-based query engine от Apache Arrow. Работает на single node или встраивается в распределённые системы. Очень быстрый для analytical-нагрузок, обещает заменить Spark для многих сценариев. Пока новый, но растёт быстро. У нас есть datafusion-course для тех, кому интересно.
DuckDB / Polars
DuckDB и Polars — single-node engines для аналитики. Не distributed, но фантастически быстрые на десятках/сотнях гигабайт. Для middle-размерных задач часто заменяют Spark, и при этом требуют только ноутбука.
Альтернативы Kafka
Kafka де-факто стандарт, но альтернативы есть:
AWS Kinesis
Kinesis — managed-аналог Kafka от AWS. Меньше параметров (упрощённое API), интеграция с AWS-сервисами (S3, Lambda, Firehose). Дешевле в управлении, но менее гибкий. Хороший выбор для AWS-нативных стеков.
Google Pub/Sub
Pub/Sub — Google аналог. Полностью serverless, без партиций как у Kafka. Использует push-модель и concurrent consumers. Хорошо интегрирован с GCP-экосистемой.
Apache Pulsar
Pulsar — родился в Yahoo, теперь Apache. Архитектурно отличается от Kafka: разделение storage (BookKeeper) и compute (broker). Поддерживает multi-tenancy лучше Kafka. Используется реже, но в сложных enterprise-сценариях встречается.
Redpanda
Redpanda — Kafka-API совместимый брокер на C++. Без ZooKeeper, без JVM. Быстрее Kafka в некоторых бенчмарках, проще операционно. Растёт.
Реальная картина: hybrid stack
В крупных компаниях редко используется один engine для всего. Типичный hybrid:
Разные инструменты для разных задач. Все говорят с Kafka и пишут в lakehouse.
Это и есть «думать как DE» — не «какой инструмент лучше», а «какой инструмент для какой задачи».
Что выбирать в новой команде
Если ты приходишь в команду без существующего стека и нужно выбрать с нуля:
- Streaming backbone — Kafka (open-source) или Confluent Cloud (managed). Альтернативы: AWS MSK, GCP Pub/Sub, Redpanda.
- Streaming processor — Flink для жёсткого realtime, Spark Structured Streaming для смешанных задач (если уже есть Spark batch).
- Batch processor — Spark на Databricks, EMR, Dataproc или standalone. Для маленьких объёмов — DuckDB/Polars.
- DWH — Snowflake, BigQuery, Databricks SQL.
- Orchestration — Airflow, Dagster, Prefect (об этом в следующем модуле).
Понимание ландшафта — обязательный навык DE. Конкретные инструменты меняются за 5 лет, но архитектурные роли (event bus, streaming processor, batch engine, DWH) остаются. Учись классифицировать инструменты по ролям — это даст быстрый старт в любом стеке.
Попробуй сам
Зайди на инженерный блог компании, которая тебе нравится (Netflix Tech Blog, Uber Engineering, Spotify Engineering). Найди статью про их data infrastructure. Попробуй классифицировать упомянутые инструменты по ролям: где у них streaming backbone, где streaming processor, где batch engine, где DWH, где orchestrator. Часто стек будет нестандартный (custom engines, fork’и Spark) — но базовые роли узнаваемы. Это упражнение даёт быстро ориентироваться в чужой архитектуре.