作者
吕亚霖，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》
