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

阿里导读：搜索离线数据处理是海量数据批量/实时计算的典型场景。阿里搜索中台团队基于内部技术和开源大数据存储计算系统，根据自身业务和技术特点，搭建了搜索线下平台，提供单日批量处理数千亿数据的计算能力和复杂业务场景下秒级实时百万TPS吞吐量。
线下搜索的背景是什么？
一个典型的商品搜索架构如下图所示，本文将关注下图中的离线数据处理系统。
什么是离线？在阿里的搜索工程体系中，我们将搜索引擎、在线评分、SearchPlanner等响应用户请求的ms级服务称为“在线”服务；相应地，转换各种数据源并将其发送到搜索引擎等在线服务的系统统称为“离线”系统。商品搜索的业务特点(海量数据、业务复杂)决定了线下系统从诞生之日起就是一个大数据系统。它具有以下特点：
1.区分任务模型上的总量和增量。
1)总量是指所有搜索业务数据的再加工和生成，并发送到在线引擎，一般每天一次。原因有二：有每日更新的业务数据；该引擎需要对大量数据进行高效的索引和预处理，以提高在线服务的效率。
2)增量是指将上游数据源的实时数据变化更新到在线引擎中。
3)对性能要求高。整个卷需要极高的吞吐能力，才能保证几个小时内完成上亿的数据。增量需要支持数万TPS秒的实时，还需要具备极高的可用性。
2.需要支持多样化的输入输出数据源，包括Mysql、ODPS、TT等数据库和消息队列作为输入，搜索、排名、图表、推荐等引擎作为输出。
3.需要提供一定的数据处理能力，如多表连接和UDTF支持，以方便搜索服务的开发和访问。
在接下来的段落中，我们会看到围绕这些特点，针对搜索业务的变化，线下系统架构的各种演变和发展。
发展概论
阿里商品搜索系统从淘宝搜索开始，2008年初左右第一代搜索系统诞生，线下系统上线。离线搜索系统经历了多年的发展，技术架构几经迭代，数据处理能力和业务支撑能力不断提升。下面将分阶段介绍搜索离线的主要技术架构和特点。
淘宝搜索阶段
2008-2012年这一阶段，重点扶持淘宝搜索业务的发展。随着淘宝商品量的不断增加，我们逐步引入Hadoop、Hbase等开源大数据计算和存储框架，实现了线下搜索系统的分发，有力支撑了淘宝搜索业务的发展。但现阶段我们支持的业务线只有淘，总共不到5条业务线。为此投入了10个左右的开发者，整体效率不高。另一方面，相关系统框架代码与淘业务高度耦合，很多特殊代码是量身定制的，不利于框架的推广和其他业务的支持。
平台阶段
从2013年底开始，尤其是最近两年，随着集团科技业务线的梳理和中台转型战略的实施，离线搜索系统需要为越来越多不同的业务团队(飞猪、钉钉、1688、AE、Lazada等)提供支持。)，对技术框架复用、开发效率提升和平台支持的需求越来越强烈。另一方面，随着大数据计算和存储技术的发展，尤其是流式计算引擎的快速发展，线下系统技术架构的进一步演进也具备了极好的土壤。
我们可以看到整个线下搜索系统的演进是沿着性能和效率两条主线，以业务和技术为双轮驱动，一步一个脚印走到今天。这是一个典型的
上一节我们简单介绍了离线系统的发展历史，也简单提到了技术架构的演变。下面，我们将介绍线下平台的技术架构，主要分为平台流程、计算和存储架构等。
平台和任务流
上图描述了线下平台的技术组件结构，部分组件简介如下：
玛特：基于气流开发的分布式任务调度平台，主要有四个方面的改进：调度性能优化、FaaS实现、容器化、API和调度功能扩展。在保持与气流兼容的基础上，大幅提升性能和稳定性。离线任务的多个Blinkjobs将建立依赖关系，并通过玛特对它们进行调度。巴哈姆特：执行引擎，整个线下平台的核心，负责线下任务的创建、调度、管理等功能，后面会详细介绍。blink:Flink的阿里内部版本，在大规模分布式、SQL、TableAPI、Batch上进行了优化重构。所有离线计算任务都是眨眼作业，包括流和批处理。Soman: UI模块，连接巴哈姆特后端，提供任务信息展示、状态管理等可视化功能，也是用户创建应用开发业务逻辑的主要入口。Catalog:存储表的信息管理，提供各种数据源表的DDL能力，负责申请、发布、变更等各种功能。离线平台存储资源。Hippo:阿里搜索自研分布式资源管理和任务调度服务，类似Yarn，提供Docker管理能力，主要服务于在线系统。Swift:阿里搜索自研高性能分布式消息队列，支持亿级消息吞吐量。存储后端是HDFS，存储和计算是分离的。下图描述了一个离线任务从数据源到输出引擎服务数据的全过程。流程图分为三层：
数据同步层：将自定义数据源表的完整和增量数据同步到Hbase的内部表，相当于源表的镜像。在这个镜像中，我们包括两个列族，cf和D，分别存储数据库的镜像和每日更新的数据。数据关联计算层：根据数据源中定义的各种关系，将不同维度的数据关联在一起，并将数据发送到用户自定义的UDTF进行处理，从而产生引擎所需的全量和增量数据。数据交互层：提供完整数据和增量数据的存储信息，与在线服务构建模块交互。
完全增量统一计算模型
那么如何为用户屏蔽掉线下平台内部的这些技术细节，让用户只需要关注业务实现？回顾一下第一节介绍的离线任务的概念，离线任务包括全量和增量。他们的业务逻辑是一样的，但是执行模式不一样。为了让用户专注于业务逻辑的开发，屏蔽线下平台的技术细节，实现全增量统一计算逻辑，我们引入了业务表的概念。
业务表：业务表是一个抽象表，由全数据表和/或增量流量表组成。完整/增量表具有相同的模式和相同的业务含义。
基于业务表和数据处理组件，用户可以开发描述离线处理过程的业务逻辑图，我们称之为业务图。下图是一个业务图的例子，上面的红框标识了只包含ODPS全数据源的业务表，下面的红框标识了包含Hdfs Swift的业务表。此外，我们还支持Mysql DRC/ODPS Swift和其他业务表的组合。您还可以在图中看到常见的数据处理组件，如连接和UDTF。当与处理组件结合时，业务表可以描述常见的离线业务处理逻辑。
那么，如何将这个业务图转化为真正的线下任务呢？巴哈姆特作为线下平台的执行引擎，会按照业务图-app图-作业图-(blink job/maatjob)的顺序，将一个业务描述转化为可执行的线下任务，如下：
1.业务图-APP图：这个环节我们主要有两个重要的工作：
1)正确性检查：根据BG中的节点信息，检查节点之间连接的合法性(比如两个输入源节点不能直连)，节点配置的正确性(数据库配置/ODPS配置是否正确)，模式推导是否正确。
2)任务的分层优化：为了使用Blinkstream模式统一完成完全和增量执行，我们需要将输入的源数据存储在内部Hbase中，直接使用Blink Stream维度表的Join函数来完成数据连接。因此，当在节点遍历过程中遇到Join和Merge组件时，有必要在AppGraph中插入一个内部HTable节点，以便将Merge或Join上游的数据同步到Hbase中。
2.App Graph-Job Graph: Job Graph是Blink/玛特任务的一个配置DAG，其中每个节点都包含了配置信息，可以在后续的流程中直接转化为计算或调度任务。
1)Blink JobGraph:从数据源业务表节点开始遍历AppGraph，每遇到一个内部HTable节点，就会生成两个(增量/完全)同步层的Blink JobGraph。在生成所有同步层的闪现作业图之后，生成两个(增量/总计)关联处理层的闪现作业图，其中所有内部表/队列作为输入。
同步层：采用业务表中的全量/增量表配置，分别生成全量和增量闪现任务配置，描述数据从数据源同步到内部表的过程。比如Mysql DRC的表，全量阶段会从Mysql拉整表数据，转换成HFile bulkload到HTable，增量阶段会从DRC拉变数据，直接写入HTable，根据需求写入驱动队列。关联处理层：关联多个httable，生成一个大而宽的httable，然后调用UDTF处理，产生最终进入引擎的数据。还需要分别生成完整和增量任务配置。2)玛特JobGraph:基于玛特的调度任务描述DAG，主要目的是根据依赖关系调度各级Blink任务，同时执行特定脚本完成与外部系统的交互等职责。通常，一个离线任务会生成多个玛特作业图，如构建/发布/停止/发布。
3.作业图-Blink/玛特作业：遍历作业图并调用Translator将作业图转换为Blink/玛特任务代码。引入JobGraph的目的是将底层计算引擎从计算任务描述中分离出来。比如我们的底层计算引擎以前是MapReduce Blink-1.4-TableAPI，最近完成了Blink-2.1基于SQL的升级。我们所有的工作基本上重写了一套翻译器，没有对上层代码结构做任何改动。
经过以上三个步骤，我们已经完成了从BusinessGraph到Blink/玛特作业的转换，并生成了多个用于数据同步/处理的Blink作业，以及通过调度这些Blink作业来执行不同功能的玛特作业。尤其是对于离线搜索场景，调度流程中加入了大量与下游引擎交互的逻辑，包括24小时不间断增量、触发引擎消费数据、切换引擎消费增量队列等重要业务流程。
存储和计算
基于Hbase的存储架构
大约在2012年，线下搜索引入Hbase作为数据存储引擎，有力支撑了搜索业务从淘宝主搜索到线下平台的整个发展过程。经过多次双11测试，其稳定性和性能得到了清晰的验证。从功能层面来看，引入Hbase offline的原因如下：
Scan/Get可用于批量/单次获取数据，bulkload/put可用于批量/单次导入数据，与搜索的全量/增量模式完全一致，自然适合支持线下商业搜索。基于HDFS和LSM树的底层存储架构保证了数据的安全性，计算和存储分离的架构保证了集群规模的可扩展性，易于提高整体吞吐量。通过单机性能优化(Async、BucketCache、Handler分层、Offheap)和集群扩展，保证在业务大幅增长的情况下，存储永远不会成为系统的瓶颈。Free Schema的特性可以很好地应对业务数据的频繁变化，也可以方便地支持一些特殊业务场景的数据逻辑。通过引入Hbase作为离线系统的内部数据存储，成功解决了MySQL的日满量对上游Mysql造成巨大压力的问题，大大提高了整个系统的吞吐量。在Hbase中存储数据也是从全尺度任务向流处理(MR-Stream)转化的基础，而这也为搜索离线中Blink流媒体引擎的孕育和发展奠定了基础。
当然Hbase也不是没有缺点。JVM内存管理的痼疾，全单处理程序导致的雪崩，容器化部署能力的缺乏也带来了很多麻烦。很快，我们将取代Hbase成为阿里开发的另一套存储引擎，希望能部分解决这些问题。
基于Flink的计算架构
2016年年中，Flink作为计算引擎逐步引入搜索离线，专注于解决搜索实时计算场景中遇到的大量问题。在社区Flink版本的基础上，实时计算团队开发了Blink，增加了native yarn模式、Incremetal checkpoint等一些特性，解决了Flink的大规模分布式操作问题。另一方面，在数据流/数据集接口的基础上，进一步强化了TableAPI和sql的功能，真正统一了流和批处理的调用接口，实现了计算业务逻辑的SQL开发模式。
线下平台是Blink的早期用户和开发者。从0.8版本开始，经历了Blink多个版本的升级和变化。使用了DataStream、TableAPI和SQL作为任务接口，并开发了大量的连接器来支持不同数据源之间的交互。目前最新的Blink-2.1.1已经在线下平台使用。巴哈姆特使用SqlTranslator直接生成SQL来描述任务逻辑，通过Bayes(Blink SQL开发平台)服务直接将任务提交给不同的Yarn集群。这具有以下明显的优点：
用SQL来描述Blink任务的业务逻辑是非常清晰的。可以直接使用Blink提供的各种运算符来完成数据处理，方便调试任务，比如dim join和groupby，而不用在数据流时期自己编写类似Hbase Join的运算符。Blink 2.1原生支持批处理，可以直接完成生成HFile的任务，离线MR任务，完全统一计算引擎到Blink。批处理模式下的分阶段调度可以大大节省计算资源，提高集群效率。通过修改提交方式，可以将Blink SQL转换为流或批处理任务，这样可以保持业务逻辑稳定，方便任务调试和验证。通过Bayes这样的开发平台，以面向服务的方式向不同的集群提交任务，彻底解决了以往通过GateWay提交任务的复杂运维问题。仅通过简单的配置就可以完成添加新的纱簇。另外，巴哈姆特自动生成并提交的Sql也会保存在Bayes上，可以直接在Bayes上调试和管理任务，方便了开发者。下图是巴哈姆特自动生成的Blink Sql示例，描述了同步层中的一项任务。该任务包括三个操作符，Source、Select Oper和Sink，实现了从Mysql到Hbase表同步的实时转换。
总结搜索离线数据处理是海量数据批量/实时计算的典型场景。基于内部技术和开源的大数据存储计算系统，搜索中站团队根据自身业务和技术特点，搭建了搜索线下平台，提供单日批量处理数千亿数据的计算能力和复杂业务场景下秒级实时百万TPS吞吐量。目前，线下平台支持集团200多个不同业务线的搜索业务需求，大大提高了业务迭代效率，成为搜索中心的重要组成部分。很快，线下平台将与阿里云上的Opensearch/ES结合，为集团外客户提供高可用、高性能的线下数据处理能力。在不久的将来，线下平台将逐步拓展到推荐和广告的数据处理场景，应用场景广阔，一个覆盖搜索/推荐/广告体系的SARO(Search Advertising and Recommendation Offline)平台将逐步成型。
最后，从0到1的搜索线下平台建设已经过去两年了，但离我们心目中的SARO平台愿景还很远。这条前进的道路将充满挑战，有许多难题等待我们去解决。欢迎对Hadoop、Flink等大数据技术感兴趣，有Java后台开发经验的同学加入我们，从阿里走向世界，让天下没有难寻。