Flink vs Spark Structured Streaming¶

Сравнения · Раздел03

Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.

Версии указаны в заголовках и связанных статьях. Численные показатели производительности не заявляются.

Критерии выбора¶

Критерий	Flink1.20.3	Spark4.0.1
Workload / architecture	Continuous keyed state/timers/windows	Micro-batch incremental SQL и unified batch/reprocessing
Consistency / transaction boundary	Checkpointed state; supported sink protocol обязателен	Checkpoint lineage + sink-specific contract; foreachBatch retries
Latency path	Record/event-time progress и checkpoint/sink cost	Trigger/batch/backlog/state и sink cost; interval не latency
Throughput / scalability	Keys/operators/state/rescale и hot key	Partitions/shuffle/executors/state store и skew
Operational complexity / cost	HA runtime/checkpoints/state evolution	Driver/executors/shuffle/checkpoints и batch platform reuse

flowchart TB
  Input --> Flink[Continuous keyed operators and timers]
  Input --> Spark[Micro-batch incremental plan]
  Flink --> Checkpoints[Checkpoint and supported sink]
  Spark --> Batch[Batch lineage and supported sink]
  Checkpoints --> Result[Versioned analytical result]
  Batch --> Result

Конкретные сценарии¶

Velocity fraud features и complex event-time timers → Flink часто соответствует модели. Spark-centric reporting/stream marts и availableNow backlog → Spark при допустимой freshness. Обе системы требуют правильного correction/upsert sink и source retention.

Ограничения и восстановление¶

Фразы «Flink EOS, Spark нет» неверны без scope. Continuous Spark mode не поддерживает произвольную micro-batch topology и имеет иной contract. Flink savepoint и Spark checkpoint нельзя переносить между engines.

Как проверить выбор¶

Зафиксировать query/event mix, schema/payload, skew, working set/state, retention, target effect и допустимую stale-read policy. Проверять lost ACK, restart/rebalance, poison record, late correction и rebuild generation. Сравнивать TCO с одинаковыми durability/replication требованиями, включая engineering, maintenance и restore. Универсальный winner отсутствует.

Типичные ошибки проектирования¶

Сравнивать разные boundaries как одинаковую гарантию; игнорировать recovery и source retention; публиковать чужие latency/TPS как свои измерения; забывать target operations.

Вопросы на собеседовании¶

Когда стоит сочетать варианты? Когда они отвечают на разные уровни/нагрузки и contracts переходов определены. Дополнительный компонент добавляет ownership, lag, recovery и стоимость, поэтому нужна измеримая польза.

Практические упражнения¶

Составьте ADR для одного сценария: invariant, rejected alternative, failure matrix, recovery evidence и план честных измерений. Укажите, какие guarantees ещё UNKNOWN.