大数据学习之问题解决+经验+调优方法整理(持续更新)
文章目录
- 1 Hadoop
- 1.1 MapReduce执行速度过慢
- 1.2 Yarn节点负载不均衡
- 1.3 Yarn节点上任务数太多，资源利用率太高
- 1.4 Hdfs参数调优
- 1.5 目录配置
- 1.6 Hadoop宕机（项目遇到）
- 2 HBase
- 2.1 优化方法
- 3 Hive
- 3.1 Hive数据倾斜
- 3.2 Tez引擎
- 4 Mysql
- 4.1mysql utf-8 超过字节数
- 5 Redis
- 5.1 缓存穿透、缓存雪崩、缓存击穿
- 6 Kafka
- 6.1 消息数据积压，Kafka 消费能力不足怎么处理？
- 6.2 处理数据重复和数据丢失
- 6.3 Kafka挂掉（项目遇到的问题）
- 6.4 Kafka计算参数
- 7 Sqoop
- 7.1 Sqoop 导入导出 Null 存储一致性问题
- 7.2 Sqoop 数据导出一致性问题
- 7.3 Sqoop 数据导出 Parquet（项目中遇到的问题）
- 8 Flume
- 9 Azkaban
1 Hadoop
1.1 MapReduce执行速度过慢
1、自定义分区函数，让key值较为均匀的分布在reduce上。
2、对map端进行压缩处理。
3、使用combiner函数(可用于求合并，不可用于求平均)。
4、增加环形缓冲区的容量，100M->200M，阈值80%->90%。
1.2 Yarn节点负载不均衡
原因：一个心跳尽可能接受任务，优先发送心跳的节点把任务领光
解决：一般情况不会发生，任务数一般大于节点数
1.3 Yarn节点上任务数太多，资源利用率太高
控制节点数目，设置yarn.site.xml参数
mapreduce.map.memory.mb，内存大小
mapreduce.map.cpu.vcores，cpu个数
配置每个任务所需资源，确定节点上任务数目
1.4 Hdfs参数调优
1、Namenode有一个工作线程池，用于处理datanode心跳和元数据请求
dfs.namenode.handler.count=20*log2(集群数)
2、hdfs和硬盘的使用控制在70%一下
1.5 目录配置
编辑日志存储路径 dfs.namenode.edits.dir 设置与镜像文件存储路径 dfs.namenode.name.dir
尽量分开，达到最低写入延迟（提高写入的吞吐量）
一台服务器一般都有很多个硬盘插槽（插了几个插槽） 如果不配置 datanode.data.dir 多目录，每次插入一块新的硬盘都需要重启服务器
配置了即插即用
1.6 Hadoop宕机（项目遇到）
1、如果 MR 造成系统宕机。此时要控制 Yarn 同时运行的任务数，和每个任务申请的
最大内存。调整参数：yarn.scheduler.maximum-allocation-mb（单个任务可申请的最多物
理内存量，默认是 8192MB）
2、如果写入文件过量造成 NameNode 宕机。那么调高 Kafka 的存储大小，控制从 Kafka
到 HDFS 的写入速度。高峰期的时候用 Kafka 进行缓存，高峰期过去数据同步会自动跟上。
2 HBase
2.1 优化方法
1、减少调整
减少region分裂：通过RowKey进行预见分区
给HFile设定合适大小：memstore刷写生成HFile，HFile增加到一定程度时，同一个region的HFile会进行合并，合并后region大小大于设定的值，会进行分裂，产生I/O花销
2、减少启停
关闭Compation，闲时手动Compatition
需要写入离线大量数据时是用那个bulkload
3、减少数据了
开启过滤提高查询速度
使用压缩snappy+lzo
4、合理设计预分区，rowKey，列族
3 Hive
3.1 Hive数据倾斜
数据倾斜表现，reduce任务维持在99%，只有少量reduce未完成
数据倾斜原因，key分布不均，业务数据特性，建表问题，某些sql语句本身就有数据倾斜的问题
解决方案：
1、参数调整
hive.map.aggr=true，map端部分聚合相当于Combiner
hive.groupby.skewindata=true，有数据倾斜的时候进行负载均衡
两个MRjob，第一个输出结果集合随机发放，相同的Group by key也会分发到不同的reduce中；第二个MRjob在进行Group By Key分布。
2、如何join
小表驱动大表
在裁剪和filter操作
空值的key变成一个字符串+随机数，把倾斜的数据分发到不同的reduce上，因为最后也关联不上
3、group by/ count distinct 大量相同特殊值
如果数据量非常大，执行如 select a,count (distinct b) from t group by a; 类型的 SQL 时，会出现数据倾斜的问题。
解决方式：使用 sum…group by 代替。
3.2 Tez引擎
优点：Tez 可以将多个有依赖的作业转换为一个作业，这样只需写一次 HDFS，且中间节点较
少，从而大大提升作业的计算性能。
安装问题：运行Tez时检查到用过多内存而被NodeManager杀死进程问题(项目里遇到)
是关掉虚拟内存检查，修改 yarn-site.xml，在项目里我选这个，因为并不是真正的内存不足
yarn.nodemanager.vmem-check-enabled
false
4 Mysql
4.1mysql utf-8 超过字节数
Mysql 的 utf8 编码最多存储 3 个字节，当数据中存在表情号、特色符号时会占用超过 3个字节数的字节，那么会出现错误 Incorrect string value: ‘\xF0\x9F\x91\x91\xE5\xB0…’
解决办法：修改库的基字符集和数据库的排序规则，将 utf8 修改为 utf8mb4
5 Redis
5.1 缓存穿透、缓存雪崩、缓存击穿
1、缓存穿透：查询不存在的数据，缓存无法命中，每次去数据库查
解决：数据库查不到的空对象也可以缓存起来设置一个很短的过期时间，最长不超过5分钟
布隆过滤器，所有可能存在的数据hash到bitmap中，存在的数据一定不会被拦截，被拦截的数据一定不存在
2、缓存雪崩：缓存集中在同一时间失效，大部分查询落在数据库上
解决：失效时间不分布在同一个时间点
3、缓存击穿：key是热点，不听的高并发，key失效的瞬间，持续的并发穿破缓存，直接请求数据库
解决：设置key永不过期
6 Kafka
6.1 消息数据积压，Kafka 消费能力不足怎么处理？
1、如果是 Kafka 消费能力不足，则可以考虑增加 Topic 的分区数，并且同时提升消费
组的消费者数量，消费者数=分区数。（两者缺一不可）
2、如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取
数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。
6.2 处理数据重复和数据丢失
1、生产者数据重复
原因：broke由于网络问题“假死”，生产者发送消息没有收到正确的broke响应，导致producer重试
解决：
1、幂等性
enable.idempotence=true，ack=all 且 retries>1
2、ack = 0，发送之后不重试，但有可能丢失，适用于吞吐量指标重要性高于数据丢失，如日志收集
2、生产者数据丢失
原因：
1、ack=0，生产者发送完不重试
2、acl=1，leader写入成功后返回，follower没同步完leader就挂了
3、unclean.leader.election.enable=true，可以选取osr的节点成为leader
解决：
1、ack=all /-1,tries > 1,unclean.leader.election.enable : false
producer 发送消息完，等待 follower 同步完再返回，如果异常则重试。这是副本的数量可能影响吞吐量，最大不超过 5 个，一般三个足够了。不允许选举 ISR 以外的副本作为 leader。
2、配置：min.insync.replicas > 1，副本指定必须确认写操作成功的最小副本数
3、失败的offesr单独记录
3、消费者数据重复
原因：消费完数据没有及时提交offset到broker
解决：
1、取消自动自动提交
每次消费完或者程序退出时手动提交。这可能也没法保证一条重复。
2、下游做幂等
一般的解决方案是让下游做幂等或者尽量每消费一条消息都记录 offset，对于少数严格的场景可能需要把 offset 或唯一 ID, 例如订单 ID 和下游状态更新放在同一个数据库里面做事务来保证精确的一次更新或者在下游数据表里面同时记录消费 offset，然后更新下游数据的时候用消费位点做乐观锁拒绝掉旧位点的数据更新。
在下一级消费者中去重。（redis、SparkStreaming、hive 的 dwd 层）
6.3 Kafka挂掉（项目遇到的问题）
1、Flume Channel 可以缓存一段时间
2、日志服务器有30天的记录，可以重新跑
6.4 Kafka计算参数
1、Kafka 的吞吐量测试（测试生产速度和消费速度）
2、Kafka 内存为 6G（不能超过 6G）
3、Kafka 数量确定：2* 峰值生产速度（m/s）* 副本数 /100 +1=?
4、Kafka 中的数据量计算 每天数据总量 100g(1 亿条) 10000 万/24/60/60=1150 条/s 平均每秒钟：1150 条
低谷每秒：400 条 高峰每秒钟：1150*10=11000 条 每条日志大小： 1K 左右 每秒多少数据量：20MB
7 Sqoop
7.1 Sqoop 导入导出 Null 存储一致性问题
Hive 中的 Null 在底层是以“\N”来存储，而 MySQL 中的 Null 在底层就是 Null，为了
保证数据两端的一致性。在导出数据时采用–input-null-string 和–input-null-non-string 两个参
数。导入数据时采用–null-string 和–null-non-string。
7.2 Sqoop 数据导出一致性问题
原因：导出时部分map导出失败，部分成功，而此时成功的部分被查看到，由于出现失败，所有数据重新导入，此时看到的数据会与之前不一致。
解决：多个 Map 任务时，采用–staging-table 方式，仍然可以解决数据一致性问题。（临时表）
7.3 Sqoop 数据导出 Parquet（项目中遇到的问题）
Ads 层数据用 Sqoop 往 MySql 中导入数据的时候，如果用了 orc（Parquet）不能导入， 需转化成 text 格式
8 Flume
1、Flume配置内存为4G
2、FileChannel优化
通过配置 dataDirs 指向多个路径，每个路径对应 不同的硬盘，增大 Flume 吞吐量。 checkpointDir 和 backupCheckpointDir 也尽量配置在不同硬盘对应的目录中，保证 checkpoint 坏掉后，可以快速使用 backupCheckpointDir 恢复数据
3、Sink：HDFS Sink 小文件处理
这三个 参数配置 写入 HDFS 后会产 生小文件 ，hdfs.rollInterval，滚动时间
hdfs.rollSize，滚动大小
hdfs.rollCount，滚动次数
4、Ganglia 监控（项目中遇到的问题）
Ganglia 监控 Flume 发现发现尝试提交的次数大于最终成功的次数
（1）增加 Flume 内存
（2）增加 Flume 台数
9 Azkaban
1、每天集群运行多少 job?
2、多个指标（200）X 6=1200（1000-2000 个 job）
3、每天集群运行多少个 task? 1000 X（5-8）=5000 多个
4、任务挂了怎么办？（项目中遇到的问题）运行成功或者失败都会发邮件