Hadoop (读写，小文件)

hadoop
历史
	2002年10月，Doug Cutting和Mike Cafarella创建了开源网页爬虫项目Nutch。
	2006年2月，Apache Hadoop项目正式启动以支持MapReduce和HDFS的独立发展。
	2006年11月，Google发表了Bigtable论文，激起了Hbase的创建。
	2009年7月 ，MapReduce 和 Hadoop Distributed File System (HDFS) 成为Hadoop项目的独立子项目。
	2012年3月，企业必须的重要功能HDFS NameNode HA被加入Hadoop主版本。
	2012年8月，另外一个重要的企业适用功能YARN成为Hadoop子项目。	
	2014年2月，Spark逐渐代替MapReduce成为Hadoop的缺省执行引擎，并成为Apache基金会顶级项目。
核心组件
	1.	hadoop通用组件 - Hadoop Common
		包含了其他hadoop模块要用到的库文件和工具
	2.	分布式文件系统 - Hadoop Distributed File System (HDFS)
		运行于通用硬件上的分布式文件系统，高吞吐，高可靠
	3.	资源管理组件 - Hadoop YARN
			于2012年引入的组件，用于管理集群中的计算资源并在这些资源上调度用户应用。
	4.	分布式计算框架 - Hadoop MapReduce
			用于处理超大数据集计算的MapReduce编程模型的实现。
	5.	Hadoop Ozone: An object store for Hadoop.
	6.	Hadoop Submarine: A machine learning engine for Hadoop
架构目标
	硬件错误
		c)	错误检测和快速自动恢复
	流式数据
	大规模数据集
	简单一致性
		一次写入多次读取
	计算向数据移动
	平台可移植性
角色
	NameNode
		管理文件系统的命名空间
			1 文件和目录的元数据：(运行时，元数据放内存)
				1 文件的block副本个数
				2 修改和访问的时间
				3 访问权限
				4 block大小以及组成文件的block信息列表
			2 以两种方式在NameNode本地进行持久化：
				1 命名空间镜像文件（fsimage）
				2 编辑日志（edits log）。
		存储结构
			dfs.namenode.name.dir
				| --current
				|		| -- version
				|		|		VERSION文件是一个Java的属性文件
				|		|			nameSpaceId
				|		|				该文件系统的唯一标志符，当NameNode第一次格式化的时候生成
				|		|			clusterId
				|		|				HDFS集群使用的一个唯一标志符
				|		|			cTime
				|		|				当前NameNode创建的时间，刚格式化的存储，该值永远是0，但是当文件系统更新的时候，这个值就会更新为一个时间戳
				|		|			storageType
				|		|				当前目录存储NameNode内容的数据结构
				|		|			blockpoolID
				|		|				一个NameNode管理一个命名空间，该命名空间中的所有文件存储的block都在block池中
				|		|			layoutVersion
				|		|				持久化数据结构的版本
				|		| -- edits_0 000 000 000 000 000 001-0 000 000 000 000 000 019
				|		| -- edits_inprogress_0 000 000 000 000 000 020
				|		| -- fsimage_0 000 000 000 000 000 000
				|		| -- fsimage_0 000 000 000 000 000 000.md5
				|		| -- fsimage_0 000 000 000 000 000 019
				|		| -- fsimage_0 000 000 000 000 000 019.md5
				|		| -- seen_txid
				|		|	1 checkpoint前切换到新edits log文件，同时更新seen_txid(前次合并fsimage和editslog之后的第一个操作编号 )
				|		|	2 当文件系统客户端进行了写操作（例如创建或移动了文件），先记在edits log。然后更新NN内存中元数据。内存中的元数据用于响应客户端的读请求。
							3.edits log在磁盘上一定数量文件（片段（Segment）），后缀是其中包含的事务ID（transaction IDs）。写操作打开一个文件（比如：edits_inprogress_00000000000010），写完后冲刷缓冲区、同步磁盘，然后返回客户端success状态码。如元数据需写到多个目录，则需所有的写完成同步到磁盘才返回success状态码。可以保证在发生宕机的时候没有事务数据丢失。
							4.	fsimage文件不记录block所在DataNode位置信息，每次系统启动从DataNode重建。DataNode向NameNode注册，NameNode请求DataNode发送block列表。之后DataNode心跳包向NameNode报告block信息。
				| --in_use.lock
		持久化
			1 描述
				fsimage是元数据的一个checkpoint（后缀表示镜像GB 中的最后一个事务）。
			2 fsimage写到磁盘很慢，写操作时不更新此数据。
			3 恢复
				如NameNode宕机，将最新fsimage加载到内存，执行edits log对应于该fsimage之后的操作，重建元数据。（每次启动NameNode的时候如此）。
	SecondaryNameNode
		系统启动期间，NameNode合并fsimage+edits log，edits log会随系统使用不断增长
		需SecondaryNameNode 为NameNode元数据生成检查点 fsimage
		存储结构
			和nameNode一样
	DataNode
		存储结构
			dfs.namenode.name.dir
				| -- current
				|		| - BP - 52680 5057 - 127.0.0.1 - 1411980 876842
				|		|	| --current
				|		|		| -- version
				|	 	|		| -- finalized
				|	 	|		| 		| -- blk_107374 1825
				|	 	|		|  		| -- blk_107374 1825_1001.meta
				|	 	|		| 		| -- blk_107374 1826
				|	 	|		| 		| -- blk_107374 1826_1002.meta
				|	 	|		| -- rbw
				|	 	| --version		
				| -- in_use.lock 

读写流程
	(1)  读文件流程
		1）client端发送读文件请求给namenode，如果文件不存在，返回错误信息，否则，将该文件对应的block及其所在datanode位置发送给client
		2）client收到文件位置信息后，与不同datanode建立socket连接并行获取数据。
	(2) 写文件流程
		1）client端发送写文件请求，namenode检查文件是否存在，如果已存在，直接返回错误信息，否则，发送给client一些可用datanode节点	
		2）client将文件分块，并行存储到不同节点上datanode上，发送完成后，client同时发送信息给namenode和datanode
			2-1）在写的过程中，FileoutPutFormat类会以64k每快写道DataNode管道中，第一个dataNode会返回信息，同时有一列ack squence数据进行核对，确认数据正确写入
			2-2）如果写入失败，则重复上一个64K块的写入。
			2-3）如果DataNode 有宕机
				第一个DataNode宕机，则client直接连接第二台datanode
				不是第一个DataNode宕机，则将该DataNode从管道移除
			完整一份写入后，再进行复制达到要求的备份数
		3）namenode收到的client信息后，发送确信信息给datanode
		4）datanode同时收到namenode和datanode的确认信息后，提交写操作。
小文件处理
	场景+方案：
		（1）小文件（Records）都是一个大逻辑文件(日志等)的一部分
			sync+append
		（2）文件本身就是很小 Consolidator
			通过容器进行分组
			1）HARfiles-在hadoop上用Archives命令，运行mapreduce任务把小文件打包成HARfiles，体现在HDFS上构建一个层次化的文件系统。在进行最终文件的读取时，需要先访问索引数据，稍慢
				路径
					har://scheme-hostname:port/archivepath/fileinarchive
					har:///archivepath/fileinarchive(本节点)
				注意
					第一，对小文件进行存档后，原文件并不会自动被删除，需要用户自己删除；
					第二，创建HAR文件的过程实际上是在运行一个mapreduce作业，因而需要有一个hadoop集群运行此命令
				缺陷
					一旦创建，Archives便不可改变。要增加或移除里面的文件，必须重新创建归档文件。
					要归档的文件名中不能有空格，否则会抛出异常，可以将空格用其他符号替换(使用-Dhar.space.replacement.enable=true 和-Dhar.space.replacement参数)。
			2） Sequence Files 
				使用小文件名作为 key，并且文件内容作为 value，支持压缩，不限制用户和文件的多少，但是 SequenceFile 文件不能追加写入，适用于一次性写入
			3） 存类似 HBase 的 KV 数据库
				Key 为小文件的文件名，Value 为小文件的内容，可以对文件进行修改，甚至能拿到所有的历史
			4）CombineFileInputFormat
				将多个文件合并成一个单独的split，另外，它会考虑数据的存储位置