双11前、中、后三阶段大数据计算平台全揭秘
12月6日-7日，由阿里巴巴集团、阿里巴巴技术发展部、阿里云云栖社区联合主办，以“2016双11技术创新”为主题的阿里巴巴技术论坛（Alibaba Technology Forum，ATF）成功在线举办。在本次论坛中，来自阿里巴巴的资深架构师林伟发表了《阿里大规模数据计算与处理平台》的演讲，他从双11备战、双11当天、双11后海量数据分析三个部分详解了大数据计算平台在今年双11的应用与实践。
以下内容根据在线分享和幻灯片整理而成。
双11备战
双11的成功离不开背后大数据分析，阿里云大数据平台在双11承担了海量数据分析服务，各个部门会在计算平台上对于相关数据进行深入分析从而保障双11成功进行：通过对物流包裹预测，帮助快递公司调配仓储，使得其在双11当天能够分发6.5亿件包裹，做到兵马未动、粮草先行；对花呗授信额度进行评估，将花呗额度按照每个人风险承受额度进行相应的调整；帮助商家精准营销，对访客分群预测，设计个性化店铺首页；对消费者进行智能导购，通过分析其原始购买记录，对其进行精准化营销，提高购物体验；在双11之前，对语音模型进行了大量的训练，打造更好的语音平台，在双11当天，97%的客服电话由语音机器人来接听；此外，为了保障双11的进行，对交易安全防控、个性化推荐、商家数据服务以及营销活动反作弊都进行了训练提升。
从计算平台的角度出发，可以用计算任务来量化这些准备工作：MaxCompute平台承担着阿里内部的绝大部分计算任务，日任务量为百万级别。从上图可以看出，从九月中旬开始，每日Job数目呈小幅度上升，上升幅度约为20%，这也表明了双11之前的备战是早在两个月前就已经开始了，计算平台每天都在为双11做准备。
治理数据：事半功倍
早在阿里巴巴平台业务初期，飞速增长和粗放式管理带来大量存储与计算资源的浪费，存在着大量无效的计算任务和重复的存储，例如一个新入职的小二一个上午提交了6个计算任务，运行失败，花费了18W；再比如某一个重要的应用，花了半天时间梳理自己的数据业务，把每天的花费从5W降到5千。
由于计算资源的增长落后于我们业务增长，并且我们需要降低我们成本从而能够更加高效服务于业务，因此数据治理显得尤为必要。
目前阿里打造了一个数据质量线上监控的闭环，将数据的访问、运行状态全部记录下来，然后通过计算平台的计算能力并行分析数据背后的关联；通过在线处理监控系统监控效果分析以及源表清洗，挖掘出数据和计算任务中的冗余数据。当发现某些数据或任务有待提高后，后续如何处理呢？
阿里目前采用的是健康分的治理体系，评价计算任务是否健康时主要从存储和计算健康度两个指标出发：存储健康度包括未管理表、废弃表、保留周期过长、同源导入等8种模型；计算健康度包括暴力扫描、产品未使用、数据倾斜、重复计算等17种模型。
两者经过一定的组合生成健康分，同时根据消耗的资源生成电子账单，然后送给业务方，使其明确所消耗的成本；此外，还设计了利益机制和操作平台来优化管理资源。
双11当天
上图是双11大屏的实时效果图，它能实时显示双11的实时交易额。大屏的背后支撑系统是StreamCompute（增量计算），它是阿里实时数据统计和监控的利器。双11当天，该系统使得从交易发生到媒体大屏统计出结果整个过程只耗费3秒钟；同时，它可以每秒钟处理1亿条交易记录；StreamCompute的整体性能是去年的5倍，而且整体运维过程中0故障发生。
在没有增量计算之前，整个双11的营业额统计和数据复盘处于摸索状态，双11当天发生的交易全部记录在后端，双11结束后通过批处理进行分析，最终产生报表，也就是说在报表没产生之前，是不清楚该年双11的具体状况的。这种方案无法给出实时的交易成交额，并且结果产生非常慢。
为了解决该问题，阿里开发了增量计算模型。通过增量计算，可以实现及时反馈，推动购物节气氛，使得消费者互动感更好；同时能够使得双11各个参与方及时的调整策略，从而达到更好的促销效果。那么如何完成从批处理到增量计算的转化呢？
如上图所示，批处理首先需要进行数据积累，数据积累完毕之后提交计算任务，经过Reduce之后产生最终结果，整个过程的时延其实是Job的Running time。
但我们希望在双11的24点就能看到最终结果，因此对其中的延时要求很高，为了满足该要求，引入增量计算。增量计算不是在数据积累完毕才开始进行任务，而是在数据积累过程中开始运算；Map、Shuffle、Reduce等阶段在数据开始时就已经调度了，整个过程中持续不断地接收数据并计算；因此最终一条记录完成时，最终结果也随之产生。这种增量计算的方式带来的好处有：
第一，低延时，最后一条记录到最终结果的产生期间的延时仅有数秒，整体的计算任务平摊到双11当天的每时每刻；
第二，Failover速度快，当出现错误时不需要从头计算，而是将中间状态进行检查，大大节省了Failover的时间；
第三，连续展示，通过增量计算可以将结果持续不断地进行展示；
第四，由于Task在持续不断地运算，因此任何时间的中间结果都是100%正确的，也就是说如果在这个时候输入数据停下来，其最后中间结果即最终结果。
统计一致性问题是增量计算中必须解决的问题，所谓统计一致性是指任何时刻双11卖家总数恒等于每档卖家数目。如上图所示，当A同学销售量增加到11时，红色模块加一而蓝色模块减一；当A同学销售增加15时，则绿色模块增加一，而红色模块减一。
统计一致性带来的最大好处是可以进行相对的比较，可以准确得出各个档次卖家的比例。在流式计算和增量计算中，实现统计一致性难度很高，下面来详细讲解下阿里是如何保障统计的一致性。
在具体双11案例中，初始化化参数为：（1）目前id为A的卖家初始化0元；（2）0-9档有6个卖家；（3）10-19档目前为10个卖家；（4）20-29档目前有8位卖家。第一阶段，A有了五元的生意，对应stream source中的（A,5），同时利用State（snapshot）记录营业额，即在stream t1中A的营业额变成5，stream t2中0-9档数目变为7。第二阶段，当A又发生6元生意时，营业额统计求和变为11，同时0-9档数目减一，10-19档数目加一；第三阶段，当A又发生15元生意时，营业额统计求和变为26，同时10-19档数目减一，20-29档数目加一。在整个交易额变化的过程中，输出都是update，无需读写操作。
增量计算的挑战中最大的挑战是任何时间的中间结果都是100%正确的，并且保证各统计数据的一致性；系统实现方面，要求所有的Operator都具有可逆性（在分布式环境需要处理跨partition的结果调整）。为了保障可逆性，需要state来记住原来产生的中间结果，能够快速定位到需要调整的value，进行正向和逆向操作；此外，增量还具有其他流计算的普遍问题，如流控、数据倾斜、容错和延时等等。
在增量计算中还提供了很好的SQL开发界面，便于业务方开发；同时还提供了完善的数据调试手段以及丰富的作业运维，目前的应用场景主要包括：
智慧城市：实时交通分析，拥塞和时间预测；
水、电、煤、油：工业设施故障监控和预测；
大安全（网络，金融，公安等）：预警监控，异常检测，网络攻击发现；
工业和商业智能：实时通话质量监测，实时交易大屏；
云计算和服务：广告点击分析，系统运维监控；
创新应用：客户支持、服务和维权的自动化。
为了保障双11期间的零故障，阿里也提前做了很多准备：首先采用了主备双链路容灾，实现秒级切换；同时进行全链路监控，对数据采集、读取、处理、入库的全过程指标监控，对QPS、流量、CPU/Memory/Disk/Network资源消耗的实时分析和展示，充分探究潜在问题；此外，还为双11配备了完善的运维分析工具，能够分析发现热点机器，快速定位诊断任务异常，以及进行一键任务rebalance、启停等运维操作。
双11后海量数据分析
双11产生了海量的数据，那么如何在双11之后进行复盘对数据进行分析，确保各类对账单能够按时按质的输出呢？这就依赖于后端的计算平台——MaxCompute。
MaxCompute承载了阿里巴巴集团所有的离线计算任务，是集团内部核心大数据平台。截止到目前支撑着每日百万级规模的作业，整个系统拥有数万台机器，单集群规模上万，存储已经到达了EB级别，每天有数千位活跃的工程师在平台上做数据处理。
MaxCompute目前具有两大成就：第一是在今年双11创纪录处理了180PB的数据；第二是100TB数据排序耗时仅为377s。
在MaxCompute中，大量的任务具有周期性，每天相似的查询会给优化器带来巨大机会，因此可以基于历史进行特定的优化，对每天提交的查询进行聚类，把以前运行数据作为Hint来帮助未来的相似的查询。新的查询首先经过相似判断，如果是相似查询，则进行Hint注入，帮助进行该次优化，当数据变化不大时，相当于查询预热。
在双11当天数据的暴增进而导致HBO的效果下降。为了解决这个问题，在双11到来前利用多种模型预先对各个数据的规模进行准确的预测，同时利用HBO能够添加数据运行Hint能力帮助双11当天的任务按照合理的配置调用资源，进而保障各个业务线报表的按时产出。
MaxCompute：全局调度
MaxCompute已经达到了物理集群的上限，单集群已达到上万级别，因此数据处理平台一定是跨地域搭建的，地域与地域之间采用昂贵的总线和专用网络连接。在双11海量数据产生时如何充分有效地利用跨地域带宽，做到带宽和延时的平衡呢？
首先，我们设计了一个全局调度方案，使得用户无需关心数据分布的具体位置，由系统帮助其访问。如上图案例所示，当A提交数据Update操作后，距离其最近的集群中存放着最新的数据；当B访问该数据时，系统会自动识别距离其较远的集群内的数据是最新数据，然后利用有限的带宽进行数据复制，维持数据的一致性。这个过程中有很多种选择，可以采用远程读、Replicate等多种模式；同时还需要充分考虑带宽，任务完成时效需求；需要进行全局分析，动态预先调整。