Day38-11｜19.4.2 Kappa 架构介绍：事件日志、统一流处理与结果视图
Day38-11｜19.4.2 Kappa 架构介绍：事件日志、统一流处理与结果视图
对应教材目录：第 19 章 大数据架构设计理论与实践 → 19.4 Kappa 架构 → 19.4.2 Kappa 架构介绍
学习目标：掌握 Kappa 架构的组成部分和数据流；理解事件日志、流处理程序、状态存储、结果视图和查询服务的职责；能够描述 Kappa 的实时处理、历史重放、版本切换、容错和治理机制。
一、Kappa 架构的基本结构
Kappa 架构试图用一条统一的数据处理路径同时支持实时处理和历史处理。所有原始数据先写入可持久化、可重放的事件日志；实时处理程序从日志尾部消费新事件；需要重算时，启动新版本处理程序，从历史位置重放事件，生成新的结果视图。
事件源 -> 采集层 -> 持久化事件日志 -> 流处理层 -> 结果存储 -> 查询服务
| |
| +--> 实时状态/指标/告警
|
+----历史重放----> 新版本结果视图架构中的“单一”主要指处理逻辑路径统一，并不代表系统只有一个组件、一个数据库或一个任务。事件日志、处理程序、状态存储和结果服务仍然可以分布式部署和水平扩展。
二、事件源与接入层
1. 事件来源
事件可以来自用户操作、交易系统、数据库变更、设备、日志、第三方接口和业务服务。接入层负责把来源不同的数据转换为统一事件格式，同时保留来源、时间和版本信息。
2. 接入可靠性
接入层需要处理认证、限流、缓冲、重试、断点、格式错误和网络抖动。对于数据库 CDC，要处理事务边界、删除、主键变化和 schema 变更；对于设备数据，要处理时钟偏差、重复和离线补发。
3. 事件契约
生产者和消费者通过事件契约协作。契约应定义字段、类型、必填项、语义、版本、兼容策略和错误处理。事件契约测试可以在发布前发现生产者变更造成的消费者故障。
三、持久化事件日志
1. 日志的职责
事件日志承担事实保存、消息传输、消费位点、分区扩展和历史重放。它不是普通的临时消息队列，必须根据重算窗口、合规和恢复目标设置可靠的保留策略。
2. 分区和顺序
日志通常按主体、设备、账户、租户或事件类型分区。分区键决定并行度和顺序范围：全局顺序成本高，通常只保证同一业务实体或分区内顺序。消费者必须明确自己依赖哪种顺序。
3. 保留和归档
热日志支持实时消费和快速重放，温日志支持较慢的历史重算，冷数据可以归档。归档后的数据如果仍要支持 Kappa 重放，必须保留格式、模式和索引信息。
四、流处理层
1. 统一处理程序
流处理程序负责读取事件、校验、过滤、转换、关联状态、聚合、调用模型和输出结果。实时处理和历史重放尽量使用同一业务逻辑，只改变输入起点、并行度和输出目标。
2. 窗口与时间
常见窗口包括滚动窗口、滑动窗口和会话窗口。处理时间简单但可能受延迟影响，事件时间更适合业务统计。水位线用于判断事件进度，迟到数据可在容忍窗口内修正结果。
3. 状态和检查点
窗口聚合、去重、连接和画像需要状态。状态应定期 checkpoint，并与消费位点绑定。故障恢复时，从最近检查点恢复状态，再重放未确认事件，避免结果丢失。
4. 背压和资源管理
当输入速度大于处理速度时，处理程序应产生背压、扩容或降级非核心计算，而不是无限缓存。需要监控消费延迟、积压量、状态大小、检查点耗时和下游写入失败。
五、状态存储与结果视图
1. 状态存储
状态存储可以是处理引擎内置状态、键值数据库、时间序列数据库或专用状态服务。状态数据应有版本、租户、时间和过期策略，避免状态无限增长。
2. 结果视图
结果视图可以包括当前状态、聚合指标、搜索索引、用户画像、实时特征和告警列表。视图是派生数据，可以被删除和重建，但要记录其来源事件范围、代码版本和计算时间。
3. 服务化查询
查询服务向应用隐藏结果存储细节，统一处理权限、缓存、限流、数据新鲜度、版本和审计。查询接口应区分临时结果、确认结果和历史版本，避免调用方误用。
六、实时处理流程
1. 生产者生成事件
2. 接入层校验并写入事件日志
3. 流处理程序按分区读取
4. 完成去重、窗口、状态和业务规则
5. 写入结果视图并提交消费位点
6. 查询服务提供最新结果
7. 记录指标、审计和处理水位写结果和提交位点之间要有可靠语义。若先提交位点再写结果，可能丢结果；若先写结果再提交位点，重启会重复处理，因此结果写入需要幂等、事务或可检测版本。
七、历史重放流程
选择事件范围和版本
|
创建新的处理作业与结果空间
|
从历史日志读取并重放
|
执行相同或指定版本的业务逻辑
|
质量校验、差异比较、性能评估
|
原子切换结果指针1. 新旧视图并行
历史重放时不应覆盖在线结果，最好生成新版本视图。新旧结果可以按实体、时间和指标对比，确认差异来自预期规则变化，而不是数据丢失或程序错误。
2. 重放速度和下游保护
重放可以提高并行度，但要限制写入和外部调用。对需要调用外部服务的逻辑，应采用回放模式、模拟接口或结果隔离，防止历史事件再次触发真实动作。
八、版本、发布与回滚
Kappa 的统一处理逻辑并不意味着版本管理简单。每次处理程序发布都可能改变状态结构、事件解释和结果口径。
应同时管理：
- 事件 schema 版本。
- 处理代码版本。
- 规则和模型版本。
- 状态快照版本。
- 结果视图版本。
- 数据水位和发布时间。
发布时可以先从最近位置并行运行新旧程序，或从历史样本重放验证。确认质量后切换服务指针；发现问题时回滚指针、停止新版本消费并保留异常结果用于分析。
九、错误处理和数据质量
事件处理失败可分为临时错误、永久错误和业务拒绝。临时错误适合重试，永久错误进入死信，业务拒绝应记录原因但不无限重试。错误事件不能被静默丢弃，否则结果缺失难以发现。
数据质量指标包括事件接入量、处理量、失败量、重复率、迟到率、状态更新成功率、结果延迟和业务对账差异。流处理“任务运行正常”不代表结果一定正确。
十、安全与治理
事件日志、状态、视图和查询服务都要执行身份、权限、加密和审计。重点包括：
- 生产者和消费者身份分离。
- 主题、分区、消费组和结果视图按租户授权。
- 敏感事件字段加密或脱敏。
- 重放、导出、回滚和管理员操作审计。
- 事件保留和个人信息删除机制。
- 代码、规则、模型、配置和 schema 的审批与签名。
- 结果版本、数据血缘和处理水位可查询。
十一、与 Lambda 的结构比较
| 项目 | Kappa | Lambda |
|---|---|---|
| 核心事实 | 事件日志 | 不可变数据集/事件 |
| 实时处理 | 流处理 | 速度层 |
| 历史处理 | 通过重放流处理 | 批处理层 |
| 业务逻辑 | 尽量一套 | 批流两套 |
| 主要难点 | 重放成本、状态和事件保留 | 批流一致性和双逻辑 |
| 适合场景 | 事件流天然、逻辑统一 | 批处理复杂、实时和准确都重要 |
十二、案例分析：实时客户标签平台
某零售平台要根据浏览、搜索、购买和售后事件更新客户标签，并支持新标签规则历史回算。
Kappa 实现如下：
- 所有行为写入长期事件日志，采用客户或账户分区。
- 流处理程序实时更新短期兴趣、频率和标签状态。
- 新规则发布时启动新版本处理程序，从指定历史时间重放事件。
- 新标签写入独立版本视图，与旧视图比较覆盖率、差异和性能。
- 验证通过后切换标签服务指针，旧版本保留一段时间便于回滚。
- 用户撤回授权时，通过事件或删除流程清理原始事件、状态和派生视图。
- 标签查询按租户、用户和用途授权，并记录导出和批量查询。
十三、案例题答题模板
介绍 Kappa 架构时可以按以下顺序：
- 说明事件流作为唯一事实来源。
- 设计接入、事件契约、日志分区、保留和重放。
- 说明统一流处理、窗口、状态、checkpoint 和位点。
- 说明结果视图、服务查询、版本切换和回滚。
- 说明重复、乱序、迟到、死信、故障和副作用隔离。
- 说明安全、数据质量、隐私、成本和运维治理。
- 解释为什么该业务适合 Kappa，以及不适合的边界。
十四、课后练习
练习 1
Kappa 架构为什么需要专门的结果版本和指针？
参考答案：新旧处理程序重放或规则变化时不能直接覆盖在线结果，需要先生成新视图、完成质量对比，再原子切换；指针便于回滚和追踪当前服务版本。
练习 2
流处理程序如何处理永久错误事件？
参考答案：记录错误原因和原始事件摘要，进入死信或隔离区，避免无限重试；通过修复数据、升级 schema 或人工处理后再选择性重放。
练习 3
Kappa 的事件日志需要具备哪些能力？
参考答案：持久化、分区、顺序范围、消费位点、长期保留、压缩归档、历史重放、权限、加密、审计和 schema 版本管理。
练习 4
论文题：论“Kappa 架构的实现与治理”。
参考答案要点：事件接入、日志、流处理、状态、结果视图、重放、版本、checkpoint、幂等、质量、安全、隐私、成本、监控、回滚和案例验证。
十五、今日复盘
- 我能否画出 Kappa 的完整组件和数据流？
- 我是否理解事件日志、状态存储和结果视图的职责？
- 我能否说明实时处理与历史重放如何使用同一逻辑？
- 我是否考虑位点、checkpoint、死信、版本和副作用？
- 我能否解释 Kappa 与 Lambda 的差异？
- 我能否将架构介绍落到实现和治理措施？
Kappa 架构介绍的核心结论是：以事件日志保存唯一事实，以统一流处理程序生成实时和历史结果，以版本化视图和服务层对外提供能力。它通过减少批流双逻辑降低一致性成本，但把复杂性转移到事件保留、重放、状态恢复、版本管理和副作用隔离上。
