Big Data - Kappa
Lambda
概述
- Lambda 架构结合了批处理和流处理的架构思想
- 将进入系统的大规模数据同时送入两套架构层中,即 Batch Layer 和 Speed Layer
- 同时产生两套数据结果并存入 Serving Layer 中
优点
- Batch Layer 有很好的容错性,同时由于保存着所有的历史记录,使得产生的数据具有很好的准确性
- Speed Layer 可以及时处理流入的数据,具有低延迟性
- 最终 Serving Layer 将两套数据结合,并生成一个完整的数据视图提供给用户
- Lambda 架构也具有很好的灵活性,可以将不同开源组件嵌入到该架构中
不足
- 使用 Lambda 架构,需要维护两个复杂的分布式系统,并保证它们逻辑上产生相同的结果输出到 Serving Layer
- 在分布式框架中进行编程是非常复杂的,尤其需要对不同的框架进行专门的优化 – 高昂的维护成本
- 维护 Lambda 架构的复杂性 – 同时维护两套系统架构
- 方向 - 改进其中一层的架构,让其具有另一层架构的特性
Kappa
架构
Apache Kafka 具有永久保存数据日志的功能,基于该特性,可以让 Speed Layer 重新处理历史数据
- 部署 Apache Kafka,设置数据日志的保留期 - 希望重新处理的历史数据的时间区间
- 如果需要改进现有的逻辑算法,则表示需要对历史数据进行重新处理
- 将 Apache Kafka 的 Log Offset 重置为 0,重新计算保留好的历史数据,生成一个新的数据视图
- 当新的数据视图处理过的数据进度赶上了旧的数据视图,则可以切换到新的数据视图中进行读取
- 与 Lambda 架构不同的是,Kappa 架构移除了 Batch Layer 的体系结构,只保留了 Speed Layer
- 只需要在业务逻辑改变或者代码更改的时候进行数据的重新处理
不足
- 只保留了 Speed Layer 而缺少 Batch Layer,在 Speed Layer 上处理大规模数据可能会有数据更新出错的情况
- 需要花费更多的时间在异常处理上
- Kappa 架构的批处理和流处理都放在了 Speed Layer 上,使用同一套代码来处理算法逻辑
- 所以,Kappa 架构不适合于批处理和流处理的代码逻辑不一致的场景
All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.