双11数据大屏背后的实时计算处理

作者：藏六 黄晓锋 同杰

双11数据大屏的实时计算架构

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集群上。如果某个集群出现不可用或者数据延迟，需要能秒级切换到另一个集群上。

更多本文内容，请关注文末，扫码在线阅读！

双11背后的大规模数据处理

作者：惠岸 朋春 谦乐

TimeTunnel（TT）在阿里巴巴集团内部是一个有着超过6年历史的实时数据总线服务，它是前台在线业务和后端异步数据处理之间的桥梁。从宏观方面来看，开源界非常著名的Kafka+Flume的组合在一定程度上能够提供和TT类似的基础功能；不同的是，在阿里巴巴的业务体量和诉求下，我们有比较多的配置管控、资源调度、轨迹校验和血缘识别等方面的工作，如下图：

图 6 TimeTunnel产品架构

1 Pub/Sub服务

通过图 7我们清楚地看到，TT的核心部分是一个基于HBase做中间存储的Pub/Sub服务，它提供了一个能支撑高读写比、大吞吐量和数据不丢的队列服务。除此之外，基于日常运维考虑，我们还支持了按时间seek和弹性伸缩的能力。

数据需要在Pub/Sub“落地”的需求一方面来自于业务上对热点数据多份消费的考虑，另一方面一些在线算法方面的应用需要经常性地对数据进行回放训练，数据“落地”能够比较好地对前后台进行解耦。事实上，TT里最热门的数据（例如天猫交易相关）有超过100倍的读写比；而从整体来看，仅双11当天流出TT的数据也比流入的数据多了3倍以上。

选择HBase作为中间存储的原因是能够成本较低地复用基于HDFS的多副本存储能力，以及HBase自身在提供读写服务时对于热点数据的内存管理能力。图 8是写入TT的数据在HBase中的存储模型，我们在broker层面通过构造合理的rowkey来使得同一个分区下的数据可按rowkey顺序scan；同时，因为在生成rowkey的时候我们使用了broker上的时间戳作为高位变量，因此能很方便地提供按时间seek的能力。

图 7 数据在HBase中的存储模型

2 数据采集

图6左侧黄色部分是TT的数据采集方案。我们通过以下途径来准实时地收集前台业务产生的增量数据：
1)、依赖DRC实现对MySQL、OceanBase以及Oracle等前台业务数据库的增量变更进行捕捉解析；
2)、自研的日志Agent部署在数十万台的应用服务器上，准实时地捕捉应用日志的变化；
3)、和其他一些内部主流存储例如OTS进行打通；
4)、用户采用TT提供的SDK主动写入。

随着集团内重要业务异地多活架构和全球化的发展，数据采集分散在跨越数千甚至上万公里的多个IDC中；而与此相反，以Galaxy、ODPS为代表的大数据计算服务则需要考虑充分地利用大集中的架构来提升吞吐能力。因此，不可避免地在数据采集过程中需要对数据进行缓冲和压缩以尽可能降低长途链路对于吞吐量的负面影响。

矛盾的是，缓冲意味着前端产生的数据需要在采集端“等待”，也就意味着消费方看到的数据是延迟的。这对于像阿里妈妈这样依赖TT做反作弊和实时计费的业务来讲是很难接受的，数据延迟意味着资损，意味着用户体验的显著下降。同样地，压缩也是要消耗采集端的服务器资源的，尤其在双11这样的场景下，前台业务对于采集端的功耗尤其敏感。

遗憾的是，世界上从来没有一个只带来好处而没有任何弊端的事物，软件和产品的设计中处处都是折衷和取舍。除了在技术层面将实现细节做到尽可能极致，TT为了服务这些不同的场景，也提供了一些可配置的参数例如buffersize、sendthreads、compressLevel等用来匹配用户对延时、性能以及功耗的不同需求。

更多本文内容，请关注文末，扫码在线阅读！

突破传统，4k大屏的沉浸式体验

作者： 彦川、小丛

能够在 4K 的页面上表演，对设计师和前端开发来说，即是机会也是挑战，我们可以有更大的空间设计宏观的场景，炫酷的转场，让观众感受影院式视觉体验，但是，又必须面对因为画布变大带来的性能问题，以及绞尽脑汁实现很多天马行空的的想法。下面是这次双11媒体大屏开发中我们的一些设计和思路。

1 3D动感跑道

当逍遥子零点倒数5，4，3，2，1，0！激昂音乐奏起，媒体中心大屏幕跳跃出一个动感十足的页面，黄橙橙的 GMV 数字蹭蹭往上长，跳跃的翻牌器下有个不断向前延伸的跑道，两旁错落有致的建筑群，顶部有一簇簇如烟花般四面飞散的点状射线…

1.1场景设计

场景包括三个部分：红色的猫门，左右两旁的建筑群，底下的炫彩跑道。基本结构如下：

1.2构建 3D 模型

基于WebGL技术，以其中的几何体构建出一个个 3D模型，为了使得建筑群错落有致，逐一调整每幢建筑的位置（调整 position 中的 x,y,z 值）

对于不规则的建筑模型，采用多种几何体拼凑的形式

1.3给建筑“穿上衣服”

现在的建筑还是死气沉沉的几何体，给每幢建筑渲染不同的图片材质后，便灵动起来了。

最后给猫门和跑道都渲染上材质，一个完整的场景便构建出来了。

1.4“跑起来吧！”

整体的动效设计是：沿着炫彩跑道不断向前冲刺，迎面而来的建筑群给观众一种强烈的视觉冲击之感。开发思路：

(1) 猫门＋跑道＋左右建筑为一个整体，复制两组，沿着 z 轴依次摆放；

(2) 摄像机的 z 值在不断前进，即不断累加；

(3) 当摄像机的 z 值超过一组模型的 z 值时候，重置该组的 z 值，移至末端。以此往复。

2 可形变的地图

地图是展现大数据可视化的最好背景，没有之一。一般情况下，可视化地图场景分为 3D 球面和 2.5D 平面两种，以前两者往往是隔绝开来的，根据展示数据的维度选择一种，比如讲全球贸易时，用球面场景的页面，讲国家贸易时，切换到 2.5D 平面场景的页面。多页面切换严重影响了阅读数据的连贯性，不符合讲故事的风格。因此，我们利用 WebGL 设计了一个可形变的地图，把场景集中在一个页面展示。

在 3D 的世界里，首先有的是点，其次是线和面，不管是平面地图还是球面地图，它们的本质都是点的集合，如果控制了点，就控制了 3D 世界的变化。我们的变形地图是一个由无数点组成的对象，通过GLSL(OpenGL Shading Language)语言，我们可以动态改变地图上点的位置。

举个简单的例子，在平面地图中，北京在世界坐标系中的位置是 P， 在球形地图中，北京在相同世界坐标系中的位置是 Q，那么从平面到球面的形变过程，其实就是 P 点到 Q 点的移动，反之亦然。推广到所有组成平面的点，形变的本质就是所有点移动到目的地点的过程。我们分别对所有点的起点（平面点）和终点（球面点）进行线性插值，就可以得到每个点的形变路径，剩下的事情就是加个缓动函数，让点运动起来。