viewFS|AndrewCode

第一部分：问题是什么？为什么要引入它？

1. 背景：单点 NameNode 的“物理极限”

在 Hadoop 早期架构中，集群依赖单一的 NameNode 管理元数据（Metadata）。随着企业数据量从 TB 级增长到 PB 级，我们遇到了两个无法回避的物理瓶颈：

内存瓶颈 (Memory Limit)：
NameNode 需要将所有目录树和 Block 信息加载到堆内存中。经验值表明，100 万个 Block 大约占用 1GB 内存。当文件数达到数亿级别时，NameNode 需要几百 GB 内存。这会导致 Full GC 频繁，甚至直接 OOM 宕机。
吞吐瓶颈 (Throughput Limit)：
即使内存够用，单台 NameNode 处理 RPC 请求的能力（QPS）也是有限的。受限于全局锁（Global Lock），在高峰期成千上万个计算任务并发访问时，NameNode 响应会变慢，阻塞整个集群。

2. 引入 Federation 后的“新麻烦”

为了解决上述问题，社区推出了 HDFS Federation（联邦），允许在一个集群中部署多个 NameNode（如 ns1, ns2），分别管理不同目录。

但是，这给客户端带来了巨大的维护成本：

硬编码问题： 业务方 A 需要写 hdfs://ns1/data/logs，业务方 B 需要写 hdfs://ns2/user/hive。
迁移困难： 如果运维想把 /data 目录从 ns1 搬到 ns2，所有相关的业务代码都需要修改路径。这在跨部门协作中几乎是不可能的任务。

结论： 我们需要一个中间层，既能利用多 NameNode 的扩展性，又能给客户端提供一个统一的、不变的访问入口。这就是 ViewFS。

第二部分：引入之后怎么使用他？ (The How)

写作策略： 给代码，给配置。程序员最喜欢看实操配置。

ViewFS 的核心思想是**“客户端挂载表 (Client-side Mount Table)”**。它不需要额外部署服务，只需要在客户端修改配置文件。

1. 核心配置 (`core-site.xml`)

我们需要定义一个逻辑名称（比如 my-cluster），并将不同的逻辑路径映射到具体的物理 HDFS 地址。

XML

<configuration>
  <property>
    <name>fs.defaultFS</name>
    <value>viewfs://my-cluster/</value>
  </property>

  <property>
    <name>fs.viewfs.mounttable.my-cluster.link./user</name>
    <value>hdfs://ns1/user</value>
  </property>

  <property>
    <name>fs.viewfs.mounttable.my-cluster.link./data</name>
    <value>hdfs://ns2/data</value>
  </property>

  <property>
    <name>fs.viewfs.mounttable.my-cluster.link./tmp</name>
    <value>hdfs://ns3/tmp</value>
  </property>
</configuration>