
参考答案:
因为高可用集群中有两个 NameNode,一个是 Active NameNode,一个是 Standby NameNode,二者可能会发生主从切换,只有 Active NameNode可对外提供服务,所以我们无法确定到底访问哪一个 NameNode,所以需要一个 nameservice 供我们访问,当我们已 nameservice 访问 NameNode 时,客户端会自动判断哪个是 Active NameNode,减轻了用户的成本。
IP 应用运维是高可用方案,对 NameNode 还是太简单了, DataNode 要同时跟两个 NameNode 建立连接,上报数据才能快速切换,而且 NameNode主从切换的时候需要校验很多状态,比如 EditLog 是否同步等,使用 IP 的话无法判断这些。
参考答案:
前面的课程中老师分享过一下源码,同学们觉得太难,后来老师就没有分享,如果大家有这个需求,后边老师可以再给大家查看一下源码,并教大家一些查看分析源码的方法,帮助大家在需要的时候有个更好的理解。本来源码分享不在我们的课程范围内,老师也不是平白无故阅读源码,需要的时候才看,比如修改 HDFS 文件内容老师就没看过。
参考答案:
可以在 YARN 的 WEB UI 中查看运行过程以及运行指标,点进第一列可以查看。
参考答案:
目前这期有打算讲解 Flink On Kubernetes 的程序,可能会放到课程后边结合实际的案例进行讲解,便于大家理解。
参考答案:
(1) 降低 BlockReport 时数据规模; NameNode 处理 BR 的效率低主要原因还是每次 BR 所带的 Block 规模过大造成,所以可以通过调整 Block 数量阈值,将一次 BlockReport 分成多盘分别汇报,提高 NameNode 处理效率。可参考的参数为: dfs.blockreport.split.threshold,默认为 1,000,000,当前集群DataNode 上 Block 规模数处于 240,000 ~ 940,000,建议调整为 500,000;
(2) 当需要对全集群的 DataNode 重启操作,且规模较大(包括集群规模和数据规模)时,建议在重启 DataNode 进程之后将 NameNode 重启,避免前面的“雪崩”问题;
(3) 控制重启 DataNode 的数量;按照当前节点数据规模,如果大规模重启DataNode,可采取滚动方式,以每次 15 个实例, 单位间隔 1min 滚动重启,如果数据规模增长,需要适当调整实例个数;
参考答案:
导致数据倾斜的原因是因为 rowkey 设计的不合理,跟 HBase 本身关系不大,这个我们在 HBase 组件运维的时候会讲解。
参考答案:
这个我们在 HBase 组件运维的时候会讲解。
参考答案:
可以查看官方文档的 Latest news,里面有具体说明,见如下方框中的 stable就是稳定的意思,至于是不是长期支持版本需要看版本的特性,这个可能需要联系官方。
参考答案:
首 先 需 要 知 道 DataXceiverServer 是 什 么 , DataXceiverServer 是DataNode 上一个用于接收数据读写请求的后台工作线程,为每个数据读写请求创建一个单独的线程去处理,这里所说的线程就是 DataXceiver。
从源码上看 DataXceiver 实现了 Runnable 接口,说明它是一个线程,他包含DataXceiverServer通过查看 DataXceiver 的 run 方法,发现调用的就是 DataXceiverServer 的处理 逻 辑 , 即 接 收 数 据 读 写 请 求 的 后 台 工 作 线 程 就 是 DataXceiver ,DataXceiverServer 封装了处理逻辑。
参考答案:
HBase 有自带的压力测试工具 PerformanceEvaluation,具体后边可以给大家分享一些实用的资料。需要的话也可以安排时间给大家讲解一下。