2019-06-05 09:35
大家好，非常高兴来到这边，我来自阿里云的郭华，今天的题目是《从Flink看大数据实时化》。
讲到Flink或者大数据实时化一般讲到的是流处理系统，今天的主题围绕这三个方面进行展开：流处理概述、流处理一般应用架构、流处理应用场景。
首先从实时性、易用性方面看一下开源大数据引擎这十几年的简单历史，我们都知道开源大数据引擎实际上理论上起源于04年谷歌发表的那篇MapReduce的论文，06年的Hadoop基本上完整实现了论文里描述的当时的系统叫做MapReduce，但是MapReduce在实时性、易用性上都有问题，实时中把大量中间数据放到硬盘中去导致虽然具备大批量的数据处理能力，但是它的数据是比较慢的。另外在易用性方面，只提供了MapReduce，这意味着都必须拆解成Map和、Reduce两个阶段，这意味着一系列的都需要MapReduce串联起来进行调度非常的繁琐。08年facebook启动了一个ladoop项目，大家知道SQL是一个使用门槛非常低的语言，把SQL提交给hive，其实hive是大大降低了MapReduce的应用门槛，所以Hadoop和hive还是标准化的解决方案。05年Spark出现了，在实时性、易用性上都有改变。从实时性上讲，这是Spark最大的亮点，设置了基于内存中间数据，通过这种形式大大加速了批处理内容，从易用性方面提供了RDD的数据抽象，在此基础上提供了非常多的算子，还有了更高的表达灵活度。但是Spark虽然说加速了MapReduce的计算过程，但还不是大数据实时化的系统，真正的流处理是11年研究的。当时它的作者经常处理来自消息队列的数据，这时候他想既然数据是一条条过来的，为什么计算不能一条条处理？在这种思路影响下开发了Storm引擎。Storm也比较成功但是还是初级的引擎，14年的Flink是比Storm成熟的。Storm可以做到至少处理一次，而Flink能够做到确保只处理一次，同时是没有中间阶段的，Flink是有自己的中间状态存储的，所以直接可以在里面进行统计。另外Flink在这个基础上又提供了更高级别的窗口以及更高层次的API、SQL等等，另外Flink除了流处理之外还在流处理基础上又封装了一层批处理引擎，所以我们说Flink叫下一代的大数据引擎，是因为它完整的具备了流和批的处理能力。
从这个版本里面来看，开源大数据的计算引擎主要通过实时性和易用性两个方面演进的，实时性从最开始基于硬盘的批处理、基于内存的批处理、实时的流处理，易用性上从MapReduce到RDD到bolt到了SQL，这是一个简单的历史。
刚才说Storm那种起诉的批处理不是实时化，流处理才是。什么是实时化？是一个事件从发生到把结果发出去的延迟，从这个结果来看批处理，假设有一堆数据，这时候有个需求开发了一个作业，这个作业提交之后把那些数据都读过来进行处理，处理完之后把结果发出去，所以在这种情况下它的延迟是比较高的。具体体现在两个方面：第一，它是由计算驱动的，而计算往往是由调度器发起的，调度器和事件发生本身是没有直接关系的；另外，它每次处理是个全量的处理，把所有数据都捞进来进行计算，计算本身也是比较耗时的。这两种计算影响下延迟是比较高的，基本上是小时级别的延迟。
再看一下流处理，流处理整个模型是不一样的，流处理里面数据是没有终结数概念的，会假设数据源源不断流进来。写个作业提交以后，作业也不会停止。同样从那两个角度来看，首先是由事件驱动的，只要有事件触发计算就会自动进行，这个延迟比较低；另一个它是一个增量的计算，意味着每次只处理一小部分数据，计算过程本身也比较难。综合这两方面，流处理能够做到秒级亚秒级的延迟，所以叫做大数据实时化的引擎。
流处理一般的应用架构，如图是个非常抽象的应用架构，有两个关键点：
1、消息队列；
2、流计算数据。
举例来说不管是WEB、APP或者IoT设备会实时把事件发送到消息队列里面去，目前事件本身就是事件型的，只要发到消息队列里去，流计算处理这些队列，关联一些历史数据进行处理，处理下游既可以是消息型也可以是静态的。消息型的可以供其他流处理系统进行消费，静态的可以做流向分析，当然架构是比较抽象的。
接下来讲几个比较典型的应用场景，一句话说，流计算是广泛的适用于大数据实时化的场景，具体从两个方面展开：
1、从公司维度，公司分成业务部门、数据部门、运维部门。
2、从数据处理的技术维度，把数据处理分成实时APL还有实时统计分析、还有事件驱动型应用。
理论上需要3×3，9个案例才能覆盖所有组合。介于时间关系我今天讲3个，一个是实时索引构建、实时统计数仓、实时异常检测。
实时索引构建。以电商场景为例，我们知道搜索引擎是提供在线搜索服务的，提供搜索服务的前提是数据都已经建立到索引之中了。比如在电商场景下，你的数据源是来自于商品的数据库、店铺数据库、自己统计的销量。搜索商品既要包括搜索数据店铺数据，也要包括销量等等。
首先把这些数据全都读进来，一批读进来之后进行关联，把结果进行拼接，拼接成最后搜索要展示的记录，之后建立到索引里面去，这是一次索引过程。当然商家在不停的发布新品，那些已发布的商品它的信息也在变化，所以还需要一个调度系统定期的刷新这些状态，也就是说它定时的调度、重复批索引的过程。这时候假设这个调度加处理本身需要一个小时，极端情况下就会出现一个问题——假如商家发布了一款商品，有可能N小时之后才会被消费者搜到，这种体验无论对商家还是消费者来讲都是非常不好的。
所以我们提了一种叫做实时索引的方案。实时索引就是刚才讲到流处理一般架构里面提到两点，第一点是系队列替换里面的存储，实时索引也是一样。第一步是把商品书数据库、销量统计库的增量发到消息队列里去了，存到MYSQL里也是可行的，MYSQL的Blog也是增加的，只要同步进去就OK了。第二部分是流计算并到消息队列，也就是说把所有信息都拼接起来，推送到索引里面去，这个过程是非常快的，可能是几秒时间，商家发布一款产品一两秒之内消费者就搜到了。
另外需要全量的索引过程，有两个系统，第一这个系统启动的时候已经存在了数据，不是增量的，需要全量导入一次。另外可能需要定期做数据校验，线上数据覆盖索引的数据。其实全量的可以用增量的逻辑，全量的程序定期调度每次都是把所有数据读进来，一条条发到消息队列里去，自动会触发实时索引的过程。这是批流统一的实时索引的方案，能够做到秒级的延迟。
再看实时统计和数仓场景。实时统计，假设是天猫双十一大屏，这是非常简单的抽象，因为天猫双十一大屏也是在我们平台进行支持的，需求是按类别实时统计PV、UV、当日实时销量和历史总销量，实时PV、UV都是活动数据一般存在日志里面。实时销量是定单信息，定单信息是数据库里的。假设在RDS上，第一步是把两部分数据发到消息队列里去，流计算定义这个消息队列，这时候出现的问题是订单里面数据只有商品ID，要用类目进行统计，所以要关联静态的数据，把静态数据放到RDS里面去。流计算做一个操作把商品类目拿到，根据类目实时统计PV、UV和当日量。这时候统计历史总销量的时候可能出现一个问题，网站上线时间比较长，有十年了，流计算里面不可能维护一个十年的中间状态。这时候我们需要一个离线的系统，比如流计算已经把每天的汇总都存到数据库里，离线数据把这些加起来就是历史的，展示到RDS里去，只要定期刷新RDS就可以了，这是非常简单的实时大屏的应用场景。
讲完实时大屏，做一个升级是实时数仓。数仓本质上也是指流计算，因为计算指标特别多，所以出现了特别多分层统计建模的理论，分ODS、DWD层、明细层、汇总层。按照我们的说法，实时计算对传统大数据的改造，第一步是把数据替换成消息队列，这个案例是来自于菜鸟的仓备团队。
他们首先把业务里面的数据都发到消息队列里面去，这个消息队列就对应于传统数仓里面的ODS层，我们把它叫原始数据层。流计算定义这个消息队列，先进行数据清洗、关联，拼接成一个明细的数据，这和刚才讲的实时ETL的过程是一样的。这个过程接着发到消息队列里去，这个叫实时明细层。定义明细层的数据比如按照小时做一个汇总，在这种情况下很多时候要做天级汇总，在小时级汇总基础上做天级汇总就完成了。
同时处理过程中中间数据都是落到传统存储的，比如做明细查询、OLAP分析都可以存到ADS，大家也可以选别的。另外有时候做大屏展示，就要支持KV查询的，因为他们数据量比较大，就选了Hbase，这就是非常简单的实时数仓的架构，主要是两个方面，第一是用消息队列取代了原来的数据分层里的表。第二是用订阅式流计算取代了原来调度驱动的批处理。当然数仓真正复杂的部分并不在于架构，而在于它的建模，这也不是今天讨论的范围，我也不是这方面的专家，大家有兴趣可以搜索一下相关资料还是非常全的，我就不详细讲了。
我们讲最后一个，实时异常检测；先说一个非常简单的异常检测算法，大家都知道高斯分布，就是大量的数据、正常的数据在中间，少量的数据在两端。所以我们认为，如果一个事件，它落到了中间就是正常的，落到了两端就是异常的。在这种思路下，我们假设这个事件有很多特征，每个特征都遵循于高斯分布，具体这个检测分三步：
1、训练。把所有特征各自的高斯分布算出来，其实高斯不就两个参数，平均值、方差，把两个参数按照历史数据做一个统计就OK了。
2、第二步找一个要检测的事件，把它的每个特征都在自己的高斯分布里边计算一下概率，这个事件的概率认为是它所有特征概率的乘积，这就是事件本身的概率。
3、取一个阈值，大于阈值就是正常的，否则就是异常的。我们看一个基于Flink和高斯分布的异常检测系统，检测主机或者服务有没有发生问题。
为了进一步简化这个问题假设只有一个特征，就是日志打印的频率。系统调用初测的时候会打印一个日志，出错了会不停的打印，把这个当成一个特征。第一步还是之前讲的架构，把主机信息、运营日志都发送到消息队列里边去。这时候做一个训练，挑一批正常的数据统计一下平均值和方差。第二步用Flink定义消息队列，这里用kafka，定义一个实时ETL的过程，统计一个打印的频率，代入之前算好的频率和方差，得到当前打印日志频率的概率。概率低于一个值我们就觉得这是异常的，发一个值看一下，最终这些都写到Elasticsearch里，这是一个非常简单的实时异常检测的系统。
今天这里讲的都非常的浅显，这里贴了一个网址，有实时计算的案例，有十几篇，每篇都有详细说明，大家有兴趣可以看一下，右边是我个人得微信帐号，对今天所讲的内容如果有问题的话可以加我讨论一下。我今天的演讲就到这里，谢谢大家！