Q1：集群线上扩容如何达到自动化？线上扩容，规模正常都是以10+以上，如果都以课堂所示，人肉操作，时间投入与产出比不匹配，人力造成很大的不必要浪费，想学习老师线上集群实际扩容的方案。

A:课堂所示兼顾了小白同学，所以是手把手纯人肉搭建，产线环境扩容数量少则几十多则上百，人肉肯定不行，我们公司的运维分为IAAS运维、大数据运维、应用运维，大数据运维工程师在扩容集群时，需要向IAAS运维工程师以工单的方式申请服务器并提出自己的需求，IAAS运维工程师在提供服务器时不管是新采购服务器还是其他集群退役的服务器都需要重装系统，重装系统的镜像是针对大数据定制的，镜像包含了大数据运维工程师的通用需求以及安装操作系统后的网络、磁盘以及其他设置，比如关闭防火墙、时钟同步、同构磁盘挂载、关闭大透明页、关闭SWAP、公用YUM源、禁用SELinux等模式化操作，大数据运维工程师收到服务器后准备工作基本准备完毕了，进行少量准备工作就可以直接进入了CM可视化批量安装模式，比如脚本批量设置hostname、脚本同步/etc/hosts文件等；当然如上所说的IAAS操作，如关闭防火墙、时钟同步、同构磁盘挂载、关闭大透明页、关闭SWAP、公用YUM源、禁用SELinux都可以脚本化，无非就是使用SSH通讯方式的设置，这就需要大数据运维同学熟练使用shell了。

Q2：已知一个HDFS的目录，想知道此目录下的文件数，而且存储于哪些DataNode节点上。

A:1.查看文件数使用count命令，如下查看/ops目录，目录数为，文件数为万+，总文件大小为9.7P

2.查看/ops/test目录下的文件存储的位置hdfsfsck/ops/test-files-blocks-locations-racks

Q3：DataNode单节点，存储容量大小与当前节点上的CPU，内存硬件之间有什么样的关系，磁盘扩容很容易，但这不意味着单节点上数据盘就可以无限地扩容，因此在这方面，有什么实际线上的经验分享，即这三者间可以遵循怎样合适的关系

A:从我们内部实践来说没有发现三者之间的规律，因为大数据业务每个公司都不一样，有的计算是CPU密集型的，有的计算是内存密集型的、有的计算是IO密集型的；我们的服务器都是中高配置，每个服务器的磁盘是4Tx10、CPU24core、G内存

Q4：老师线上+规模集群，抛开一些其它组件集群，仅讨论HDFS数据存储集群，保守理应也在有节点左右，想知道这些存储节点只是单集群NameNode集群来维护吗？还是多集群独立维护的，如果是多集群存储数据，它们之间数据是如何打通进行关联的？如果仅是一个集群的话，我想知道这个集群的NameNode上面的配置，是如何Hold住这些数据DataNode的？

A:我们的集群也是用的Cloudera公司的，我们付了费用，Cloudera没有保障说CM能够纳管节点以上的集群，再加上我们的机房有容量限制，所以我们是建了多套集群，最大集群有+节点，最小集群也有+节点；+datanode下，namenode是可以支撑的，像一些互联网大厂，字节跳动、京东等他们的单集群规模有上万节点，此时就需要对hdfs进行深度定制了，他们改了很多源码，而且有+高级技术维护人员；4多集群建设要考虑业务情况，比如我们公司有10个以上业务，5大核心集群，按业务相关情况划分集群，不过也难免有跨集群的作业，目前公司内部自主研发了大数据采集交换平台，你也可以使用distcp进行数据对拷，目前我们也正在准备研发多集群并行混算平台。

Q5：HDFS存储节点上的数据，存储压缩格式是如何选取的，默认采用哪种文件存储类型与存储格式，冷热数据如何界定的？

A:我们产线环境用了gz和snappy压缩格式，gz用于不常用的冷数据，snappy用于热数据；冷热数据是跟业务相关的，后续集群治理的课程中也有冷热数据的区分。

Q6：课堂上看到HDFS集群的DataNode与HBASE是集成在一起部署的，我好奇，HBase面向的都是高频率读写的业务，老师确定部署一起后，线上业务没有出现过问题吗？

A:你应该是理解错了，HBase不能跟YARN在一起部署；HBase需要跟HDFS部署在一起的，这样可以利用数据的本地性提升IO性能，并且可以降低网络延迟，降低带宽负载。

Q7：Yarn集群计算层，目前集群面向用户使用群体少，故白天仅是数据写入，集群CPU资源都较为存在大量冗余状态，但对于凌晨执行集中高频提交跑批作业计算任务时，集群的CPU资源明显不够，甚至引起节点CPU负载过高导致节点的宕机，从而造成集群雪崩。简单来说，白天集群资源使用率在5%，凌晨执行高频跑批作业任务时，资源使用率上到%，引起集群宕机。在不增加资源的前提下，资源老师会如何划分队列？

A:这个划分队列无法解决根本问题，建议将业务划分优先级，错开时间执行。

Q8：某一台CDH物理机12块RAID0硬盘，如果其中有4块RAID0硬盘同时损坏,请问接下来大数据运维人员的详细处理流程是什么？

A:HDFS有个参数

dfs.datanode.failed.volumes.tolerated，值为0的时候表示当有任何损坏后datanode则停止服务，如果4快盘同时损坏了，此时datanode进程已经停止了，你可以修改hdfs-site.xml配置文件将损坏的磁盘路径去掉，重启datanode即可，然后进入磁盘报修流程，待磁盘更换后，停止datanode，在hdfs-site.xml配置文件中假如新的磁盘，启动datanode即可。

第一个方案：修改磁盘后，节点退役，重新服役

第二个方案：同一个节点磁盘间按空闲比率写数据，空闲比率高的有先写

Q9：CDH如果为开发人员提供HIVESERVER2服务，可以让开发人员通过beeline命令访问?

A:是的，beeline使用JDBC协议来连接HIVESERVER2

Q10：在晚高峰期HDFS集群会出现某些datanode不稳定的情况，频繁有datanode脱离节点,该如何处理呢？

A:需要找到datanode的具体原因，datanode相对来说还是比较稳定的，需要看下是否是GC问题，如果是的话适当调大内存，再看下最大的打开文件数或进程数的限制是否太小

1）查看jvm是否有频繁fullgc，如果有调大jvm内存

2）查看datanode是否在做df-sk来统计存储大小，如果管理的block太多的话可能卡死；如果是说集群中小文件过多，需要解决小文件的问题，参考集群治理中的HDFS画像

3）查看此节点上是否运行了过多的作业导致节点负载很高，如果是1如果整个集群资源是否负载过高，如果能扩容则扩容2优化占资源高的作业，这样会整体降低资源负载，参考集群治理中的作业画像3整个集群资源是否负载不是很高，nodemanage虚拟核数于集群的CPU核数比率调低

4）建议不重要的作业错峰运行

Q11：CDH集群扩容10抬起机器后，新加入的Datanode角色数据相对较少，如何处理HDFS的数据分布不均衡的现象呢?

A:在内存占用较低的节点上启动balancer脚本，将HDFS中所有节点的存储值中的最低值和平均值的差值设置为5%。命令：./start-balancer.sh-threshold5

Q12：CDH监控项从某种角度来说并不是很细粒度，老师课上可能时间有限等原因只是稍微提了一下监控思路，请问您线上是如何监控的呢，能将详细步骤给我们刨析一下吗?

A:目前我们产线环境还是以CDH监控为主，CDH的指标还是挺多的，只不过保留的周期不长，对于排障来说基本够用了，当然我们会推进一些监控工具，不过在课堂不会展开细讲，后续有Flink监控方面的实战。

Q13：如何基于CDH集群监控大量的小文件的呢？衡量小文件标准，以及出现大量小文件在生产环境该如何解决呢?

A:CM解决不了大量小文件的监控，需要额外做其他工作，这块在集群治理的HDFS画像里面我们会详细讲；对于怎么衡量小文件的标准，你可以简单认为小于blocksize的文件就是小文件，但是在企业真实情况下小文件问题可能更加严重，比如大量10M、几十M以下的文件，单纯技术无法解决问题，需要组织协同，这个在集群治理里面我们会详细讲。

Q14：之前上课只是大致提了一下YARN资源调度，生产环境使用CDH如何配置YARN资源队列调度，咱们后续的课程还会讲吗？

A:这个会讲解的，也会讲解我们产线环境是如何划分队列的。

Q15：CDH如何对HDFS各级目录做权限管理，目录的配额(即使用HDFS的容量限制)限制呢?

A:HDFS可通过ACL精细控制目标权限，除了ACL后续我们也会讲sentry；目前我们产线环境没有做容量配额限制，怕影响生产，我们通过集群治理来解决容量问题，集群治理是我们的课程内容之一，后续会讲解

Q16：Hdfs,Yarn,MapReduce,Hive,

Spark,Storm,Kafka,Flink

这些组件您在生产环境的调优参数是如何配置的，后续会为我们分享一些调优参数及说明么?我们也方便对照自己的集群作为参考适当调整。

A:HDFS可通过ACL精细控制目标权限，除了ACL后续我们也会讲sentry；目前我们产线环境没有做容量配额限制，怕影响生产，我们通过集群治理来解决容量问题，集群治理是我们的课程内容之一，后续会讲解

Q17：后期的大数据组件监控项目是针对课上所有的组件进行监控的么？还是只是分享监控思路，代码能给我们学院吗？

A:大数据组件监控主要在CM上进行监控，后续有集群治理案例实战，实战代码可以给学员的。

Q18：生产环境中重启HDFS集群时时间过程，每次重启都导致40分钟左右才能启动成功，需要调优什么参数让NameNode快一点变为Active呢？为什么调优这些参数后会导致NameNode启动加快呢?

A:HDFS重启流程：加载fsimage文件-加载editlog日志-根据情况判断是否做checkpoint-等待block汇报

1、如果fsimage太大也会延长加载时间，导致启动过慢，如果果太大说小文件太多，需要治理小文件

2、checkpont周期太长的话会导致启动的时候重放太多editlog日志，建议checkpoint周期缩短

3、block汇报，这个一般时间较长

1）block过大导致，说明小文件过多，需要进行小文件治理

2)降低BlockReport时数据规模；NameNode处理BR的效率低主要原因还是每次BR所带的Block规模过大造成，所以可以通过调整Block数量阈值，将一次BlockReport分成多盘分别汇报，提高NameNode处理效率。可参考的参数为：dfs.blockreport.split.threshold，默认为1,,，当前集群DataNode上Block规模数处于,~,，建议调整为,；

3)当需要对全集群的DataNode重启操作，且规模较大（包括集群规模和数据规模）时，建议在重启DataNode进程之后将NameNode重启，避免前面的“雪崩”问题；

4）控制重启DataNode的数量；按照当前节点数据规模，如果大规模重启DataNode，可采取滚动方式，以每次15个实例,单位间隔1min滚动重启，如果数据规模增长，需要适当调整实例个数；

Q19：生产环境中我们有必要利用CM"图表生成器"来自定义图标形成仪表盘吗?如果有必要，官方提供的度量值太多了，您在是生产环境中都定义了哪些监控图标呢?

A:这个我们会在正式课中CM监控章节进行讲解，主要是主机以及各个组件的核心指标，当出现问题之后再去查看其他指标即可。

Q20：在录播视频中安装Spark,Hive选择依赖是HDFS，那什么情况下Spark,Hive需要依赖HBase呢?如果Spark和Hive依赖关系开始选择的是只依赖于自己HDFS，后期想要改成依赖HBase该如何操作呢?老师您能用大白话给我们解释一下这个依赖关系是干嘛的吗?

A:依赖就是想要使用Spark和Hive分析读取谁的数据，依赖HDFS就是使用使用Spark和Hive读取HDFS数据进行分析，依赖HBase就是使用使用Spark和Hive读取HBase数据进行分析。在实际的产线环境中很少使用Spark和Hive依赖HBase，大多时候都是依赖HDFS，即读取HDFS的数据进行分析。一般来说Spark程序读写HBASE的时候，程序中会写zk地址，通过zk的地址找到hbase,然后进行读写操作。

Hive读写hbase需要在建hive表的是在hive配置文件中增加zk信息写上hbase的连接信息；所以Spark和Hive来读写hbase数据的时候不要CDH选择以来。

Q21：为什么安装HDFSHA模式需要自定义一个nameservice的名称呢？为什么apacheHadoop不直接以VIP地址来解析呢，而是要在hdfs-site.xml配置中对象nameservice通过名称解析成相应的地址，如果采用VIP(比如keepalived)技术不是也可以实现主备切换么,那官方使用nameservice的优点在哪呢?

A:因为高可用集群中有两个NameNode，一个是ActiveNameNode，一个是StandbyNameNode，二者可能会发生主从切换，只有ActiveNameNode可对外提供服务，所以我们无法确定到底访问哪一个NameNode，所以需要一个nameservice供我们访问，当我们已nameservice访问NameNode时，客户端会自动判断哪个是ActiveNameNode，减轻了用户的成本。VIP应用运维是高可用方案，对NameNode还是太简单了，DataNode要同时跟两个NameNode建立连接，上报数据才能快速切换，而且NameNode主从切换的时候需要校验很多状态，比如EditLog是否同步等，使用VIP的话无法判断这些。

Q22：HDFS地上传和下载都是实际上都是client自己完成的，在课堂上老师说删除并不是client自己完成的，client将需要删除的元数据信息发送给NameNode，而后通过NameNode和DataNode心跳机制实现，前面的增删查的原理您都说了，那修改HDFS文件内容的原理能帮我们分析一些吗?或者带我们查看一下源码可以吗？

A:前面的课程中老师分享过一下源码，同学们觉得太难，后来老师就没有分享，本来源码分享不在我们的课程范围内，老师也不是平白无故阅读源码，需要的时候才看，比如修改HDFS文件内容老师就没看过。

Q23：MapReduce严格意义上没有组件名称，我理解它只是一个计算思想，那我们可以在YARN中看到MapReduce的计算过程的身影吗？具体在哪里看呢？

A:可以在YARN的WEBUI中查看运行过程以及运行指标，点进第一列可以查看。

Q24：现在随着云原生技术越来越普及，以CNCF组织为首的开源产品Kubernetes越发火爆，我们后期课程是否会讲解在Kubernetes集群中运行大数据组件呢？可以为我们提前爆料一些内容吗？

A:目前这款有打算讲解FlinkOnKubernetes的程序，可能会放到最后

Q25：生产环境调优HDFS集群参数后CDH该如何进行平滑重启呢？

A:请参考Q18。

Q26：如果发现现有集群出现数据倾斜，生产环境中HBase出现数据倾斜了该如何解决呢？出现数据倾斜的原因到底是什么，换句话说，导致数据倾斜的罪魁祸首到底是开发，运维还是软件自身缺陷呢？

A:导致数据倾斜的原因是因为rowkey设计的不合理，跟HBase本身关系不大，开发人员涉及的rowkey不合理，导致大量的rowkey写到了少量的regionserver中。如果正确的涉及rowkey需要根据业务情况而定，原则尽量让rowkey打散到regionserver中

Q27：生产环境RowKey该如何设计才合理呢，合理的设计RowKey后者就一定能避免数据倾斜吗？

A:这个我们在HBase组件运维的时候会讲解。

Q28：目前Hadoop官方都发布了哪些版本呢?如何区分Hadoop所有的发行版本中哪个是稳定版，哪个是测试版，哪个是长期支持版本呢?

A:可以查看官方文档的Latestnews，里面有具体说明，见如下方框中的stable就是稳定的意思，至于是不是长期支持版本需要看版本的特性，这个可能需要联系官方。

Q29：DataXceiver这个类的和DataNode有什么关系呢?网上查阅了相关资料，都说它和文件操作超预期有什么关系，但描述的都模棱两可，老师您能用大白话帮我们解答一下吗？

A:首先需要知道DataXceiverServer是什么，DataXceiverServer是DataNode上一个用于接收数据读写请求的后台工作线程，为每个数据读写请求创建一个单独的线程去处理，这里所说的线程就是DataXceiver。从源码上看DataXceiver实现了Runnable接口，说明它是一个线程，他包含DataXceiverServer通过查看DataXceiver的run方法，发现调用的就是DataXceiverServer的处理逻辑，即接收数据读写请求的后台工作线程就是DataXceiver，DataXceiverServer封装了处理逻辑。

Q30：老师，CDH6我们已经按照视频搭建完成了，一个HDFS,HBase集群能承担多大的压力如何测试呢?

A:HBase有自带的压力测试工具PerformanceEvaluation，具体可以查看网上的资料。

Q31：HDFS2.X和HDFS3.X的区别有哪些呢？我查看了很多博客写的都是"HDFS3.x支持删码"之类的，但在ApacheHadoop的changelog中并没有发现该类字样，这样应该在哪里看呢?

A:在官方文档可以看到。

Q32：最近大数据运维JD上写着"负责公司大数据平台和机器学习平台的运维工作",这两个平台是否就是咱们的CDH集群呢？能介绍一下啊机器学习平台的日常运维都有哪些吗?

A:按老师的理解都是hadoop平台的运维，不过还要具体看企业自身的情况。

Q33：请问一下，可以限制一个队列中container的数量吗?

A:假如队列中有核CPU,那么该队列最多可以同时运行个container，可以通过这个简单的转换进行限制。

Q34：老师您遇到YARN资源还剩很多(还剩下50%左右)，但是MapReduce任务就是卡着不动的场景吗？我把job并发度降低就好了。但原因在哪我依旧不知道...

A:这个要具体详细查看原因了，卡着不动不代表是整个集群资源的问题，可能是任务本身的数据倾斜，也可能是GC问题，也可能是任务所在的服务器负载过高，也可能是所在队列的资源问题。

YARN作业慢问题排查思路：

1.首先看作业所处的资源队列有没有资源

2.查看作业的哪些task运行慢：如果说某个task运行慢

1）是否是数据倾斜，如果有就是数据倾斜引起的，此时如果是hivesql，需求调整sql语句，避免数据倾斜

2）查看task所在集群的系统负载是否很高，如果是则进去这台主机查看高的原因，原因可能是此机器上运行了大量的task导致系统资源负载过高，还有就是某个task的jvm频繁进行垃圾回收导致系统负载过高

3.硬件问题

4.查看最近集群有没有变更（如：我们生产上遇到一个问题，大面积作业运行缓慢，因为最近扩容了50台集群，但是其他集群某些机器的host文件里面配置的这50台集群的host有问题）

5.查看RPC请求是否过慢

Q35：CDH是开源的产品，但是CM是要付费的呀，我们在生产环境中使用CM没有向cloudera公司交钱是否会收到律师函呢？但是不用CM我们又不知道如何管理(搭建，扩容，监控等)CDH集群了，如果公司不愿意交钱的话我们大数据运维该如何处理呢？

A:以后都没有免费的了，不原因交钱的话可以使用开源社区版，节点不多的话可以人肉运维，自搭建监控平台，节点多的话自己可以写脚本或借助自助化工具运维，比如ansible等。

Q36：老师，数据仓库到底是个什么东东呢？能给我们举个例子说明数仓的角色定位及功能吗？还有就是数据仓库是大数据运维工程师搭建还是大数据开发它们自建搭建呢？

A:数据仓库主要是大数据开发搭建的，数据仓库主要是根据采集的数据进行清洗、加工、汇总生成多维度的报表数据，给高层领导看到，运维人员不参与数据清洗、加工等工作，只负责hadoop平台搭建和运维；数据仓库是基于hadoop之上建立的。

Q37：之前回复得知，线上集群规模是以集群为粒度划分业务线，跨集群间数据也是需要交互，这种业务是如何根据集群来划分？还是说，它们之前数据的交互实时性不高？跨了集群的数据具体是如何能打通的？DistCp跨集群间的数据迁移也觉得它慢。根本无法满足要求。它可配置的参数也配置了。

A:实时性要求不好，我们机房有万兆带宽的专线，跨集群同步数据不会同步全量数据，在源端集群会先经过数据过滤，只传输需要并进行清洗过滤后的数据。

Q38：HDFSSHELL命令方式去监控HDFS文件信息这些，如前边就提问的查询文件数，Block块等，对于专业人士偶尔查询，还行，但对于一个外行的人，连如何登录服务器都不知道，但他就是想知道集群的使用情况，老师是如何将这种资讯汇报他们的，或者是收集方案？

A:我们将收集的数据写入ES，可以使用kibana制作报表。

Q39：DataNode节点间数据均衡这

个场景，大规模集群下必定会

存在低配置节点，如：CPU/

内存/数据盘，这里就仅聊数

据盘这个，如：A节点G，

B节点G，这种情况下，

是怎样均衡节点数据的？5%

值吗？这里怎么均衡都是无法

达到预期的均衡值呀，是直接

将A节点下线吗？又比如说同

一节点C，挂载了3块数据盘，

分别为，/mnt/a/10G,/mnt/

b/G,/mnt/c/G,这种

DataNode节点的均衡数据又

应该如何解决的，+规模

的HDFS应该也不会是3.x版本

吧？对于不支持DiskBanancer

的2.X版本，解决方案有吗？

A:首先异构磁盘确实会带来问题，没有绝对的均衡，节点间存储比率不超过5%算是均衡了；HDFS在写入时有两种选择卷（磁盘）的策略，一是基于轮询的策略（RoundRobinVolumeChoosingPolicy），二是基于可用空间的策略

（AvailableSpaceVolumeChoosingPolicy）

将这个配置

dfs.datanode.fsdataset.volume.choosing.policy为

org.apache.hadoop.hdfs.server.datanode.fsdataset.AvailableSpaceVolumeChoosingPolicy

Q40：NodeManager节点会将当前节点的DataNode实时上报给RescourceManager，但您之前说HDFS集群的唯一访问入口是NameNode，那是否每台NodeManager在收集本地的DataNode数据时都得访问NameNode获取呢？如果是的话也太浪费HDFS性能了吧，如果不是那是NodeManager是采用什么机制实现不经过NameNode就能获取一个DataNode的数据呢？

A:“NodeManager节点会将当前节点的DataNode实时上报给RescourceManager”,这个说法是不对的，应该是DataNode上报自己的block给NameNode，RescourceManager和NodeManager管的是资源而不是数据。当作业要读取hdfs数据的时候仅仅从NameNode上获取数据的位置，而不会获取数据本身，得到数据的位置后作业再去找DataNode获取数据本身

Q41：为什么重启YARN服务后，我们在RescourceManager的WebUI上就看不到之前的历史YARN日志了呢？难道这个日志是保存到内存中的吗？有什么办法重启YARN服务后，依旧可以看到重启YARN服务之前的日志呢？

A:日志不是保存本地磁盘或者HDFS上的，你可以截图来展示你的问题。

Q42：ElasticSearch和HDFS都是分布式文件系统，也都可以做数据存储和检索功能，也都是JAVA开源产品，为什么在大数据领域中HDFS比ES更火呢？

A:这两个组件没有可比性，应对的场景不一样，HDFS应用于海量数据存储，ES应用于全文搜索，在电商和搜索引擎用的多

Q43：开发人员在hive中创建的元数据表信息该如何实时监控呢？

A:可以使用阿里开源的Canal来实时读取Hive的元数据库mysql的binlog数据，达到实时监控表的变更操作。

推荐：使用FlinkCDC来实时获取Hive的元数据库mysql的变化。

Q44：HDFS的数据被删除没法直接被监控，企业中该如何避免开发人员误删除数据免得咱们运维背锅呢？

A:打开审计日志，并使用filebeat采集然后写入ES中，可以实时查询所有数据的操作。

Q45：大数据安全，权限管理，审计是否有一套完整的解决方案呢？

A:目前老师所知，没有一套完整方案，可能商业化产品有，大数据安全可以大概有边界网关的安全，比如云桌面、VPN等，其次是大数据组件自己的安全。

Q：HDFS跨集群的数据迁移，针对以下不同场景，都是仅考虑带宽问题吗？如何在跨集群迁移这个是体现出高效率办公呢？这个数据量级暂定在T吧，定太大那不现实，定太小，使用U盘就能拷贝了，也没有参考的意义。

2.1：同一运营商，不同机房迁移，如：阿里云北京机房迁移阿里云上海机房

2.2：不同运营商，如阿里云迁移腾讯云

2.3：本地物理机上云

A:老师也无法回答你这个问题，带宽层面只能说建设网络专线。

Q46：前面我的问题是想了解，冷热数据文件类型与存储压缩，是两个点，老师仅回复了压缩。压缩层，这个细想，它就仅与CPU挂钩，没有过多好探讨的，目前我好奇的是对于规模的集群文件存储类型的选择。ORC,TEXT,Parquert等这些，都是基于哪方面设计层的。

A:我们采集的数据格式是snappy,可以认为是ODS层；沉淀数据用的gz;

parquet不是不适合数仓，而是对数仓的特定分层来说优势没有体现出来，parquet是当只

转载请注明:http://www.aideyishus.com/lktp/2496.html