关于Lambda架构和Kappa架构

下面的知识点是摘自于b站“课工场优越实训中心”的文章《三张图讲清楚大数据基础设施》
文章链接为：https://www.bilibili.com/read/cv8768704?share_source=copy_link&share_medium=iphone&bbid=Z74E607FA37E3C304E68B048B0E9982CAA2A&ts=1611108435

lambda架构：
结构：
1.ServingLayer
主要是想用用户的请求，根据用户需求把Batch层和Speed层的数据集合到一起，得到最终的数据集。
2.SpeedLayer
主要是对实时增量数据进行处理，每来一次数据经不断的更新View层，提供给到业务
3.BatchLayer
主要对离线数据进行处理，将介入的数据进行预处理，存储，查询的时候直接在预处理结果上查询并不需要再进行完整的计算，最后以View层提供到业务；
优点：
1.将流处理和批处理分开，很好的结合了实时计算和流计算的优点，结构稳定，实时计算成本可控，提高了整个系统的容错性、降低了复杂性。
缺点：
离线数据和实时数据很难保障数据的一致性，开发人员需要维护两套系统。

kappa架构是在Lambda架构的基础上删除了Batch层，所有的数据都是流处理实时计算，计算好了之后可以直接给到业务层使用。也可以放到数据湖中，需要进行离线分析时使用。
优点：
开发人员只需要维护实时处理模块，不需要离线实时数据合并。
缺点：
在实时处理时可能会存在信息丢失的情况。

摘自《Flink x Zeppelin ，Hive Streaming 实战解析》—flink中文社区
其实在大数据领域，一直存在两种架构 Lambda 和 Kappa：

Lambda 架构——流批分离，静态数据通过定时调度同步到 Hive 数仓，实时数据既会同步到 Hive，也会被实时计算引擎消费，这里就引出了一点问题。

1.数据口径问题

2.离线计算产出延时太大

3.数据冗余存储

Kappa架构——全部使用实时计算来产出数据，历史数据通过回溯消息的消费位点计算，同样也有很多的问题，毕竟没有一劳永逸的架构。

1.消息中间件无法保留全部历史数据，同样数据都是行式存储，占用空间太大

2.实时计算计算历史数据力不从心

3.无法进行 Ad-Hoc 的分析