这是阿里巴巴搜索基础设施团队高级总监Xiaowei Jiang的客座文章。这篇文章改编自阿里巴巴在Flink Forward 2016上的演讲，你可以在这里看到会议的原始演讲。

阿里巴巴是全球最大的电子商务零售商。我们2015年的年销售额总计3940亿美元 - 超过eBay和亚马逊的总和。阿里巴巴搜索是我们的个性化搜索和推荐平台，是我们客户的关键切入点，负责我们的大部分在线收入，因此搜索基础架构团队不断探索改进产品的方法。 是什么让电子商务网站上的搜索引擎变得更好？实时的结果对于每个用户而言尽可能相关且准确。

在阿里巴巴的规模上，这是一个非常重要的问题，很难找到能够处理我们用例的技术。 ApacheFlink®就是这样一种技术，阿里巴巴正在使用基于Flink的系统Blink，为其搜索基础设施的关键方面提供支持，并为最终用户提供相关性和准确性。

在这篇文章中，我将介绍Flink在阿里巴巴搜索中的角色，并概述我们选择在搜索基础架构团队中与Flink合作的原因。 我还将讨论如何通过Blink调整Flink以满足我们的独特需求，以及我们如何与数据工匠和Flink社区合作，将这些更改贡献给Flink。一旦我们成功将我们的修改合并到开源项目中，我们正在积极地将我们的系统从Blink转换为vanilla Apache Flink。

第1部分：阿里巴巴搜索中的Flink

文档创建

为用户提供世界级搜索引擎的第一步是构建可供搜索的文档。在阿里巴巴的案例中，该文件由数百万个产品清单和相关产品数据组成。 搜索文档创建是一项挑战，因为产品数据存储在许多不同的地方，并且由搜索基础架构团队将所有相关信息汇集在一起​​以创建完整的搜索文档。一般来说，这是一个3阶段的过程：

1. 将来自不同来源（例如MySQL，分布式文件系统）的所有产品数据同步到一个HBase集群中。
2. 使用业务逻辑将来自不同表的数据连接在一起，以创建最终的可搜索文档。这是一个HBase表，我们称之为'Result'表。
3. 将此HBase表导出为文件或一组更新。

阿里巴巴搜索 - 基础设施介绍

所有这三个阶段实际上都在经典的“lambda架构”中的2个不同的管道上运行：完整构建管道和增量构建管道。

• 在完整构建管道中，我们处理所有数据源，这通常是批处理作业。
• 在增量管道中，我们处理批处理作业完成后发生的更新。例如，卖家可以修改价格或描述，或者库存可用性可能会发生变化。此信息必须尽快反映在搜索结果中。增量构建管道传统上是流工作。

搜索算法的实时A/B测试

阿里巴巴实时-AB-测试

在线机器学习

这里有几个应用程序，首先，我们将讨论实时功能更新。阿里巴巴搜索排名中使用的一些功能包括产品点击率，产品库存和总点击次数。这些数据会随着时间的推移而变化，如果我们可以使用最新的可用数据，我们将能够为用户提供更相关的搜索排名。我们的Flink管道为我们提供在线功能更新，并大大提高了转换率。 其次，一年中有特定的日子（如单身日））产品大幅折扣 - 有时高达50％ 。 因此，用户行为发生了巨大变化。交易量巨大，通常比我们在正常日子看到的高很多倍。我们之前训练过的模型在这种情况下毫无用处，因此我们使用我们的日志和Flink流媒体作业来支持在线机器学习，构建考虑实时数据的模型。结果是这些不常见但非常重要的销售日的转化率要高得多。

阿里巴巴，在线机器学习

第2部分：选择一个框架来解决问题

当我们选择Flink为我们的搜索基础设施提供支持时，我们的评估包括以下四个类别。Flink满足了我们四个方面的要求。

• 敏捷性：我们的目标是能够为整个（2管道）搜索基础架构流程维护一个代码库。我们想要一个足够高级的API来表达我们的业务逻辑。
• **一致性： **对卖方或产品数据库的更改必须反映在最终搜索结果中，因此搜索基础架构团队需要至少一次语义（对于公司中的其他一些Flink用例，我们只有一次要求）。
• 低延迟：当库存可用性发生变化时，必须非常快速地反映在搜索结果中; 例如，我们不希望对售罄的产品给出高搜索排名。
• 成本：阿里巴巴处理大量数据，在我们的规模上，效率提升可显着节省成本。我们需要一个能够有效处理高吞吐量的框架。

更广泛地说，有两种方法可以考虑统一批处理和流处理。第一种方法是使用批处理作为起点，然后尝试在批处理之上构建流。但是，这可能无法满足严格的延迟要求，因为模拟流的微批处理需要一些固定的开销 - 因此，当您尝试减少延迟时，开销的比例会增加。在我们的规模上，需要为每个微量接头安排1000个任务，重新建立连接，并重新加载状态。因此，在某些时候，微批方法变得过于昂贵而无法理解。 另一方面，Flink使用流媒体作为基本起点，并在流媒体之上构建批处理解决方案，批处理基本上是流的特殊情况。使用这种方法，我们不会在批处理模式下失去优化的好处 - 当流是有限的时，您仍然可以进行任何您希望进行批处理的优化。

第3部分：什么是Blink？

Blink是Flink的分支版本，我们一直在努力满足我们在阿里巴巴的一些独特要求。此时，Blink正在几个不同的集群上运行，每个集群大约有1000台机器，因此大规模的性能对我们来说非常重要。 Blink的改进通常包括两个方面：

• 使Table API更加完整，以便我们可以为批处理和流式传输提供相同的SQL
• 更强大的YARN模式仍然与Flink的API和更广泛的生态系统100％兼容

表API

我们首先添加了对用户定义函数的支持，以便将我们独特的业务逻辑轻松地引入Flink。我们还添加了一个流到流的连接，这是一项非常重要的任务，但由于Flink对州的一流支持，在Flink中相对简单。接下来，我们添加了一些不同的聚合，最有趣的可能是distinct_count，以及窗口支持。 （编者注：FLIP-11涵盖了与上面列出的功能相关的Flink的一系列Table API和SQL改进，建议读者阅读对该主题感兴趣的任何人。）

Blink表-API改进

接下来，我们将介绍运行时改进，我们可以进入四个单独的类别。

Blink on Yarn

当我们开始我们的项目时，Flink支持2种集群模式：独立模式和YARN上的Flink。在YARN模式下，作业无法动态请求和释放资源，而是需要预先获取所有必需的资源。并且不同的作业可能共享相同的JVM进程，这有利于资源利用而不是资源隔离。 Blink包含一个体系结构，其中每个作业都有自己的JobMaster，可根据作业的要求请求和释放资源。并且不同的作业不能在同一个Java进程中运行，从而在作业和任务之间产生最佳隔离。阿里巴巴团队目前正在与Flink社区合作，将这项工作贡献给开源，并且FLIP-6（除了YARN之外还扩展到其他集群管理器）可以获得改进。

闪烁上纱

Operator Rescale

在生产中，我们的客户可能需要改变运营商的并行性，但与此同时，他们不想失去状态。当我们开始研究Blink时，Flink不支持在保持状态的同时改变运算符的并行性。Blink将“桶”概念作为国家管理的单位。存在比任务更多的存储桶，并且每个任务将被分配多个存储桶。当并行性发生变化时，我们会将桶重新分配给任务。使用此方法，可以更改运算符的并行性并维护状态。

（编者注： Flink社区同时为Flink 1.2解决了这个问题 - 该功能在最新版本的主分支中可用。Flink关于“关键组”的概念在很大程度上与上面提到的“桶”相同，但实现方式略有不同，数据结构如何支持这些桶。有关更多信息，请查看Jira中的FLINK-3755。）

Blink运营商的重新调整

增量检查点

在Flink中，检查点分两个阶段进行：在本地拍摄状态快照，然后将状态快照保存到HDFS（或其他存储系统），并且状态的整个快照与每个快照一起存储在HDFS中。我们的状态太大，不能接受这种方法，因此Blink只将修改后的状态存储在HDFS中，并且我们已经能够大大提高检查点效率。这种修改使我们能够在生产中使用大型状态。

Blink增量检查点

异步I / O.

许多工作的生产瓶颈是访问HBase等外部存储。为了解决这个问题，我们引入了异步I / O，我们将致力于为社区做出贡献，并在FLIP-12中进行了详细介绍。 （编者注：数据工匠认为FLIP-12足够大，可以在不久的将来在某个时候单独写一篇文章。所以我们只是简单介绍一下这个想法，暂时你应该看看如果您想了解更多内容，请参阅FLIP文章。在发布时，代码已经提供给Flink。）

Blink异步IO

第4部分：阿里巴巴Flink的下一步是什么？

我们将继续优化我们的流媒体作业，特别是更好地处理临时偏斜和慢速机器，而不会否定背压的积极方面和更快的故障恢复。正如Flink Forward的一些不同发言人所讨论的那样，我们认为Flink作为批处理器和流处理器具有巨大的潜力。我们正在努力充分利用Flink的批处理功能，并希望在几个月内实现Flink批处理模式。 会议的另一个热门话题是流式SQL，我们将继续在Flink中添加更多的SQL支持和Table API支持。阿里巴巴的业务继续增长，这意味着我们的工作变得越来越大 - 确保我们可以扩展到更大的集群变得越来越重要。 非常重要的是，我们期待继续与社区合作，以便将我们的工作贡献回开源，以便所有Flink用户都能从我们在Blink中投入的工作中受益。我们期待在Flink Forward 2017上向您介绍我们的进展情况。

本篇文章翻译自 https://www.ververica.com/blog/blink-flink-alibaba-search