传统的数据处理架构->流处理架构(Lambda架构->Kappa架构)

传统的数据处理架构

类似于流式处理，来一个事件，立即做出响应，适用于关系型数据库，数据量较小的情况

用Web程序来举例，用户点击了网页上的按钮后，会向服务器发起请求，后台立即做出响应，从数据库中查询对应的信息，进行计算，得到的结果，可能再存回数据库中，最后给用户做一个页面响应

比如用户登录，用户填写用户名和密码之后，点击注册，后台做出响应，去数据库中查询，验证该用户是否存在，如果不存在就把用户信息经过一些加密处理，再保存到数据库当中，最后给用户反馈，注册成功

 

类似于批处理，攒上一批数据，一起处理

因为数据量太大，数据来源多种多样，可能来自于mysql,sqlserver,orcale等多个关系型数据库，和一些非结构化的数据，比如前端埋点数据，可能为JSON或其他格式，一个单纯的关系型数据库根本无法处理

所以如果对实时性要求不高，就采用批处理的方式，存放到数据仓库中进行汇总之后，再进行分析

 

如果要做到低延迟实时分析，就要使用流式处理的方式

有状态的流式处理

像一个管道，数据从一边流入，进行处理后，从另一边流出，但后边如果像继续使用，也可以拿出来消费

在前面的事物处理流程中，需要数据时，就从数据库中查询

此处和此过程相似，如果要做一些复杂的计算，需要一些其他信息，要有一个地方存储信息，这里保存在Local state（本地状态中），访问和计算会很快，但本地状态占用内存，而且可能会丢失，如果出现故障怎么恢复？

所以这里使用checkpoint操作，把Local State周期性的保存到远程的存储空间（Remote Storage）中去

（Remote Storage可能是文件系统，数据库等）

当数据量大时，可以做成分布式，但是分布式可能存在网络延迟带来的乱序问题，怎么解决？

采用两套系统，流处理保证数据的实时性，批处理保证数据的准确性

当有数据输入时，来一条处理一条，隔一段时间，采用批处理的方式，处理一批数据，保证结果的准确性

所以用户这边看到的情况是，数据实时显示，但隔一段时间后，数据可能还会变化

Lambda架构

可参考详情：https://www.cnblogs.com/cciejh/p/lambda-architecture.html

http://ytluck.github.io/big-data/my-bigdata-post-34.html

 

这种架构虽然综合了流处理和批处理，支撑了数据行业的早期发展，但是它也有一些致命缺点，并在大数据3.0时代越来越不适应数据分析业务的需求

但是它需要同时开发两套系统，工作量翻倍

 

而flink使用一套API解决了以上所有问题

 Kappa架构

参考：http://ytluck.github.io/big-data/my-bigdata-post-37.html

https://www.jianshu.com/p/4f18d82a9c75

去除了批处理层，使用FLink作为流处理层的流式计算框架