xx客户大数据相关问题答疑

1、官方发布的补丁是否可以在CDH5.X上patch？

如果是cdh的包，需要在cdh官方给出相关补丁包，然后我们可以进行补丁操作。

如果是开源的包，是无法进行补丁操作的，因为cdh会对开源有些细节点的适配改掉，此改动有可能会影响组件间和组件对cdm的适配，有可能会出现找不到类等问题

2、是否支持CDH上安装Flink？a).流join，延迟数据处理方法？ b).flink sql 执行计划优化？c). flink 日志以taskmanager为单位打印，一个job运行于多个taskmanager，或多个job运行于一个taskmanager,如何收集一个job的日志？

CDH支持安装flink，需要单独的flink包。

流join

设置ttl：sql.ttl.min和sql.ttl.max超出ttl延迟的默认丢弃，代码可以通过设置AllowedLateness延缓丢弃时间

执行计划优化：

设置空闲状态保留时间因为flinksql中regu lar join inner 、 left 、 right 数据一直会存在状态中，可以使用ttl设置状态保留时间。

开启 MiniBatch 也就是微批处理，缓存到一定的数据量在处理，参数：table.exec.mini batch.enabled设置为ture，批量输出的间隔时间：

table.exec.mini batch.allow latency=5s，防止 OOM 设置每个批次最多缓存数据的条数 ，可以设为 2 万条：table.exec.mini batch.size=20000。（注意如果对超低延迟要求的不建议开启）（在flink1.12之前版本中开启Flink的miniBatch不会清理过期状态即设置了ttl无法清理过期状态，。

开启 LocalGlobal 原理是在原先的Aggregate分成两个阶段分别是Local+Global，类似于MapReducer的Combine+Reduce 处理模式。即第一阶段localAgg在上游节点本地积一批数据进行聚合操作并输出这次微批的增量值Accumulator，第二阶段将收到的Accumulator进行more合并得到最终的结果GlobalAgg。开启LocalGlobal能靠LocalAgg的聚合筛选部分倾斜数据，从而降低GlobalAgg热点起到提升性能的作用。因为他会先进行一次本地聚合，然后在进行全局聚合，可以坚守GlobalAgg的热点。开启LocalGlobal需要先开启MiniBatch。开启MiniBatch：table.exec.mini batch.enabled设置为ture，批量输出的间隔时间：table.exec.mini batch.allow latency=5s ；开启 LocalGlobal：table.optimizer.agg phase strategy=TWO_PHASE（聚合策略。默认 AUTO ，支持参数 AUTO 、TWO_PHASE( 使用 LocalGlobal 两阶段聚合 、 ONE_PHASE( 仅使用 Global 一阶段聚合）针对于普通聚合（SUM 、 COUNT 、 MAX 、 MIN 和 AVG ）有较好的效果。对于 DISTINCT 的聚合（如 COUNT DISTINCT 收效不明显，因为 COUNT DISTINCT 在 Local 聚合时，对于 DISTINCT KEY 的去重率不高，导致在 Global 节点仍然存在热点。

开启 Split Distinct ，为了解决COUNT DISTINCT 的热点问题，一般是改两层聚合（增加按 Distinct Key取模的打散层）（Flink1.9.0 版本开始，提供了 COUNT DISTINCT 自动打散功能， 通过HASH_CODE(distinct_key) % BUCKET_NUM 打散，不需要手动重写。）Split Distinct 开启方式（要结合 minibatch 一起 使用）：开启 Split Distinct：table.optimizer.distinct agg.split.enabled=true；第一层 打 散 的 bucket 数目：able.optimizer.distinct tagg.split.bucket num=1024；（Flink1.9.0版本及以上支持）

3、zookeeper：当zk的集群部署节点出现系统loadaverage飙升导致超过半数的zk服务节点异常，进而触发zk自己服务的不对外相应。这个时间内，在zk服务注册的临时节点在几十秒内被删除，有对该问题的优化或解决方案？

一般zk节点建议不要性能使用过度，如果多次出现此场景，建议如下：

a)      分析系统loadaverage多节点均飙升的异常情况，常稳环境一般情况下不建议性能波动短时间内超过30%-50%

b)      建议扩容zk至5节点，保证zk半数以上正常使用

c)      建议znode不要过于频繁的创建删除，zk是树形结构模型，此结构特点为读会快于写，此场景下不建议频繁写入和删除

d)      如果有业务单独在使用zk，建议单独部署组件给业务使用，以保证依赖zk的大数据平台组件运行正常

4、HDFS：服务强制停止后，出现block missing的解决办法？

出现block missing即表示hdfs上的块不存在了，并不是少于3份，因此很难恢复。因此，从根源谨防服务强制停止才是正确的处理方式，namenode采用ha架构的同时定期备份fsimage文件

出现此情况时，只能通过执行hdfs fsck /确认丢失的文件路径然后执行hdfs fsck [path-to-file] -delete删除后重新入数据

5、hive中小文件场景是否会有句柄数占用问题？如何优化小文件问题提升性能（不影响用户访问hive表）？

句柄数占用问题：理论上存在，当hdfs存在大量小文件时，单个节点（单个dn）上的小文件过多，此时如果针对此表进行了读写操作，就又可能存在此问题。主要原因是该节点句柄数不足导致打开文件句柄失败然后就会重试往其他datanode节点写数据，最终表现为写文件很慢或者写文件失败，但由于分布式的特点，大量访问的块一般情况下不会存在于单一的dn中，除非集群特别小，小文件特别多。否则此情况出现的概率较低

此问题解决办法：

a)      执行ulimit -a命令查看有问题节点文件句柄数最多设置是多少，如果很小，建议修改成640000

b)      执行vi /etc/security/limits.d/90-nofile.conf编辑这个文件，修改文件句柄数设置。

c)      重新打开一个终端，用ulimit -a命令查看是否修改成功，如果没有，请重新按照上述步骤重新修改

d)      重启出现问题的dn实例

小文件问题优化方案：（写入时操作，如果是sqoop或者其他的方式入库，需要根据实际情况调整，此处以mr为例。建议不要使用impala、presto等交互式查询组件进行入库）

1.     如果文件存储格式是orc格式的表

Orc的表合并小文件请使用：

Alter Table tableNmae [PARTITION (partition_key = 'partition_value'[,...])] CONCATENATE;

2.     其他格式表合并小文件

Create Table As Select (CTAS)，即用 hive 把数据从源表(含大量小文件)查出并插入到一张临时表，所有数据插入到临时表后，源表和临时表的表名互换即可。

insert overwrite table tb_name partition(p=xx) select * from tb_name where p=xx;

注意，你需要给 hive 会话添加下面的配置来控制小文件合并的条件：

set hive.merge.mapfiles=true;

set hive.merge.mapredfiles = true;

set mapreduce.input.fileinputformat.split.maxsize=256000000;

set mapreduce.input.fileinputformat.split.minsize=256000000;

set hive.merge.smallfiles.avgsize = 128000000;

set mapred.max.split.size=100000000;

set mapred.min.split.size.per.node=100000000;

set mapred.min.split.size.per.rack=100000000;

对于新业务，设置完参数直接运行sql即可。

上述参数都是客户端参数，在业务侧设置参数即可

6、hadoop集群部署：事前-高可用方案是怎么考虑的？

Namenode采用主备架构，在hadoop3.0还可以加入主备从架构。Hmaster、resourcemanager同样为主备架构。而hive等可采用负载均衡的架构，通过zk确定当前session访问的具体服务（伪随机）

7、hadoop集群部署：事中-列举可能会出现哪些线上故障（或者以往发生过的top 5），如何迅速解决？

a)      Nn启动超时：nn故障后快速查看nn日志，发现nn进入安全模式没有正常退出，原因是丢块超过阈值，此时进入原声页面确认块上报情况，并确认元数据正常后可通过后台命令退出安全模式，保证nn正常启动，后再针对原生页面显示的丢块情况进行详细处理

b)      HMaster启动失败报skip assigning xxx，it is on a dead but processed yet server：移走/hbase/WALs和/hbase/MasterProcWALs，重启后把移走的文件移回原位防止数据丢失

c)      Hive join操作报code2: Hive在执行join的时候，数据量小时会生成MapJoin，执行MapJoin时会生成localtask任务，localtask启动的jvm内存继承了父进程的内存。当有多个join执行的时候，启动多个localtask，如果机器内存不够，就会导致启动localtask失败。修改hive的配置“hive.auto.convert.join”为“false”或者调整loacltask内存hive.mapred.local.mem

d)      数仓开发同学在做数据开发时误将id字段映射到分区字段，运行sql产生千万级别文件，导致NameNode、DataNode、JournalNode、Sentry等服务内存使用暴增，服务出现问题；

处理：

* 增加组件内存，配置如下：

1）、NameNode内存修改为153600M

2）、DataNode内存修改为10240M

3）、Journalnode内存修改为3072M

4）、Sentry内存修改为10240M

* 删除有问题的表，删除HDFS上表目录。

* 开发规范

e)      两台journalnode频繁fullgc，导致namenode连接journalnode超时，namenode进程自动退出，Namenode服务启动较慢，因为两台namenode长期没有合并fsimage，且hdfs小文件过多，再启动的时候需要加载大量的元数据文件（edits），耗时较长。

处理：

* journalnode增加内存

* 小文件治理

* fsimage/edit文件合并情况监控

8、hadoop集群部署特殊情况：磁盘满 或者硬盘坏导致元数据或数据文件（含副本）损坏，怎么在尽量减少数据损失和减少恢复时间来进行恢复？

元数据损坏：当Standby NameNode存储元数据（命名空间）时，出现断电的情况，Standby NameNode启动失败，MD5文件会损坏。通过移除损坏的fsimage，然后启动Standby NameNode，可以修复此问题。Standby NameNode会加载先前的fsimage并重现所有的edits。

修复步骤：

移除损坏的fsimage。

rm -rf  ./fsimage_0000000000000096

启动Standby NameNode。

数据损坏：隔离dn或者修改“dfs.datanode.data.dir”，删除数据损坏文件所在磁盘在配置中的信息，隔离磁盘优先启动或者隔离节点，将此dn从hdfs-site.xml中剔除，然后重启hdfs即可

9、HDFS JournalNode 编辑目录（dfs.journalnode.edits.dir）下数据损坏（单节点损坏或所有节点数据损坏），如何恢复 HDFS？

单节点损坏

a)      停止HDFS服务。

b)      确认editlog没有损坏的JournalNode。

JournalNode的运行日志中无java.io.IOException: Can't scan a pre-transactional edit log错误日志，则为editlog没有损坏。

c)       拷贝正常JournalNode上的editlog到损坏的JournalNode节点上。

d)      查看dfs.journalnode.edits.dir的值，获取JournalNode上editlog的存储目录

e)      备份editlog损坏的JournalNode节点上的editlog。

f)       拷贝正常节点的editlog到异常节点。

g)      在异常节点修改拷贝后的文件属组。

h)      重启HDFS服务，启动成功。

所有节点损坏：

a)    找到重启前的主NameNode，进入其数据目录（查看配置项“dfs.namenode.name.dir”可获取），得到最新的FSImage文件的序号。

b） 查看各JournalNode的数据目录（查看配置项“dfs.journalnode.edits.dir”可获取），查看序号从第一部获取到的序号开始的edits文件，看是否有不连续的情况（即前一个edits文件的最后一个序号 和 后一个edits文件的第一个序号 不是连续的，如下图中的edits_0000000000013259231-0000000000013259237就和后一个edits_0000000000013259239-0000000000013259246就是不连续的）。

a)      如果有这种不连续的edits文件，则需要查看其它的JournalNode的数据目录或NameNode数据目录中，有没有连续的该序号相关的连续的edits文件。

b)      如果找不到连续的edits文件，需要查看fsimage文件后的编号后的editslog文件是否连续，如连续则说明丢失的未合并部分的数据（数据较新），如以合并则需要恢复至上一个fsimage周期，此周期后的数据需要重新入

10、Impala（或其他查询引擎）：查询计划优化；小文件合并问题；并发提升参数配置；

查询优化：impala执行计划，分为3个粒度去看：explain、summary、profile。
explain查看具体执行计划阶段，有各阶段执行所需内存和读取数据大小，summary可以查看各阶段的具体指标，比如最大时间和平均时间，两者相差较大说明存在数据倾斜。profile可以判断查询是IO消耗型的，CPU 消耗型的， 网络消耗型的， 或者受性能低下节点的影响， 从而可以检查某些推荐的配置是否生效等。另外还有一些其他优化手段：compute stats、分区、文件格式（parquet）、避免小文件、最小化的客户端传输开销。

小文件合并参考hive小文件合并，impala自身对小文件的处理度并不高，自己优化小文件的能力较差，建议使用impala读取，但是写入和处理不建议使用impala

并发提升参数配置：

①mem_limit，内存不足会导致并发失败。
②control_service_queue_mem_limit，CDH6.2.0开始引进了一个新的impalad命令行参数，这个参数的默认值是50MB。其目的是把执行查询时的控制命令从原来的数据流里剥离出来，从而避免不必要的延时甚至阻塞。