这是我参与更文挑战的第9天，活动详情查看： 更文挑战
背景
这是Hadoop笔记系列的第三篇,昨天把底层MapReduce运行机制的笔记汇总了一下,今天整理一下一些零散的细节点.
零散笔记汇总
Hive
Hive是基于hadoop的一个数据仓库工具,处理能力强而且成本低廉,Hive是将结构化的数据文件映射为一张数据库表,提供类SQL语言,实现完整的SQL查询功能,可以将SQL语句转换为MapReduce任务运行,十分适合数据仓库的统计分析
- Hive采用行存储的方式(SequenceFile)来存储和读取数据,效率低:当要读取数据表某一列数据时需要先取出所有数据然后再提取出某一列的数据,效率很低,同时,它还占用较多的磁盘空间
- Hive 并不能够在大规模数据集上实现低延迟快速的查询,因为底层是运行Hadoop
- Hive 查询操作过程严格遵守Hadoop MapReduce 的作业执行模型，Hive 将用户的HiveQL 语句通过解释器转换为MapReduce 作业提交到Hadoop 集群上
- Hive 并不提供实时的查询和基于行级的数据更新操作。
- Hive 的最佳使用场合是大数据集的批处理作业，例如，网络日志分析
- 用户可以非常自由的组织 Hive 中的表，只需要在创建表的时候告诉 Hive 数据中的列分隔符和行分隔符，Hive 就可以解析数据
- Hive 中所有的数据都存储在 HDFS 中
Hadoop2中引入的activity-standy模式
Hadoop系列第一篇笔记中提到了一点,Hadoop的NameNode存在单点故障问题,这个指的是旧版本的Hadoop,在Hadoop2开始支持activity-standy模式----如果主NameNode失效，启动备用主机运行NameNode
Hadoop的不足
- 一个Job只有Map和Reduce两个阶段（Phase），复杂的计算需要大量的Job完成，Job之间的依赖关系是由开发者自己管理的
- ReduceTask需要等待所有MapTask都完成后才可以开始
- 时延高，只适用Batch数据处理，对于交互式数据处理，实时数据处理的支持不够
- 中间文件写到HDFS上面,必须一次一次在一个Map/Reduce步骤完成之后不必要地把数据写到磁盘上再读出，才能继续下一个节点，因为Map Reduce2个阶段完成之后，就算是一个独立计算步骤完成，必定会写到磁盘上等待下一个Map Reduce计算; 而Spark加入了更多内存Cache操作
HDFS数据块大小
HDFS(Hadoop Distributed File System)默认的最基本的存储单位是64M的数据块 HDFS中的文件是被分成64M一块的数据块存储的
fsimage文件
- fsimage文件,也即命名空间映像文件,是内存中的元数据在硬盘上的checkpoint，它是一种序列化的格式，并不能够在硬盘上直接修改
- 当元数据节点失败时，则最新 checkpoint的元数据信息从fsimage加载到内存中，然后逐一重新执行修改日志中的操作
- 从元数据节点就是用来帮助元数据节点将内存中的元数据信息 checkpoint 到硬盘上的
checkpoint的过程
- 从元数据节点通知元数据节点生成新的日志文件，以后的日志都写到新的日志文件中。
- 从元数据节点用 http get 从元数据节点获得 fsimage 文件及旧的日志文件。
- 从元数据节点将 fsimage 文件加载到内存中，并执行日志文件中的操作，然后生成新的 fsimage 文件。
- 从元数据节点奖新的 fsimage 文件用 http post 传回元数据节点
- 元数据节点可以将旧的 fsimage 文件及旧的日志文件，换为新的 fsimage 文件和新的日志文件(第一步生成的)，然后更新 fstime 文件，写入此次 checkpoint 的时间
- 这样元数据节点中的 fsimage 文件保存了最新的checkpoint的元数据信息，日志文件也重新开始，不会变的很大了
NameNode和Editlog
Namenode 存储 HDFS 的元数据。对于任何对文件元数据产生修改的操作， Namenode 都使用一个称为 Editlog 的事务日志记录下来 例如，在 HDFS 中创建一个文 件，Namenode 就会在 Editlog 中插入一条记录来表示；同样，修改文件的 replication 因子也将往 Editlog 插入一条记录。Namenode 在本地 OS 的文件系统中存储这个 Editlog。 整个文件系统的 namespace，包括 block 到文件的映射、文件的属性，都存储在称为 FsImage 的文件中，这个文件也是放在 Namenode 所在系统的文件系统上
checkpoint机制
Namenode 在内存中保存着整个文件系统 namespace 和文件 Blockmap 的映像。这 个关键的元数据设计得很紧凑，因而一个带有 4G 内存的 Namenode 足够支撑海量的文件 和目录。当 Namenode 启动时，它从硬盘中读取 Editlog 和 FsImage，将所有 Editlog 中的事务作用（apply)在内存中的 FsImage ，并将这个新版本的 FsImage 从内存中 flush 到硬盘上,然后再 truncate 这个旧的 Editlog，因为这个旧的 Editlog 的事务都已经作用在 FsImage 上了。这个过程称为 checkpoint。在当前实现中，checkpoint 只发生在 Namenode 启动时，在不久的将来我们将实现支持周期性的 checkpoint
