Hadoop思想与原理
1.hadoop是什么
是什么呢？就是一个棕黄色玩具大象的名字。这是真的！hadoop的作者Doug Cutting说的，这是他儿子的玩具的名字。（是不是太随意了，想想国人取名字的场景。。。）我们回到正轨，hadoop是世界上最大的富豪Apache捐助的分布式系统基础架构。该框架由java语言设计实现，用以实现在大量计算机组成的集群中对海量数据进行分布式计算。Hadoop得以在大数据处理应用中广泛应用得益于其自身在数据提取、变形和加载(ETL)方面上的天然优势。Hadoop的分布式架构，将大数据处理引擎尽可能的靠近存储。
不知道大家有没有听说Nutch这个框架。如果有人使用java做爬虫就应该知道！该框架的作者就是Doug Cutting。hadoop也起源于Nutch并且借鉴了Google于2003年发表的GFS和MapReduce相关论文。有兴趣的可以翻出去看一下。
1.1 hadoop简介
我们先看一下hadoop1.x的生态系统：
我们对上面各个模块做一些简要说明：
- Ambari：基于web的Hadoop集群安装，部署，管理，监控工具。
- HDFS：分布式文件系统，提供数据容错和对数据的高吞吐率访问。
- MapReduce：分布式，并行编程模型。将任务分为map和reduce两个阶段，从而实现每个阶段对数据的并行处理。
- ZooKeeper：高性能的分布式应用程序协调服务，是google的chubby的一个开源实现。
- HBase：基于HDFS的面向列存储的分布式数据库，用于快速读写大量数据。
- Hive：以类SQL语言提供实时大规模数据实时查询的数据仓库。
- Pig：提供高级数据流语言和计算框架来代替mapreduce任务的编写。
- Mahout：可扩展的基于mapreduce的机器学习和数据挖掘库。
- Flume：高可用，高可靠，分布式的海量日志采集、聚合和传输的系统。提供对数据进行简单处理，并写到各种数据接收方的能力。
- Sqoop：用于在关系数据库，数据仓库和Hadoop文件系统之间转移数据的工具。
我们再来看一下hadoop2.x系统架构：
名称
节点（NameNode）与DataNode的功能：
在HDFS中，名称节点（NameNode）负责管理分布式文件系统的命名空间（Namespace），保存了两个核心的数据结构，即FsImage和EditLog FsImage用于维护文件系统树以及文件树中所有的文件和文件夹的元数据 操作日志文件EditLog中记录了所有针对文件的创建、删除、重命名等操作
名称节点的启动： 1.在启动时，系统会将FsImage中的内容加载到内存中去，之后再执行EditLog中的操作，使得内存中的数据和实际同步，存在内存中的支持客户端的读。 2.一旦在内存中成功建立文件系统元数据的映射，则创建一个新的FsImage文件和一个空的EditLog文件 3.名称节点起来之后，HDFS中的更新操作会重新写到EditLog文件中，因为FsImage文件一般都很大（GB级别的很常见）， 如果所有的更新操作都往FsImage文件中添加，这样会导致系统运行的十分缓慢，但是，如果往EditLog文件里面写就不会这样， 因为EditLog 要小很多。每次执行写操作之后，且在向客户端发送成功代码之前，edits文件都需要同步更新
但为了防止EditLog过大的问题：引入了第二名称节点（SecondaryNameNode） 第二名称节点：是HDFS架构中的一个组成部分，它是用来保存名称节点中对HDFS 元数据信息的备份，并减少名称节点重启的时间。 SecondaryNameNode一般是单独运行在一台机器上
SecondaryNameNode让EditLog变小的工作流程： （1）SecondaryNameNode会定期和NameNode通信，请求其停止使用EditLog文件，暂时将新的写操作写到一个新的文件edit.new上来，这个操作是瞬间完成，上层写日志的函数完全感觉不到差别； （2）SecondaryNameNode通过HTTP GET方式从NameNode上获取到FsImage和EditLog文件，并下载到本地的相应目录下； （3）SecondaryNameNode将下载下来的FsImage载入到内存，然后一条一条地执行EditLog文件中的各项更新操作，使得内存中的FsImage保持最新；这个过程就是EditLog和FsImage文件合并； （4）SecondaryNameNode执行完（3）操作之后，会通过post方式将新的FsImage文件发送到NameNode节点上
（5）NameNode将从SecondaryNameNode接收到的新的FsImage替换旧的FsImage文件，同时将edit.new替换EditLog文件，通过这个过程EditLog就变小了
工作流程图：
DataNode：数据节点是分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者是名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表
即HDFS需要实现的方面： 1.兼容廉价的硬件设备 2.流数据读写 3.大数据集 4.简单的文件模型 5.强大的跨平台兼容性 但这样面临的局限性： 1.不适合低延迟数据访问 2.无法高效存储大量小文件 3.不支持多用户写入及任意修改文件
分别从以下这些方面，梳理清楚HDFS的 结构与运行流程，以图的形式描述。
- 客户端与HDFS
- 客户端读
- 客户端写
- 数据结点与集群
- 数据结点与名称结点
- 名称结点与第二名称结点
- 数据结点与数据结点
- 数据冗余
- 数据存取策略
- 数据错误与恢复
5.
HDFS：
海量数据存储，适合一次性扫描大量数据。
适合一次写入多次读取
不适合频繁更新的数据
HBASE：
适用一次扫描少量数据。
适合多次写入多次读取
支持数据更新
支持删除数据
5.Hbase与RDBMS的关系
RDBMS ：
支持SQL查询
支持事务
支持Join
6.
现在假设我们要从Table2里面查询一条RowKey是RK10000的数据。那么我们应该遵循以下步骤：
1. 从.META.表里面查询哪个Region包含这条数据。
2. 获取管理这个Region的RegionServer地址。
3. 连接这个RegionServer, 查到这条数据。
系统如何找到某个row key (或者某个 row key range)所在的region
bigtable 使用三层类似B+树的结构来保存region位置。
第一层： 保存zookeeper里面的文件，它持有root region的位置。
第二层：root region是.META.表的第一个region其中保存了.META.表其它region的位置。通过root region，我们就可以访问.META.表的数据。
第三层： .META.表它是一个特殊的表，保存了hbase中所有数据表的region 位置信息。
7.
假设.META.表的每行（一个映射条目）在内存中大约占用1KB，并且每个Region限制为128MB，那么，上面的三层结构可以保存的用户数据表的Region数目的计算方法是：
(-ROOT-表能够寻址的.META.表的Region个数)×（每个.META.表的Region可以寻址的用户数据表的Region个数）
一个-ROOT-表最多只能有一个Region，也就是最多只能有128MB，按照每行（一个映射条目）占用1KB内存计算，128MB空间可以容纳128MB/1KB=217行，也就是说，一个-ROOT-表可以寻址217个.META.表的Region。
同理，每个.META.表的Region可以寻址的用户数据表的Region个数是128MB/1KB=217。
最终，三层结构可以保存的Region数目是(128MB/1KB)×(128MB/1KB)=234个Region
