流式计算框架简单综述-第一篇

摘要

本文深入剖析流式计算原理、流批一体架构、Lambda与Kappa架构优劣，并结合实际场景，全面阐述实时数据处理的技术演进与工程实践。

引言

流式计算的背景和场景

在日常生活中，我们通常会先把数据存储在一张表中，然后再进行加工、分析，这里就涉及到一个时效性的问题。如果我们处理以年、月为单位的级别的数据，那么多数据的实时性要求并不高；但如果我们处理的是以天、小时，甚至分钟为单位的数据，那么对数据的时效性要求就比较高。在第二种场景下，如果我们仍旧采用传统的数据处理方式，统一收集数据，存储到数据库中，之后在进行分析，就可能无法满足时效性的要求。

通过大数据处理我们获取了数据的价值，但是数据的价值显然不是恒定不变的。一些数据在事情发生后不久就有了更高的价值，而且这种价值会随着时间的推移而迅速减少。流处理的关键优势在于它能够更快地提供洞察力，通常在毫秒到秒之间。

流式处理可以用于两种不同场景：事件流和持续计算。

1、事件流

事件流能够持续产生大量的数据，这类数据最早出现与传统的银行和股票交易领域，也在互联网监控、无线通信网等领域出现、需要以近实时的方式对更新数据流进行复杂分析如趋势分析、预测、监控等。简单来说，事件流采用的是查询保持静态，语句是固定的，数据不断变化的方式。

2、持续计算

比如对于大型网站的流式数据：网站的访问PV/UV、用户访问了什么内容、搜索了什么内容等，实时的数据计算和分析可以动态实时地刷新用户访问数据，展示网站实时流量的变化情况，分析每天各小时的流量和用户分布情况；

比如金融行业，毫秒级延迟的需求至关重要 。一些需要实时处理数据的场景也可以应用Storm，比如根据用户行为产生的日志文件进行实时分析，对用户进行商品的实时推荐等。

其实这两种，事件流和持续计算本质上都是事件流。

流式计算与批量计算

大数据的计算模式主要分为批量计算(batch computing)、流式计算(stream computing)、交互计算(interactive computing)、图计算(graph computing)等。其中，流式计算和批量计算是两种主要的大数据计算模式，分别适用于不同的大数据应用场景。

流数据（或数据流）是指在时间分布和数量上无限的一系列动态数据集合体，数据的价值随着时间的流逝而降低，因此必须实时计算给出秒级响应。流式计算，顾名思义，就是对数据流进行处理，是实时计算。批量计算则统一收集数据，存储到数据库中，然后对数据进行批量处理的数据计算方式。主要体现在以下几个方面：

1、数据时效性不同：流式计算实时、低延迟，批量计算非实时、高延迟。

2、数据特征不同：流式计算的数据一般是动态的、没有边界的，而批处理的数据一般则是静态数据。

3、应用场景不同：流式计算应用在实时场景，时效性要求比较高的场景，如实时推荐、业务监控...批量计算一般说批处理，应用在实时性要求不高、离线计算的场景下，数据分析、离线报表等。

4、运行方式不同，流式计算的任务持续进行的，批量计算的任务则一次性完成。

流式计算框架、平台与相关产品

第一类，商业级流式计算平台（IBM InfoSphere Streams、IBM StreamBase等）；

第二类，开源流式计算框架（Twitter Storm、S4等）；

第三类，公司为支持自身业务开发的流式计算框架。

Strom：Twitter 开发的第一代流处理系统。1

Heron：Twitter 开发的第二代流处理系统。

Spark streaming：是Spark核心API的一个扩展，可以实现高吞吐量的、具备容错机制的实时流数据的处理。

Flink：是一个针对流数据和批数据的分布式处理引擎。

Apache Kafka：Linkedin开发的大数据消息队列，由Scala写成。该项目的目标是为处理实时数据提供一个统一、高通量、低等待的平台。

Apache Samza, Linkedin开发的大数据流式处理系统，可以实现流批一体的分布式处理引擎。

流式计算术语简介

水位：

连接：

状态：

exactly-once: 在消息队列中，生产者重试发送消息，也只会让消息被发送给消费者一次。[2]

Lamda计算框架架构

如何实时地在任意大数据集上进行查询？大数据再加上实时计算，问题的难度比较大。Lambda架构通过分解的三层架构来解决该问题：Batch Layer，Speed Layer和Serving Layer。

Batch Layer

理想状态下，任何数据访问都可以从表达式Query= function(all data)开始，但是，若数据达到相当大的一个级别（例如PB），且还需要支持实时查询时，就需要耗费非常庞大的资源。一个解决方式是预运算查询函数（precomputed query function）。书中将这种预运算查询函数称之为Batch View（A），这样当需要执行查询时，可以从Batch View中读取结果。这样一个预先运算好的View是可以建立索引的，因而可以支持随机读取（B）。于是系统就变成：

（A）batch view = function(all data)

（B）query = function(batch view)

在Lambda架构中，实现（A）batch view =function(all data)的部分称之为Batch Layer。Batch Layer的功能主要有两点：

存储master dataset, 这是一个不变的持续增长的数据集
在master dataset上预先计算查询函数，构建查询所对应的View

View是一个和业务关联性比较大的概念，View的创建需要从业务自身的需求出发。一个通用的数据库查询系统，查询对应的函数千变万化，不可能穷举。但是如果从业务自身的需求出发，可以发现业务所需要的查询常常是有限的。Batch Layer需要做的一件重要的工作就是根据业务的需求，考察可能需要的各种查询，根据查询定义其在数据集上对应的Views。

view可以理解为是等同于关系型数据库中的物化视图的概念。

Speed Layer

Batch Layer可以很好的处理离线数据，但有很多场景数据不断实时生成，并且需要实时查询处理。Speed Layer正是用来处理增量的实时数据。

Speed Layer和Batch Layer比较类似，对数据进行计算并生成Realtime View，其主要区别在于：

Speed Layer处理的数据是最近的增量数据流，Batch Layer处理的全体数据集
Speed Layer为了效率，接收到新数据时不断更新Realtime View，而Batch Layer根据全体离线数据集直接得到Batch View。Speed Layer是一种增量计算，而非重新计算（recomputation）
Speed Layer因为采用增量计算，所以延迟小，而Batch Layer是全数据集的计算，耗时比较长

综上所诉，Speed Layer是Batch Layer在实时性上的一个补充。Speed Layer可总结为：

（C）realtime view＝function(realtime view，new data)

注意，realtime view是基于新数据和已有的realtime view。

Lambda架构将数据处理分解为Batch Layer和Speed Layer有如下优点：

容错性。Speed Layer中处理的数据也不断写入Batch Layer，当Batch Layer中重新计算的数据集包含Speed Layer处理的数据集后，当前的Realtime View就可以丢弃，这也就意味着Speed Layer处理中引入的错误，在Batch Layer重新计算时都可以得到修正。这点也可以看成是CAP理论中的最终一致性（Eventual Consistency）的体现。
复杂性隔离。Batch Layer处理的是离线数据，可以很好的掌控。Speed Layer采用增量算法处理实时数据，复杂性比Batch Layer要高很多。通过分开Batch Layer和Speed Layer，把复杂性隔离到Speed Layer，可以很好的提高整个系统的鲁棒性和可靠性。

Serving Layer

有一类称为Monoid特性的函数应用非常广泛。Monoid的概念来源于范畴学（Category Theory），其一个重要特性是满足结合律。如整数的加法就满足Monoid（结合律）特性：

plaintext 复制代码

(a+b)+c=a+(b+c)

不满足Monoid特性的函数很多时候可以转化成多个满足Monoid特性的函数的运算。如多个数的平均值Avg函数，多个平均值没法直接通过结合来得到最终的平均值，但是可以拆成分母除以分子，分母和分子都是整数的加法，从而满足Monoid特性。

Monoid的结合律特性在分布式计算中极其重要，满足Monoid特性意味着我们可以将计算分解到多台机器并行运算，然后再结合各自的部分运算结果得到最终结果。同时也意味着部分运算结果可以储存下来被别的运算共享利用（如果该运算也包含相同的部分子运算），从而减少重复运算的工作量。

Lambda架构的Serving Layer用于响应用户的查询请求，合并Batch View和Realtime View中的结果数据集到最终的数据集。

这儿涉及到数据如何合并的问题。前面我们讨论了查询函数的Monoid性质，如果查询函数满足Monoid性质，即满足结合律，只需要简单的合并Batch View和Realtime View中的结果数据集即可。否则的话，可以把查询函数转换成多个满足Monoid性质的查询函数的运算，单独对每个满足Monoid性质的查询函数进行Batch View和Realtime View中的结果数据集合并，然后再计算得到最终的结果数据集。另外也可以根据业务自身的特性，运用业务自身的规则来对Batch View和Realtime View中的结果数据集合并。

综上所诉，Serving Layer采用如下等式表示：

（D）query**＝**function(batch view, realtime view)

Lambda架构组件选型

上面分别讨论了Lambda架构的三层：Batch Layer，Speed Layer和Serving Layer。总结下来，Lambda架构就是如下的三个等式：

plaintext 复制代码

batch view = function(all data)
realtime view = function(realtime view, new data)
query = function(batch view, realtime view)

数据流进入系统后，同时发往Batch Layer和Speed Layer处理。Batch Layer以不可变模型离线存储所有数据集，通过在全体数据集上不断重新计算构建查询所对应的Batch Views。Speed Layer处理增量的实时数据流，不断更新查询所对应的Realtime Views。Serving Layer响应用户的查询请求，合并Batch View和Realtime View中的结果数据集到最终的数据集。

下图给出了Lambda架构中各组件在大数据生态系统中和阿里集团的常用组件。数据流存储选用不可变日志的分布式系统Kafka、TT、Metaq；BatchLayer数据集的存储选用Hadoop的HDFS或者阿里云的ODPS；BatchView的加工采用MapReduce；BatchView数据的存储采用Mysql（查询少量的最近结果数据）、Hbase（查询大量的历史结果数据）。SpeedLayer采用增量数据处理Storm、Flink；RealtimeView增量结果数据集采用内存数据库Redis。

Lambda架构总结

数据从底层的数据源开始，经过各种各样的格式进入大数据平台，在大数据平台中经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算。一条线是进入流式计算平台（例如 Storm、Flink或者Spark Streaming），去计算实时的一些指标；另一条线进入批量数据处理离线计算平台（例如Mapreduce、Hive，Spark SQL），去计算T+1的相关业务指标，这些指标需要隔日才能看见。

Lambda架构经历多年的发展，其优点是稳定，对于实时计算部分的计算成本可控，批量处理可以用晚上的时间来整体批量计算，这样把实时计算和离线计算高峰分开，这种架构支撑了数据行业的早期发展，但是它也有一些致命缺点，并在大数据3.0时代越来越不适应数据分析业务的需求。缺点如下：

实时与批量计算结果不一致引起的数据口径问题：因为批量和实时计算走的是两个计算框架和计算程序，算出的结果往往不同，经常看到一个数字当天看是一个数据，第二天看昨天的数据反而发生了变化。
批量计算在计算窗口内无法完成：在IOT时代，数据量级越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成白天20多个小时累计的数据，保证早上上班前准时出数据已成为每个大数据团队头疼的问题。
开发和维护的复杂性问题：Lambda 架构需要在两个不同的 API（application programming interface，应用程序编程接口）中对同样的业务逻辑进行两次编程：一次为批量计算的ETL系统，一次为流式计算的Streaming系统。针对同一个业务问题产生了两个代码库，各有不同的漏洞。这种系统实际上非常难维护
服务器存储大：数据仓库的典型设计，会产生大量的中间结果表，造成数据急速膨胀，加大服务器存储压力。

因此上有了Kappa架构。

Kappa架构

Kafka的创始人Jay Kreps认为在很多场景下，维护一套Lambda架构的大数据处理平台耗时耗力，于是提出在某些场景下，没有必要维护一个批处理层，直接使用一个流处理层即可满足需求，Kappa架构。

Kappa架构的兴起主要原因：

批处理被被认为是流式处理的一个子集，所以可以省略掉。
Kappa架构相对更简单，实时性更好，所需的计算资源远小于Lambda架构，随着实时处理的需求在不断增长，更多的企业开始使用Kappa架构。

Kappa架构的流行并不意味着不再需要批处理，批处理在一些特定场景上仍然有自己的优势。比如进行一些数据探索、机器学习实验，需要使用批处理来反复验证不同的算法。Kappa架构适用于一些逻辑固定的数据预处理流程，如统计一个时间段内商品的曝光和购买次数、某些关键词的搜索次数等。

参考

1\]mob604756ebed9f, 一网打尽Flink高频面试题,[blog.51cto.com/u_15127538/...](https://link.juejin.cn?target=https%3A%2F%2Fblog.51cto.com%2Fu_15127538%2F2659011 "https://blog.51cto.com/u_15127538/2659011") \[2\]阿凡卢,Kafka中的exactly-once,[www.cnblogs.com/luxiaoxun/p...](https://link.juejin.cn?target=https%3A%2F%2Fwww.cnblogs.com%2Fluxiaoxun%2Fp%2F13048474.html "https://www.cnblogs.com/luxiaoxun/p/13048474.html") \[3\]大数据流动,Flink入门宝典（详细截图版）,[juejin.cn/post/684490...](https://juejin.cn/post/684490394427195392 "https://juejin.cn/post/684490394427195392") \[4\]独孤风/大数据流动，Flink流批一体实现原理，[mp.weixin.qq.com/s/o8ZIinTSe...](https://link.juejin.cn?target=https%3A%2F%2Fmp.weixin.qq.com%2Fs%2Fo8ZIinTSeGZvfT19gyU2Eg "https://mp.weixin.qq.com/s/o8ZIinTSeGZvfT19gyU2Eg") \[5\]kk大数据，水位和窗口，[cloud.tencent.com/developer/a...](https://link.juejin.cn?target=https%3A%2F%2Fcloud.tencent.com%2Fdeveloper%2Farticle%2F1539213 "https://cloud.tencent.com/developer/article/1539213") \[6\]先荐，流式计算简介，[aijishu.com/a/106000000...](https://link.juejin.cn?target=https%3A%2F%2Faijishu.com%2Fa%2F1060000000009451 "https://aijishu.com/a/1060000000009451") \[7\]Heriam，深入理解Lamda架构，[www.cnblogs.com/cciejh/p/la...](https://link.juejin.cn?target=https%3A%2F%2Fwww.cnblogs.com%2Fcciejh%2Fp%2Flambda-architecture.html "https://www.cnblogs.com/cciejh/p/lambda-architecture.html") \[8\]皮皮鲁的科技星球,大数据处理平台从Lambda到Kappa的演进,[juejin.cn/post/684490...](https://juejin.cn/post/6844904013217923086 "https://juejin.cn/post/6844904013217923086") \[9\]废物大师兄, Flink 入门, [www.cnblogs.com/cjsblog/p/1...](https://link.juejin.cn?target=https%3A%2F%2Fwww.cnblogs.com%2Fcjsblog%2Fp%2F12905871.html "https://www.cnblogs.com/cjsblog/p/12905871.html") \[10\]zhisheng, Flink从0到1学习------ 分享四本 Flink 国外的书和二十多篇 Paper 论文,[aijishu.com/a/106000000...](https://link.juejin.cn?target=https%3A%2F%2Faijishu.com%2Fa%2F1060000000002768 "https://aijishu.com/a/1060000000002768") \[11\]Flink官方，Flink的容错机制，[nightlies.apache.org/flink/flink...](https://link.juejin.cn?target=https%3A%2F%2Fnightlies.apache.org%2Fflink%2Fflink-docs-master%2Fzh%2Fdocs%2Flearn-flink%2Ffault_tolerance%2F "https://nightlies.apache.org/flink/flink-docs-master/zh/docs/learn-flink/fault_tolerance/") \[12\]林小铂，Flink容错，[www.whitewood.me/2019/07/28/...](https://link.juejin.cn?target=http%3A%2F%2Fwww.whitewood.me%2F2019%2F07%2F28%2F%25E6%25B7%25B1%25E5%2585%25A5%25E7%2590%2586%25E8%25A7%25A3-Flink-%25E5%25AE%25B9%25E9%2594%2599%25E6%259C%25BA%25E5%2588%25B6%2F "http://www.whitewood.me/2019/07/28/%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3-Flink-%E5%AE%B9%E9%94%99%E6%9C%BA%E5%88%B6/")