我正在hdfs上设置分布式hbase,并试图了解系统在读操作期间的行为。
这就是我如何理解读取操作的高级步骤。
客户机连接到namenode以获取包含他感兴趣的行的副本的datanode列表。
从这里客户端缓存datanode列表并开始直接与所选datanode对话,直到它需要来自其他datanode的其他行,在这种情况下,它会再次询问namenode。
我的问题如下:
谁选择了要联系的最佳副本数据节点?客户如何选择“最接近”的副本?namenode是否按排序顺序返回相对datanode的列表?
当客户端切换到另一个已请求行的datanode时,有哪些场景(如果有的话)?例如,如果其中一个datanode过载/变慢,那么客户机库是否能够从namenode返回的列表中找到另一个datanode?
是否有可能从其中一个副本获取过时数据?例如,客户机获取了数据节点列表并开始从其中一个节点读取数据。同时,另一个客户端向namenode发出一个写请求。我们有dfs.replication==3和dfs.replication.min=2。namenode在3个节点中的2个节点上刷新到磁盘后,是否认为写入成功,而第一个客户端正在从第3个节点读取数据,并且不知道(尚未)还有另一个写入操作已提交?
hadoop在支持hbase时是否保持相同的读取策略?
谢谢您
1条答案
按热度按时间vx6bjr1n1#
谁选择了要联系的最佳副本数据节点?客户如何选择“最接近”的副本?namenode是否按排序顺序返回相对datanode的列表?
客户是决定最好联系谁的人。它按以下顺序挑选:
文件在同一台机器上。在这种情况下(如果配置正确),它将短路datanode并直接转到文件作为优化。
文件位于同一机架中(如果配置了机架感知)。
文件在别的地方。
当客户端切换到另一个已请求行的datanode时,有哪些场景(如果有的话)?例如,如果其中一个datanode过载/变慢,那么客户机库是否能够从namenode返回的列表中找到另一个datanode?
没那么聪明。如果它认为datanode坏了(意味着它超时了),但在我所知道的任何其他情况下,它都会切换。我相信它只会转到列表中的下一个节点,但它可能会再次联系namenode——我不是100%确定。
是否有可能从其中一个副本获取过时数据?例如,客户机获取了数据节点列表并开始从其中一个节点读取数据。同时,另一个客户端向namenode发出一个写请求。我们有dfs.replication==3和dfs.replication.min=2。namenode在3个节点中的2个节点上刷新到磁盘后,是否认为写入成功,而第一个客户端正在从第3个节点读取数据,并且不知道(尚未)还有另一个写入操作已提交?
陈旧的数据是可能的,但不是在你描述的情况下。文件只写一次并且是不可变的(除了append,但是如果不需要的话就不要append)。namenode在文件完全写入之前不会告诉您文件在那里。在这种情况下,附加,羞愧你那么。从主动附加到本地文件系统上的文件中读取数据的行为也是不可预测的。在hdfs中也应该有同样的结果。
一种可能发生过时数据的方法是,如果检索块位置列表,并且namenode决定在访问它之前同时迁移这三个位置。我不知道那里会发生什么。在使用hadoop的5年中,我从来没有遇到过这个问题。即使在工作的同时运行平衡器。
hadoop在支持hbase时是否保持相同的读取策略?
hdfs对hbase没有特殊处理。有人谈论使用hbase的自定义块放置策略来获得更好的数据局部性,但这还没有定论。