【问题标题】：Reading operations on hadoop and consistency levelhadoop 和一致性级别上的读取操作
【发布时间】：2014-07-24 21:24:39
【问题描述】：
我正在 HDFS 上设置分布式 HBase，并试图了解系统在读取操作期间的行为。
这就是我理解读取操作的高级步骤的方式。
- 客户端连接到 NameNode 以获取 DataNode 列表，其中包含他感兴趣的行的副本。
- 客户端从这里缓存 DataNode 列表并开始直接与选择的 DataNode 对话，直到它需要来自其他 DataNode 的其他行，在这种情况下它会再次询问 NameNode。
我的问题如下：
- 谁选择最好的副本DataNode联系？客户端如何选择“最接近”的副本？ NameNode 是否按排序顺序返回相关 DataNode 列表？
- 当客户端切换到另一个已请求行的 DataNode 时，会有哪些场景（如果有）？例如，如果其中一个 DataNode 变得过载/缓慢，客户端库能否从 NameNode 返回的列表中找出联系另一个 DataNode？
- 是否有可能从其中一个副本中获取过时数据？例如，客户端获取 DataNodes 列表并开始从其中一个读取。与此同时，另一个客户端向 NameNode 发出了写请求。我们有 dfs.replication == 3 和 dfs.replication.min = 2。NameNode 认为在 3 个节点中的 2 个上刷新到磁盘后写入成功，而第一个客户端正在从第 3 个节点读取并且不知道（还）还有另一个写入已提交？
- Hadoop 在支持 HBase 时保持相同的读取策略？
谢谢
【问题讨论】：
标签：
hadoop
hbase
consistency
【解决方案1】：
谁选择了最好的副本 DataNode 来联系？客户端如何选择“最接近”的副本？ NameNode 是否按排序顺序返回相关 DataNode 列表？
客户是决定与谁联系的最佳人选。它按以下顺序选择它们：
- 文件在同一台机器上。在这种情况下（如果配置正确），它将使 DataNode 短路并直接进入文件作为优化。
- 文件在同一个机架中（如果配置了机架感知）。
- 文件在其他地方。
当客户端切换到另一个已请求行的 DataNode 时，会有哪些场景（如果有）？例如，如果其中一个 DataNode 变得过载/缓慢，客户端库能否从 NameNode 返回的列表中找出联系另一个 DataNode？
这不是那么聪明。如果它认为 DataNode 已关闭（意味着它超时），但在我所知道的任何其他情况下，它都会切换。我相信它只会转到列表中的下一个，但它可能会再次联系 NameNode——我不是 100% 确定。
是否有可能从其中一个副本中获取陈旧数据？例如，客户端获取 DataNodes 列表并开始从其中一个读取。与此同时，另一个客户端向 NameNode 发出了写请求。我们有 dfs.replication == 3 和 dfs.replication.min = 2。NameNode 认为在 3 个节点中的 2 个上刷新到磁盘后写入成功，而第一个客户端正在从第 3 个节点读取并且不知道（还）还有另一个写入已提交？
过时的数据是可能的，但不是在您描述的情况下。文件是一次写入且不可变的（除了追加，但如果不需要，不要追加）。 NameNode 在文件完全写入之前不会告诉你文件在那里。在追加的情况下，那么你会感到羞耻。从本地文件系统上的主动附加到文件中读取的行为也是不可预测的。在 HDFS 中您应该期待同样的结果。
可能发生陈旧数据的一种方法是，如果您检索块位置列表，并且 NameNode 决定在您访问它之前一次迁移所有三个位置。我不知道那里会发生什么。在使用 Hadoop 的 5 年中，我从来没有遇到过这个问题。即使在做事的同时运行平衡器。
Hadoop 在支持 HBase 时保持相同的读取策略？
HDFS 不会对 HBase 进行特殊处理。有人谈论 using a custom block placement strategy with HBase 以获得更好的数据局部性，但那是在杂草中。