什么是离线搜索？

一个典型的产品搜索架构如下图所示。本文重点介绍下图中的离线计算系统（offline system）。

离线是什么？在阿里巴巴的搜索技术体系中，我们将满足用户ms级请求的服务，如搜索引擎、在线评分计算、SearchPlanner等，称为在线服务；分别对来自不同来源的数据进行转换和处理并发送到搜索引擎。在线服务等系统统称为离线系统。商品搜索的业务特点（大数据、业务复杂）决定了线下系统从一开始就是一个大数据系统。它具有以下特点：

1。任务模型中区分全量和超量

1）全量 指将所有搜索业务数据重新处理并传输到网络引擎，通常每天一次。原因有二：业务数据每天更新；引擎需要完整的数据量进行高效的索引和预处理，以提高网络服务的效率。

2）增长是指从上游数据源到网络引擎实时发生的数据变化的更新。

3）性能要求高。满量程需要极高的吞吐量，这保证数亿数据能够在几个小时内完成。增长必须支持数万TPS，具有实时性能和极高的可用性。

2。需要支持各种输入输出数据源，包括：Mysql、ODPS、TT等数据库和消息队列作为输入，搜索、排名、图谱、推荐等各种引擎作为输出。

3。为了方便搜索业务开发和接入，需要提供一定的数据处理能力，比如多表连接、UDTF支持等。

在接下来的段落中，我们将看到围绕这些特征，应对搜索业务变化的线下系统架构的各种发展和发展。

开发简介

阿里巴巴商品搜索系统源于淘宝搜索。 2008年初左右，第一代搜索系统诞生，随后推出离线系统。离线搜索系统经过多年的发展，技术架构经过多次迭代，数据处理能力和业务支撑能力不断提升。下面逐步介绍离线搜索的主要技术架构和特点。

★淘宝搜索阶段

2008年至2012年这个阶段，我们重点支持淘宝搜索的业务发展。随着淘宝产品体量的不断增长，我们逐渐采用Hadoop、Hbase等开源大数据计算和存储框架来实现。推广了线下搜索系统，有力支持了淘宝搜索业务的发展。但现阶段我们支持的商家只有淘宝，总共不到5家。大概有10个开发商投入，整体效率不高。另一方面，相关系统框架代码与淘宝业务密切相关，很多特殊代码是定制的，不利于架构推广或支持其他公司。 ？团队（飞猪、钉钉、1688、AE、Lazada等）在提供支持，复用技术框架、提高开发效率、支撑平台的需求越来越强烈。另一方面，随着大数据计算和存储技术的发展，特别是流计算引擎的快速发展，为离线系统技术架构的进一步发展提供了良好的基础。

我们看到整个离线搜索系统的发展是在性能和​​效率两条主线上，业务和技术两轮驱动一步一步走到现在。这是技术与商业高度融合、互动、共同发展的典型例子。

离线平台技术架构

上一篇我们简单介绍了离线系统的发展历史，也简单提到了技术架构的发展。下面介绍一下线下平台的技术架构，主要分为平台流程和计算存储架构等方面。

平台组件及任务流程

上图描述了离线平台技术组件的结构，部分组件介绍如下：

• Earth：Airflow开发的分布式任务调度平台。改进的要点是时机。性能优化、执行器FaaS、容器化、API、调度器扩展四个部分，在保持与Airflow兼容的同时，大幅提升了性能和稳定性。离线任务中的多个 Blink 作业会创建依赖关系并通过 Maat 进行调度。
• Bahamut：执行引擎是整个离线平台的核心，负责创建、调度、管理离线任务等各种功能，后面会详细介绍。
• Blink：阿里巴巴Flink内部版本，对大规模分布式、SQL、TableAPI、批处理等进行了极大的优化和重构。离线平台上的所有计算任务都是Blink作业，包括流和包。
• Soman：与Bahamut后端对接的UI模块，提供任务信息显示、状态管理等可视化功能。它也是为用户生成的应用程序开发业务逻辑的主要入口点。
• 目录：管理存储表信息，提供各种数据源表的DDL能力，负责离线平台存储资源的申请、释放、修改等各项功能。
• Hippo：阿里巴巴搜索自研的分布式资源管理和任务调度服务，类似于Yarn，提供Docker管理能力，主要服务于网络系统。
• Swift：阿里搜索自有的高性能分布式消息队列，支持数十亿消息选项。存储程序由HDFS和存储与处理分离的架构支持。

下图描述了离线操作从数据源到引擎输出数据的整个过程。该流程图分为三层：

• 数据同步层：将用户自定义数据源表的全量和增量数据同步到Hbase内部表，相当于源表的镜像。该镜像有两个列族cf和d，分别存储数据库镜像和每日更新的数据。
• 数据关系计算层：根据数据源中定义的不同关系，将不同维度的数据链接在一起，并将数据发送到自定义的UDTF处理，产生引擎所需的全量和增量数据。 。 。
• 数据交互层：提供全量和增量数据存储信息，并与网络服务构建器模块交互。

全增量统一计算模型

那么如何在线下平台上让用户免受这些技术细节的影响，让用户只专注于业务呢？回顾第一节介绍的离线任务的概念，离线任务包括全量任务和增量任务。它们的业务逻辑是相同的，但是执行方式不同。为了让用户专注于业务逻辑的开发，保护线下平台的技术细节，实现完整的递进统一的数据处理逻辑，我们引入了业务表的概念。

业务表：业务表是由完整数据表和/或增量流表组成的抽象表。全量/增量表的schema是一样的，业务意义也是一样的。

基于工作表和数据处理组件，用户可以开发描述离线处理过程的业务逻辑图，我们称之为业务图。下图是业务图的示例。顶部红色框代表仅包含完整ODPS数据源的业务表。下方红框代表包含Hdfs+Swift的业务表。此外，我们还支持多个业务表的组合，例如Mysql+DRC/ODPS+Swift。图中还可以看到Join、UDTF等常见的数据处理组件。业务表和处理组件的组合可以描述常见的离线业务处理逻辑。

如何将这份业务日程变成真正的线下任务？ Bahamut作为离线平台执行引擎，将业务描述转换为可执行的离线任务，顺序为业务图->APP图->作业图->（Blink作业/Maat作业）如下：

1 。业务图->APP图：在这个环节，我们主要有两个重要的任务：

1）正确性检查：根据BG中节点的信息，检查节点之间连接的合法性（例如两个输入源节点不能直连）、节点配置的正确性（数据库配置/ODPS配置是否正确）以及schema推导是否正确。

2）任务分层优化：为了使用Blink Stream模式均匀完整增量执行，我们需要将输入源数据存储在内部Hbase中，并直接使用Blink Dimension Table Join功能来完成数据。联系。因此，当节点遍历过程中遇到join、join组件时，需要在AppGraph中插入一个内部HTable节点，以将join或join上游数据与Hbase同步。

2。 APP Graph->Job Graph：JobGraph是一个Blink/Maat任务配置DAG，其中每个节点都包含配置信息，可以直接转换为下游流程中的计算或调度任务。

1）Blink JobGraph：从数据源业务表节点开始遍历AppGraph。每次发现内部 HTable 节点时，都会创建两个（增量/完整）Blink JobGraph 同步层。为所有同步层生成 Blink JobGraph 后，所有内部 HT 表/队列都用作输入，为关联的处理层创建两个（增量/完整）Blink JobGraph。

①同步层：利用业务表的全表/全表配置，分别创建全量和增量Blink任务配置，描述数据从数据源同步到内部HT表的过程。例如，对于Mysql+DRC表，full阶段从mysql中拉取整个表的数据并将其转换为HTable以进行批量HFile加载。增量阶段从DRC中拉取变化的数据并直接写入HTable并根据需要写入驱动程序队列。

②联动处理层：联动多个HT表，创建一个大宽表，然后调用UDTF处理创建最终要输入引擎的数据。还需要分别生成完整任务和附加任务的配置

2）Maat JobGraph：基于Maat的调度任务描述DAG。主要目标是根据依赖关系调度各个级别的 Blink 任务，同时执行特定的脚本来完成与外部系统的交互等职责。一般来说，一个离线操作会创建多个Maat JobGraph，例如构建/发布/暂停/发布。

3。 Job Graph -> Blink/Maat Job：循环遍历JobGraph并调用翻译器将JobGraph转换为Blink/Maat任务代码。引入JobGraph的目的是为了将底层计算引擎与计算任务的描述分离。例如：我们的底层计算引擎以前是MapReduce + Blink-1.4-TableAPI，最近完成了基于SQL的Blink-2.1更新。我们所有的工作基本上都是在不改变上层代码结构的情况下重写翻译器程序集。

经过以上三个步骤，我们完成了BusinessGraph（公司描述）到Blink/Maat作业的转换，生成了多个Blink作业进行数据同步/处理，并利用这些Blink作业对各个功能进行依赖调度。地球工作。特别是对于离线搜索场景，调度流程中增加了大量与下游引擎通信的逻辑，包括24小时连续增量、触发引擎消耗数据、切换引擎消耗增量队列等重要业务流程。

存储与数据处理

★ 基于Hbase的存储架构

离线搜索在2012年左右引入Hbase作为数据存储引擎，有力支撑了从淘宝核心搜索到离线平台整个搜索业务的发展。 ，它已经通过了多次双11测试，其稳定性和性能都得到了明确的验证。从功能角度来看，引入Hbase进行离线搜索的主要原因是：

1. 可以通过Scan/Get批量/单独检索数据，可以通过bulkload/pipe批量/单独导入数据。这与完整/增强的搜索功能一致。体积模型完全一致，自然适合支持离线搜索。
2. 底层存储基于HDFS，LSM-Tree架构保证数据安全。计算和存储架构分离，确保集群规模可水平扩展，并且可以轻松提高整体吞吐量。通过单机性能优化（Async、BucketCache、Handler分层、Offheap）和集群扩展，保证业务大幅增长时存储空间永远不会成为系统的瓶颈。
3. 免费的Schema特性可以很好地处理频繁的业务数据变更，轻松支持一些特殊业务场景的数据逻辑。

采用Hbase作为离线系统的内部数据存储，成功解决了全量上游Mysql每天压力很大的问题，并且大大提升了整个系统的吞吐量。将数据存储在Hbase中，也是将所有任务转换为流处理（MR->Stream）的基础，为后来Blink的流引擎在离线搜索中的采用和发展铺平了道路。

当然，Hbase 也不是没有缺点。 JVM内存管理的长期问题、单机完整管理器引发的雪崩以及容器部署选项的缺乏也引发了许多问题。很快我们就会取代Hbase作为阿里巴巴的内部开发。另一组存储引擎应该可以部分解决这些问题。

★ 基于Flink的计算架构

2016年中，Flink作为离线搜索计算引擎逐步推出，专注于解决与实时搜索计算相关的诸多问题。基于社区版Flink，实时计算团队开发了Blink，为Flink添加了许多功能来解决大规模分布式操作问题，例如自然线程和增量检查点。另一方面，在DataStream/DataSet接口的基础上，进一步完善。它集成了TableAPI和SQL的功能，真正结合了Stream和Batch的调用接口，实现了基于SQL的业务逻辑数据处理的开发模型。

线下平台是Blink的早期采用者和开发者。从 Blink 0.8 版本开始，已经进行了多次更新和修改。它先后使用DataStream、TableAPI和SQL作为任务接口，还开发了大量的连接器来支持不同数据源之间的交互。目前，线下平台已经使用最新的Blink-2.1.1。 Bahamut使用SqlTranslator直接生成SQL来描述任务逻辑，并通过Bayes服务（Blink SQL开发平台）将任务直接传递到不同的线程集群。下面是一些实现方法： 明显的好处：

1. 使用 SQL 描述 Blink 任务的业务逻辑非常清晰。完成数据处理，可以直接使用Blink提供的各种算子，这样可以更方便地调试任务，例如：dim join、groupby，而不用在数据流动期间自己动手。写了一个类似Hbase Join的算子。
2. Blink 2.1 原生支持批处理。使用批处理模式，可以直接完成HFile生成、离线MR任务，以及与Blink完成PC引擎链接。在批处理模式下执行任务时使用分段调度程序可以显着节省计算资源并提高集群效率。通过改变提交方式，Blink SQL可以转换为流式或批式作业，这样可以更方便地调试和验证作业，同时保持业务逻辑的稳定性。
3. 通过面向服务的开发平台（如Bayes）向不同集群提交任务，彻底解决了GateWay提交任务复杂的运维问题。添加新的纱线集群只需要简单的配置。另外，Bahamut自动生成和传输的Sql也存储在Bayes中，任务可以直接在Bayes中调试和管理，方便开发者。

下图是Bahamut自动生成的Blink Sql示例，描述了同步层任务。该任务包含三个算子：Source、Select Opera、Sink，实现MySQL实时更改到Hbase表的同步。

-- 定义数据源表，这是一个DRC（Mysql binlog流）源CREATE TABLE DRCSource_1 (
  `tag_id`                        VARCHAR,
  `act_info_id`                    VARCHAR,) with (  tableFactoryClass='com.alibaba.xxx.xxx.DRCTableFactory',
  -- other config);-- 定义输出表CREATE TABLE HbaseSink_1 (
  `tag_id`                    VARCHAR,
  `act_info_id`               VARCHAR,) with (
  class='com.alibaba.xxx.xxx.CombineSink',
  hbase_tableName='bahamut_search_tmall_act',
  -- other config
 );-- 定义Blink任务的业务逻辑INSERT INTO HbaseSink_1SELECT
  `tag_id`,
  `act_info_id`,FROM DRCSource_1;

总结

离线计算是海量数据集/实时计算相结合的典型场景。搜索中层团队以内部技术为基础，结合开源大数据存储和计算系统，打造出基于其业务和技术能力的系统。离线搜索平台提供了针对复杂业务场景的单日批量处理千亿级数据的计算能力和每秒百万级TPS的实时吞吐量。线下平台目前支持超过200个不同商家群体的搜索业务需求，显着提升业务迭代效率，成为搜索中心的重要组成部分。离线平台很快将与阿里云上的Opensearch/ES集成，为外部客户提供高可用、高性能的离线计算能力。未来，线下平台将逐步拓展到应用场景广泛的推荐、广告等数据处理场景。包含SARO（离线搜索广告和推荐）平台的搜索/推荐/广告系统正在逐渐兴起。

最后，0-1线下搜索平台建成已经两年了，但离我们心目中的SARO平台愿景还很远。前进的道路注定充满挑战。还有很多问题等待解决。