Kafka Streams vs Flink¶
Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.
Версии указаны в заголовках и связанных статьях. Численные показатели производительности не заявляются.
Критерии выбора¶
| Критерий | KafkaStreams4.1 | Flink1.20.3 |
|---|---|---|
| Workload / architecture | Embedded JVM Kafka topology, app-owned deployment | Dedicated processing runtime, multiple supported sources/sinks |
| Consistency / transaction boundary | exactly_once_v2 Kafka/state boundary | Managed state/checkpoint + supported sink protocol |
| Latency path | Task/commit interval/state store и Kafka path | Watermarks/timers/network/checkpoint/sink path |
| Throughput / scalability | Input partitions/tasks/threads/hot keys | Operators/key groups/slots/state/rescale |
| Operational complexity / cost | Application instances/internal topics/local stores | JobManager/TaskManagers/durable checkpoints/operations |
flowchart TB
Kafka --> Streams[Application-owned JVM topology]
Streams --> Local[Local state plus Kafka changelog]
Kafka --> Flink[Processing cluster operators]
Other[Other supported sources] --> Flink
Flink --> State[Managed state and durable checkpoints]Конкретные сценарии¶
Один service-owned Kafka enrichment → Streams может уменьшить отдельную runtime инфраструктуру. Общая платформа сложных stateful jobs/heterogeneous sources → Flink при operational competence. Внешний ledger effect требует отдельного протокола в обоих случаях.
Ограничения и восстановление¶
Library не означает отсутствие ops; engine cluster не создаёт universal EOS. Сравнивать state restore, topology upgrades, serializer compatibility и external side effects.
Как проверить выбор¶
Зафиксировать 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.