阿里资深搜索专家蒋晓伟：Blink计算引擎的创建和更新

　　阿里资深搜索专家蒋晓伟：Blink计算引擎的创建和更新

　　本文来自阿里巴巴资深搜索专家姜晓伟在首届阿里巴巴线上峰会上的分享。本次分享的重点是Blink计算引擎，它是阿里巴巴搜索的流式计算和批处理引擎。与Flink相比，在上层，Blink拥有完整的Table API，集成了batch和stream，可以支持各种业务需求；在底层，Blink 重新开发了兼容 Flink 和生态的 runtime，实现了流处理和批处理。完美的统一。

　　以下是整理好的内容。

　　一、Search 文档创建和更新

　　

　　要构建搜索系统，您首先需要创建一个搜索文档。具体的创建过程分为三步：第一步是将分散在各个地方的数据同步到HBase。数据同步后，HBase收录了创建文档所需的所有数据；第二步，对HBase中的数据进行汇总，经过业务逻辑处理后，将生成的需要搜索的文档存入结果表；第三步，将HBase中的结果表导出到搜索引擎中，搜索文档的创建完成。值得注意的是：上述每一步都收录两个过程，完整的和增量的。

　　物化视图

　　

　　结果表可以看作是物化视图，是一种扩展数据，类似于索引。数据库可以保证物化视图与其对应表的一致性。从物化视图的角度，可以重新解释全量和增量。所谓全量，相当于索引创建和重构的过程；而增量意味着索引的维护。通过物化视图，只能使用相同的SQL语句同时解决增量和全量问题。

　　流与表的二重性

　　

　　要在大数据中实现增量和全尺度的统一处理，我们首先需要了解几个概念。

　　第一个概念是流和表的二元性。上图左半部分是一个流，包括word和count两列，记录每个单词出现的次数；右边是一个history表，里面也有word和count两列，但是word列有一个对应的主键。如果用左边的流程更新右边的历史表，就会从原来的5条记录减少到3条记录。通过物化操作，可以将流转化为历史表；当历史表存在时，我们可以通过查看和导出历史表的修改日志来恢复原创流。从某种意义上说，流和历史表中收录的信息量是一样的。流和表的二元性意味着我们可以将流计算和批处理结合起来。需要注意的一点是，这里的表格指的是动态表格，其内容是不断修改的。

　　第二个概念是流的等价性。当且仅当它们产生相同的常规历史表时，两个流是等效的。如果有两个流用于更新同一个历史表，假设它们可以在不同的时间点获取同一个历史表，那么这两个流是等价的。流的等价性给流处理带来了极大的灵活性。正是这种灵活性，让我们能够在 Blink 中完美地结合流处理和批处理。

　　二、什么是闪烁？

　　

　　Blink 是阿里巴巴搜索团队基于 Flink 开发的计算引擎。其目的是为了支持阿里巴巴的*敏*感*词*计算需求。 Blink 实现了流处理和批处理的完美统一。与Flink相比，在上层，Blink拥有完整的Table API，集成了batch和stream，可以支持各种业务需求；在底层，Blink 重新开发了兼容 Flink 和生态的 Runtime。

　　Blink 的 Table API

　　

　　Blink 的 Table API 的设计原理是实现流和批的一体化处理。以此原理，Blink 开发了一系列功能，包括：

　　Blink 的运行时间

　　

　　Blink 在运行时也做了很多改进。一是Blink与YARN实现原生态融合；其次，它优化了Checkpoint和状态管理，使其可以在生产环境中使用。同时，Blink 兼具容错性、高可用性、稳定性和可维护性。有很大的改进；此外，Blink 还支持动态缩放。

　　三、Flink 在 YARN 上

　　

　　上图是Flink on YARN的架构，它是Hadoop中的调度系统。集成Flink和YARN的思路很简单：在运行Flink之前，需要先启动Flink集群，这个集群需要进行配置；集群启用后，Flink集群可以接收用户提交的工作； Flink集群接收到用户提供的work后，通过JobManger将YARN获取的资源分配给不同的Jobs。每个YARN Node上都有一个YARN NodeManager，用于调用不同的Container。这种架构有几个明显的缺陷：

　　首先，不同Flink Jobs的任务可能运行在同一个Flink TaskManager中，即不同Jobs的任务可能运行在同一个进程中，一个job的失败可能会杀掉整个进程，更加孤立不好;

　　第二点，因为Flink集群需要提前配置，一旦资源被Flink占用，YARN就不能再将这些资源分配给其他集群，可能会造成一定程度的资源浪费，如果预先配置资源不足，无法简单扩展Flink集群；第三，由于管理所有作业的 Flink JobManager 进程运行在一个独立的容器中，当作业急剧增加时，Flink JobManager 成为整个架构可扩展性的瓶颈。

　　Blink YARN 原生态整合

　　

　　在Blink YARN的原生态整合中，去掉了单点JobManager。当用户提交作业时，YARN ResourceManager 会启用一个 Job Master，两者相互对应。当job中的task需要资源时，会通过Job Master向YARN申请资源，实现资源的动态分配；同时，不同的Job在不同的Container中，保证Job之间的隔离。

　　Blink 的故障处理机制

　　

　　在分布式系统中，失败是不可避免的。面对机器崩溃和进程崩溃，如何保证系统一致性是一个很大的挑战。一致性主要包括至少一次和恰好一次两种语义。至少一次意味着流中的每条消息都可以保证至少处理一次而不会丢失消息。至少实施一次相对容易。您只需要记录成功处理了哪些消息。即使一条消息处理失败，您只需要在最后一条成功处理的消息后重新开始处理。

　　Exactly once 是指处理的消息和状态之间的一致性。如何只实现一次这个逻辑？在分布式系统中，我们可以通过 Chandy-Lamport 算法恰好实现一次逻辑。在流的源头，当你需要做一个检查点时，你可以插入一个名为 Barrier 的特殊消息。它的作用是将状态获取快照之前的消息与其之后的消息区分开来。 Barrier 和其他消息一样，也会流入每一个运营商。

　　Blink Worker 错误恢复

　　

　　Blink Worker 错误恢复分为两种情况：第一种是 At Least Once，如果一个节点出现故障，我们只需要重启该节点，然后找到影响该节点的源，然后重放源。 , 无需重新启动整个作业；第二个是Exactly Once，如果一个节点出现故障，我们需要找到该节点的连通图，重启节点，然后将连通图倒回到最后一个checkpoint的位置进行回放。

　　Blink Master 的高可用

　　

　　当Blink的JobMaster失败时，YARN会重启JobMaster，但此时JobMaster已经失去了原来的状态。为了保证JobMaster不会丢失原来的状态，我们将JobMaster中的代码写成状态机。每次修改状态前，都需要log到HDFS；新的JobMaster启动前，通过HDFS回放获取原创状态，保证Blink Master的高可用。

　　Blink 的动态缩放

　　

　　在流计算中，实验和实际在线使用存在偏差，随着业务的增加，流量也会发生变化。通过引入bucket，动态支持Blink的伸缩。此外，在Blink中，我们增加了多个监控指标，用于观察工作绩效。

　　四、现状和计划

　　

　　目前，Blink 已经在阿里实现了数千个机器级集群，支持搜索和推荐核心业务。同时，集团内外都对Blink表现出了浓厚的兴趣，Uber、FaceBook等公司都在考虑使用Blink。