双11数据大屏背后:大规模流式增量计算及应用（附资料）

------------------

【福利 】2017云栖大会深圳峰会

3月27-29日， 37场分论坛， 100 余嘉宾

阿里云总裁、CTO及首席科学家到场分享

涵盖全球技术热点

点击文末 阅读原文

免费限时报名

报名详情见文末

------------------

首先从理解什么是数据流开始今天的分享，其实在真实的世界中，大部分的数据都是连续产生的数据流，比如手机上产生的GPS信号、用户在互联网上的行为、在线搜索、用户的点击、社交网络分享、即时通信以及一些传感器和物联网设备采集的日志信息等，这些数据都是连续产生的，自然就形成了数据流，在这些数据流产生以后， 在很多场景下对于数据流的实时分析就会产生很大的价值。

接下来从大家比较熟悉的数据场景切入，比如大家经常会关注的股市情况，股价的波动其实就是实时数据的分析和聚合，除此之外大家在日常生活中还可能比较关心天气预报，可能会根据实时的信息来看比如当前的台风的情况，这些都是大家习以为常的，也已经深入大家生活的实时数据分析。

而随着实时数据源的越来越多，实时数据的规模也越来越大，可以应用的场景也越来越多，实时数据的应用也正在往更多的领域深入。比如像每年的天猫双11全球狂欢节，阿里巴巴就有一个实时大屏，左图上是2015年的情况，当时在第35分钟的时候就已经有了200亿的销售额，同样的2016年也是一样，所有的交易数据都会在秒级之内反映在数据大屏之上，再比如在2015年还有模拟的一个地球，可以看到从卖家到买家的订单都会被实时地刻画出来，这在商业领域将会给大家一个非常直观的印象，也可以用于辅助商业决策。

特别是在安全以及监控这些领域，数据有时候除了用于看以外还可以预先设定很多规则，基于流计算的“规则引擎”提供了传统的安全监控系统无法提供的海量数据处理能力，根据这些规则就可以省去很多的人力劳动，可以自动化地进行报警，利用大规模分布式集群实时计算和分析监控数据，避免人肉数据检查的低效，有效扩大监控范围，提升监控时效。这方面目前有很多的应用，比如像监控电网的运作等。

除了判断简单规则以外，还可以通过实时分析数据去发现一些规律，去实现更多的机器智能。 这里举的是阿里巴巴帮助协鑫光伏的一个案例，协鑫光伏是一个专门加工太阳能电池的企业，它的设备都非常复杂，上面的每个设备都有几百个传感器，加起来就有成千上万路信号输入，如果通过人去理解传感器的行为，去检测或者预测哪一个设备将会发生故障再去更换，这中间的延迟就会造成很大的浪费，也就会导致次品率上升的问题。而通过实时的数据分析加上人工智能的算法最终实现了机器自动预警和判断，这样不仅提高了工作效率，甚至还能够预先自动提示操作人员对于设备的某些部件进行更换，最终实现对于良品率的提高，进而提高企业的收益。

更进一步除了对于简单结构化的数据的分析， 实时分析还可以运用到更广泛的场景， 阿里巴巴目前正在进行的一个项目就是城市大脑，就是将杭州所有城区的道路摄像头的视频信息做实时分析，用不同路口的视频信息来检测人和车的行为，以此来帮助城市更好地管理和优化交通，为解决城市拥堵问题带来很大的价值。

未来，实时数据分析将会越来越多地从我们所熟知的领域进入我们未知的领域，基于实时数据分析的应用的创新也会给我们的生活带来越来越多的变化，这将是激动人心的大趋势。

那么从流式数据处理背后的系统架构去看这个问题，实际上实时的数据处理对于大规模大数据的处理系统带来了大规模的高要求的挑战。因为数据是实时产生的，但是由于成本原因或者处理能力的问题，数据一般采取“先存后算”的架构，传统的架构上数据会在分布式文件系统中存储下来，然后再经过批量的计算，比如每天产生一个数据报表，这就是传统的数据处理的一套工具链。

而在新的要求更加实时的流式数据处理中，原来的“先存后算”的架构显然是无法满足要求的。对应的对于实时数据流的处理则希望能够随着数据的产生实时地进行加工处理，能够实现很高的时效性以及很低的计算延迟，并且实时地帮助各种各样的场景对于大数据的价值进行挖掘。

如果将流式数据处理系统架构进一步细化，从原来先存后算的架构过渡到这样一个不依赖于一开始的批量数据存储而每时每刻都要计算的架构，这中间存在着很多的问题和挑战。下图就是将系统架构稍微细化一点的示意图，对于数据源而言，首先数据是实时产生的，需要通过数据总线将实时产生的数据很低延迟地存储下来，并且需要传输给流计算。但是因为数据量的规模以及数据源端的各种复杂性，这样的数据总线是要求保证数据的持久化的，而且需要保持很低的延时，同时需要保证规模化，所以需要进行数据切片还需要保证数据的顺序。因为产生的数据本身是存在顺序的，很多应用对于数据的顺序也是非常关心的，所以整体而言对于数据总线部分是存在新的要求的，这些就是关于输入和数据采集的问题。

在之后会详细地分析计算这一部分，在这里先不考虑计算。那么假设数据通过计算之后能够产生某种价值和知识，在系统架构的消费端也需要经过改造。这里举个例子如果需要将应用改造为实时化的，可能在十几年之前会需要打印出一个纸质的报表，但是这个纸质的报表在实时处理的今天就无法展示出实时的形态了，所以首先需要进行报表电子化。其次要想实现低延迟的展现，就是从数据计算出结果到能够让用户看到计算结果需要很低的延时，否则在实时决策中的效果就无法达到预期。除此之外，整个实时计算系统是由很多服务构建的，所以计算出来的结果可能需要通过消息队列连接更多的服务，比如触发了某个规则引擎中规则，就可能需要调用某一个报警机制，比如发短信来通知用户，这就需要上下游更多系统之间的配合。第三个场景就是有时实时计算除了使得之前提到的应用成为可能还有一种场景下就需要数据采集手段的提高，因为存在大量的实时数据不得不以流式地进行预处理做一些筛选，将真正重要的信息存储下来再去进行离线的更加深入的分析。所以无论是数据的上游还是下游都需要大量的改造功能才能使得实时计算成为可能。

后面将会主要分享一下计算这部分，对于实时计算而言，需要面对很多的挑战。

首先实时计算需要很高的性能，需要保持延时和吞吐的平衡，需要很好的扩展性，能够支持超大集群规模的线性扩展。还需要考虑容错问题，大家知道在进行批处理的时候产生一个错误就需要重新计算，而且容错这部分还需要考虑低延时。还有因为很多任务可能同时在进行计算，所以也需要保证资源的有效利用。实时任务会一直占用资源，而有一些不同的数据流的输入速度不同，如何调配资源的共享和隔离也是一个挑战，除此之外还需要考虑流计算的易用性等等问题。

因为今天分享的主题是增量流式处理，所以在这这些流式计算所面对的挑战中选择一个话题展开来讲，今天就主要分享关于实时计算如何编程的问题。那么什么是实时计算的编程呢？其实就是去写一个程序来表达实时处理逻辑，数据是以流的形式进来然后存储在某个消息队列中，之后应用再去消息队列中获取数据并进行计算，并将数据产生的价值传输到下游的系统中。但是与离线计算不同，实时流式计算需要考虑很大的规模，需要同时并行地运行在很多的CPU上面，所以流式计算的编程实际上就是对于分布式程序的编程，这其实将会一个比较困难的问题。

而对于实时计算编程的一个简单的解决方式就是目前大数据方面非常通用的模型——数据流计算。 这里举的例子就是2011开源的流计算系统Storm，Storm实现的就是如图的这样一个数据流的模型，这里有输入流和输出流，中间存在多阶段的计算。

当然知识这里示例性地分为了三个阶段，而真实情况下可能有多个阶段，在每个阶段上数据并行会有多个计算节点。与批处理不同，数据流模型上面的数据是流动的，所以每个事件在每个阶段都是流水式地执行和触发的，这就是基本的数据流模型，也是被很多系统所采用的模型。下图中只画出了6个节点，如果在成千上万的节点上去写这个程序，如何表达计算逻辑就是比较困难的了。刚才提到过数据并行，所以只需要为每一个阶段编写一个程序就可以了。图中包含了三个阶段，如果根据Storm的概念来看，其实每个阶段的编程接口实际上是非常简单的，这里是一个示例，比如X节点实现了这样的一个interface，实现的函数就是当数据灌给你的时候需要该怎么做，这是一个非常简单的接口，如果以这样一个非常底层的接口去描述实时逻辑，下图中列举了一个非常简单的例子，就是WordCount将输入的数据切成Word分词，并根据一些窗口去计算词频然后进行统计。一个简单的WordCount会占用很多的代码行，图中是从网上找的一个例子，所以大家可以想象如果一个非常复杂的业务使用基本的接口去写在某些场景下会是非常困难的。

面对上述这样的问题，一个想法就是与离线计算的处理一样去寻找更高层的语言，所以大家会尝试着去使用SQL。接下来列举两个具体的例子，就是如何使用SQL将比较复杂的拓扑通过简单的几行代码描述出来。

这里的例子就是前些年一个学术界的系统，可以看到上图中左边是使用C#高级语言写的一个MapReduce的程序，实际上就把每个记录调用Mapper()函数变成多个队，之后进行GroupBy()并按照不同的组进行Select并做一个Reducer。这个程序就比刚才一行行去写要简单很多，系统也可以自动从类似于SQL的描述性语言去生成右侧的DataFlow，右侧的数据图从输入到MapReduce实际上是两个阶段。另外一个更复杂的例子是分布式排序，可以看到一个非常复杂的问题也可以通过写非常简单的语言对于每个Mapper()出来的结果给一个Key进行OrderBy()，右边在生成计划的时候可以做非常多的工作。这个例子就是想告诉大家不仅可以用高层语言来简化对于复杂拓扑的描述，还可以让拓扑在生成的时候进行很多的优化。这里稍微解释一下右边这个图，这个图就是对于数据进行排序，大家可能想象简单的MapReduce就能够进行排序，但是在实际的执行情况下为了达到高效，数据的负载均衡是非常重要的，那么如何保证数据在排序这件事情上是分段均衡的呢？这里的解决思路就是对于每一份数据都进行采样，这样就能对于数据分布进行大致地了解，根据数据分布可以确定数据应该按照什么的range进行重新划分，这样就可以将数据分的比较均匀。如果采样足够高效，这部分的时间是值得的，因为这会使得后面的计算更加高效，计算的并行度和加速比也会变得非常高。以上就是SQL的例子，可以看出，在离线的情况下SQL可以帮助我们简化编程。

接下来我们再回到在线计算，今天的问题就是如何帮助大家用各种简单的方式编写一个流计算的程序，这里举的例子是一个离线的SQL语句，那么如果直接将这个SQL用于流计算会产生什么样的问题呢？假设输入的数据是连续的无穷的数据流，在这样的情况下大家可以看到有什么样的困哪呢，因为Group By需要对于例子中所有的Customer Name进行聚合，也就是需要知道某一个“Mike”购买的全部东西才能进行聚合，但是对于实时连续不断输入的流，如何才能知道“Mike”有没有购买更多的东西呢，怎么知道什么时候该输出呢？其实这里例子就是想要告诉大家如果简单地将SQL语句用于描述数据流处理实际上在语义上是无法匹配的，所以这样例子中的Group By是不会有输出的，但是如果等所有的数据都输入之后再进行处理就无法达到低延时的效果了，这就是困难所在。

为了解决上述的问题，大家也都想了各种各样的方法，但是到目前为止并没有一个最佳的解法。其中一种方式是使用类似SQL的语言去写这个问题，但是对其中的一些算子进行修改或者引入一些必要的算子。这里举个例子就是join操作，如果在SQL里面使用join其实就是将两个表连接在一起，但是在流式计算中将两个流join如何才能知道已经流过的数据能不能与当前流中的数据连接上呢，就需要保留太多的数据，所以一种做法就是在join上加一个范围限定实现时序的join。另外Group By操作的问题就是永远都无法产生输出，所以可以弱化它的语意，让Group只做分流，不同的用户进来将会丢到不同的Group中，但是并不在其上做聚合。那么什么时候做聚合呢？就是需要在流上引入Window的概念，Window有各种各样的定义，可以按照几分钟或者几小时进行一次聚合等。总之这一系列算法都是引入类似SQL的语言实现，这个方法是微软最早出SQL Server的时候就有的流数据库的语言，目前包括亚马逊、Storm也在提这种语言，但是这部分还没有统一的标准，各家都有各家的东西。最近Apache Calcite标准试图将不同的语言进行统一，形成一套大家公认的流式语言，其实标准化非常重要，不然的话学习成本将会非常高。