百度桑田·存储一致技术底座架构演进

随着 AI 时代的极速开展，对存储技术提出了更高的要求，尤其是在大规模、高性能和低老本方面。为了应答这些应战，百度桑田·存储打造了一个高度可复用的一致技术底座。咱们在这个一致的技术底座中处置了云存储的特性疑问，让下层存储系统的迭代更高效。

首先，我将简明引见一下百度桑田·存储一致技术底座的全体架构。这个一致的技术底座由三个外围组件形成，区分是一致的元数据底座、一致的层级 Namespace 以及一致的数据底座。

咱们以为各种存储系统实践上是由元数据面和数据面两部分组成，经过提炼出高度可复用的元数据面和数据面的一致技术底座，就能积木式搭建各种云存储系统，比如对象存储、文件存储、块存储等，最大化缩小重复开发的上班。

接上去，我将详细引见这三个外围组件。

首先是一致的元数据底座。这个元数据底座是专门为元数据场景设计的散布式事务 K-V 存储系统。基于 Meta-Aware 的设计理念，具有万亿级别的元数据存储才干。它撑持了对象存储 BOS 和文件存储 CFS/AFS 的元数据存储。

而后是一致的层级 Namespace。基于一致的元数据底座构建的层级 Namespace，曾经退化到了单机散布式一体化架构，具有高性能和良好的可扩展性。

最后是一致的数据底座。这是一个在线纠删码 EC 存储系统，旨在提供高吞吐量和低老本的一致数据存储服务。该系统驳回无逻辑单点的微服务架构，允许 ZB 级别数据规模。

这三个外围组件独特构建了百度桑田的一致技术底座，撑持了下层的各类存储产品，如对象存储 BOS、块存储 CDS 以及文件存储 CFS/AFS 等。

目前，最新的第三代一致技术底座曾经允许了百度桑田·存储数据湖减速方案 2.0 的规模化运行。

1.一致元数据底座演进

首先引见百度桑田·存储元数据底座的开展历程。这张图展现了咱们三代架构的演进环节。

首先，第一代架构。在初期，咱们的元数据存储散布在多套系统之上，比如对象存储，同时依赖于 MySQL 和一套散布式 K-V 键值系统。这种多系统并存的方式虽然满足了过后的需求，但也带来了高昂的运维老本。更为关键的是，MySQL 无法做到线性扩展，难以应答极速增长的数据需求。

随后，第二代架构，降生于 2017 年。过后，HopsFS 论文的宣布让咱们看到了基于散布式事务数据库处置对象和文件元数据存储扩展性疑问的或许性。遭到启示，咱们启动了自研通用 NewSQL 名目。经过两年的努力，文件存储 CFS 和对象存储 BOS 的系统扩展性失掉了清楚性优化。但是，虽然扩展性失掉了改善，元数据的性能仍未到达现实形态，这成为咱们下一步优化的重点。

进入第三代架构，自 2019 年起，咱们看法到通用 NewSQL 的设计无法在云存储元数据场景中充散施展性能优势。于是，咱们深化剖析了百度外部各个云存储场景的元数据特色，面向这些场景启动了从新设计，终于处置了上一代架构扩展性和性能难以统筹的疑问。这一系统已成为百度桑田·存储的外围撑持，成功了大规模片面的上线，服务于百度默认云的对象存储 BOS、文件存储 CFS 以及百度外部的类 HDFS 文件系统 AFS，极大地优化了产品的竞争力。

接上去我将讲述为什么通用 NewSQL 在元数据存储中会引入额外的开支。

重要要素在于通用 NewSQL 并不感知元数据的语义，这造成了多方面的资源糜费。为了更好地理解这一点，我将从 4 个维度启动详细论述：分区（Partition）、事务与索引、单机引擎以及接口设计。

首先，从 Partition 的角度来看，元数据具有高度的部分性。例如，一个目录下的一切元数据，或许一个小规模文件系统的一切元数据，往往须要集中存储以提高访问效率。但是，通用 NewSQL 难以保证这种部分性，无法将关系的元数据所有搁置在同一个 Shard 中。这象征着，当咱们访问这些元数据时，经常须要跨 Shard 启动操作，从而造成跨 Shard 事务的高额开支，影响全体性能。

其次，谈到事务与索引，通用系统的事务处置往往随同着较大的开支。以多版本并发控制（MVCC）为例，虽然它能够提高并发性，但也带来了额外的渣滓回收（GC）开支。此外，二级索引在通用系统中通常依赖散布式事务来保证原子性，这进一步加剧了系统的累赘。散布式事务自身开支渺小，造成全体性能难以到达现实形态。

第三，从单机引擎的角度剖析，通用 NewSQL 通常驳回繁多的单机引擎，目前较多驳回 Log-StructuredMerge-Tree（LSM-Tree）结构。虽然 LSM-Tree 在写性能方面体现杰出，但在某些场景下并不现实。例如，关于数据量较小且重要启动点查问的表，LSM-Tree 的性能不如全内存的哈希引擎。这种不适配性造成了资源的低效应用和性能瓶颈。

最后，关于接口设计，基于通用 NewSQL 的成功，会造成元数据的语义与元数据的存储层彻底分别。这种分层解耦的架构虽然在软件工程角度有低耦合、高内聚的优势，但也带来了额外的开支。为了降落这些开支，咱们须要将元数据的语义下沉究竟层的事务 K-V 系统中，使得存储层能够更好地理解和优化元数据的操作，从而优化全体性能。

综上所述，通用 NewSQL 由于无法感知和优化元数据的特定语义，造成在分区治理、事务处置、存储引擎选用以及接口设计等多个方面发生了额外的开支。因此，咱们须要针对元数据的特性，设计公用的存储处置方案，以更好地满足性能和扩展性的需求。

基于咱们前面探讨的应战，百度桑田·存储自主研发了一致元数据底座。

从系统架构上看，百度桑田的底座与业界的 NewSQL 系统相似，但在设计上有一个关键性的外围差异—— Meta-Aware。便捷来说，这象征着底层的事务 K-V 系统能够深度感知元数据的语义，从而成功更高效的处置。

接上去，我将从 4 个方面详细论述这一外围差异及其带来的优势。

首先，从分区（Partition）角度来看，允许自定义决裂战略和 co-located 机制。详细来说，咱们能够确保一个目录下的一切元数据或一个文件系统中的一切元数据被调配到同一个 Shard。这一设计确保了大部分操作只要在单个 Shard 内成功，从而防止了跨 Shard 事务带来的高额开支，清楚优化了系统的性能和照应速度。

其次，在事务与索引方面，元数据操作通常是短事务。咱们成功了一个 TTL 为 5 秒的内存 MVCC 机制，只在内存中维持多版本，仅将一个版本启动耐久化存储，这样就大大缩小了多版本 GC 的开支。此外，咱们同时允许了同步和异步二级索引机制，关于有强分歧性需求的场景驳回同步索引，关于那些分歧性要求不高的场景驳回异步索引，有效防止了散布式事务带来的高额开支。这种设计使得系统能够灵敏应答不同分歧性需求的业务场景。

第三，从单机引擎角度，一致元数据底座允许依据表的访问特色来选用最适合的存储引擎。目前，咱们允许 LSM-Tree 引擎、全内存哈希引擎等多种引擎。例如，关于数据量大且有范围查问需求的场景，咱们驳回LSM-Tree 引擎。而关于访问频繁且数据量小的表，全内存哈希引擎则能提供更高的查问效率。这种灵敏的引擎选用确保了不同类型的元数据操作都能取得最佳的性能体现。

最后，在接口（SDK）设计方面，咱们引入了协处置器机制，将文件存储的目录树逻辑下推究竟层事务 K-V 系统，从而防止额外的 RPC 开支，减速了元数据操作的效率。

综上所述，百度桑田的一致元数据底座经过 Meta-Aware 的设计理念，在分区治理、事务处置、存储引擎选用以及接口设计等多个方面成功了清楚优化，不只要效降落了系统开支，提高了性能，还增强了系统的扩展性和灵敏性。

正是这些翻新性的设计，使得百度桑田的一致元数据底座能够更好地满足咱们复杂多变的业务需求。

2.一致层级 Namespace 底座演进

接上去我将为大家引见百度桑田的一致层级 Namespace 架构的演进历程。咱们的层级目录树架构阅历了三个阶段演进：

首先，第一阶段：相似 HDFS 的单机方案。在这一阶段，咱们驳回了相似 HDFS 的单机架构。这种方案的最大优势是极低的提前，能够在高并发访问下坚持高效的照应速度。但是，这种单机方案存在清楚的扩展性瓶颈，其规模只能允许到 10 亿级别的元数据。随着业务规模的一直扩展，这一限度逐渐浮现，无法满足未来更大规模的数据需求。

随后，进入第二阶段：基于散布式数据库的散布式 Namespace 方案。为了打破单机方案的限度，咱们转向了基于散布式数据库构建的散布式 Namespace 架构。这一方案的重要优势在于可线性扩展，能够随着业务增长灵敏地扩展系统容量。但是，散布式方案的实质是就义部分性来保证扩展性，而部分性的就义肯定会带来性能的损耗，为了处置部分性就义而带来的性能瓶颈，百度桑田在第二阶段内演进了三代架构，一直优化散布式 Namespace。

最后，第三阶段：单机散布式一体化方案。咱们提出并成功了单机散布式一体化方案，做到了规模自顺应。当系统规模较小时，这一方案能够施展单机 Namespace 系统的性能优势，成功百微秒级的低提前。随着业务规模的扩展，系统能够无感平滑迁徙到散布式架构，成功水平扩展，满足不同规模阶段的需求。这种一体化方案不只统筹了性能与扩展性，还大幅优化了系统的灵敏性和可保养性。

在散布式层级 Namespace 优化上，咱们重要处置了两个外围疑问：

除了减速门路解析，Index 的引入还带来了其余优化的时机：

但是，这个方案带来了以下技术应战：

首先，单主机的 Index分片面临单点性能瓶颈疑问:

其次，极速门路解析或许造成同目录下的目录修正操作事务抵触和高提前：

百度桑田·存储团队经过一系列技术翻新系统性地处置了上述疑问。

单机和散布式架构能够做到合二为一的最外围的一个点是在规模到达临界点的时刻，后端架构做到平滑切换。

咱们详细的成功方法是这样做的：无论是单机架构和散布式架构，都基于咱们自研的一致元数据底座去构建：

3.一致数据底座演进

百度桑田·存储数据面的架构可以概括为三个阶段。第一个阶段，配件上 HDD 为主、SSD 量较少，架构上驳回的 master-slave 结构。一个管控节点治理数据节点，经常使用 3 正本系统的设计，单个系统只允许单个数据中心。

第二阶段，HDD 和 SSD 混用，SSD 量较第一个阶段回升，节点结构依然驳回 master-slave 结构，数据存储经常使用离线 EC，单个系统允许多个数据中心。

第三阶段，大规模经常使用 SSD，同时为了降落老本，开局经常使用磁带存储，并经常使用 PMEM 等减速配件，驳回无逻辑单点的微服务结构，数据存储经常使用在线EC。

第一代架构的痛点显而易见，3 正本造成高存储老本，此外无法应答机房级别缺点。虽然第二代架构在允许 EC 和少数据中心架构上有所改良，但依然存在以下清楚疑问：

架构瓶颈：驳回master-slave 架构，扩展性受限于单机的存储空间和处置才干。

单点缺点危险：Master 作为单点，缺点或许造成整个系统无法用。虽然经常使用分歧性协定或许共享存储成功了高可用，但是这种方式的成功都是形态机方式，触发 bug 往往就会造成一切 master 节点缺点。

迭代效率低：以 HDFS namenode 为例，其模块迭代需极为审慎，任何疑问都或许形成集群无法用，降落了系统的迭代速度。

写入环节复杂：数据先以 3 正本方式写入散布式 K-V 存储，当散布式 K-V 中单个分片数据写入到达阀值的时刻，再经过读取启动 EC 编码，最终写入 EC 系统中。这样屡次的读写操作消耗少量 CPU 和 I/O，造成写性能和读吞吐量降落。

固定正本数：驳回 1.5 正本的 EC 编码系统无法进一步降落老本。

综上所述，由于第二代系统在 master-slave 架构带来的扩展性和性能瓶颈、离线 EC 造成的性能疑问以及固定正本机制造成的高老本，成为制约系统进一步优化和扩展的重要阻碍，第三代系统努力于系统性的处置上述疑问。

百度桑田·存储最新的第三代数据底座架构驳回了无逻辑单点的微服务架构。这里有两个关键词：一个是无逻辑单点，一个是微服务架构。

无逻辑单点的意思是系统中任何一组形态机中止上班，系统可用性和性能不受影响。微服务架构的意思是从配置的维度将原来单体的结构分拆，比如数据校验、数据修复、负载平衡、容量平衡等等，从而放慢迭代效率。这种结构的好处是：可用性更高，扩展性更强，迭代效率更快，能够允许 ZB 级别数据。

同时，这个数据底座提供了高效 EC 机制，这个机制有两个特点：

在云存储系统的构建中，业界普通存在 2 种架构路途：

目前，这 2 种路途已在不同云厂商落地，均打造出了低劣的云存储产品，很好地助力了社会经济的开展。