存储方案作为产品——Midgard 探索
作者 | greatstone94
导读
互联网业务大多是围绕数据展开，获取、生产数据，投入到产品中为用户服务。百度的搜索业务正是典型的数据密集业务，数据规模大，使用方式多样，极为关注如何构建高效低成本的存储系统。
然而软硬件技术升级、业务增长与变迁从未停止，一个久经验证的方案可能在短短半年后就偏离了设计之初的最佳状态。Midgard 是搜索场景下提出的智能化的数据存储方案管理器，本文简要介绍了 Midgard 如何有效利用数据自身提供的信息，如何利用存储系统的先进特性，始终保持数据服务的高效低廉。
全文 3733 字，预计阅读时间 10 分钟。
01 存储需求如何变动
为了说明业务和技术同时驱动着存储方案的变化，此处举一个较为容易理解的例子：网页的倒排索引构建。
假设我们要经营一个叫做 tendu 的检索服务，业务就是接受一批网页集合，并对这些网页提供检索服务，当网页集合或者网页内容发生变化时，也将这些变化更新到检索结果中。
1.1 业务起步——方案 1.0
tendu 业务初起步的时候需求是非常简单明了的，因为规模和性能并非瓶颈，需求说明往往是流程性的。我们给出下面这样一个模型来示意这批网页的检索服务应该如何构建：
为了说明清楚，上图中完整表述了离在线的结构，但是在本文中，我们只关注离线的部分。除去网页数据库之外（假设这个数据库在我们的目标之外，并且极为稳定），最为主要的数据组件就是”正排计算结果存储“这个数据库，这个数据库有两个主要作用：
这时我们可以看到这个数据系统的需求是明了简单的：
1、根据 key 和数据名随机读写数据。
2、全量扫描所有数据。
那么一个简单的类 Big-Table 表格存储系统就可以解决上述问题，此时我们的方案是 1.0 版本，计算系统面对唯一一个数据库，使用 Get/Put 接口来计算网页正排数据，使用 Scan 接口来扫描数据全集组装倒排。
1.2 快速更新 —— 方案 2.0
随着 tendu 的用户越来越多，用户也发现了产品有一些问题：更新非常慢，一个已经更新到第 10 话的漫画，在检索结果中，依然显示为一周前的第 2 话。面对这些用户反馈，业务很快总结出了这个阶段的新目标：提升更新速度。
在 1.0 方案当中，整个系统的需求都是流程性的，在这个目标下，只要正排对应的网页特征以及倒排索引被正确的产出，这就是一个合格的方案。为了完成更新速度提升的目标，业务需求补充了一些量化描述：
我们在 1.0 当中采取的类表格存储很快遇到了瓶颈：计算过程中需要从数据库当中 Get 一些列，而 1.0 方案中采用了 HDD 介质的数据库来存储所有数据，HDD 介质的随机 IO 能力非常低，要提升随机 Get 的吞吐量则需要非常高的成本，为此，我们重新修改上述的架构。
经过业务的一番分析发现，有频繁 Get 需求的只是一部分非常少的数据列，大约只占数据库整体的 5%，因此需要一个支持对小体积数据进行高频查询的存储服务。我们在这里增加了一个 redis 作为这个类型数据的缓存，正排计算服务的随机 Get 请求发送给 Redis，写入请求同时发送给 Redis 和我们的表格存储。
至此，使用 HDD 和内存混合存储的方案基本满足了业务的快速更新需求。
1.3 大范围收录 —— 方案 3.0
随着更新速度越来越快，用户在检索服务上可以得到的结果越发精准、有效，业务效果广受好评，但是也迎来了新的产品需求：有一些小众的需求不是大多数人的需要，但是恰好有一些网页可以满足这部分需求，这部分网页的数量是非常巨大，但是往往更新并不频繁。
此时需求中出现了两组数据集合：
优质集合
广泛集合
为满足分别的扫描需求，做出分库分表的方案，一个库存储优质集合，另外一个库存储广泛集合。
02 引入存储方案层
2.1 精细化存储方案的问题
如上，我们讲述了一个检索服务的演变，为了不断适应新的业务需求，不停变换存储方案。带来的结果是：
1、存储效果——到达了较为理想的状态。
2、存储后端数量翻倍（1 到 2）再翻倍（2 到 4）。
3、不同存储之间的数据存在关系，这些关系需要所有业务计算模块知晓，管理成本上升。
2.2 Midgard——存储方案管理
开篇的例子很好的说明了存储方案调整的方式，根据数据使用需求、结合存储介质特性，反复迭代。Midgard 是基于这一思路做出来的数据层，让业务脱离对具体存储的管理和维护。用户可以使用变更需求描述的方式表达业务变化，而代码和各种设施层面则不需变动，因为 Midgard 提供了稳定的接口。
核心结构——按名访问数据
Midgard 的核心可以看作以下几个部分：
1、Meta 模块，元信息管理，存放了各种数据的基础配置信息，比如某字段是否拥有 Cache，存储在何处。
2、Server 模块接口层，处理用户请求，将用户请求根据元信息加载进来并进行预处理。
3、算子/执行器层，接口层会将用户请求编译成多个算子，并组织成一定结构交给执行器执行。
通过较为简单的分层结构满足了数据名与接口实现分离的要求，算子和执行器通过从 Meta 模块获取的编排信息就可以知道有哪些步骤需要执行，接口层面则对用户完全屏蔽掉这些细节。并且修改 Meta 当中的信息就可以修改一个数据列的具体行为，实现了数据存储方案的灵活管理。
按需调整能力
1、用户向 Midgard 注册数据接口的需求量
例如数据 PAGE_SCORE 需要 get 接口供给 1000QPS 的服务能力
2、根据业务需求，修改存储方案的元信息
一般来说业务会有两类需求：新增添加数据，定期更新存储方案重新调优
3、稳定使用
4、Midgard 根据从执行器和存储服务上采集到的数据反过来优化存储方案
从上面的示意图来看，Midgard 是数据需求与存储方案之间的桥梁，接受各种需求，落地成各种存储方案，后续再根据从执行层获取到的后验信息积极的调整存储方案。
在我们一开始举的例子当中，那些嵌在各个业务代码里的存储间处理逻辑，对业务就可以简化成一步：对 Midgard 更新数据需求描述，并且业务无需管理这些具体的存储组件，当我们要开展一个新的业务时也可以复用我们现有的技术方案。
组合计算能力
此外，得益于执行器的结构，每个操作都是由若干个独立的算子组合形成的，Midgard 因此具备一定的组合计算能力。
举一个例子：现有两张表，表 A 包含了网页的主要信息，表 B 是一个用户评分系统，记录了用户对网页的打分，其中有一项 sham_score 标记了用户是否认为网页有虚假信息，并且这一列加载了 cache。
我们现在想要组装一个任务，从表 A 中定期扫描所有的网页，将 sham_score>5 的数据全部清除。一般来说这可能需要一些复杂的代码来同时读取三个存储：a) 表 A b) 表 B c) sham_score 的缓存，但是 Midgard 的组合计算能力，可以将细节隐藏在冰山之下。
用户传递给 Midgard 的可能是一个简单的原语序列：
首先 Midgard 会把它拆解为一个命令序列：
然后 Midgard 会从元信息中得出 sham_score 有可用缓存的信息，拆解为：
考虑到这样一个任务，对存储的主要压力有：A 的扫描压力，cache 读取压力，原数据读取压力，从 A 中删除数据压力。还可以在 Midgard 中插入几个限流算子，由于使用了惰性求值，所以在限流策略不触发数据消费时，限流算子之前的算子的 IO 就可以暂时挂起。
这样一套逻辑如果由各个业务单独实现可能会非常繁琐，但是得益于 Midgard 算子的原子化拆分，很容易通过简单组装完成数据的功能组合。
03 结语
整体来说，Midgard 是搜索的数据系统在智能化方面的尝试。很多数据业务都是人工了解业务诉求、分析合适的方案，方案一经制定极少变动，只有在极少数大规模架构变革时顺带修改。
这种运营模式依赖人工经验，缺少持续维护的途径，并且在产生新的技术突破时很难惠及存量业务，而且会随着时间推移，需求的变动使得最初的方案设计逐渐腐化。
Midgard 希望提供一个对业务稳定的数据接口层，让存储方案变更对业务屏蔽，并且具有长久的可维护性。例子当中的分表和缓存也不是 Midgard 仅有的能力，未来可能会接入更多的功能和方案选择，让存储系统面向数据使用者，持续迭代。
——END——
推荐阅读
版权声明: 本文为 InfoQ 作者【百度Geek说】的原创文章。
原文链接:【http://xie.infoq.cn/article/5fa39c97f388dc8e79cf95a5b】。文章转载请联系作者。
百度官方技术账号 2021-01-22 加入
关注我们，带你了解更多百度技术干货。
评论