一、概况简介
京东大数据平台构建了一个健全的基础架构，它起着至关重要的作用，为多样化的数据处理任务和高级分析工作提供了支持。该平台的核心组成部分之一是 Hadoop Distributed File System（HDFS），这是一个高度可扩展的分布式文件存储系统。HDFS 在京东大数据平台中承担了重要的角色，它不仅是数据存储的基石，同时也是数据处理流程的一个重要环节。它为上层的数据分析工具和应用提供了数据支撑，并为下游的数据产品和服务提供了强有力的数据输入。
为了强化数据管理和运维效率，京东大数据平台实施了可视化管理工具，这使得运维团队能够通过监控系统轻松快捷地定位集群问题。实时监控和可视化数据展现，极大地简化了日常管理任务，提高了运维响应速度。京东大数据平台的离线存储能力已经达到了较大规模，拥有数万台服务器，总存储量达到 EB 级别。日常数据增长量达到数十 PB。这种规模的存储系统为平台上每天百万次的作业提供了稳定且高效的读写性能，保障了大数据平台的平稳运行。
二、跨域存储
1. 存在的问题
随着京东业务的持续发展，对底层数据存储的要求也日益增高，单机房独立部署的架构已无法满足日常的需求，也不符合未来多机房的发展需求，面临着一系列跨域存储问题：
容灾能力：在当前的多机房分布架构中，虽然存在多个数据中心，但尚未实现真正的多机房容灾能力。
数据同步：当业务层需要跨机房访问数据时，目前采用的方案主要是数据同步。这种同步通过 distcp 进行，实现元数据和存储数据的复制。在这种模式下，元数据会在每个数据中心各自存储一份，这种做法无法保证元数据的一致性，数据一致性的确保必须依赖于业务层的逻辑。
数据存储：由于数据在多个机房存储，导致了数据的大量冗余，这种冗余不仅占据了大量的存储空间，也导致了单位数据存储成本的显著提高。
跨机房专线不受控：跨机房复制数据时，通过跨机房的专线进行数据表的读取，这些操作可能导致机房间专线出现一些不可控的问题。
2. 存储架构
针对上述问题，我们决定采用全量存储加上全网拓扑的策略来实现异地容灾和跨域存储的能力。通过这种方法，可以提高数据的可用性和一致性，同时优化存储效率，降低成本。
在这一架构中，多个数据节点（DN）同时向同一机房的元数据节点（NameNode）汇报信息，实现了全网拓扑结构和全量存储的功能。这种设计允许单个元数据节点统一管理源数据，有效解决了数据一致性问题，并控制了数据迁移成本，达到无感知迁移的用户体验。
在跨域存储功能实施之前，机房间的数据同步主要通过 distcp 完成。然而，在实际工作中，如在一个大规模机房迁移过程中，若采用 distcp 进行迁移，涉及的数据量高达数十 PB，这将要求迁移所有相关业务表和任务，带来巨大的成本。
采用了跨域存储架构后，迁移效率得到显著提升，提高了 350%。此架构支持跨机房数据同步，业务无需分析上下游链路，极大简化了迁移过程。在一个实际案例中，迁移了上万张表，涉及数十个产品和上千个业务。
除了实现跨机房存储节点的汇报功能外，架构还在其他机房部署了只读节点，并支持跨机房切换能力，允许元数据节点实现跨机房容灾能力。只读节点的引入，使得可以启用读写分离，将读流量全部转移到只读节点，从而提高了整个集群的读性能，性能提升超过了 70%。同时，随着读流量从活跃节点迁移走，活跃节点可以专注于优化写性能。此外，开启聚合写功能进一步提升了集群写数据的能力。
尽管跨机房存储架构带来了多种优势，但它也伴随着一些挑战需要克服。
首先，随着跨机房存储功能的实施，集群规模可能会迅速扩大，导致单一集群规模激增至数万的规模。这种快速扩张带来了管理和维护的难度，对集群管理能力提出了更高的要求。
其次，跨机房心跳（心跳机制用于监测节点间的活跃状态）同样面临挑战。由于物理距离和网络延迟的存在，确保跨机房心跳的稳定和可靠性变得更加困难，需要采用高效的同步机制来减少心跳丢失和误判的情况。
最后，多机房存储节点的加入复杂化了元数据节点的拓扑结构，同时对跨机房流量的控制也提出了新的要求。流量控制机制必须能够应对来自不同机房的数据流，确保数据同步的效率和准确性，同时避免网络拥堵和数据丢失。
总结而言，为了充分发挥跨机房存储架构的优势，必须解决伴随其带来的规模扩张、心跳同步和流量控制等一系列问题。
3. 拓扑与数据存储
针对跨机房数据分布问题，采取了通过修改目录上的 XTTR 属性来解决的方案。该方案实现了跨域标签功能，该标签携带了关键信息，包括数据分布、标签状态、标签的生命周期以及提交信息等。这些标签随着 Editlog 生成，并持久化保存在对应的文件系统镜像（fsimage）中。
在新增文件时，系统会检查文件的父目录来确定对应的跨域标签。如果父目录包含多层，并且有多个目录都配置了跨域标签，系统将遵循“就近原则”，即选择与文件最接近的跨域标签来进行操作。这样的处理原则确保了数据分布的合理性，并提高了存储系统的效率和一致性。
4. 跨域数据流
跨域流量控制是跨域存储特性的核心组成部分，它主要通过跨域标签来管理机房间的数据流动。根据客户端的访问请求及其所属机房信息，系统可以确定数据应当写入的目标机房。
在数据写入过程中，系统首先依据块标签（跨域标签）决定同机房需要写入的数据块数量。完成数据块的写入后，这一操作将触发元数据节点内部的一个模块——CR check 模块。CR check 模块负责下发补块任务，以实现异步的跨机房数据同步。
例如，当客户端访问属于 A 机房时，数据首先会被写入 A 机房。随后，元数据节点将下发补块任务，并通过异步操作在其他机房间进行数据块的相互拷贝。这个过程确保了数据在各个机房间能够得到一致性的维护，同时也满足了数据冗余和可靠性的需求。通过这种方式，跨域存储不仅优化了数据的写入流程，还提高了整个存储系统的稳定性和可扩展性。
5. 跨域补块
最初阶段，跨域读取和数据同步是通过 distcp 来实现的。随着架构的演进，现有跨域存储架构在元数据节点内部新增了一个名为 CR check 的模块，该模块负责创建数据拷贝任务，以便执行跨机房间的数据复制。
就性能而言，元数据节点内部通过 CR check 模块下发的异步补块任务效率明显高于 distcp 同步效率。这是因为 CR check 模块下发的补块任务可以分发至多个数据节点（DN）上执行，其并发性显著提升。此外，在节点选择方面，CR check 模块的性能也优于 distcp。
在实际应用中，除了处理新数据的跨机房复制过程，还需要处理现有的存量数据。这涉及到批量变更目录下跨域标签的操作，主要源于三种操作：新增跨域标签、删除跨域标签以及修改跨域标签。特别地，修改跨域标签通常涉及目录的重命名操作，例如将目录从跨域目录转移至非跨域目录，或从一个跨域目录移动到另一个跨域目录。
这些目录相关的操作通过内部的异步更新器模块进行处理。该模块调用 CR check 模块扫描目录下的所有文件，以判断哪些文件需要进行跨域补充处理。这样的设计确保了在文件层面上，跨域存储能够灵活地响应目录变化，维护数据的一致性和完整性。
6. 异步更新器
异步更新器是一个关键组件，用于处理存量数据的异步更新任务。为了优先保障电商等优先级较高的表尽快完成跨机房数据流动，异步更新器采用了带有优先级的队列设计。
在处理队列中的任务时，异步更新器会启动一个线程，该线程会按照任务的优先级进行排序处理。在处理过程中，线程不会一次性完成一个目录下的所有任务，而是采取轮询方式，分步处理不同目录下的任务。这样的设计保证了在处理过程中，一旦有新的高优先级目录任务加入，系统可以及时调整处理顺序，优先处理这些高优先级任务。同时避免了单个大表（如 PB 级别的表）占用过多时间而导致其他任务阻塞的问题。异步更新器不会等待一个目录下的所有任务全部完成后才开始处理下一个目录。这种设计确保了系统处理的高效性和响应性，不仅符合了初期的设计理念，同时也避免了大表在数据迁移中对系统造成的影响。
7. 跨域流控
跨域流控是跨域存储架构中的一个重要机制，用于管理和控制不同机房间的数据传输速度。在初始版本的跨域架构设计中，存在单一的跨域模块队列。然而，在大规模使用场景下，由于不同机房间数据存储节点的数量和专线带宽的差异，出现了数据补块速度不一致的问题。这导致了在某些小机房中数据补块速度缓慢，进而造成了跨域模块队列和异步更新器队列的大量积压。
这种积压不仅影响了其他机房补块的速度，还可能出现跨区域读取数据，专线不可控的现象。为解决此问题，我们根据机房分布和数据流动方向，进行了补块队列的拆分，从而避免了不同机房间数据流控制的相互影响。
处理补块任务的是 CrossRegionRedundancyMonitor 线程，它负责处理补块队列中的所有数据块，并将这些块转化为异步补块任务，下发到数据节点（DN）端执行。该线程复用了社区版本 ReduceMonitor 线程中处理补块的部分逻辑，这样既保证了非跨域补块的时效性，同时也提升了跨域补块的处理速度。
由于跨机房拷贝涉及专线的使用，为了减轻对专线的冲击，我们引入了限速器。随着模块队列积压问题的出现，我们意识到统一限速存在不合理性。因此，在二次优化时，我们对限速器也进行了拆分，每个补块队列对应一个限速器，并且限速值可以根据专线的实时使用量动态调整。这样的优化不仅保障了专线的稳定性，还加快了数据传输的速度，提高了整个跨域存储架构的效率。
跨机房流量的管理不仅涉及数据的跨机房流动，还包括跨机房的数据读写操作。如前所述，所有的 RPC 请求均携带机房信息，系统依据该信息返回指定的存储节点。例如，如果请求来自机房 A，则会优先写入或读取机房 A 的数据；若来自机房 B，则相应地操作机房 B 的数据。这种机制有效避免了大部分的跨域流量。
然而，存在一些异常情况，比如使用非标准客户端访问或机房信息缺失的情况，这时候存储系统中可能没有可用的节点信息。为了兼容这类情况，系统会根据IP 信息推断机房位置。在获取到机房信息后，系统按照访问流程选择对应的节点。如果无法选择到合适的节点，系统可能会进行降级处理，例如允许访问跨域标签所指定的其他机房节点。
针对异常访问情况，系统设有专门的任务进行监控和统计，该任务会针对异常情况进行汇总。系统需要根据关键信息追踪任务来源。一旦确定了任务来源，可以通知相关的数据治理团队进行处理，以确保数据的正确管理和优化跨机房流量的使用。通过这种方式，系统旨在减少非必要的跨机房流量，提高数据读写的效率。
三、分层存储
随着集群存储规模的扩大，数据量的增长以及存储节点机器类型的多样化，一系列的挑战和问题随之浮现。
其中一个显著问题是冷热数据的管理。未对冷热数据进行区分对待可能导致存储资源的浪费，因为冷数据（很少访问的数据）占用了与热数据（频繁访问的数据）同等的存储资源，对效率和成本都造成了影响。
另外，不同硬件间的差异也是一个需要关注的问题。不同硬件的存储节点性能差异可能导致数据存取效率不一，这要求存储系统能够识别和优化使用不同硬件特性，以提高整体存储性能。
数据治理的推进也是随着存储规模的增长而变得更加复杂和重要。有效的数据治理能够确保数据的安全、合规以及有效使用，同时降低数据冗余和管理成本。
为了应对这些挑战，存储系统需要一系列的优化措施，如智能数据分层、自适应数据迁移、不同硬件性能的优化利用，以及持续的数据治理和质量控制。这些措施旨在保证存储系统的高效运作，同时确保数据的安全性和可访问性。
1. 存储对比
微服务架构中，常见的存储方案包括本地缓存、Redis 和 MySQL。这三种存储方式各自适用于不同的数据访问频率和数据热度。具体来说：
（1）本地缓存
- 存储最频繁访问的数据，性能最高。
- 数据读取速度最快，因为避免了网络传输的开销。
（2）Redis
- 存储在内存中，但访问数据需要通过网络。
- 相比本地缓存，性能略有下降，但仍远高于磁盘存储。
（3）MySQL
- 通常用于持久化存储，涉及到磁盘 I/O，因此性能较低。
- 适用于不频繁访问的数据或需要持久化保证的数据。
这种数据存储的分层策略与 HDFS 社区提出的异构存储策略相呼应。HDFS 的异构存储允许将不同类型的数据存储在不同性能的本地磁盘上。我们可以根据数据的热度将其存储在相应的磁盘类型上。HDFS 异构存储的优势在于能够更细粒度地管理存储，支持到磁盘级别的类型定义。然而，这种优势在某些情况下也可能转变为劣势：
- 由于磁盘类型有限，不支持过多层次的定义。
- 存储节点类型的变更可能需要重启服务才能生效。
- 若涉及到磁盘类型新增，可能需要修改存储节点代码，并进行滚动升级，这对大型集群是一个复杂的过程。
- 冷热数据之间的状态转换不够灵活。
为了更高效地管理冷热数据，我们需要一种支持冷热数据自动转换的分层存储方案。这种方案能够动态根据数据的访问模式和热度进行数据迁移，优化存储资源使用，提高系统性能。
2. 京东分层存储
京东存储机器主要分为三种类型：SSD 盘机器、HDD 盘机器和多 HDD 盘的高密存储机器。这三种机型的主要区别在于磁盘的性能和磁盘数量。由于 SSD 的性能优于 HDD，HDD 的小盘机器的性能又优于多磁盘 HDD 机器的性能。基于对京东存储机器分布现状的分析，决定采用以下分层存储策略：
- 热数据：存储在性能较高的 SSD 盘上，以提供快速的数据访问速度。
- 温数据：存储在性能适中的 HDD 盘上。
- 冷数据：存储在高密度 HDD 盘上。
这种策略不仅充分利用了不同机器类型的硬件特性，还解决了冷热数据分层的问题，优化了存储资源的使用。为了实现这种分层存储，京东对网络拓扑进行了调整，以标识不同的机器类型，并确定它们应当存储哪些类型的数据。此外，通过修改目录的XATTR（扩展属性）来标识目录中数据的冷热需求。通过这种策略和调整，我们能够有效地将数据定位到适合其访问的存储介质上，从而提高了存储系统的整体性能。
为了实现数据的自动转换，即热数据与温数据的互转以及温数据与冷数据的互转，我们在元数据节点（NameNode）内部引入了一个自动转换模块。该模块基于元数据节点内部的多个组件协同工作，实现了数据的动态迁移和存储类型转换。
数据自动转换的实现细节如下：
- 热数据转换为温数据：通过内部的数据搬移机制实现节点替换。
- 温数据转换为热数据：同样依靠数据搬移机制进行节点替换。
- 冷数据处理：利用时间生存期（TTL）功能，当数据存储到冷数据节点时，会进行副本转换为纠删码（Erasure Coding, EC）的过程，以优化存储效率和耐久性。
为了根据不同的机器类型区分数据存储位置，数据节点（DataNode，DN）上新增了多个属性，包括但不限于：
- 读写权重：决定节点在读写操作中的优先级。
- 存储使用量：反映节点的存储空间占用情况。
- 节点健康度：指示节点的健康状况。
在进行数据块的选择和写入时，不仅可以根据存储类型进行划分，还可以根据 DN 节点上的这些属性值来做出决策。这些属性值会向上汇总到机架和更高层次的元数据中。因此，在选定机架之后，可以基于节点的健康度或读写权重等因素，选择健康性更高的节点来进行数据的读写操作。通过这种方式，我们实现了一种动态的数据存储策略，既优化了存储资源的使用，又提高了数据访问的性能和可靠性。
在实施的分层存储方案中，涉及到多个内部模块的修改，特别是三个核心模块的设计与实现对于数据冷热状态的转换至关重要：
- 数据访问监视器：
该监视器默认采用最近最少使用（LRU）算法统计文件目录的访问情况，筛选出热点数据。
提供 API 支持，允许变更已实现的其他策略。 - 分层管理模块：
主要功能是扫描已标记分层标签的目录，结合访问监视器提供的热点数据信息。
对这些目录处理，创建数据转换任务，并提交到任务管理模块。 - 任务管理模块：
京东在元数据节点内部实现了一个分布式调度平台，包含多种功能，如数据节点变更、数据类型转换和数据生命周期管理等。
该模块复用社区原有的任务下发机制，例如在数据节点（DN）心跳时，从元数据节点获取数据块删除、复制或恢复任务。
模块扩展了任务类型，具体任务的处理则在存储节点上实现。
通过这些模块的协同工作，京东的分层存储方案有效提高了核心链路的整体性能。数据访问监视器的策略改进，使得高频访问数据得到加速，提升了 L0 和 L1 任务的时效性，整体性能提高了 10%。同时，分层存储方案也降低了平均存储成本，通过高密存储和 EC（纠删码）转换，提升了 EC 数据的覆盖率，达到 30%，并且使得冷数据存储成本降低了90%。
京东的分层存储方案不仅提升了数据处理的效率和速度，也显著降低了存储资源的成本，实现了存储系统性能与成本的双重优化。
3. 实践结合
京东结合跨域存储和分层存储实现了两个具体的应用场景，分别是跨域生命周期管理和数据调度功能。
（1）跨域生命周期管理
- 社区版本中的跨地方存储可能会造成数据的过度冗余，提高存储成本。京东的跨域存储方案也面临类似问题，但冗余度有所降低。
- 某些数据在平台上写入后很久不会被读取，可以根据文件创建时间和跨域标签对数据进行流动处理。从多机房数据转换为单机房数据，并引入分层存储功能，将单机房数据通过EC 转换为高密存储，从而将数据冗余度降低。这种策略大幅度降低了数据的冗余度，并将数据从性能较好的机器转移到了适合冷存储的机器上。
（2）数据调度功能
- 可以理解为反生命周期过程，即通过访问监视器统计结果进行数据反向加热。数据加热后，结合跨域标签进行多机房分布，提升数据读取效率。
- 任务漂移的支持。根据计算资源的动态分配，将任务分配到资源较多的集群执行，优化线上任务的时效性。多机房之间的计算资源可能在不同时间段不一样，任务漂移功能能够智能地分配任务，确保数据就近处理，进一步提升任务处理的效率。
这两个场景展示了京东如何通过智能化的存储和数据管理策略，实现了存储成本的优化和数据处理性能的提升。跨域生命周期管理通过动态调整数据存储位置和方式，大幅度降低了存储成本；而数据调度功能则确保了数据和计算资源的有效配合，提高了任务执行的时效性和效率。这些创新的存储管理方法对于大规模分布式存储系统来说至关重要，帮助我们实现了资源的最优化利用。
