阿里新一代实时计算引擎 Blink，每秒支持数十亿次计算
发布时间：2018-02-08 17:59

　　作者介绍

　　王峰，淘宝花名”莫问"，2006年毕业后即加入阿里巴巴集团，长期从事搜索和大数据基础技术研发工作，目前在计算平台事业部，负责实时计算北京研发团队。

　　在阿里巴巴的11年工作期间，持续专注大数据计算与存储技术领域，基于Hadoop开源生态打造的数据基础设施一直服务于搜索、推荐等阿里核心电商业务场景，最近一年带领团队对Apache Flink进行了大量架构改进、功能完善和性能提升，打造出了阿里新一代实时计算引擎: Blink。目前数千台规模的Blink生产集群已经开始在线支持搜索、推荐、广告、蚂蚁金服等核心实时业务场景。

　　

　　王峰在清华大学演讲

　　实时计算时代来临

　　随着互联网应用的普及、智能硬件的发展，数据的种类和规模都呈现了爆炸式的增长，各行各业都希望能够从大数据中发掘出更深层次的信息和知识，并产生实际价值。数据挖掘手段也逐渐从基本的数据统计向更高层次的机器学习和深度学习演变，但这些都需要强大的计算能力作为支撑，因此大数据价值的体现离不开大数据计算平台的发展。

　　目前大数据业界在计算技术上已经取得了显著的成果，例如：第一代开源的大数据处理技术Hadoop已经可以处理超大规模的数据集合，第二代开源的大数据处理技术Spark更好的利用了内存，并进一步加快了大数据处理的性能。

　　各大公司也都基于自身业务场景和数据规模定制了自己的大数据计算平台，但这些大数据计算平台大都是批处理系统，虽然具备海量数据处理能力，但在时效性上有明显的滞后。显然，数据的价值不仅体现在空间维度上，同时也在时间维度上进行伸展，很多场景下数据的价值也会随着时间的流逝而逐渐消失。因此，大数据计算平台需要能够尽可能的提升计算的时效性，越快地从数据中挖掘出信息就意味着能够获取到更大的价值。

　　时效性对数据价值的影响尤其在电子商务领域更加明显。通常人们在不同时刻会有着不同的消费需求和潜在目标。很多时候，这些需求和目标都是临时的（即和历史行为关联度较低），并且从产生到结束之间的时间是非常有限的。这种情况在阿里巴巴双十一大促这样的场景中表现的尤为明显。

　　大促场景下，用户会由于丰富的促销活动和环境而临时产生更多的购物需求，并且每个购物需求的有效期是有限的。因此，搜索和推荐系统需要及时发现用户的需求变化，在数据有效期内完成模型更新，推荐用户当前感兴趣的商品。此外，阿里巴巴的数据大屏也需要在大促期间实时展示成交额等大家关注的统计信息，而不是大促结束后第二天再让大家看到数据。

　　其实目前不仅在阿里巴巴，各个行业都对大数据时效性的计算需求在日益增加，因此，阿里巴巴需要研发世界级一流的流式计算引擎，实时处理海量数据，提供在线统计、学习和预测能力，不仅支持阿里巴巴自己的核心电商场景，同时也能通过阿里云向外部中小企业提供流式计算服务，输出实时计算能力，这就是我今天要分享的最新一代阿里巴巴实时计算引擎Blink。

　　流式计算介绍

　　显然批量计算模型是无法满足当前大数据实时计算需求的，只有流式计算模型才是实时计算的天然计算模型，因此我先介绍下流式计算的基本思想，尤其是区别于传统批量计算的一些概念。批量计算是对于有限固定的数据集合进行处理，流式计算是对无限数据流的处理，即计算无法确定数据何时会结束。从另一个角度看，批量计算其实也可以认为是流式计算的一种特例，因此批量计算可以看做是一个数据流中的片段，即有明确开始和结束标记的数据流，如下图所示：

　　

　　完善的流式计算不仅应该提供实时计算能力，还应该支持计算过程中的状态管理，状态主要是指计算过程中需要的数据或者变量，例如：统计计算中的aggregation(sum/min/max…)，机器学习中的feature和model，状态管理包括这些数据的存储、备份、恢复，版本管理，提供读写访问API，并保证一致性，如下图所示：

　　

　　此外，完善的流计算还需要考虑数据的时序问题，因为现实场景中，数据的产生顺序和接收顺序未必一致，因此需要给数据附带时间戳属性，即：event time，计算逻辑可以按照数据的event time来处理，这样可以解决数据的乱序问题，配合watermark机制，可以较好的解决time window计算，如下图所示：

　　

　　流和批统一的计算引擎

　　

　　完整的生态系统

　　

　　状态管理和一致性

　　Chandy-Lamport算法是Flink支持状态管理和强一致性的核心理论基础，算法基础思想如下图所示：

　　

　　Chandy-Lamport算法的核心思想就是定期在流式计算任务中插入Barrier，然后触发整个流做一次Checkpoint，即将任务的State做一次Snapshot持久化保存。在下次任务重启的时候，可以基于上次成功的Checkpoint进行恢复，过程如下图所示：

　　

　　Flink的问题

　　综上所述，Flink是一套理念和架构设计非常先进的流处理引擎，并几乎支持了流式计算所有的特质，但Flink发展尚在初期，在活跃度和成熟度上稍有欠缺，并且尚未在业内得到大规模生产实践的检验，因此是无法直接应用在阿里巴巴这种级别的生产场景中的，因此我们在2015年下半年启动了Blink项目，目标是扩展、优化、完善Flink，使其能够应用在阿里巴巴大规模实时计算场景，并将此项目命名为Blink，下面我将介绍Blink的设计以及在阿里巴巴的应用。

　　Blink介绍

　　Blink产生背景

　　在2015年，当时我们还是阿里巴巴搜索事业部的数据技术团队，负责阿里巴巴所有商品搜索后台的数据处理，包括淘宝，天猫，B2B等全球商品，面对海量商品的数据处理，我们需要在维护两套数据处理流程，一套是每天晚上的全量流程，同时还要一套白天的实时增量流程，为了降低开发和维护成本，我们开始探索一套流和批统一的计算引擎。

　　当时我们重点分析对比了Spark和Flink两套技术，最后虽然觉得Spark相对成熟稳定，但Spark是从Batch出发，模拟Streaming，而Flink正好相反是从Streaming出发，认为Batch是Streaming的Special Case，因此我们感觉Flink的设计思想更先进，更适合未来的计算发展方向，更适合我们的需求，因此我们决定选择Flink技术方向。

　　Blink - Alibaba Flink

　　虽然Flink具备流计算的各种优势，但Flink在成熟度和活跃度上的不足，使得我们无法在阿里巴巴业务场景中直接使用，因此我们启动了Blink项目，目标就是扩展、优化、完善Flink，使其能够应用在阿里巴巴大规模实时计算场景，并将我们在阿里巴巴对Flink的改进都回馈给开源社区。

　　最近一年中Blink已经将多项架构、功能和性能改进贡献给Flink社区，例如：

　　Flink架构升级，插件化原生支持不同调度系统，并实现了原生运行在Hadoop YARN上

　　Failover稳定性改进，优化了Task/TaskManager以及JobManager各种组件Fail的场景处理

　　提出并实现了增量式Checkpoint的架构，使得Flink的Checkpoint/Recovery速度大幅提升，成本明显下降

　　提出并实现了Async Operator，通过异步方式，让I/O密集型计算节点的性能大幅提升

　　提出了大量Table API的全新设计，以及流和批在SQL层面的统一概念和方案

　　Blink在阿里巴巴的现状

　　

　　Blink实时计算引擎在阿里巴巴内部是运行在Hadoop集群上的，Blink计算任务会根据自己的需求向YARN申请计算资源，运行过程中周期性将计算状态持久化到HDFS上，以方便随时恢复，因此可以看出新型的Blink计算平台也可以很好的leverage成熟的Hadoop生态。

　　在API层，Blink提供了基础的DataStream/DataSet API，用户可以利用基础API有较高自由度的开发。此外，Blink重点提供了Table API/SQL这种高级语言API，可以降低门槛让更多开发人员以更低成本进行开发，这对于更多更快速的业务接入是非常有价值了，而且在SQL层Flink之前的进展是非常缓慢的，Blink对Flink给与了非常及时的补充和完善。

　　此外，基于Blink，我们建设出了一套在线机器学习平台Porsche，其为算法人员提供了一套非常丰富的算法插件机制，帮助算法人员快速搭建各种常用的机器学习流程。因此，Porsche完全leverage了Blink的实时计算能力，并释放了Blink在实时在线机器学习领域的力量。

　　目前Blink已经在阿里巴巴生产环境运行将近一年时间，支持了阿里巴巴多条核心业务线，例如：搜索，推荐，推荐，蚂蚁和安全等，大致的生产运行规模如下所示：

　　运行的总机器数已经超过3000台

　　最大的生产集群机器数已经超过1500台

　　每秒支持数十亿次的实时计算

　　最大的生产任务已经超过5000个并发，包含10TB级的State，亿级TPS

　　Blink在去年阿里巴巴双11购物节中完成了第一次正式的挑战，搜索和推荐全实时链路全天稳定运行，不仅保证了淘宝、天猫商品实时更新无延迟，同时基于Blink的在线机器学习平台Porsche由于能够较好的将用户和商品行为实时学习，因此产生了非常好的时效性效果，大幅提升了双11商品成交转化率。

　　例如：双11当天有很多爆款商品，销售速度非常快，可能很快售罄，如果将用户都引导到这些商品上，会导致用户实际没有成交机会，浪费大量流量，良好的时效性数据可以让在线学习平台较快的预测到这种场景，并将用户流量进行更加合理的分配。因此可以看出，基于实时计算的在线机器学习平台其实已经开始真正走向舞台，并产生巨大价值。

　　Blink在阿里巴巴的经典案例

　　实时A/B Test

　　A/B Test的目标就是通过实时数据分析和统计反馈，不断调整在线系统的算法模型，自动适应到最佳效果， A/B Test数据收集和处理流程大致如下图所示，Blink任务从线上日志实时同步用户行为数据，然后解析、过滤、统计，最终将各项统计指标写入OLAP系统中，让算法或者运营人员可以实时看到线上实际效果，从而合理调整配置各种模型，逐步达到最佳效果。

　　

　　商品数索引构建流程

　　淘宝的搜索引擎是用户在淘宝购物的最主要入口，淘宝的商品数据处理和索引构建流程大致如下图所示，淘宝的商品库都存储的阿里巴巴的MySQL集群中，搜索的数据处理流程需要从MySQL将数据同步到搜索引擎后台的HBase存储中（类似：Google都将网页抓取到BigTable中），然后进行各种业务逻辑处理和索引构建，最终将索引推送到在线搜索引擎中提供搜索服务。

 

      由于淘宝的商品搜索引擎需要在每天白天不断进行实时商品更新，同时晚上还需要一套额外的全量商品更新流程，因此基于Blink的统一计算模型，流式计算和批量计算可以使用一套用户逻辑代码完成。

　　Porsche – 在线机器学习平台

　　在线机器学习平台利用了Blink强大的实时计算能力，能够实时的对海量用户和商品行为数据进行流式特征提取以及训练学习，并将实时更新的特征和模型实时同步给在线的搜索和推荐引擎，实现个性化搜索和推荐，数据流程如下图所示：

　　Blink技术架构

　　15

　　从Blink的架构图中可以看出，Blink在内部模块组成上和Flink是有着非常清晰的界限的，绿色部分是和Flink共享的基础核心框架，Blink在这些框架、协议和接口上的改进都会回馈给社区，保证兼容性。

　　但蓝色部分是扩展层，例如：资源管理，状态存储，运维监控、Debug工具，输入输出层等，Blink都会根据阿里巴巴技术生态和业务场景进行定制开发，使得Blink能够在和Flink共享基础内核和生态的前提下，依然能够灵活支持阿里巴巴自身的场景需求。

　　这种架构设计，将之前开源技术的开放通用化和企业需要定制需求的矛盾进行了解耦，使得我们既可以和开源社区密切合作，享受开源的红利，同时也可以根据阿里巴巴自身需求进行高度定制和优化，不会受制于外部不可控因素。

　　Blink的未来

　　目前Blink已经在阿里巴巴内部达成共识，成为阿里巴巴统一的实时计算引擎，接下来我们将继续加大在Blink技术发展上的投入，并与开源社区更加密切的合作，突进流式计算的发展。应用场景上，一方面会继续扩大计算规模，并提推出内部统一实时计算服务，统一支持阿里内部的所有实时计算业务；另一方面也将会通过阿里云的公有云和专有云渠道向外界输出我们的实时计算能力，让更多行业和用户也都能享受到阿里巴巴实时计算的技术成果。

　　总之，Blink的实时计算之路刚刚开启，未来必将有更大的挑战和机遇，也非常欢迎各位对实时计算有兴趣的技术爱好者以及高校学子们投身到这件开创新一代计算平台的事情上来。

　　作者：王峰