Hadoop CAP理论
大数据技术原理与应用——概念、存储、处理、分析与应用
C (强一致性) ：系统在执行过某项操作后仍然处于一致的状态。在分布式系统中，更新操作执行成功后所有的用户都应该读取到最新的值，这样的系统被认为具有强一致性。
A (可用性) ：每一个操作总是能够在一定的时间内返回结果，这里需要注意的是“一定时间内”和“返回结果”。
P (分区容错性)：分区容错性可以理解为系统在存在网络分区的情况下仍然可以接受请求(满足一致性和可用性)。
Hadoop的HDFS只支持数据增加，而Mapeduce却进行全局计算，完美地符合了他对数据处理的期望！
Hadoop也存在某个节点数据丢失的问题，但随着流式计算，丢失的数据终究会随着系统的正常而被最终合并，因此数据最终是一致的。
Hadoop不能进行实时计算咋办？作者又构建了一套基于Cassandra和ElephantDB的实时数据处理系统。。。。搞的无比复杂！
具体关于分布式系统CAP理论的质疑推荐一个博客和一些参考文献：
CAP理论
参考资料：
【1】
【2】
【3】
【4】
【5】
【6】
【7】
【8】
Hadoop 组件
核心组件
- HDFS ----Hadoop生态系统的基础组件是Hadoop分布式文件系统(HDFS)。HDFS的机制是将大量数据分布到计算机集群上，数据一次写入，但可以多次读取用于分析。它是其他一些工具的基础，例如HBase。
- MapReduce ----Hadoop的主要执行框架即MapReduce，它是一个用于分布式并行数据处理的编程模型，将作业分为mapping阶段和reduce阶段(因此而得名)。开发人员为Hadoop编写MapReduce作业，并使用HDFS中存储的数据，而HDFS可以保证快速的数据访问。鉴于MapReduce作业的特性，Hadoop以并行的方式将处理过程移向数据，从而实现快速处理。
其他组件
Hbase ----一个构建在HDFS之上的面向列的NoSQL数据库，HBase用于对大量数据进行快速读取/写入。HBase将Zookeeper用于自身的管理，以保证其所有组件都正在运行。
Zookeeper ----Zookeeper是Hadoop的分布式协调服务。Zookeeper被设计成可以在机器集群上运行，是一个具有高度可用性的服务，用于Hadoop操作的管理，而且很多Hadoop组件都依赖它。
Oozie ----一个可扩展的Workflow系统，Oozie已经被集成到Hadoop软件栈中，用于协调多个MapReduce作业的执行。它能够处理大量的复杂性，基于外部事件(包括定时和所需数据是否存在)来管理执行。
Pig ----对MapReduce编程复杂性的抽象，Pig平台包含用于分析Hadoop数据集的执行环境和脚本语言(Pig Latin)。它的编译器将Pig Latin翻译为MapReduce程序序列。
Hive ----类似于SQL的高级语言，用于执行对存储在Hadoop中数据的查询，Hive允许不熟悉MapReduce的开发人员编写数据查询语句，它会将其翻译为Hadoop中的MapReduce作业。类似于Pig，Hive是一个抽象层，但更倾向于面向较熟悉SQL而不是Java编程的数据库分析师。
Hadoop HDFS 分布式文件系统 两大部件
- ** NameNode**
HdFS中主节点，存储文件的元数据，如文件名，文件目录结构，文件属性（生成时间，副本个数，文件权限），以及每个文件的块列表和块所在的DataNode等等。 -
DataNode
在HDFS中存储文件块数据，以及块数据的校验和。
HDFS 读写机制
HDFS读文件数据流
在读取HDFS的文件时，首先客户端调用FileSystem的open()函数打开文件，DistributedFileSystem用RPC调用元数据节点，得到文件的数据块信息。对于每一个数据块，元数据节点返回保存数据块的数据节点的地址。DistributedFileSystem返回FSDataInputStream给客户端，用来读取数据。客户端调用stream的read()函数开始读取数据。DFSInputStream连接保存此文件第一个数据块的最近的数据节点。Data从数据节点读到客户端，当此数据块读取完毕时，DFSInputStream关闭和此数据节点的连接，然后连接此文件下一个数据块的最近的数据节点。当客户端读取完数据的时候，调用FSDataInputStream的close函数。客户端读取HDFS中的文件访问数据流的整个过程如图3-3所示。
图 3-3 HDFS中的读文件数据流的过程
图3-3中的操作序号1、2、3、4、5表示执行顺序，读取文件的数据流步骤如下：
1） 调用FileSystem的open()打开文件，见序号1:open。
2） DistributedFileSystem使用RPC调用NameNode节点，得到文件的数据块元数据信息，并返回FSDataInputStream给客户端，见序号2：get block locations。
3） 客户端调用stream的read()函数开始读取数据，见序号3:read。
4） 调用FSDataInputStream直接从DataNode获取文件数据块，见序号4、5：read。
5） 读完文件时，调用FSDataInputStream的close函数，见序号6:close。
HDFS写数据流
HDFS的写数据操作，比读数据复杂一些。读数据的时候，只需要在多个数据块文件的选一个读，就可以了，但是，写数据需要同时写到多个数据块文件上，这就相对比较复杂了。HDFS的写机制可以通过图3-4进行简单描述。
图3-4 HDFS写文件基本机制
如图3-4所描述，数据流从客户端开始，流经一系列的节点，到达最后一个DataNode。图3-4中的所有DataNode只需要写一次硬盘，DataNode1和DataNode2会从socket上接收到数据，直接写到下个节点的socket上。需要注意的是，如果当前DataNode处于数据流的中间，那么该数据包会被发送到下一个节点。接下来就是处理数据和校验，并分别将数据包写到数据块文件和数据块元数据文件。如果出错，抛出的异常会导致receiveBlock关闭相关的输出流，并终止传输。同时，数据校验出错还会上报到NameNode上。
最后一个DataNode由于没有后续节点，PacketResponder的ackQueue每收到一项，表明对应的数据块已经处理完毕，那么就可以发送成功应答。如果该应答是最后一个包的，PacketResponder会关闭相关的输出流并提交。如果DataNode有后续节点，那么，它必须等到后续节点成功应答才可以发送应答。
上面描述了HDFS在写数据时的基本处理机制，从客户端开始，直到在HDFS上完成写一个文件的整体数据流程如图3-5所示。
图3-5 HDFS写数据流图
正如图3-5所示，首先客户端调用create()来创建文件，然后DistributedFileSystem同样使用RPC调用NameNode元数据节点，在文件系统的命名空间中创建一个新的文件。NameNode首先确定文件原来不存在，以及客户端有创建文件的权限，然后创建新文件。DistributedFileSystem返回DFSOutputStream，客户端用于写数据。客户端开始写入数据，DFSOutputStream将数据分成块，写入data queue。Data queue由Data Streamer读取，并通知元数据节点分配数据节点，用来存储数据块（每块默认复制3块）。分配的数据节点放在一个pipeline里。Data Streamer将数据块写入pipeline中的第一个数据节点。第一个数据节点将数据块发送给第二个数据节点。第二个数据节点将数据发送给第三个数据节点。DFSOutputStream为发出去的数据块保存了ack queue，等待pipeline中的数据节点告知数据已经写入成功。如果数据节点在写入的过程中失败：关闭pipeline，同时将ack queue中的数据块放入data queue中的开始位置。
