NameNode是HDFS吞吐量的瓶颈吗？
Is NameNode the bottleneck of HDFS throughput?
在HDFS中，每次读写都必须通过NameNode来获取关于数据存储位置的metaDate。这样的系统如何扩展？ NameNode会不会成为整个系统的瓶颈？
Namenode 确实成为瓶颈，但并不像看起来那么容易。 Namenode保存元数据，一旦client say for read从Namenode获取到block location，就不需要再去namenode读取，直接连接datanodes读取，无需NN干预。
至于写入，客户端确实首先去 Namenode 在命名空间树中创建一个条目，然后让数据节点将数据写到哪里，一旦它有了数据节点位置，它就会只与数据节点对话，它会返回仅在需要另一个块时才发送到 Namenode。因此，在大多数情况下，客户端只会使用数据节点，它会在非常短的时间内转到名称节点。
Namenode 上的读取调用（比如获取块位置）都是并行处理的，只有写入调用不是并行处理的（比如获取要写入的新块）。在正常的生产中，读取负载通常在 60:40 左右，因此这确实可以扩展并且运行良好。
最近增加了一类Namenode，叫做Observer Namenode，可以服务所有的Read请求，集群中可以有N个Observer Namenode...
如果你想了解 Observer Namenodes，可以在这里阅读：
https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/ObserverNameNode.html
在HDFS中，每次读写都必须通过NameNode来获取关于数据存储位置的metaDate。这样的系统如何扩展？ NameNode会不会成为整个系统的瓶颈？
Namenode 确实成为瓶颈，但并不像看起来那么容易。 Namenode保存元数据，一旦client say for read从Namenode获取到block location，就不需要再去namenode读取，直接连接datanodes读取，无需NN干预。 至于写入，客户端确实首先去 Namenode 在命名空间树中创建一个条目，然后让数据节点将数据写到哪里，一旦它有了数据节点位置，它就会只与数据节点对话，它会返回仅在需要另一个块时才发送到 Namenode。因此，在大多数情况下，客户端只会使用数据节点，它会在非常短的时间内转到名称节点。
Namenode 上的读取调用（比如获取块位置）都是并行处理的，只有写入调用不是并行处理的（比如获取要写入的新块）。在正常的生产中，读取负载通常在 60:40 左右，因此这确实可以扩展并且运行良好。
最近增加了一类Namenode，叫做Observer Namenode，可以服务所有的Read请求，集群中可以有N个Observer Namenode...
如果你想了解 Observer Namenodes，可以在这里阅读： https://hadoop.apache.org/docs/current/hadoop-project-dist/hadoop-hdfs/ObserverNameNode.html