共计 3681 个字符，预计需要花费 10 分钟才能阅读完成。
作者 | 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 的可能是一个简略的原语序列：
Scan(A).Join(B.sham_score).Filter(sham_score > 5).Delete(A)首先 Midgard 会把它拆解为一个命令序列：
Scan A
Join sham_score
Filter sham_score > 5
Delete A而后 Midgard 会从元信息中得出 sham\_score 有可用缓存的信息，拆解为：
Scan A
Join sham_score.cache // 尝试读取缓存
FallbackJoin sham_score // 如果缓存获取失败则退回到原数据
Filter sham_score > 5
Delete A思考到这样一个工作，对存储的次要压力有：A 的扫描压力，cache 读取压力，原数据读取压力，从 A 中删除数据压力。还能够在 Midgard 中插入几个限流算子，因为应用了惰性求值，所以在限流策略不触发数据生产时，限流算子之前的算子的 IO 就能够临时挂起。
Scan A
Limit xx M/s // 插入限流算子通过执行器反压
Join sham_score.cache // 尝试读取缓存
FallbackJoin sham_score // 如果缓存获取失败则退回到原数据
Filter sham_score > 5
Limit xx M/s // 插入限流算子进行反压
Delete A这样一套逻辑如果由各个业务独自实现可能会十分繁琐，然而得益于 Midgard 算子的原子化拆分，很容易通过简略组装实现数据的性能组合。
03 结语
整体来说，Midgard 是搜寻的数据系统在智能化方面的尝试。很多数据业务都是人工理解业务诉求、剖析适合的计划，计划一经制订极少变动，只有在极少数大规模架构改革时顺带批改。
这种经营模式依赖人工教训，短少继续保护的路径，并且在产生新的技术冲破时很难惠及存量业务，而且会随着时间推移，需要的变动使得最后的方案设计逐步腐化。
Midgard 心愿提供一个对业务稳固的数据接口层，让存储计划变更对业务屏蔽，并且具备短暂的可维护性。例子当中的分表和缓存也不是 Midgard 仅有的能力，将来可能会接入更多的性能和计划抉择，让存储系统面向数据使用者，继续迭代。
——END——
举荐浏览
百度垂类离线计算零碎倒退历程
度加剪辑 App 的 MMKV 利用优化实际
百度工程师浅析解码策略
百度工程师浅析强化学
浅谈对立权限治理服务的设计与开发
