阿里如何实现秒级百万TPS？搜索离线大数据平台架构解读

★ 淘宝搜索阶段

在2008-2012这个阶段，我们重点支持淘宝搜索的业务发展，随着淘宝商品量的不断增加，逐步引入Hadoop、Hbase等开源大数据计算和存储框架，实现了搜索离线系统的分布式化，有力地支持了淘宝搜索业务的发展。但是在这个阶段，我们支持的业务线只有淘系合计不到5个业务线，为此投入了大约10名开发人员，整体效率不高。另一方面相关系统框架代码与淘系业务高度耦合，量身定制了很多特殊代码，不利于架构的推广和其它业务的支持。

 

★ 组件&平台化阶段

 

2013年底以来，特别是最近两年，随着集团技术业务线的梳理以及中台化战略的推行，搜索离线系统需要为越来越多的不同业务团队（飞猪、钉钉、1688、AE、Lazada等等）提供支持，技术框架复用、开发效率提升和平台化支持的需求越来越强烈。另一方面随着大数据计算、存储技术的发展，尤其是流计算引擎的飞速发展，离线系统技术架构上的进一步演进也具备了绝佳的土壤。

 

离线平台技术架构

平台组件和任务流程

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

 

• 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（业务表）：Business Table是一个抽象表，由一个全量数据表和/或一个增量流表组成，全量/增量表的Schema相同，业务含义相同。

 

基于业务表和数据处理组件，用户可以开发出一个描述离线处理流程的业务逻辑图，我们称之为Business Graph。下图就是一个Business Graph的样例，其中上侧红框标识的就是只包含ODPS全量数据源的Business Table，最下方红框中标识的是包含Hdfs+Swift的Business Table，除此之外我们还支持Mysql+DRC/ODPS+Swift等多种业务表的组合。图中还可以看到Join、UDTF等常用的数据处理组件，业务表与处理组件结合在一起就能够描述常见的离线业务处理逻辑。

 

参考博客：https://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA==&mid=2247488245&idx=1&sn=1c70a32f11da7916cb402933fb65dd9f&chksm=e9292ffade5ea6ec7c6233f09d3786c75d02b91a91328b251d8689e8dd8162d55632a3ea61a1&scene=21#wechat_redirect