共计 3756 个字符，预计需要花费 10 分钟才能阅读完成。
作者
吕亚霖，2019 年退出作业帮，作业帮基础架构 - 架构研发团队负责人，在作业帮期间主导了云原生架构演进、推动施行容器化革新、服务治理、GO 微服务框架、DevOps 的落地实际。
张浩然，2019 年退出作业帮，作业帮基础架构 - 高级架构师，在作业帮期间，推动了作业帮云原生架构演进、负责多云 k8s 集群建设、k8s 组件研发、linux 内核优化调优、底层服务容器化相干工作。
背景
大规模检索系统始终都是各个公司平台业务的底层基石，往往是以千台裸金属服务器级别的超大规模集群的形式运行，数据量微小，对于性能、吞吐、稳定性要求极为刻薄，故障容忍度很低。除了运行层面外，超大规模集群和海量数据场景下的数据迭代和服务治理也往往是一个微小的挑战：增量和全量的数据散发效率，短期和长期的热点数据追踪等都是须要深入研究的问题 本文将介绍作业帮外部设计实现的基于 fluid 计算存储拆散架构，可能显著升高大规模检索系统类服务的复杂度，使得大规模检索系统能够像失常在线业务一样平滑治理。
大规模检索系统所面临的问题
作业帮的泛滥学习材料智能剖析和搜寻性能中都依赖于大规模数据检索零碎，咱们的集群规模在千台以上，总数据量在百 TB 级别以上，整个零碎由若干分片组成，每个分片由若干服务器加载雷同的数据集，运行层面上咱们要求性能达到 P99 1.Xms，吞吐量顶峰百 GB 级，稳定性要求 99.999% 以上。
以往环境中为了进步数据读取效率和稳定性，更多的在思考数据本地化存储，咱们的检索系统每日产生索引项并须要进行 TB 级别的数据更新，这些数据通过离线建库服务产出之后，须要别离更新到对应的分片中，这种模式下带来了许多其余挑战，比拟要害的问题集中在数据迭代和扩展性上：
- 数据汇合的离散 ：因为理论运行中，每个分片的每个节点都须要复制下来本分片所有数据，由此带来了同步数据下发艰难的问题。理论运行中如果要同步数据到单服务器节点，须要应用分级下发，先下发一级（十级）由一级分发给二级（百级）再分发给三级（千级），这个散发周期长且须要层层校验来保证数据准确性。
- 业务资源弹性扩缩较弱 ：原先的零碎架构采纳的是计算和存储紧耦合，数据存储和算力资源严密捆绑，资源灵便扩大能力不高，扩容往往须要以小时为单位进行，不足应答突发峰值流量扩容能力。
- 单分片数据扩展性有余 ：单分片数据下限受分片集群内的单机存储下限限度。如果达到存储下限，往往须要拆分数据集，而这种拆分不是由业务需要驱动的。
而数据迭代和扩展性的问题又不得不带来了老本压力和自动化流程上的单薄。
通过对检索系统运行和数据更新流程的剖析，以后面临的关键问题是因为计算和存储的耦合所带来的，因而咱们思考如何去解耦计算和存储，只有引入计算存储拆散的架构才可能从根本上解决复杂度的问题 计算存储拆散最次要的就是将每个节点存储本分片全量数据的形式拆离开，将分片内的数据存储在逻辑上的近程机器上 然而计算存储拆散又带来了其余的问题，比方稳定性问题，大数据量下的读取形式和读取速度，对业务的入侵水平等等问题，尽管存在这些问题，然而这些问题都是可解决以及易解决的 基于此咱们确认计算存储拆散肯定是该场景下的良方，能够从根本上解决零碎复杂度的问题。
计算存储拆散架构解决复杂度问题
为了解决上述计算存储拆散所须要思考的问题，新的计算存储拆散架构必须能达到以下指标：
- 读取的稳定性，计算存储拆散究竟是通过各种组件配合替换掉了原始文件读取，数据加载形式能够替换，然而数据读取的稳定性仍然须要和原始放弃等同程度。
- 每个分片千节点同时数据更新场景下，须要最大限度的晋升读取速度，同时对网络的压力须要管制在肯定水平内。
- 反对通过 POSIX 接口读取数据，POSIX 是最具备对各种业务场景的适应性的形式，这样无需侵入业务场景下，屏蔽了上游变动对上游的影响。
- 数据迭代的流程的可控性，对于在线业务来说，数据的迭代理当被视为和服务迭代等同的 cd 流程，那么数据迭代的可控性就及其重要，因为自身就是 cd 流程的一部分。
- 数据汇合的可伸缩性，新的架构须要是一套可复制，易扩大的模式，这样能力面对数据汇合的伸缩、集群规模的伸缩具备良好的应答能力。
为了达成上述指标，咱们最终选用了 Fluid 开源我的项目作为整个新架构的要害纽带。
组件介绍
Fluid 是一个开源的 Kubernetes 原生的分布式数据集编排和减速引擎 ，次要服务于云原生场景下的数据密集型利用，例如大数据利用、AI 利用等。通过 Kubernetes 服务提供的数据层形象，能够让数据像流体一样在诸如 HDFS、OSS、Ceph 等存储源和 Kubernetes 下层云原生利用计算之间灵便高效地挪动、复制、驱赶、转换和治理。而具体数据操作对用户通明，用户不用再放心拜访远端数据的效率、治理数据源的便捷性，以及如何帮忙 Kuberntes 做出运维调度决策等问题。
用户只需以最天然的 Kubernetes 原生数据卷形式间接拜访形象进去的数据，残余工作和底层细节全副交给 Fluid 解决。Fluid 我的项目以后次要关注数据集编排和利用编排这两个重要场景。
数据集编排能够将指定数据集的数据缓存到指定个性的 Kubernetes 节点，而利用编排将指定该利用调度到能够或曾经存储了指定数据集的节点上。这两者还能够组合造成协同编排场景，即协同思考数据集和利用需要进行节点资源调度。
咱们抉择应用 fluid 的起因
- 检索服务曾经实现容器化革新，人造适宜 fluid。
- Fluid 作为数据编排零碎，使得下层无需晓得具体的数据分布就能够间接应用，同时基于数据的感知调度能力，能够实现业务的就近调度，减速数据拜访性能。
- Fluid 实现了 pvc 接口，使得业务 pod 能够无感知的挂载进入 pod 外部，让 pod 内能够像应用本地磁盘一样无感知。
- Fluid 提供元数据和数据分布式分层缓存，以及高效文件检索性能。
- Fluid+alluxio 内置了多种缓存模式（回源模式，全缓存模式），不同的缓存策略（针对小文件场景的优化等）和存储形式（磁盘，内存），对于不同的场景具备良好的适应性，无需太多批改即可满足多种业务场景。
落地实际
- 缓存节点和计算节点的拆散: 尽管应用 fuse 和 worker 联合部署能够取得更好的数据本地性能，然而在在线场景下，咱们最终选用了缓存和计算节点拆散的计划，起因是通过缩短肯定的启动工夫换来更优的弹性是值得的，以及咱们并不心愿业务节点稳定性问题和缓存节点的稳定性问题纠缠在一起。Fluid 反对 dataset 的可调度性，换言之就是缓存节点的可调度性，咱们通过指定 dataset 的 nodeAffinity 来进行数据集缓存节点的调度，从而保障缓存节点可高效，弹性化的提供缓存服务。
在线场景的高要求: 对于在线业务场景，鉴于零碎对于数据的访问速度、完整性和一致性有较高的要求，因而不能呈现数据的局部更新、非预期的回源申请等; 所以对数据缓存和更新策略的抉择就会很要害。
- 适合的数据缓存策略 : 基于以上需要，咱们抉择应用 Fluid 的全缓存模式。在全缓存模式下，所有申请只会走缓存，而不在回源到数据源，这样就防止了非预期的长耗时申请。同时 dataload 的过程则由数据更新流程来把控，更平安和标准化。
- 联合权限流的更新流程 : 在线业务的数据更新也是属于 cd 的一种，同样也须要更新流程来管控，通过联合了权限流程的 dataload 模式，使得线上数据发版更平安和标准化。
- 数据更新的原子性 : 因为模型是由许多文件组成，只有所有的文件全副缓存起来之后，才是一份能够被应用的残缺的模型；所以在全缓存无回源的前提下，就须要保障 dataload 过程的原子性, 在数据加载的过程中过，新版本数据不能被拜访到，只有在数据加载实现之后，才能够读取到新版本数据。
以上计划和策略配合咱们自动化的建库和数据版本治理性能，大大提高了整体零碎的安全性和稳定性，同时使得整个过程的流转更加智能和自动化。
总结
基于 Fluid 的计算存储拆散架构，咱们胜利地实现：
- 分钟级百 T 级别的数据散发。
- 数据版本治理和数据更新的原子性，使得数据散发和更新成为一种可管控，更智能的自动化流程。
- 检索服务可能像失常无状态服务一样，从而可能轻松通过 TKE HPA 实现横向扩大，更快捷的扩缩带来了更高的稳定性和可用性。
瞻望
计算和存储拆散的模式使得以往咱们认为十分非凡的服务能够被无状态化，能够像失常服务一样被纳入 Devops 体系中，而基于 Fluid 的数据编排和减速零碎，则是实际计算和存储拆散的一个切口，除了用于检索系统外，咱们也在摸索基于 Fluid 的 OCR 零碎模型训练和散发的模式。
在将来工作方面，咱们打算持续基于 Fluid 优化下层作业的调度策略和执行模式，并进一步扩大模型训练和散发，进步整体训练速度和资源的利用率，另一方面也帮忙社区一直演进其可观测性和高可用等，帮忙到更多的开发者。
对于咱们
更多对于云原生的案例和常识，可关注同名【腾讯云原生】公众号~
福利：
①公众号后盾回复【手册】，可取得《腾讯云原生路线图手册》&《腾讯云原生最佳实际》~
②公众号后盾回复【系列】，可取得《15 个系列 100+ 篇超实用云原生原创干货合集》，蕴含 Kubernetes 降本增效、K8s 性能优化实际、最佳实际等系列。
③公众号后盾回复【白皮书】，可取得《腾讯云容器平安白皮书》&《降本之源 - 云原生老本治理白皮书 v1.0》
