星环科技是一家致力于打造企业级大数据基础软件，围绕数据全生命周期为企业提供基础软件及支持的厂商。在这个数据驱动的数字化世界中，来自社交媒体、金融科技等不同领域的数据正在大幅度增长，例如大量商业报告、网页、图像和音视频等。如今，接近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大揭秘（下）》中进行深入剖析。