接前一篇文章:软考 系统架构设计师系列知识点之大数据设计理论与实践(13)
所属章节:
第19章. 大数据架构设计理论与实践
第4节 Kappa架构
19.4.3 Kappa架构的实现
下面以Apache Kafka为例来讲述整个全新架构的过程。
部署Apache Kafka,并设置数日志的保留期(Retention Period)。这里的保留期指的是希望能够重新处理的历史数据的时间区间。例如,如果你希望重新处理最多一年的历史数据,那就可以把Apache Kafka中的保留期设置为365天;如果你希望能够处理所有的历史数据,那就可以把Apache Kafka中的保留期设置为“永久(Forever)”。
如果我们需要改进现有的逻辑方法,那就意味着我们需要对历史数据进行重新处理。需要做的就是重新启动一个Apache Kafka作业实例(Instance)。此作业实例将从头开始,重新计算保留好的历史数据,并将结果输出到一个新的数据视图中。我们知道,Apache Kafka的底层是使用Log Offset来判断现在已经处理到哪个数据块了,所以只需要将Log Offset设置为0,新的作业实例就会从头开始处理历史数据。
当这个新的数据视图处理过的数据进度赶上了旧的数据视图时,应用便可以切换到从新的数据视图中读取了。
停止旧版本的作业实例,并删除旧的数据视图。
19.4.4 Kappa架构的优缺点
- 优点
Kappa架构的优点在于将实时和离线代码统一起来,方便维护而且统一了数据口径的问题,避免了Lambda架构中与离线数据合并的问题。查询历史数据的时候只需要重放存储的历史数据即可。
- 缺点
Kappa的缺点也很明显:
(1)消息中间件缓存的数量和回溯数据有性能瓶颈。通常算法需要过去180天的数据,如果都存在消息中间件,无疑有非常大的压力。同时,一次性回溯订正180天级别的数据,对实时计算的资源消耗也非常大。
(2)在实时数据处理时,遇到大量不同的实时流进行关联时,非常依赖实时计算系统的能力,很可能因为数据流先后顺序问题,导致数据丢失。
(3)Kappa在抛弃了离线数据处理模块的时候,同时抛弃了离线计算更加稳定可靠的特点。Lambda虽然保证了离线计算的稳定性,但双系统的维护成本高,且两套代码会导致后期运维困难。
对于以上Kappa框架存在的几个问题,目前也存在一些解决方案。对于消息队列缓存数据性能的问题,Kappa+框架提出使用HDFS来存储中间数据。针对Kappa框架展示层能力不足的问题,也有人提出了混合分析系统的解决方案。
至此,“19.4.3 Kappa架构的实现”和“19.4.4 Kappa架构的优缺点”的全部内容就讲解完了。更多内容请看下回。