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