IELAB网络实验室 真正的大数据！抗住1.8亿/秒数据洪峰，阿里—流计算的秘密
首先来展示2017 年较2016年数据洪峰峰值的比较：
2016 年：支付成功峰值 12 万笔 / 秒，总数据处理峰值 9300 万 / 秒
2017 年：支付成功峰值 25.6 万笔／秒，实时数据处理峰值 4.72 亿条 / 秒，阿里巴巴集团数据公共层总数据处理峰值 1.8 亿 / 秒
在17年双 11 流量峰值翻翻的情况下，依然稳固做到实时数据更新频率：从第 1 秒千万剁手党涌入到下单付款，到完成实时计算投放至媒体大屏全路径，秒级响应。 面对越发抬升的流量面前，实时数据却越来越快、越来越准。在 hold 住数据洪峰的 背后，是阿里巴巴流计算技术的全面升级。
流计算应用场景：
数据技术及产品部定位于阿里数据中台，除了离线数据外，其产出的实时数据也 服务于集团内多个数据场景。包括今年（其实也是以往的任何一年）双 11 媒体大屏 实时数据、面向商家的生意参谋实时数据，以及面向内部高管与小二的各种直播厅产 品，覆盖整个阿里巴巴集团大数据事业部。
同时随着业务的不断发展壮大，到目前为止，日常实时处理峰值超 4000 万 /s， 每天总处理记录数已经达到万亿级别，总处理数据量也达到 PB 级别。
面对海量数据的实时数据我们成功做到了数据延迟控制在秒级范围内，在计算准 确率上，已实现了高精准、0 误差，达到精确处理。比如：今年的双 11 当天，双十 一媒体屏第一条记录从交易表经过流计算计算处理到达媒体大屏秒级响应。
数据中台流计算实践中的数据链路：
在经过最近几年大促数据洪峰的经历后，使得我们的流计算团队在引擎选择，优 化性能以及开发流计算平台上都积累了丰富的经验。我们也形成了稳定高效的数据链 路架构，下图是整个数据链路示意图：
业务数据的来源非常多，分别通过两个工具（DRC 与中间件的 logagent）实时 获取增量数据，并且同步到 DataHub（一种 PubSub 的服务）。
实时计算引擎 Flink 作业通过订阅这些增量数据进行实时处理，并且在经过 ETL 处理后把明细层再次回流到 Datahub，所有的业务方都会去定义实时的数据 进行多维度的聚合，汇总后的数据放在分布式数据库或者关系型数据库中（Hbase、 Mysql），并通过公共的数据服务层产品（One Service）对外提供实时数据服务。
最近一年，我们在计算引擎和计算优化方面做了很多工作，实现了计算能力、开 发效率的提升。
计算引擎升级及优化：
在 2017 年，我们在实时计算架构上进行了全面的升级，从 Storm 迁移到 Blink，并且在新技术架构上进行了非常多的优化，实时峰值处理能力提高了 2 倍以，平稳的处理能力更是提高 5 倍以上：
优化状态管理
实时计算过程中会产生大量的 state，以前是存储在 HBase，现在会存储在 RocksDB 中，本地存储减少了网络开销，能够大幅提高性能，可以满足细粒度的数 据统计（现在 key 的个数可以提升到亿级别了，是不是棒棒哒 ~）
优化 checkpoint（快照 / 检查点）和 compaction（合并）
state 会随着时间的流转，会越来越大，如果每次都做全量 checkpoint 的话， 对网络和磁盘的压力非常大；所以针对数据统计的场景，通过优化 rocksdb 的配置， 使用增量 checkpoint 等手段，可以大幅降低网络传输和磁盘读写。
异步 Sink
把 sink 改成异步的形式，可以最大限度提高 CPU 利用率，可以大幅提供 TPS。
抽象公共组件：
除了引擎层面的优化，数据中台也针对性地基于 Blink 开发了自己的聚合组件 （目前所有实时公共层线上任务都是通过该组件实现）。该组件提供了数据统计中常用 的功能，把拓扑结构和业务逻辑抽象成了一个 json 文件。这样只需要在 json 文件中 通过参数来控制，实现开发配置化，大幅降低了开发门槛，缩短开发周期——再来举个 栗子：之前我们来做开发工作量为 10 人 / 日，现在因为组件化已让工作量降低为 0.5 人 / 日，无论对需求方还是开发方来讲都是好消息，同时归一的组件提升了作业性能。
按照上述思路及功能沉淀，最终打磨出了流计算开发平台【赤兔】。
该平台通过简单的“托拉拽”形式生成实时任务，不需要写一行代码，提供了常 规的数据统计组件，并集成元数据管理、报表系统打通等功能。作为支撑集团实时计 算业务的团队，我们在经过历年双 11 的真枪实弹后沉淀的 [ 赤兔平台 ] 中独有的功能 也成为它独一无二的亮点：
一、大小维度合并 比如很多的实时统计作业同时需要做天粒度与小时粒度的计算，之前是通过两个任务分开计算，聚合组件会把这些任务进行合并，并且中间状态进行共用，减少网 络传输 50% 以上，同时也会精简计算逻辑，节省 CPU。
二、精简存储
对于存储在 RocksDB 的 Keyvalue，我们设计了一个利用索引的 encoding 机 制，有效地将 state 存储减少一半以上，这个优化能有效降低网络、cpu、磁盘的压力。
三、高性能排序 排序是实时中非常常见的一个场景， top 组件利用内存中 PriorityQueue（优先队 列） 和 blink 中新的 MapState feature（中间状态管理特性），大幅减少序列化次数， 性能提高 10 倍左右。
四、批量传输和写操作 最终写结果表 HBase 和 Datahub 时，如果每处理一条记录都去写库的话，就 会很大限制我们的吞吐。我们组件通过时间触发或者记录数触发的机制（timer 功能）， 实现批量传输和批量写（mini-batch sink），并且可以根据业务延时要求进行灵活配 置，提高任务吞吐的同时，也降低了服务端压力。
数据保障：
对于高优先级应用（每天 24 小时不间断服务），需要做到跨机房容灾，当某条链路 出现问题时，能够秒级切换到其他链路，下图是整个实时公共层的链路保障架构图：
从数据采集、数据同步、数据计算、数据存储、数据服务，整条链路都是独立 的。通过在 Oneservice 中的动态配置，能够实现链路切换，保障数据服务不终端。
上面内容就是保障今年双 11 流量洪峰的流计算技术秘密武器——我们不仅在于 创新更希望能沉淀下来复用、优化技术到日常。
随着流计算的技术外界也在不停更迭，后续基于阿里丰富业务场景下我们还会不 断优化升级流计算技术：
1.平台化，服务化，Stream Processing as a service
2.语 义 层 的 统 一，Apache Beam，Flink 的 Table API， 以 及 最 终 Stream SQL 都是非常热的 project
3.实时智能，时下很火的深度学习或许未来会与流计算碰撞产生火花
4.实时离线的统一，这个也是很大的趋势，相较于现在普遍存在的实时一套，离 线一套的做法，实时离线的统一也是各大引擎努力想要达到的。
文章选自微信公众号阿里技术：
节选段：如何扛住 1.8 亿 / 秒的双 11 数据洪峰？ 阿里流计算技术全揭秘
https://alitech-private.oss-cn-beijing.aliyuncs.com/1515133551738/2017alitech_02.pdf?Expires=1558345626&OSSAccessKeyId=LTAIqKGWQyF6Vd3W&Signature=XVJIdtBbf0hIwF5vvcpFjlDAP5E%3D
Ielab老师：赵韶磊