Lambda vs Kappa vs Streaming-first¶
Сравнения · Lambda · Kappa · Streaming-first
Тип материала: инженерное сравнение; выводы зависят от требований и условий эксплуатации. Схемы и примеры иллюстративны.
INFERENCE: Lambda/Kappa сравнивают способы live и historical computation, Streaming-first — приоритет оперативного пути. Третий подход может включать первые два. Все примеры ниже HYPOTHETICAL, кроме явно обозначенных FACT.
Критерии выбора¶
| Критерий | Lambda | Kappa | Streaming-first |
|---|---|---|---|
| Исторический пересчёт | Отдельный batch path | Единая логическая обработка history и live | Стратегия пересчёта выбирается отдельно |
| Код бизнес-правил | Нужно предотвращать drift двух путей | Обычно общий processing model | Не определяет число code paths |
| Хранение истории | Raw/master dataset | Replayable log/archive с достаточной полнотой | Не задаёт; recovery всё равно нужен |
| Публикация результата | Batch coverage + непересекающийся tail | New generation, catch-up, cutover | Freshness и degraded-mode contract |
| Главный риск | Overlap/gap и разные semantics | Невоспроизводимость, дорогой replay | Быстрые, но неполные/неверные решения |
| Когда выбрать | Отдельный batch алгоритм действительно необходим | Replay достаточен и поддерживает тот же расчёт | Свежесть приносит бизнес-ценность |
| Когда ограничить | Стоимость двух путей не окупается | История потеряна или алгоритм требует иного execution | Потребителям достаточно редких batch updates |
«Один код» не означает одинаковый результат при любых inputs. Watermarks, source ordering, dimension snapshots и versioning остаются частью расчёта. Daily scheduled SQL job может быть правильнее сложного stream processor, если задержка соответствует задаче.
Unified Batch/Stream на примере антифрода добавляет ещё одну ось сравнения — общую семантику вычислений для bounded scan и непрерывного потока.
Как выбирать на конкретных сценариях¶
FinTech reporting: требуется оперативный предварительный turnover и финальное закрытие с bank files. Если финальный расчёт имеет отдельную сложную модель, Lambda может оправдать два пути; их необходимо сверять и фиксировать source coverage. Если historical input обрабатывается той же моделью, Kappa уменьшит дублирование логики. В обоих случаях стратегия может быть streaming-first для оперативных consumers.
iGaming activity: есть длинная полная история и versioned corrections. Kappa подходит для перестройки activity projections. Если live exposure использует приближение, а закрытая аналитика — другой точный расчёт, Lambda может быть честнее. Authoritative bet acceptance и wallet не выбираются этим сравнением.
Ежедневный regulatory dataset: если его потребители не используют live updates, batch-first зачастую проще. Отсутствие streaming — результат требований, а не недостаток зрелости.
Сочетание решений¶
flowchart TB
F["Нужны оперативные решения?"] --> S["Streaming-first: определить freshness и degraded mode"]
S --> R["Как пересчитать историю?"]
R --> K["Одна модель и полный replay: Kappa"]
R --> L["Особый batch path необходим: Lambda"]
F --> B["Нет оперативного потребителя: рассмотреть batch-first"]Диаграмма — модель выбора, не взаимоисключающая классификация всех систем. Выбор должен включать capacity для catch-up и стоимость source/sink нагрузки, а не только normal-mode latency.
Ограничения и evidence¶
FACT: LinkedIn описал уход WVYP от Lambda, а Uber — production Kappa backfill с Hive streaming source. LinkedIn, 2020, Uber, 2020. Эти две истории показывают разные инженерные ответы; они не доказывают универсальность Kappa.
Система с exactly-once state может иметь duplicate external payout. Replay нельзя направлять в live action consumer без отдельного business protocol. Уточняйте общие гарантии.
Типичные ошибки проектирования¶
Выбирать по модному имени; считать Kappa отсутствием archive; называть micro-batch несовместимым со streaming; смешивать event-time finality и закрытие финансового периода.
Вопросы на собеседовании¶
Почему streaming-first не всегда Kappa? У live-first системы может оставаться независимый batch correction path.
Что решает выбор? Свойства historical computation, полнота inputs, recovery capacity, стоимость двух реализаций и freshness конкретного consumer.
Практические упражнения¶
Опишите один workload с общей исторической логикой и другой с отдельным batch algorithm. Для каждого укажите coverage, cutover, late corrections и критерий, при котором решение стоит пересмотреть.