阿里妹导读：今年的双11再次刷新了记录——支付成功峰值达25.6万笔／秒、实时数据处理峰值4.72亿条/秒。面对较去年增幅%的数据洪峰，流计算技术可谓功不可没。今天，我们将揭开阿里流计算技术的神秘面纱。
双11刚刚拉下帷幕，激动的心还停留在那一刻：
当秒针刚跨过11号零点的一瞬间，来自线上线下的千万剁手*在第一时间涌入了这场年度大趴——从进入会场到点击详情页，再到下单付款一气呵成。
前台在大家狂欢的同时，后台数据流量也正以突破历史新高的洪峰形式急剧涌入：
支付成功峰值达25.6万笔／秒
实时数据处理峰值4.72亿条/秒
而作为实时数据处理任务中最为重要的集团数据公共层（保障着业务的实时数据、媒体大屏等核心任务），在当天的总数据处理峰值更是创历史新高达1.8亿/秒！想象下，1秒钟时间内千万人涌入双11会场的同时，依然应对自如。
流计算的产生即来源于数据加工时效性的严苛需求：
由于数据的业务价值会随着时间的流失而迅速降低，因此在数据发生后必须尽快对其进行计算和处理，从而能够通过数据第一时间掌握业务情况。今年双11的流计算也面临着一场实时数据洪峰的考验。
首先来展示今年（年）较去年（年）数据洪峰峰值的比较：
年：支付成功峰值12万笔/秒，总数据处理峰值万/秒
年：支付成功峰值25.6万笔／秒，实时数据处理峰值4.72亿条/秒，阿里巴巴集团数据公共层总数据处理峰值1.8亿/秒
在今年双11流量峰值翻翻的情况下，依然稳固做到实时数据更新频率：从第1秒千万剁手*涌入到下单付款，到完成实时计算投放至媒体大屏全路径，秒级响应。面对越发抬升的流量面前，实时数据却越来越快、越来越准。在hold住数据洪峰的背后，是阿里巴巴流计算技术的全面升级。
流计算应用场景
数据技术及产品部定位于阿里数据中台，除了离线数据外，其产出的实时数据也服务于集团内多个数据场景。包括今年（其实也是以往的任何一年）双11媒体大屏实时数据、面向商家的生意参谋实时数据，以及面向内部高管与小二的各种直播厅产品，覆盖整个阿里巴巴集团大数据事业部。
同时随着业务的不断发展壮大，到目前为止，日常实时处理峰值超万/s，每天总处理记录数已经达到万亿级别，总处理数据量也达到PB级别。
面对海量数据的实时数据我们成功做到了数据延迟控制在秒级范围内，在计算准确率上，已实现了高精准、0误差，达到精确处理。比如：今年的双11当天，双十一媒体屏第一条记录从交易表经过流计算计算处理到达媒体大屏秒级响应。
数据中台流计算实践中的数据链路
在经过最近几年大促数据洪峰的经历后，使得我们的流计算团队在引擎选择，优化性能以及开发流计算平台上都积累了丰富的经验。我们也形成了稳定高效的数据链路架构，下图是整个数据链路示意图：
业务数据的来源非常多，分别通过两个工具（DRC与中间件的logagent）实时获取增量数据，并且同步到DataHub（一种PubSub的服务）。
实时计算引擎Flink作业通过订阅这些增量数据进行实时处理，并且在经过ETL处理后把明细层再次回流到Datahub，所有的业务方都会去定义实时的数据进行多维度的聚合，汇总后的数据放在分布式数据库或者关系型数据库中（Hbase、Mysql），并通过公共的数据服务层产品（OneService）对外提供实时数据服务。
最近一年，我们在计算引擎和计算优化方面做了很多工作，实现了计算能力、开发效率的提升。
计算引擎升级及优化
在年，我们在实时计算架构上进行了全面的升级，从Storm迁移到Blink，并且在新技术架构上进行了非常多的优化，实时峰值处理能力提高了2倍以上，平稳的处理能力更是提高5倍以上：
优化状态管理
实时计算过程中会产生大量的state，以前是存储在HBase，现在会存储在RocksDB中，本地存储减少了网络开销，能够大幅提高性能，可以满足细粒度的数据统计（现在key的个数可以提升到亿级别了，是不是棒棒哒~）
优化checkpoint（快照/检查点）和