星环科技分布式文件系统 TDFS 大揭秘（上）

星环科技是一家致力于打造企业级大数据基础软件，围绕数据全生命周期为企业提供基础软件及支持的厂商。在这个数据驱动的数字化世界中，来自社交媒体、金融科技等不同领域的数据正在大幅度增长，例如大量商业报告、网页、图像和音视频等。如今，接近 80%的数据都是非结构化的。不同于结构化半结构化数据的良好结构，存储和处理如此庞大的非结构化数据集正在成为传统计算技术的挑战。

本文将着重介绍星环科技新推出的一款致力于打造高性能、高可靠、高可用、强一致的分布式文件系统 TDFS。

从 HDFS 说起：

HDFS 是 Hadoop 非常重要的核心之一。其旨在通过计算机集群在分布式环境中有效地存储和处理大批量文件，有效地解决大规模、海量数据的存储以及读写性能的问题，并确保了设备的稳定性。HDFS 常常用于在 Hadoop 生态体系内提供分布式文件读写服务，是 Hadoop 生态系统中使用最为广泛的组件。

HDFS 有以下的设计目标：

●高可靠性，可以防止服务器出现故障宕机所导致的数据丢失等问题；

●相比较磁盘阵列构建成本低，可构建在廉价 x86 服务器上；

●将大文件切成 Block，支持 GB-TB 级别海量数据存储；

●支持大规模离线批处理，利用数据本地性提速计算过程。

虽然 HDFS 有效解决了用户大文件存储等问题，但在处理大量小文件时性能下降滞后。并且其本身设计也存在一些缺陷，例如 NameNode 的单点性能瓶颈，NameNode 高可用过程中写放大严重，无法存储大量小文件等问题。

以下是 HDFS 的简易架构图：

从整个系统架构上看，NameNode 扮演着十分重要的角色，其一大功能是负责进行元数据的存储与管理。其中元数据信息包括文件名、路径、文件所有者、副本数等。

NameNode 通常将元数据热加载至内存中，但是随着数据规模和集群规模的持续增长，逐渐出现内存受限的问题，并且很多存储小文件时被隐藏的问题被暴露出来，比如启动时间变长。NameNode 的启动过程通常分为几个阶段，包括 fsimage 本地数据加载、读取 JournalNode 上比 fsimage 新的 editlog、在本地进行 editlog replay、DataNode 的 BlockReport。

随着数据规模的增长，现场经常出现需要 replay 的 editlog 非常多的情况，在 replay 完成之前，NameNode 将一直处于 Safemode 状态。在该状态下无法对外提供服务，并且处理来自 DataNode 的 BlockReport 阶段的时长会同步增加。最后只有当 DataNode 消息中上报的 block 个数达到 NameNode 所需的 99.99%后，NameNode 才会退出 Safemode 状态，并开始对外提供服务，整体启动过程将十分耗时。并且，Block 数量庞大时，BlockReport 请求也有可能导致 NameNode 长时间卡顿。

除此之外，由于有关元数据的管理处理等操作基本都是基于 NameNode 来进行，那么当内存被大量占用时，对于元数据的增删改查的操作性能会出现下降的趋势，相对于更复杂的操作处理，比如 RPC (Remote Procedure Call) 请求的性能下降趋势将会更加明显。

HDFS 为了实现高可用，需要额外引入 Zookeeper，JournalNode ，ZKFC，Standby NameNode，但是引入额外服务的同时也会因此引入其他问题。这里比较严重的问题是一次文件系统元数据的操作将会被同步到至少 5 个不同的副本当中（JournalNode3 份，NameNode2 份），如果每个进程配置了两个目录，那么这个情况还会进一步恶化。另外，多个职能不同但是互相依赖的进程也给运维，特别是故障定位制造了很大的麻烦。

此外，NameNode 内存使用和元数据量正相关。在较大的集群中，NameNode 中所存储的元数据量通常十分庞大。然而，单个 NameNode 可支撑的文件数量以及吞吐量十分有限。尽管可以通过采取小文件合并或数据压缩等手段减少所存储的元数据量，但随着集群规模和业务的不断发展，压力都集中在单个 NameNode 上（如下图所示），导致系统瓶颈，无法具备高可用。并且，当元数据量达到了 NameNode 的上限时，则需要不断的删除旧的数据来维持现有的储存量。CMS(concurrent mark sweep) GC 频率也将会越来越高，甚至可能会由于过程中文件过大而空间不足以存放所导致的 promotion fail，从而触发 FullGC，极易诱发系统内部工作线程卡顿等问题，风险将不可控。

因此，当总元数据量超过单个 NameNode 可支撑的上限时，系统则需改用 Federation 的方式来维护，即增加机器。

尽管这样的机制可以解决当前元数据存储量有限的问题，但是两套 NameNode 之间相互独立互不相通，其中 NameNode 元数据以及 DataNode 块文件无法进行共享，如果出现业务需要访问所有数据的情况，那么则需要根据业务来进行拆分，改造过程会十分麻烦。拆分过程需要使用 DistCP 将数据进行完整的拷贝，存储成本将会非常高，而且进行读写备份的过程十分繁琐，整体效率也会大大降低。并且，使用了 Federation 之后，路径需要使用 ViewFs 的方式来访问，基本上所有需要访问 HDFS 的业务代码都有可能需要进行相应的改造。比如原来要访问 HDFS 的/path/to/abc.log，现在要改成 viewfs://path/to/abc.log，或者 hdfs://nameservice1/path/to/abc.log。

虽然在这个机制下 NameNode 以及 NameSpace 存在多个，但是其中单一的 NameNode 以及 NameSpace 仍然存在单点故障。如果其中一个 NameNode 出现故障宕机，那么其文件系统所管理的元数据将无法访问。

TDFS 的诞生

基于前文中提到的业务方面的瓶颈，星环科技推出了 TDFS --一个云原生，兼容 Hadoop 及更多生态，支持对象存储、文件系统，致力于打造高性能、强一致的分布式存储系统，其充分具备高扩展性、低成本、高可靠和高可用等特性。

为什么需要 TDFS

TDFS 提供了对以上问题的解法。TDFS 1.0 是 Rust 编写的新一代分布式文件系统，支持了分布式文件系统(Distributed File System）和对象存储系统（Object Storage）两个系统的特性。同时 TDFS 的元数据管理采用了新的分布式一致性协议，简化了元数据存储的架构的同时也减少了元数据 Editlog 的复制份数。TDFS 采用了全新的元数据存储数据结构，内存中可以存放 10 倍于 HDFS 元信息数据的同时，还可以将较冷的元数据信息识别并利用硬盘进行存放，有效解决文件存储数量因为内存不足受到的限制。

以下是 TDFS 支持的主要核心能力：

●海量存储— TDFS 提供无上限文件元数据存储，无单点瓶颈。充分满足客户海量大数据存储与分析的需求的同时可以有效提高资源利用率，确保数据高可用。

●安全可靠— 基于分布式架构技术，TDFS 提供数据多副本冗余存储，确保数据的持久性以及服务的可用性。

●数据管理 — TDFS 提供文件目录结构，支持数据批量导入和导出的时候以文件形式进行数据交换。

●兼容生态— 基于分布式存储架构，TDFS 在通信协议上兼容 HDFS 协议，可直接替换 NameNode，支持对 TDH 的热升级，兼容 Hadoop 生态。

●稳定性 — 由 Native 语言编写，性能平滑，没有 GC 带来的突发性性能波动。

●高性能 — TDFS 支持用户快速的进行创建目录、目录存取，检索、查看目录下的统计信息及进行权限管理等操作。此外，TDFS 有着更高的并发度，单个存储对象的操作也更快。

TDFS 全方位满足了企业对存储性能、容错性、服务成本等多方面的需求，有效适用于对海量数据进行存储实时计算、即时查询、综合检索和数据分析等主流业务场景，在海量大数据的存储、查询和计算中作为数据源以支持满足不同的大数据计算与存储分析场景需求。

关于 TDFS 是如何实现这些功能的，我们将会在《星环科技分布式文件系统 TDFS 大揭秘（下）》中进行深入剖析。