一、实时计算架构

1.1 背景

2016年的双11我们的实时数据直播大屏有三大战场，它们分别是面向媒体的数据大屏、面向商家端的数据大屏、面向阿里巴巴内部业务运营的数据大屏。

每一个直播大屏对数据都有着非常高的精度要求，特别是面向媒体的数据大屏，同时面临着高吞吐、低延时、零差错、高稳定等多方面的挑战。在双11的24小时中，支付峰值高达12万笔/秒，处理的总数据量高达百亿，并且所有数据是实时对外披露的，所以数据的实时计算不能出现任何差错。除此之外，所有的代码和计算逻辑，都需要封存并随时准备面对包括美国证监会在内的监管机构的问询及和检查。

在面向商家的数据直播大屏中，为了实时观察店铺流量情况，需要处理全网的所有流量数据。另外，为了让商家更全面更细地分析流量，增加了很多实时的数据维度，比如我们需要计算每个商家的访客数量、加购数量、热销商品、流量来源、每个商品的访问情况等等。

面向阿里巴巴内部业务运营小二的数据大屏，则提供了最为丰富角度的数据。除了大盘数据之外，还针对不同业务进行了定制，如淘宝、天猫、天猫国际、天猫超市、无线、聚划算、淘海外、飞猪旅行、村淘、AliExpress、卖全球等业务模块，每个业务模块还会进行各维度的交叉分析，比如行业、类目、地域等。这些数据监控了当天活动进展的方方面面，也是当天活动应急响应决策的重要依据。

以上每个直播功能需要实时处理的数据量都是非常庞大的，每秒的总数据量更是高达亿级别，这就对我们的实时计算架构提出了非常高的要求。在面对如此庞大数据的时候，我们的实时处理是如何做高精度、高吞吐、低延时、强保障的呢？

1.2 实时计算处理链路整体架构

DRC: DRC(Data replication center)是阿里自主研发的数据流产品，支持异构数据库实时同步，数据记录变更订阅服务。为跨域实时同步、实时增量分发、异地双活、分布式数据库等场景提供产品级的解决方案。

TT: TT(TimeTunnel)是一个高效的、可靠的、可扩展的消息通信平台，基于生产者、消费者和Topic模式的消息中间件。

GALAXY: Galaxy是全球领先的通用流计算平台，支撑阿里绝大部分实时计算任务，支持专有云打包输出。平台易用性高、数据准确性100%、集群线性扩展、支持容错、支持多租户、资源隔离。双11流量暴增情况下，Galaxy做到毫秒级计算延迟，满足极高稳定性要求，每天处理消息量万亿级。

OTS: 开放结构化数据服务（Open Table Service，OTS）是构建在飞天大规模分布式计算系统之上的海量结构化和半结构化数据存储与实时查询的服务， OTS以数据表的形式组织数据，保证强一致性，提供跨表的事务支持，并提供视图和分页的功能来加速查询。OTS适用于数据规模大且实时性要求高的应用。

1.3 实时计算聚合组件：XTool介绍

在实时数据统计的场景中，大部分都是根据某些维度进行去重、求和、算记录数、求最大值、求最小值、求平均值、算排行榜等聚合计算，另外还会涉及到实时多表join、静态维表关联、时间窗口管理等。而storm只提供了最底层的计算算子，每一次的聚合操作、关联操作等都是需要代码开发的，效率非常低，并且对于实时计算中checkpoint、snapshot的存储和恢复没有标准化的定义。

为了提高实时计算开发效率和降低运维成本，我们在storm的trident语义上，把通用聚合功能封装成了XTool组件，提供配置化定义实时计算拓扑，不需要任何的代码编写。另外，聚合组件还提供了重跑、续跑、exactly one等各种特性，方便修复日常运维中遇到的数据问题。XTool是一个完整的实时计算解决方案，对接了数据同步中间件（TimeTunnel）、数据储存（HBase）、流计算引擎（storm）等，把这些系统结合起来形成一个通用的实时计算服务架构。

XTool通过xml文件来描述实时任务的拓扑结构，只需要在里面中定义数据源输入、聚合维度、聚合指标、输出信息、任务监控信息等，XTool会自动解析成对应的聚合Task，并在storm集群中提交实时任务，用户不需要管临时数据如何存储、故障如何恢复、事务信息保障等细节问题。

海量数据实时处理中经常会遇到雪崩、数据倾斜、数据重复等问题，除了通用功能外，XTool通过输入限流、自动Hash分桶、主键唯一化等策略来解决以上的问题。例如在遇到数据倾斜问题时，只需要配置一个标记，XTool在解析xml文件时会自动对distinct操作进行Hash分桶去重，在下层直接进行求和就可以得到去重指标。

高性能是实时计算中赖以生存的特性，XTool组件为了满足百万/秒甚至千万/秒的qps要求，进行了大量的性能和资源调优工作。比如进行指标去重的时候支持精准去重、布隆去重、基数估计去重等模式，在业务需求和资源使用率上取得很好的平衡。另外，XTool会按照LRU（最近最少）算法缓存聚合结果在内存中，并把维度的key做成布隆集合，当新数据来的时候，可以避免不必要的读库操作。XTool还充分利用了localOrShuffle特性（类似Hadoop中的map计算本地化），把计算移到数据存储节点上进行，大幅减少数据序列化次数，性能提升非常显著。

目前几乎所有面对商家、媒体、运营小二、高管的实时计算应用都是通过XTool来实现的，其经历了几次双11的考验，表现出非常高的吞吐量和稳定性保障，功能也越来越丰富。后面计划把XTool通过Apache Beam来实现，让其不再只能依赖storm计算引擎，可以灵活在各个引擎间进行切换，比如Flink、Apex、Spark等。

1.4 OneService服务介绍

统一数据服务平台（OneService）是数据技术及产品部-产品技术主导的，以集团数据公共层One Data提供上层应用接口依始，提供简单数据查询服务（承接包括公共层所有数据在内多个BU简单数据查询服务），复杂数据查询服务（承接集团用户识别（OneID）、用户画像（GProfile）复杂数据查询服务），实时数据推送服务 三大特色数据服务。

简单数据查询服务：定位简单数据查询引擎，通过物理表、逻辑表组合绑定的方式，将具体数据来源屏蔽在引擎内部，用户在平台简单配置来源表等元数据信息，便可以做到不需要依赖任何应用、代码获得接口服务（hsf服务），目前SmartDQ支持接入数据源类型为HBase/Mysql/Phoenix/OpenSearch；

复杂数据查询服务：复杂数据查询引擎，目前承接了集团用户识别（OneID）、用户画像（GProfile）等复杂数据处理查询；

实时数据推送服务：通过数据推送机制，对外提供高性能、高稳定性的JsonP/webSocket接口，提供流量和交易相关的实时数据推送服务。

OneService还重点解决了服务的高可用问题：

服务本身的高可用：例如多机房部署、HSF分组隔离等，这里不再展开。

查询链路的快速切换能力：媒体大屏用到的GMV等指标，后台一般都会冗余多个计算任务，并写入到多个HBase集群上。如果某个集群出现不可用或者数据延迟，需要能秒级切换到另一个集群上。

二、大数据整体链路如何应对

2.1 如何进行实时任务优化

优化工作在实时计算中显得尤为重要，如果吞吐量跟不上的话，也就失去了实时的特性。吞吐量不佳原因非常多，有些是跟系统资源相关，有些跟实现方式相关，以下几点是实时任务优化中经常需要考虑的要素：

1、独占资源和共享资源的策略：

在一台机器中，共享资源池子是给多个实时任务抢占的，如果一个任务在运行时的80%以上的时间都需要去抢资源，这时候就需要考虑给它分配更多的独占资源，避免抢不到CPU资源导致吞吐量急剧下降。

2、合理选择缓存机制，尽量降低读写库次数：

内存读写性能是最高的，根据业务的特性选择不同的缓存机制，让最热和最可能使用的数据放在内存，读写库的次数降下来后，吞吐量自然就上升了。

3、计算单元合并，降低拓扑层级：

拓扑结构层级越深，性能越差，因为数据在每个节点间传输时，大部分是需要经过序列化和反序列的，而这个过程非常消耗CPU和时间。

4、内存对象共享，避免字符拷贝：

海量数据处理中，大部分对象都是以字符串存在的，在不同线程间合理共享对象，可以大幅降低字符拷贝带来的性能消耗，不过要注意不合理使用带来的内存溢出问题。

5、高吞吐和低延时间取平衡：

这两个特性是一对矛盾体，当把多个读写库操作或者ACK操作合并成一个的时候，可以大幅降低因为网络请求带来的消耗，不过也会导致延时会高一些，在业务上衡量做两者的取舍。

2.2 如何进行数据链路保障

实时数据的处理链路非常长（数据同步->数据计算->数据储存->数据服务），每一个环节出现问题，都会导致实时数据停止更新。实时计算属于分布式计算的一种，而单个节点故障是常态的，这种情况在直播大屏中特别明显，因为数据已经不再更新了，所有的客户都会发现数据出现了问题。因此，为了保障实时数据的可用性，需要对整条计算链路都进行多链路搭建，做到多机房容灾，甚至异地容灾。

由于造成链路问题的情况比较多，并且一般不能在秒级里面定位到原因，因此会通过工具比对多条链路计算的结果数据，当某条链路出现问题时，一定会比其他链路计算的值小，并且差异会越来越大。这时候会一键切换到备链路，并且通过推送配置的形式让其秒级生效，所有的接口调用会立刻切到备链路，对直播大屏完全透明，并且用户也感知不到故障的发生。

2.3 如何进行压测

在双十一备战中，会对实时链路进行多次压测，主要是模拟双十一的峰值情况，验证系统是否能够正常运行。压测都是在线上环境进行的，这里面分为数据压测和产品压测，数据压测主要是蓄洪压测。类似大坝中把几个小时甚至几天的数据积累下来，并在某个时刻全部放开，达到模拟双十一洪峰流量的情况，这里面的数据属于真实的数据。比如通过把实时作业的订阅数据点位调到几个小时或者几天前，这时候每一批读到的数据是最多的，对实时计算的压力也最大。

产品压测还细分为产品本身的压测和前端页面稳定性测试：

1、产品压测：

通过收集大屏服务端的所有读操作的url，通过PAP压测平台进行压测流量回放，按照QPS：500次/每秒 的目标进行压测。在过程中不断的迭代优化服务端的性能，提升大屏应用处理数据的性能。

2、前端页面稳定性：

将大屏页面在浏览器打开，并进行8小时到24小时的前端稳定性测试。监控大屏前端js对客户端浏览器的内存、CPU等消耗。检测出前端js内存泄漏等问题并fix，提升前端页面的稳定性。

三、架构升级应对未来

流式计算是对批处理的一个补充，其中最重要的特点就是实时性，而随着业务的增长，实时计算需要处理的数据也会随着增长，因此，吞吐量的提升是实时计算中最大的挑战。除此之外，降低开发成本、提升运维效率也是我们一直追求的目标，让实时计算技术给更多的业务场景提供价值。

我们会通过架构升级、底层计算引擎优化、业务逻辑优化等方式来突破实时计算的性能瓶颈，力求把实时计算的性能提高一个数量级。另外，后面计划把XTool移植到Apache Beam (Google Dataflow)上面，并尝试底层不同引擎的Beam Runner （Flink，Apex，Gearpump等新开源流计算技术以及阿里巴巴自己的Galaxy），封装数据统计的流计算开发产品（图形化定义流计算拓扑结构），让其保持良好的可移植性；同时让流计算开发对 ETL开发人员更友好，降低流计算的开发成本；加强阿里巴巴在开源社区的影响力。