导读：百度搜寻中台将搜寻外围能力赋能阿拉丁（百度搜寻特型后果）、垂直畛域搜寻、利用内搜寻等场景，撑持了数百个检索场景、百亿级内容数据的检索。咱们通过智能化的设计理念，在容量主动调整、数据按需存储等方面获得了效率和老本的显著收益，并通过进阶云原生的设计，在海量数据和海量检索方面实现高可用和高性能。通过海量数据管理的云原生和智能化，咱们心愿低成本的实现让用户找到每一个有价值的数据。

全文 5103 字，预计浏览工夫 16 分钟

一、背景

1.1 背景简介

百度搜寻中台反对的业务线多、业务层面的差异性很大，使得数据的治理、存储和计算的老本，对检索架构造成微小挑战。比方传统模式下的业务接入，咱们要人工评估数据规模进而设计正当的在线部署计划、实现正当的老本，然而业务很难晓得本人的数据规模、或者在较短时间内数据有了数倍的增长，须要人工调整部署计划，这个不仅周期长、人力投入大，也会导致稳定性和成果方面的危险。

为了高效撑持泛滥业务内容数据的接入、迭代，咱们设计了云原生时代的内容数据智能架构，通过数据管理的智能化实现人工保护效率的极大晋升，并实现按需分配优化老本；在海量数据的检索下，实现高可用和高性能，用翻新技术保障用户体验。

本文的次要内容集中在下图中的两头局部：

大抵流程如下：

1. 业务通过离线建库环节产出建库包，并失效到消息中间件中。
2. 业务内容数据（比方索引数据、正排数据）按大小拆成相应的分片服务，并通过订阅分片映射的音讯 Topic 数据，实现流式更新。
3. 每个分片由 PaaS 容器承载，启动时从 DFS 拉取对应的存量数据，并定时将数据长久化上传到 DFS 中；并从数据中间件读取增量数据，从而实现有状态服务的云原生。
4. 业务检索申请通过 PaaS 层面的服务发现，检索对应业务的内容数据。

和其余业务场景不同，咱们搜寻业务的特点次要有：

1. 存储 / 计算难以拆散：搜寻场景的高性能、低提早要求，计算和存储难以拆开专项优化，须要本地化的存储 + 计算。
2. 全扇出的并发模式：搜寻场景是 Query 到 Doc 的映射，须要通过语义解析、构建检索表达式、扇出所有的分片服务、合并后果，而惯例场景下的 Key/Value 查问，能够通过 Hash 关系实现精准的扇出。
3. 最终一致性保障：正本间没有通信，通过音讯队列增量更新形式，保障秒级别的最终一致性。

1.2 上代内容数据管理架构存在的问题

上述架构很好的实现了 PaaS 化、自动化运维的历史指标，但随着新业务的接入和存量业务的迭代深耕，差异化 / 高频化的内容数据需要场景，给这种偏动态模式下的治理架构带来了极大的挑战，具体体现在：

1. 效率方面：偏动态模式下的容量调整，须要人工调整数据的散布、分片的大小、扇出的规定，往往须要周级别甚至是月级别能力实现，越来越高频的容量调整需要，使得上述架构无奈在效率层面持续满足业务的需要。
2. 老本方面：局部业务具备多种场景的内容数据，不同场景的数据拜访频度差别是微小的，动态的数据管理架构难以实现资源的按需分配和 rebalance(再均衡）。
3. 稳定性方面：单业务数据量级由亿级别冲破至 50 亿级别，全扇出模式下须要扇出数百个分片服务，极大扇出带来的是可用性的急剧下降。
4. 性能方面：关联计算（比方 join 操作）须要上游屡次检索查问 & 合并，性能层面难以满足业务的提早要求。

为了解决上述问题，咱们以云原生化的思路对上述架构进行了革新，通过弹性伸缩和按需分配机制来解决效率和老本问题，而后基于云原生之上引入数据调度策略来解决稳定性和性能问题。

二、整体架构设计

2.1 架构概述

名词解释：

• 分区(slot)：数据管理的最小单元（比方一组索引数据），进一步形象和拆解上代架构中对于消息中间件 Topic 的概念。
• 分片(shard)：承载一组 slot 数据的引擎服务。
• 正本(replica)：分片中的一个实例。
• 套餐类型：预约义的一系列标准化的容器资源规格（比方存储类型可选用 RAM/SSD/DISK 等介质），满足各类检索场景对资源的匹配诉求。

架构外围组成：

1. 分区管制单元：依据业务场景和内容数据的特色，管制建库时的分区策略，比方按某特色汇聚（实现关联计算）、某维度打散（实现冷热拆散）等等。
2. 分片管制单元：依据检索场景的数据量，管制所须要的分片规模，实现分片的容量调整。
3. 正本管制单元：依据检索场景的资源诉求、流量、性能要求，管制分片所应用的套餐类型和正本个数，同时对接 PaaS 零碎，实现套餐资源池的治理。
4. 寻址管制单元：依据业务的分区策略和分片策略，联合数据 slot 层面的服务发现机制，实现数据层面的动静寻址能力。

2.2 外围工作流程

1. 评估业务检索场景和内容数据的特色等，生成相干控制策略，比方分区策略、分片策略、正本策略、寻址策略。
2. 内容建库数据通过【分区控制器】写入到数据中心。
3. 【分片控制器】初始化分片的服务信息，比方分片的个数和要管控的数据分区等。
4. 【正本控制器】依据正本策略和分片策略来调配实例、注册服务。
5. 【寻址控制器】实现数据层面的服务注册和发现机制。
6. 业务通过【寻址控制器】来拜访相应的内容数据。

三、云原生化设计

针对容量调整效率低下和冷热差别大导致的老本节约问题，咱们以云原生化的思路对上代架构进行了革新，实现了数据的弹性伸缩和资源的按需分配。

3.1 弹性伸缩机制设计

弹性伸缩包含垂直伸缩和程度伸缩，各自特点简介如下：

• 垂直伸缩：调整物理硬件配置的形式，来加强零碎的弹性，比方调大容器的资源配额、更换 ssd 等。
• 益处：速度快、操作简略等
• 毛病：容器迁徙 & 故障复原周期长、有瓶颈问题（天花板较低）。
• 程度伸缩：调整正本数来应答流量、数据量的涨幅状况。
• 益处：天花板足够高。
• 毛病：实现艰难、门槛较高。

垂直伸缩受限比拟多，咱们采取了程度伸缩计划，针对搜寻场景下如何实现程度伸缩呢？

3.1.1 针对流量上涨场景下的程度伸缩

因为最终一致性的前提束缚，能够通过减少 shard- 0 正本数的形式，实现程度扩大。

3.1.2 针对数据量上涨场景下的程度伸缩

1. 零碎检测到分片服务容量达到阈值，或者人工发动容量指令，比方游戏检索数据由 2 分片调整为 4 分片。
2. 分片控制器计算调整后的分片需要，并初始化新的数据分片所绑定的数据区间，shard1=[2,4)、shard3=[6,8)
3. 寻址控制器通过服务发现机制，感知到分片调整 & 新分片服务 ready 后，开始更新路由规定，由 2 分片调整为 4 分片。
4. 路由切换后，开始革除旧分片无用的数据，shard0=[0,4) -> shard0=[0,2)、shard1=[4,8) -> shard2=[4,6)。

通过上述流程实现了数据量上涨的状况下，分片原地扩容的计划。

3.1.3 实际效果

通过自动化的弹性伸缩能力，实现了业务数据流量、容量疾速变动场景下的极致伸缩，容量调整由周级别升高为小时级。

3.2 资源按需分配机制设计

资源按需分配机制经常呈现在离线计算畛域，因为它对提早不太敏感、更重视吞吐，目前有一些比拟成熟的解决思路。但对提早和性能要求比拟刻薄的在线检索畛域，如何实现资源的按需分配呢？咱们目前的解决思路是冷热数据的拆散。

3.2.1 冷热拆散机制实现资源的按需分配

搜寻业务个别蕴含多种检索场景（比方问答场景、举荐场景等等），每种检索场景的数据量和检索性能特色不尽相同，要害特色如下：

依据业务场景特色决策的数据分布和寻址状况如下图所示：

1. 【分区控制器】依据业务的数据特色布局数据的散布，比方按冷热属性、按场景属性等，场景 A 散布在[0,4)、场景 B 散布在[4,20)。
2. 【分片控制器】依据数据规模、拉链长度等特色确定分片规模，场景 A 划分 1 个分片，场景 B 划分 4 个分片。
3. 【正本控制器】依据数据拜访 qps 和提早特色，筛选不同存储介质和正本数，场景 A &B 抉择高性能 / 低提早容器组，场景 C 抉择大容量 / 低成本容器组，场景 A 须要 5 正本，其余仅须要 2 正本。
4. 【寻址控制器】提供业务不同场景数据的服务发现能力。

通过冷热拆散机制 & 联合业务检索特色，抉择相应的资源套餐，实现资源的按需分配。

3.2.2 实际效果

业务均匀节省成本 30%，典型业务场景下可节省成本 80%。

四、进阶云原生

通过云原生化的革新，咱们解决了上代架构面临的效率和老本问题，对于极大扇出带来的稳定性问题和典型场景下的性能进化问题，咱们的解决思路是引入数据调度策略：管制检索数据分布和计算方向，实现最大化的精准扇出和本地化的计算减速。

4.1 精准扇出数据调度策略

搜寻场景是 Query 到 Doc 的映射，全分片扇出的并发模式。对于超大规模业务来说，须要划分泛滥的数据分片，全扇出模式下会带来一些稳定性问题，比方业务 A 须要划分 100 个分片，每个分片的服务可用性是 99.99%，在全扇出模式下，整体可用性只有 99.99% ^ 100 ≈ 99%。

为了解决上述问题，咱们设计了精准扇出数据调度策略，针对极大扇出的业务检索场景，抽取业务检索的通用特色（比方按用户 ID、按店铺 ID），控制数据的散布和计算方向，实现大规模检索场景下的精准扇出。

4.1.1 解决极大扇出带来的稳定性问题

以店铺内检索场景为例，其场景特点如下：

• 业务特色：检索数据均带有店铺 ID 标识、用户申请是依照店铺级别搜寻，整体数据量级十亿级。
• 检索申请：
• 查问某个店铺的商品
• …
• 建库申请：
• 某个店铺商品信息的更新
• …

精准扇出调度策略示例如下：

1. 【分区控制器】依据业务携带的 uid 信息，划分数据分区并写入到数据中心，依据 sliceKey=uid-123 确定 group0 数据分区组，再依据 DocID 在 group 内再次均分数据。
2. 【分片控制器】依据各个数据分区组的容量等状况，划分数据分片。比方分区组 [0,32) 容量小，只须要 2 个分片服务就能承载所有数据，而分区组 [64,96) 则须要 32 个分片服务承载所有数据。
3. 【寻址控制器】依据业务携带的 uid 信息，确定对应的分区组 group，并路由到对应的分片服务组。

4.1.2 实际效果

对于店铺内检索场景来说，由数百层的扇出规模，升高为 32 层扇出，局部状况下可升高为 2 层扇出。

4.2 本地化计算数据调度策略

针对具备关联检索的场景，抽取关联属性的特色（比方用户和商品的连贯关系），业务对具备关联属性的数据携带雷同的标识，使得相关联的数据内聚化，从而实现计算的本地化。

4.2.1 直播带货场景下的关联计算问题

什么是关联计算？对于数据库畛域来说，关联计算 =Join 操作，对于检索场景来说，关联计算 = 检索到 A 条件状况下，再用 A 的后果检索 B。检索场景常因数据量级的问题，须要触发屡次分布式的检索，容易造成提早突增的性能问题。

以直播电商搜寻场景为例，其场景特点如下：

• 业务特色：主播能够抉择多个商品售卖，商品能被多个主播带货，主播量级在十万级，商品量级在亿级别。
• 检索申请：
• 查问某个主播所带货的商品列表
• …
• 建库申请：
• 商品的属性变更
• 主播的信息变更
• …

为了反对搜寻场景下的主播商品关联需要，个别有如下两种计划：

• 拆分两张表：主播信息表和商品信息表
• 主播查问商品：须要先查问主播信息表，再查商品信息表。
• 毛病：须要 2 次分布式检索，提早较高。

• 只保留一张表：主播信息和商品信息进行叉乘
• 主播查问商品：只须要查一张表
• 毛病：老本节约重大，更新艰难（热门商品更新状况下，须要同步更新 10W+ 主播，提早不可承受）

4.2.2 本地化计算优化带货场景关联计算的性能

咱们的解决思路是将关联数据内聚化，实现计算的本地化，从而优化检索性能，如下图所示：

1. 建库侧：对于须要关联的关系数据和商品数据携带雷同的特色标识，比方 sliceKey=sid-1，
2. 分区控制器：依据直播带货的关联分区策略，确保关联数据的数据分区是雷同的（内聚化）。
3. 分片控制器：雷同分区的数据被布局到雷同的分片服务中（索引计算服务），实现关联数据的本地化和计算的本地化。
4. 检索侧：携带特色标识 sliceKey=sid= 1 定位数据分区，通过寻址控制器找到对应的分片服务。

4.2.3 实际效果

1. 通过本地化计算，解决了直播带货场景下因分布式检索 Join 带来的性能降落问题，均匀提早升高 50%。
2. 提供了一种关联计算速度优化的思路。

五、总结 & 瞻望

本文以百度搜寻中台上代检索数据管理架构面临的问题为出发点，基于云原生设计了数据智能化的弹性伸缩和资源的按需分配，解决了效率和老本方面问题。除此之外，在云原生之上引入了精准扇出和本地化计算的数据调度策略，解决了稳定性和性能方面的问题。

目前业务数据冷热属性评估老本较高，并且随着业务迭代其冷热属性也在一直变动，从新调整须要肯定的周期和老本。后续咱们会尝试自动化开掘业务数据的冷热特色和引入更多的指标优化的特色因素，冀望在多指标特色因素的束缚状况下，最大化水平实现搜寻场景下资源的按需分配。

举荐浏览：

|百度文库新一代文档阅读器！核心技术点全解析！

|详解预训练模型在信息检索第一阶段的利用

|疾速剪辑 - 助力度咔智能剪辑提效实际

———- END ———-

百度 Geek 说

百度官网技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢送各位同学关注