2019-08-06

你公司到底需不需要引入实时计算引擎？

合理的需求选择恰当的技术栈

前言

先广而告之，本文摘自本人《大数据重磅炸弹——实时计算框架 Flink》课程第二篇，内容首发自我的知识星球，后面持续在星球里更新。

自己之前发布过一篇 Chat 《大数据“重磅炸弹”：实时计算框架 Flink》，里面介绍了多种需求：

小田，你看能不能做个监控大屏实时查看促销活动销售额（GMV）？

小朱，搞促销活动的时候能不能实时统计下网站的 PV/UV 啊？

小鹏，我们现在搞促销活动能不能实时统计销量 Top5 啊？

小李，怎么回事啊？现在搞促销活动结果服务器宕机了都没告警，能不能加一个？

小刘，服务器这会好卡，是不是出了什么问题啊，你看能不能做个监控大屏实时查看机器的运行情况？

小赵，我们线上的应用频繁出现 Error 日志，但是只有靠人肉上机器查看才知道情况，能不能在出现错误的时候及时告警通知？

小夏，我们 1 元秒杀促销活动中有件商品被某个用户薅了 100 件，怎么都没有风控啊？

小宋，你看我们搞促销活动能不能根据每个顾客的浏览记录实时推荐不同的商品啊？

……

大数据发展至今，数据呈指数倍的增长，对实效性的要求也越来越高，于是像上面这种需求也变得越来越多了。

那这些场景对应着什么业务需求呢？我们来总结下，大概如下：

初看这些需求，是不是感觉很难？

那么我们接下来来分析一下该怎么去实现？

从这些需求来看，最根本的业务都是需要实时查看数据信息，那么首先我们得想想如何去采集这些实时数据，然后将采集的实时数据进行实时的计算，最后将计算后的结果下发到第三方。

数据实时采集

就上面这些需求，我们需要采集些什么数据呢？

买家搜索记录信息
买家浏览的商品信息
买家下单订单信息
网站的所有浏览记录
机器 CPU/MEM/IO 信息
应用日志信息

数据实时计算

采集后的数据实时上报后，需要做实时的计算，那我们怎么实现计算呢？

计算所有商品的总销售额
统计单个商品的销量，最后求 Top5
关联用户信息和浏览信息、下单信息
统计网站所有的请求 IP 并统计每个 IP 的请求数量
计算一分钟内机器 CPU/MEM/IO 的平均值、75 分位数值
过滤出 Error 级别的日志信息

数据实时下发

实时计算后的数据，需要及时的下发到下游，这里说的下游代表可能是：

告警方式（邮件、短信、钉钉、微信）

在计算层会将计算结果与阈值进行比较，超过阈值触发告警，让运维提前收到通知，及时做好应对措施，减少故障的损失大小。

存储（消息队列、DB、文件系统等）

数据存储后，监控大盘（Dashboard）从存储（ElasticSearch、HBase 等）里面查询对应指标的数据就可以查看实时的监控信息，做到对促销活动的商品销量、销售额，机器 CPU、MEM 等有实时监控，运营、运维、开发、领导都可以实时查看并作出对应的措施。

让运营知道哪些商品是爆款，哪些店铺成交额最多，哪些商品成交额最高，哪些商品浏览量最多；

让运维可以时刻了解机器的运行状况，出现宕机或者其他不稳定情况可以及时处理；

让开发知道自己项目运行的情况，从 Error 日志知道出现了哪些 Bug；

让领导知道这次促销赚了多少 money。

从数据采集到数据计算再到数据下发，整个流程在上面的场景对实时性要求还是很高的，任何一个地方出现问题都将影响最后的效果！

实时计算场景

前面说了这么多场景，这里我们总结一下实时计算常用的场景有哪些呢？

交通信号灯数据
道路上车流量统计（拥堵状况）
公安视频监控
服务器运行状态监控
金融证券公司实时跟踪股市波动，计算风险价值
数据实时 ETL
银行或者支付公司涉及金融盗窃的预警

……

另外我自己在我的群里也有做过调研（不完全统计），他们在公司 Flink（一个实时计算框架）使用场景有这些：

总结一下大概有下面这四类：

实时数据存储

实时数据存储的时候做一些微聚合、过滤某些字段、数据脱敏，组建数据仓库，实时 ETL。

实时数据分析

实时数据接入机器学习框架（TensorFlow）或者一些算法进行数据建模、分析，然后动态的给出商品推荐、广告推荐

实时监控告警

金融相关涉及交易、实时风控、车流量预警、服务器监控告警、应用日志告警

实时数据报表

活动营销时销售额/销售量大屏，TopN 商品

说到实时计算，这里不得不讲一下和传统的离线计算的区别！

实时计算 VS 离线计算

再讲这两个区别之前，我们先来看看流处理和批处理的区别：

流处理与批处理

看完流处理与批处理这两者的区别之后，我们来抽象一下前面文章的场景需求（实时计算）：

实时计算需要不断的从 MQ 中读取采集的数据，然后处理计算后往 DB 里存储，在计算这层你无法感知到会有多少数据量过来、要做一些简单的操作（过滤、聚合等）、及时将数据下发。

相比传统的离线计算，它却是这样的：

在计算这层，它从 DB（不限 MySQL，还有其他的存储介质）里面读取数据，该数据一般就是固定的（前一天、前一星期、前一个月），然后再做一些复杂的计算或者统计分析，最后生成可供直观查看的报表（dashboard）。

离线计算的特点

数据量大且时间周期长（一天、一星期、一个月、半年、一年）
在大量数据上进行复杂的批量运算
数据在计算之前已经固定，不再会发生变化
能够方便的查询批量计算的结果

实时计算的特点

在大数据中与离线计算对应的则是实时计算，那么实时计算有什么特点呢？由于应用场景的各不相同，所以这两种计算引擎接收数据的方式也不太一样：离线计算的数据是固定的（不再会发生变化），通常离线计算的任务都是定时的，如：每天晚上 0 点的时候定时计算前一天的数据，生成报表；然而实时计算的数据源却是流式的。

这里我不得不讲讲什么是流式数据呢？我的理解是比如你在淘宝上下单了某个商品或者点击浏览了某件商品，你就会发现你的页面立马就会给你推荐这种商品的广告和类似商品的店铺，这种就是属于实时数据处理然后作出相关推荐，这类数据需要不断的从你在网页上的点击动作中获取数据，之后进行实时分析然后给出推荐。

流式数据的特点

数据实时到达
数据到达次序独立，不受应用系统所控制
数据规模大且无法预知容量
原始数据一经处理，除非特意保存，否则不能被再次取出处理，或者再次提取数据代价昂贵

实时计算的优势

实时计算一时爽，一直实时计算一直爽，对于持续生成最新数据的场景，采用流数据处理是非常有利的。例如，再监控服务器的一些运行指标的时候，能根据采集上来的实时数据进行判断，当超出一定阈值的时候发出警报，进行提醒作用。再如通过处理流数据生成简单的报告，如五分钟的窗口聚合数据平均值。复杂的事情还有在流数据中进行数据多维度关联、聚合、塞选，从而找到复杂事件中的根因。更为复杂的是做一些复杂的数据分析操作，如应用机器学习算法，然后根据算法处理后的数据结果提取出有效的信息，作出、给出不一样的推荐内容，让不同的人可以看见不同的网页（千人千面）。

使用实时数据流面临的挑战

数据处理唯一性（如何保证数据只处理一次？至少一次？最多一次？）
数据处理的及时性（采集的实时数据量太大的话可能会导致短时间内处理不过来，如何保证数据能够及时的处理，不出现数据堆积？）
数据处理层和存储层的可扩展性（如何根据采集的实时数据量的大小提供动态扩缩容？）
数据处理层和存储层的容错性（如何保证数据处理层和存储层高可用，出现故障时数据处理层和存储层服务依旧可用？）

总结

本文从日常需求来分析该如何去实现这类需求，需要实时采集、实时计算、实时下发，并用图片把需求完成后的效果图展示了出来，接着我们分析了对实时性要求高的计算这块，然后将离线计算与实时计算进行了对比、批处理与流处理进行对比、离线计算的特点与实时计算的特点进行了对比，再加上我自己的调研结果，归纳了实时计算的四种使用场景，提出了使用实时计算时要面临的挑战。因为各种需求，也就造就了现在不断出现实时计算框架，而下文我们将重磅介绍我们推荐的实时计算框架 —— Flink。