hadoop名词解释
QJM and shuffle
1. QJM
1.1 背景
自从hadoop2版本开始，社区引入了NameNode高可用方案。NameNode主从节点间需要同步操作日志来达到主从节点元数据一致。最初业界均通过NFS来实现日志同步，大家之所以选择NFS，一方面因为可以很方便地实现数据共享，另外一方面因为NFS已经发展20多年，已经相对稳定成熟。
虽然如此，NFS也有缺点不能满足HDFS的在线存储业务：网络单点及其存储节点单点。业界提供了数据共享的一些高可用解决方案，但均不能很好地满足目前HDFS的应用场景。
| 方案 | 网络单点 | 存储单点 | 备注 |
|---|---|---|---|
| Mysql | HA | 无 | 无 |
| Drbd+heartbeat+NFS | 无 | 无 | 脑裂；数据有丢失风险 |
| Keepalive+NFS | 无 | 有 | 数据有丢失风险 |
为了满足共享日志的高可用性，社区引入QJM。QJM由cloudera开发，实现了读写高可用性，使HDFS达到真正的高可用性成为可能。
1.2 术语和定义
| 术语和定义 | 解释 |
|---|---|
| Epoch | 由主节点在启动及其切换为主的时候分配，每次操作JN节点均会检查该值,类似zookeeper中的zxid，此时主NameNode类似zookeeper中的leader，JN节点类似ZK中的Follower |
| JournalNode | QJM存储段进程，提供日志读写，存储，修复等服务 |
| QJM | Qurom Journal Manager |
| startLogSegment | 开始一个新的日志段,该日志段状态为接收写入日志的状态 |
| finalizeLogSegment | 将文件由正在写入日志的状态转化为不接收写日志的状态 |
| recoverUnfinalizedSegments | 主从切换等情况下，恢复没有转换为finalized状态的日志 |
| journalId | 日志ID，由配置指定，如qjournal://g42:8485;g35:8485;uhp9:8485/geminifs，则其中的geminifs即为journalId |
2. shuffle
作者：Lijie Xu 链接：https://www.zhihu.com/question/27643595/answer/127473409 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
-
从逻辑角度来讲，Shuffle 过程就是一个 GroupByKey 的过程，两者没有本质区别。 只是 MapReduce 为了方便 GroupBy 存在于不同 partition 中的 key/value records，就提前对 key 进行排序。Spark 认为很多应用不需要对 key 排序，就默认没有在 GroupBy 的过程中对 key 排序。
»