[大数据]2021-07-08

hadoop2.x和3.x的区别

不停机升级过程中有哪些不兼容的地方（namenode的editlog、datanode的块布局等）版本回滚会有啥问题？

当前滚动升级存在的问题记录在 Apache Hadoop Wiki 中，主要问题是 Edit Log 不兼容，无法进行滚动升级，
滚动升级的操作流程在 Hadoop 官方升级文档中有介绍，概括起来大致步骤如下：

1 .JournalNode升级，使用新版本依次重启 JournalNode
2. NameNode 升级

升级准备，生成 fallback fsimage 文件

使用新版本 Hadoop 重启 Standby NameNode，重启 ZKFC

做 failover，使升级后的 NameNode 变成 Active 节点

使用新版本 Hadoop 重启另一个 NameNode，重启 ZKFC

3.升级 DataNode，使用新版本 Hadoop 重启所有 DataNode 节点

4.做 Finalize，确认集群变更到3.2
在滚动降级中，当3.2版本的 NameNode 使用3.2版本 Hadoop 重启时，如果当前最新的 Fsimage 是3.2版本 NameNode 产生的，则2.7版本 Hadoop 重启 NameNode 会直接 Shutdown，原因是，3.2版本 Haodop 产生的 Fsimage 文件，2.7版本的 Hadoop 无法进行加载，这将导致如果升级中遇到问题想回滚的话，无法完成回滚操作。经过深入分析，我们发现有两个问题会导致这种情况出现。

第二个问题，由于 NameNode 对 StringTable 的修改导致了 Fsimage 的不兼容，目前该问题可以通过回滚 commit 进行解决，社区反馈修复也不是很必要，可以通过先升级到无该 commit 的版本，滚动升级稳定后，直接进行小版本升级，跨过这个不兼容特性。记录 ISSUE 为 HDFS-14831，总结起来，需要做 HDFS2.x 到 3.x 的滚动升级，需要关注这些 ISSUE，HDFS-13596，HDFS-14396，HDFS-14831，HDFS-14509。

hdfs写数据过程，写的过程中有哪些故障，分别会怎么处理？dataqueue和ackqueue如何交互的？ackqueue中的数据如何重新放回到dataqueue中？如何保证有序？写数据的过程中是一个个package写入并确认成功后再写下一个吗？不过不是，是怎么写的，除了错误如何恢复的？

那么问题来了，如果他们之间的一个datanode突然坏掉了怎么办。

1、如果传输过程中，有某个datanode出现了故障，那么当前的pipeline会被关闭，出现故障的datanode会从当前的pipeline中移除，剩余的block会继续剩下的datanode中继续以pipeline的形式传输，同时Namenode会分配一个新的datanode，保持replicas设定的数量。
2、关闭pipeline，将ack queue中的数据块放入data queue的开始。
3、当前的数据块在已经写入的数据节点中被元数据节点赋予新的标示，则错误节点重启后能够察觉其数据块是过时的，会被删除。
4、失败的数据节点从pipeline中移除，另外的数据块则写入pipeline中的另外两个数据节点。
5、元数据节点则被通知此数据块是复制块数不足，将来会再创建第三份备份。
6、客户端调用create()来创建文件
7、DistributedFileSystem用RPC调用元数据节点，在文件系统的命名空间中创建一个新的文件。
8、元数据节点首先确定文件原来不存在，并且客户端有创建文件的权限，然后创建新文件。
9、DistributedFileSystem返回DFSOutputStream，客户端用于写数据。
10、客户端开始写入数据，DFSOutputStream将数据分成块，写入data queue。
11、Data queue由Data Streamer读取，并通知元数据节点分配数据节点，用来存储数据块(每块默认复制3块)。分配的数据节点放在一个pipeline里。
12、Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。
13、DFSOutputStream为发出去的数据块保存了ack queue，等待pipeline中的数据节点告知数据已经写入成功。

spark比mapreduce快的原因

数据倾斜问题，怎么解决

一、绝大多数task执行得都非常快，但个别task执行的极慢。
二、原本能正常执行的Spark作业，某天突然爆出OOM（内存溢出）异常。观察异常栈，是我们写的业务代码造成的
1、增加jvm内存,这适用于第一种情况(唯一值非常少，极少数值有非常多的记录值(唯一值少于几千)),这种情况下,往往只能通过硬件的手段来进行调优,增加jvm内存可以显著的提高运行效率。

2、增加reduce的个数,这适用于第二种情况(唯一值比较多，这个字段的某些值有远远多于其他值的记录数，但是它的占比也小于百分之一或千分之一),我们知道,这种情况下,最容易造成的结果就是大量相同key被partition到一个分区,从而一个reduce执行了大量的工作,而如果我们增加了reduce的个数,这种情况相对来说会减轻很多,毕竟计算的节点多了,就算工作量还是不均匀的,那也要小很多。

3、自定义分区,这需要用户自己继承partition类,指定分区策略,这种方式效果比较显著。

4、重新设计key,有一种方案是在map阶段时给key加上一个随机数,有了随机数的key就不会被大量的分配到同一节点(小几率),待到reduce后再把随机数去掉即可。

5、使用combinner合并,combinner是在map阶段,reduce之前的一个中间阶段,在这个阶段可以选择性的把大量的相同key数据先进行一个合并,可以看做是local reduce,然后再交给reduce来处理,这样做的好处很多,即减轻了map端向reduce端发送的数据量(减轻了网络带宽),也减轻了map端和reduce端中间的shuffle阶段的数据拉取数量(本地化磁盘IO速率),推荐使用这种方法。

kafka的ack机制

简单点理解就是：

producer发送消息到leader收到消息之后发送ack
leader和follower之间同步完成数据会发送ack

实际上ack可以看做一种信号，用于消费者来确认消息是否落盘
1.重复写入场景，主要出现在我们我们ack应答机制用的-1的时候， 举个栗子，producer发送消息到broker, broker里leader、follower已经落盘，准备回应producer的时候，突然间这个leader挂了，ack没发出去，producer没收到确认收到的消息，这个时候，会重新选举出一个leader, producer会重新发消息到新的leader并落库, 这就造成了数据重复，试想如果kafka应用在给用户发奖励的场景， 给用户多发一份奖励，会怎么样呢？

这种的问题出现场景不多，解决方案目前来说我能想到的就只能是架构、运维层面优化，保持服务稳定。

2.重复消费场景，这种问题大多出现在ack应答机制设置为0或者1的情况，举个1的例子，某一个consume因消费过慢、网络问题或者无法消费，触发rebalanced（kafka集群的一个保护设定，用于剔除掉无法消费或者过慢的消费者

）, 此时数据会重新发到一个新的consume里消费，这时候就会出现重复消费的问题，根本上就是记录消费位置的offset因某种情况没有改变，消费进入死循环或者多次从同一个offset消费。试想，kafka应用在扣除用户金币的场景，多扣一次，又会怎么样呢？

重复消费问题的解决方案我们可以从下面的角度入手：

1确认consume的消费速度，过慢是不行滴
2幂等性，0.11版本及之后版本的kafka引入幂等，即无论向server发送多少次一样的数据，都会持久化一次，0.11版本之前的需要consume自己去做幂等逻辑，但幂等性也只能解决单次会话，单个分区数据重复问题，因为假如0.11版本之后你开启了幂等性，那么如果producer挂了，新起了一个producer时，会重新分配一个新的pid，之前的去重数据集合就会失效。这一点实际上也解决了，就是由消费组、主题、分区组成的唯一一个id， 重启之后这个凭借这个id可以找回pid，这里不详述，有需要自行搜索资料学习。
3通过kafka配置来尽可能的避免重复消费，这点网上有介绍，如果配置调优，有兴趣可以继续深入
4做好监控，无论是消息积压还是consume的消费速度等，如果可以，最好也能监控到offset的位置信息

hive的order by 和 sort by有什么区别

hive调优

Hive中的数据在哪存放，mysql的在哪存放

Hadoop中的小文件问题，怎么解决数据倾斜问题。Spark的架构。Spark提交一个任务的具体流程。划分stage是依据什么划分的。Rdd的五个特性。Stage的数量等于什么，等于宽依赖数量+1

Spark中的并行度等于什么

等于rdd的一个分区数

Kafka集群架构，其中一个节点挂掉怎么选主的。(zookeeper) zookeeper的选主策略