大数据之路读书笔记-05实时技术_大数据的及时性是指数据的价值有时效性,越来越多的场景对数据处理速度提出了要求

大数据之路读书笔记-05实时技术

在大数据系统中，离线批处理技术可以满足非常多的数据使用场景需求，但在 DT 时代， 每天面对的信息是瞬息万变的，越来越多的应用场景对数据的时效性提出了更高的要求。数据价值是具有时效性的，在一条数据产生的时候，如果不能及时处理并在业务系统中使用，就不能让数据保持最高的“新鲜度”和价值最大化。

如图 5.1 所示是 2016 年“双 11”全球狂欢节当天，面向媒体开发的数据直播大屏在 24 点时定格的成交数据：1207 亿。在前台实时直播的数据，实际上是阿里实时计算系统在承载。直播大屏对数据有着非常高的精度要求，同时面临着高吞吐量、低延时、零差错、高稳定等多方面的挑战。在“双11”的 24 小时中，支付峰值高达 12 万笔／秒，下单峰值达 17 .5 万笔／秒，处理的总数据量高达百亿，并且所有数据是实时对外披露的，所以数据的实时计算不能出现任何差错。除此之外，所有的代码和计算逻辑都需要封存，并随时准备面对监管机构的问询和检查。

除面向媒体的数据大屏外，还有面向商家端的数据大屏、面向阿里巴巴内部业务运营的数据大屏。整个大屏直播功能需要实时处理的数据量非常庞大，每秒的总数据量更是高达亿级别，这就对实时计算架构提出了非常高的要求。面对如此庞大的数据量，阿里巴巴的实时处理是如何做到高精度、高吞吐量、低延时、强保障的呢？

---

5. 1 简介

相对于离线批处理技术，流式实时处理技术作为一个非常重要的技术补充，在阿里巴巴集团内被广泛使用。在大数据业界中，流计算技术的研究是近年来非常热门的课题。

业务诉求是希望能在第一时间拿到经过加工后的数据，以便实时监控当前业务状态并做出运营决策，引导业务往好的方向发展。比如网站上一个访问量很高的广告位，需要实时监控广告位的引流效果，如果转化率非常低的话，运营人员就需要及时更换为其他广告，以避免流量资源的浪费。在这个例子中，就需要实时统计广告位的曝光和点击等指标作为运营决策的参考。
按照数据的延迟情况，数据时效性一般分为三种（离线、准实时、实时）
●离线：在今天（ T）处理 天前 N, N > I ）的数据，延迟时间粒度为天。
●准实时 ：在当前小时（H）处理 小时前 H-N, N>O ，如 0.5小时、 小时等）的数据，延迟时间粒度为小时。
●实时 ：在当前时刻处理当前的数据，延迟时间粒度为秒；
离线和准实时都可以在批处理系统中实现（比如 HadoopMax Compute Spark 等系统），只是调度周期不一样而己，而实时数据则需要在流式处理系统中完成。简单来说，流式数据处理技术是指业务系统每产生一条数据，就会立刻被采集并实时发送到流式任务中进行处理，不需要定时调度任务来处理数据。
整体来看 ，流式数据处理一般具有以下特征。

1.时效性高
数据实时采集、实时处理，延时粒度在秒级甚至毫秒级，业务方能够在第一时间拿到经过加工处理后的数据。
2.常驻任务
区别于离线任务的周期调度，流式任务属于常驻进程任务， 一旦启动后就会一直运行，直到人为地终止，因此计算成本会相对比较高。这一特点也预示着流式任务的数据源是无界的，而离线任务的数据源是有界的。这也是实时处理和离线处理最主要的差别，这个特性会导致实时任务在数据处理上有一定的局限性。
3. 性能要求高
实时计算对数据处理的性能要求非常严格，如果处理吞吐量跟不上采集吞吐量，计算出来的数据就失去了实时的特性。比如实时任务钟只能处理 30 秒采集的数据，那么产出的数据的延时会越来越长，不能代表当前时刻的业务状态，有可能导致业务方做出错误的运营决策在互联网行业中，需要处理的数据是海量的，如何在数据量快速膨胀的情况下也能保持高吞吐量和低延时，是当前面临的重要挑战。因此，实时处理的性能优化占了任务开发的很大一部分工作。
4. 应用局限性
实时数据处理不能替代离线处理，除了计算成本较大这个因素外，对于业务逻辑复杂的场景（比如双流关联或者需要数据回滚的情况），其局限性导致支持不足。另外，由于数据源是流式的 ，在数据具有上下文关系的情况下，数据到达时间的不确定性导致实时处理跟离线处理得出来的结果会有一定的差异。

5.2 流式技术架构

在流式计算技术中，需要各个子系统之间相互依赖形成一条数据处理链路，才能产出结果最终对外提供实时数据服务。在实际技术选型时可选的开源技术方案非常多，但是各个方案的整体架构是类似的 只是各个子系统的实现原理不太一样。另外，流式技术架构中的系统跟离线处理是有交叉的，两套技术方案并不是完全独立的，并且在业界中有合并的趋势。
各个子系统按功能划分的话，主要分为以下几部分。
1 数据采集
数据的源头，一般来自于各个业务的日志服务器（例如网站的浏览行为日志、订单的修改日志等），这些数据被实时采集到数据中间件中，供下游实时订阅使用。
2.数据处理
数据被采集到中间件中后，需要下游实时订阅数据，并拉取到流式计算系统的任务中进行加工处理。这里需要提供流计算引擎以支持流式任务的执行。
3.数据存储
数据被实时加工处理（比如聚合、清洗等）后，会写到某个在线服务的存储系统中，供下游调用方使用。这里的写操作是增量操作，并且是源源不断的。
4.数据服务
在存储系统上会架设一层统一的数据服务层（比如提供 HSF 接口、HTTP 服务 ），用于获取实时计算结果。
整体技术架构如图 5.2 示。

从图 5.2 可以看出，在数据采集和数据服务部分实时和离线是公用的，因为在这两层中都不需要关心数据的时效性。这样才能做到数据源的统一，避免流式处理和离线处理的不一致。

5.2.1 数据采集

数据采集是整个数据处理链路的源头，是所有数据处理链路的根节点，既然需要做到实时计算，那么自然就需要做到实时采集了。所采集的数据都来自于业务服务器，从所采集的数据种类来看，主要可以划分为两种：
●数据库变更日志，比如 MySQL binlog 志、 HBase hlog志、 Ocean Base 的变更日志、 Oracle 的变更日志等。
●引擎访问日志，比如用户访问网站产生的 pache 擎日志、搜索引擎的接口查询日志等。
不管是数据库变更日志还是引擎访问日志，都会在业务服务器上落地成文件，所以只要监控文件的内容发生变化，采集工具就可以把最新的数据采集下来 。一般情况下，出于吞吐量以及系统压力上的考虑，并不是新增一条记录就采集1次，而是基于下面的原则，按批次对数据进行采集。
●数据大小限制：当达到限制条件时，把目前采集到的新数据作为批（例如 512KB 批）。
●时间阐值限制：当时间达到一定条件时，也会把目前采集到的新数据作为一批，避免在数据量少的情况下一直不采集（例如 30秒写一批）。
只要上面的其中一个条件达到了，就会被作为一批新数据采集到数据中间件中，这两个条件的参数需要根据业务的需求来设定，当批次采集频繁时，可以降低延时，但必然会导致吞吐量下降。
对于采集到的数据需要一个数据交换平台分发给下游，这个平台就是数据中间件。数据中间件系统有很多实现方式，比如开源的系统有Kafka ，而阿里巴巴集团内部用得比较多的是 TimeTunnel （原理和 Kafka类似），还有 MetaQ Notify 等消息系统。
从图5 .3 可以看出，消息系统是数据库变更节点的上游，所以它的延时比数据中间件低很多，但是其支持的吞吐量有限。因此，消息系统一般会用作业务数据库变更的消息中转，比如订单下单、支付等消息。对于其他较大的业务数据（每天几十 TB容量），一般会通过数据中间件系统来中转，虽然它的延时在秒级，但是其支持的吞吐量高。消息系统和数据中间件的性能对比如表 5.1 所示。

另外，在一些情况下，有些业务并没有通过消息系统来对数据库进行更新（比如有些子业务的订单数据是通过同步方式导人 MySQL 的）也就是说，从消息系统中获取的数据并不是最全的，而通过数据库变更日志拿到的业务变更过程数据肯定是全的。因此，为了和离线数据源一致，一般都是通过数据中间件来采集数据库变更数据这种形式来获取实时数据的（这需要在数据处理层对业务主键进行 merge 处理，比如一笔订单可能会被变更多次，会有多条变更记录 ，这时就需要进行 merge拿到最新的数据）。
时效性和吞吐量是数据处理中的两个矛盾体 ，很多时候需要从业务的角度来权衡使用什么样的系统来做数据中转。

5.2.2 数据处理

实时计算任务部署在流式计算系统上，通过数据中间件获取到实时源数据后进行实时加工处理。在各大互联网公司中，有各种开源的和非开源的流计算引擎系统在使用。在业界使用比较广泛的是 Twitter 开源的Storm 系统、雅虎开源的 S4 系统、 Apache spark Streaming ，以及最近几年兴起的 Flink 。这些系统的整体架构大同小异，但是很多细节上的实现方式不太一样，适用于不同的应用场景。
在阿里巴巴集团内使用比较多的是 阿里云提供的 StreamCompute系统，作为业界首创的全链路流计算开发平台，涵盖了从数据采集到数据生产各个环节，力保流计算开发严谨、可靠。其提供的 SQL 语义的流式数据分析能力（ StreamSQL ），让流数据分析门槛不再存在。它在Storm 的基础上包装了一层 SQL 语义，方便开发人员通过写 SQL 就可以实现实时计算，不需要关心其中的计算状态细节，大大提高了开发效率，降低了流计算的门槛。当然，它也支持传统模式的开发，就像 Hadoop中的 Hive MapReduce 关系一样，根据不同的应用场景选择不同的方式。另 StreamCompute 还提供了流计算开发平台，在这个平台上就可以完成应用的相关运维工作，不需要登录服务器操作 ，极大地提高了运维效率。
下面以 Storm 为例，简单讲一下流数据处理的原理。实时应用的整个拓扑结构是一个有向无环图（详情可参考 Apache Storm 的官网：
http