背景

 

• 任务模型上区分全量和增量。

  • 全量是指将搜索业务数据全部重新处理生成，并传送给在线引擎，一般是每天一次。这么做有两个原因：有业务数据是daily更新；引擎需要全量数据来高效的进行索引整理和预处理，提高在线服务效率
  • 增量是指将上游数据源实时发生的数据变化更新到在线引擎中。
  • 性能方面有较高要求。全量需要极高吞吐能力，确保数以亿计的数据可以在数小时内完成。增量则需要支持数万TPS秒级的实时性，还需要有极高的可用性。
• 需要支持多样化的输入和输出数据源，包括：Mysql，ODPS，TT等各种数据库和消息队列作为输入，搜索、Ranking、图、推荐等各种引擎作为输出。
• 需要提供一定能力的数据处理能力，例如多表Join、UDTF支持等，以方便搜索业务的开发和接入。

发展简介

淘宝搜索阶段

平台组件和任务流程

 

 

• Maat: 分布式任务调度平台，基于Airflow发展而来，主要改进点是调度性能优化、执行器FaaS化、容器化、API及调度功能扩展等四个部分，在保持对Airflow兼容的基础上，大幅提升性能，提高了稳定性。 一个离线任务的多个Blink job会通过Maat建立依赖关系并进行调度。
• Bahamut: 执行引擎，是整个离线平台的核心，负责离线任务的创建、调度、管理等各种功能，后文会详细介绍。
• Blink：Flink的阿里内部版本，在大规模分布式、SQL、TableAPI、Batch上做了大量的优化和重构。离线平台的所有计算任务都是Blink job，包括stream和batch。
• Soman: UI模块，与Bahamut后端对接，提供任务信息展示、状态管理等可视化功能，也是用户创建应用的开发业务逻辑的主要入口。
• Catalog: 存储表信息管理，提供各种数据源表的DDL能力，负责离线平台存储资源的申请、释放、变更等各种功能。
• Hippo：阿里搜索自研的分布式资源管理和任务调度服务，类似于Yarn，提供Docker管理能力，主要服务于在线系统。
• Swift：阿里搜索自研高性能分布式消息队列，支持亿级别消息吞吐能力，存储后端为HDFS，存储计算分离架构。

• 数据同步层：将用户定义的数据源表的全量和增量数据同步到Hbase内部表，相当于源表的镜像。这个镜像中我们包含cf和d两个列族，分别存储数据库的镜像和Daily更新的数据。
• 数据关联计算层：按照数据源中定义的各种关系，将不同维度的数据关联到一起，把数据送到自定义的UDTF中进行处理，产出引擎所需的全量和增量数据。
• 数据交互层：提供全量和增量数据的存储信息，与在线服务build模块进行交互。

 

全增量统一的计算模型

Business Table（业务表）：Business Table是一个抽象表，由一个全量数据表和/或一个增量流表组成，全量/增量表的Schema相同，业务含义相同。

 

• Business Graph->APP Graph：在这个环节中我们主要有2个重要的工作

  • 正确性校验：根据BG中的节点信息，校验节点间连接的合法性（例如两个输入源节点不能直接连接）、节点配置的正确性（数据库配置/ODPS的配置是否正确）、Schema推导是否正确。
  • 任务分层优化：为了用Blink Stream模式来统一完成全量和增量的执行，我们需要将输入源数据存入内部Hbase，直接使用Blink维表Join功能来完成数据的连接。于是在节点遍历过程中遇到Join、Merge组件时，需要在AppGraph中插入一个内部的HTable节点，将Merge或者Join上游的数据同步进入Hbase。
• APP Graph->Job Graph: JobGraph是一个Blink/Maat任务的配置DAG，其中每个节点包含配置信息，可以在后续的过程中直接转化为计算或者调度任务。

  • Blink JobGraph：从数据源业务表节点开始遍历AppGraph，每当碰到一个内部HTable节点时，会生成两个（增量/全量）同步层的Blink JobGraph。所有同步层Blink JobGraph生成后，以所有的内部HTable/queue为输入，生成两个（增量/全量）关联处理层的Blink JobGraph。

    • 同步层：采用Business Table中的全量/增量表配置，分别生成全量和增量的Blink任务配置，描述把数据从数据源同步到内部HTable过程。例如对于Mysql+DRC的表，全量阶段将会从mysql中拉取全表数据并转化为HFile bulkload到HTable中，增量阶段则是从DRC中拉取变化数据，直接写入HTable，并根据需求写入驱动queue。
    • 关联处理层：关联多个HTable，生成大宽表后调用UDTF处理，产出最终的进入引擎的数据。同样需要分别生成全量和增量任务配置
  • Maat JobGraph：基于Maat的调度任务描述DAG，主要目的是将各个层次的Blink任务按照依赖进行调度，同时执行特定的脚本完成与外部系统的交互等职责。一般来说一个离线任务会生成Build/Publish/Stop/Release等多个Maat JobGraph。
• Job Graph->Blink/Maat Job: 遍历JobGraph，调用Translator将JobGraph转换为Blink/Maat的任务代码。引入JobGraph的目的是将底层的计算引擎与计算任务描述解耦，例如：我们底层的计算引擎曾经是MapReduce +Blink-1.4-TableAPI, 最近刚完成了Blink-2.1 基于SQL的升级，我们所有的工作基本上是重写了一套Translator，对上层的代码结构没有任何变动。

存储与计算

基于Hbase的存储架构

1. 通过Scan/Get可以批量/单条的获取数据，通过bulkload/put可以批量/单条的导入数据，这与搜索的全量/增量模型完全吻合，天然适合支持搜索离线业务。
2. 底层存储基于HDFS，LSM-Tree的的架构能够确保数据安全性，计算存储分离的架构保证了集群规模水平可扩展，易于提高整体的吞吐。通过单机性能优化（Async、BucketCache、Handler分层、Offheap）和集群的扩容，确保了业务大幅增长时，存储从来没有成为系统的瓶颈。
3. Free Schema的特性能够很好的应对业务数据频繁变化的情况，也能够方便支持一些特殊业务场景的数据逻辑。

基于Flink的计算架构

1. 采用SQL来描述Blink任务业务逻辑非常清晰，可以直接利用Blink提供的各种Operator完成数据处理，方便任务的调试，例如：dim join、groupby，而不是在Datastream时期需要自行编写完成类似Hbase Join的Operator。
2. Blink 2.1原生支持Batch，采用Batch模式可以直接完成生成HFile的任务，下线MR任务，彻底统一计算引擎到Blink。Batch模式任务执行时采用分阶段调度可以大幅的节省计算资源，提高集群效率。Blink SQL可以通过修改提交模式，分别转化为Stream或Batch任务，在保持业务逻辑稳定的同时方便任务调试和验证。
3. 通过Bayes这样的开发平台服务化的方式提交任务到不同集群，彻底解决以前任务通过GateWay提交运维复杂的问题，添加新的Yarn集群只需要简单配置即可完成。另外在Bayes上同样会保存Bahamut自动生成提交的Sql，可以在Bayes上直接进行任务的调试和管理，方便了开发人员。

-- 定义数据源表，这是一个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_1
SELECT
  `tag_id`,
  `act_info_id`,
FROM DRCSource_1;

总结

1. 搜索离线平台系统架构及实现介绍
2. SARO平台最佳实践之Lazada