1、数据量大，MySQL存储不了 2、即使能存储，处理的性能也很差。 3、数据种类的多样化。mysql适用于存储结构化的数据，对于非结构化或半结构化的数据，mysql并不适用
分布式：分而治之。一分、二计算处理、三合并。就是将多台机器的资源【集群】在逻辑上合并成一个整体，通过分布式的软件，提供分布式的服务。
主从架构：主从节点进程。 主节点主要功能有： 1、管理所有从节点的存亡 2、管理任务的分配 3、接收客户端的请求 从节点的功能主要是： 1、负责管理每一台机器自己的资源。有几台机器就有几个从节点 2、接收主节点分配的任务，调用自己的机器来执行任务。
1、单点故障问题：主节点只有一个，如果主节点进程或者所在机器故障，会导致整个分布式服务不可用的 2、分布式数据一致性问题：多台机器要共享同一份数据，如何保证读取的数据一致性问题 解决：zookeeper。
1、数据一致性问题
利用ZK实现一致性存储，将数据存储在ZK中所有节点都从ZK中读取数据。 2、主节点单点故障问题解决：分布式框架可以构建多个主节点，保证同一时刻只有一个是工作状态状态 Active：工作状态Standby：备份状态问题：如何决定谁是工作谁是备份？解决：利用zookeeper的临时节点进行辅助选举 实现：让两个主节点A和B都到ZK中创建一个同名临时节点file，谁创建成功，谁就是Active，另外一个由于节点已存在，就会创建失败 假设A创建成功，A就是Active的B作为Standby，并为file节点设置监听，如果A故障，与ZK的会话会断开，file这个临时节点，就会被删除，B会受到这个监听的信息，发现A故障，就会切换为Active状态HDFS（Hadoop Distributed File System）：hadoop分布式文件系统。
HDFS就是一个逻辑上的文件系统本质：将多台机器的文件系统从逻辑上合并了，构建一个虚拟的文件系统 主：NameNode：管理节点 负责管理接受客户端请求 从：DataNode：存储节点 负责将NameNode分配的存储任务对自己所在机器的文件系统进行操作。HDFS解决分布式存储的机制。默认机制如果一个文件大于128MB，就会被拆分，每128MB一个块，不足128M，按实际大小存储。
300M => HDFS block1:128M block2:128M block3:44M最终HDFS的数据还是存储在Linux的文件系统中的，存储在哪？
hdfs-site.xml属性<property> <name>dfs.datanode.data.dir</name> <value>file:///export/server/hadoop-2.7.5/hadoopDatas/datanodeDatas</value> </property>通过冗余副本存储，来保证数据安全性。默认为3，所有的数据块，在存储时，实际存储了3份。
<property> <name>dfs.replication</name> <value>3</value> </property>负责实现与用户交互，提交请求给服务端，将服务端返回的结果再展示给用户
1、管理集群：所有DataNode在启动时会向NameNode进行注册 （1）管理从节点的状态【存活状态】：心跳机制
每隔一段时间，DN会向NN发送一个心跳，表示自己是一个正常存活的DN节点如果长时间NN没有接收到某一个DN的心跳，就会认为这个DN故障状态，不再分配任务 （2）管理数据的安全：汇报块机制每隔一段时间，DN要向NN发送当前自己这台DN上所存储的所有块的信息NameNode会根据汇报的信息与自己管理元数据进行比对，发现是否有数据丢失2、管理元数据：元数据在NameNode启动时，会被加载到内存中
元数据中记录了每一个块所对应的文件以及存储的位置 {block1：file1：root：timestamp：id：List< node1,node2,.noder3>}元数据的产生以及管理 产生：元数据在格式化的时候会产生一个元数据文件fsimage管理：NameNode启动时，会读取这个文件的数据加载到内存 问题：为什么要将fsimage的内存读取到内存中？ 为了加快NameNode对元数据读写的速度 NameNode会根据客户端的请求读写内存的元数据 问题：由于NameNode只更改内存的元数据，并没有修改文件元数据，如果一旦NameNode故障，内存中数据丢失，重启重新加载文件元数据，文件元数据没有发生变化，导致元数据丢失的？ 解决：将内存中元数据的变化【操作】记录在edits文件中，每次NameNode会将edits与fsiamge文件进行合并加载到内存 问题：fsiamge文件一直没变，edits越来越大，会有很多无用的元数据，导致NameNode启动非常慢？ 解决：SecondaryNameNode：辅助节点。负责定期或者定量的将edits与fsiamge文件进行合并，生成最新的元数据文件：fsiamge 。3、负责接收管理客户端请求。
负责接收任务，实现基于文件系统的数据块的读写。
在写的过程中，pipeline中的datanode出现故障（如网络不通），输出流如何恢复？ 1、输出流中ackQueue缓存的所有packet会被重新加入dataQueue 2、将故障的datanode从pipeline中删除 3、通知namenode分配新的datanode到数据流pipeline中，并建立新的pipeline 4、将新的datanode与其他datanode的数据同步 5、更新namenode中的元数据 6、完成后续写入操作。
情况一：读取block过程中，client与datanode通信中断 1、client与存储此block的第二个datandoe建立连接，读取数据 2、记录此有问题的datanode，不会再从它上读取数据
情况二：client读取block，发现block数据有问题 1、client读取block数据时，同时会读取到block的校验和，若client针对读取过来的block数据，计算检验和，其值与读取过来的校验和不一样，说明block数据损坏 2、client从存储此block副本的其它datanode上读取block数据（也会计算校验和）。 3、client会告知namenode此情况。
为了保证datanode中保存的数据安全，hadoop有如下两种机制 1、副本机制 对于每个块构建副本，一般来说是3份，不同的副本存储在不同的机器上，保证数据安全 2、安全模式 在安全模式下，HDFS会尝试恢复故障数据块，同步保存的数据。
namenode格式化时，会产生元数据文件：fsimage,fsimage文件是用来保存元数据的文件，每当namenode启动都会将fsimage中的元数据加载到内存中。 问题1：每次修改元数据，只会修改内存中的元数据，而文件中元数据没有变化，如果namenode发送故障，会导致元数据丢失。 解决：将内存中元数据的变化写到edits文件，每次namenode启动先加载edits和fsimage。 问题2：edits不断变大会导致namenode启动变慢。 解决：SecondaryNameNode进程会定时或edits文件达到一定大小时，通过http协议到NameNode所在的节点上下载edists文件和fsiamge文件，合并生成最新的fsimage文件，namenode会将内存中元数据的变化写入新的edits文件中。namenode下次启动会加载新的fsimage和新的edits文件。
这里拿hdfs为例来讲解高可用架构，mapreduce的高可用与hdfs唯一的区别是，在MapReduce中resourcemanager的主从节点之间的监听与数据一致性，都是由zookeeper来完成的，而在hdfs中，zookeeper的作用是主备监听，hdfs的namenode的数据一致性是由journalnode来完成的，但是其原理与zookeeper的一致性原理类似。不使用zookeeper的原因主要是zookeeper上节点容量太小。
hdfs中namenode是如何实现高可用的呢？
问题1：怎么解决主节点的单点故障问题？
解决：启动多个主节点，Hadoop2中可以启动两个NameNode。
问题2：两个NameNode只能有一个是active状态，两个namenode是怎么工作的？使用Zookeeper实现辅助选举，每个namenode都会有一个zkfc进程，这个进程负责监控自己对应的namenode，监听当前namenode的状态，帮助namenode在zk中创建临时结点。 这两个namenode都要通过zfkc进程向zk注册，在zk上创建临时节点。谁创建成功，该namenode结点状态为active，另外一个standby。Standby对临时节点设置监听，如果Active故障，这个临时节点会被删除，Standby会重新创建这个临时节点，Standby会成为新的Active。 只有active节点可以接受用户请求，只有Active的NameNode的元数据在发生变化。
问题3：两个NameNode都维护自己的内存元数据，如何保证两个NameNode内存元数据的一致性？元数据安全性前面已经提及，实现将edits文件实现高可靠的分布式共享存储，activenamenode将元数据操作写入edits文件中，standbynamenode 从edits文件中读取，并与本地的fsimage文件合并。功能设计角度，可以选择zookeeper来实现。 但是zookeeper中只能存储小数据，edits是比较大的数据，不能使用zookeeper Hadoop自己设计了一种服务，类似于Zk的机制，但是以文件形式来管理的，没有大小限制，也是分布式的，每台节点存储的内容都是一样：Journalnode
问题4：为什么HA架构中没有SecondaryNameNode？
它的工作由Standby的NameNode来实现了，Standby的NameNode会将读取的edits与fsiamge合并，定期生成最新的元数据，并且会主动将新的fsiamge同步给Active的NameNode一份。
问题5：脑裂问题 ① 正常情况下的切换：假设Active的NameNode故障:Namenode1。
NameNode1故障，ZKFC1发现这个问题，ZKFC1 会主动断开与ZK连接临时节点自动删除ZKFC2收到这个临时节点被删除的通知，于是ZKFC2会创建这个临时节点ZKFC2会通知NameNode2转换为Active状态② 特殊情况下的问题：假设Active的NameNode对应的ZKFC1出现问题，网络通信问题或者进程资源问题。
临时节点自动删除ZKFC2收到这个临时节点被删除的通知，于是ZKFC2会创建这个临时节点ZKFC2会通知NameNode2转换问题：现在两个NameNode都是Active状态现象：脑裂③ 解决：在ZKFC创建临时节点的时候，同时创建一个永久性节点：ActiveBreadCrumb
ZKFC1会创建两个节点：临时节点和永久性节点如果ZKFC1故障，临时节点自动删除，永久性性节点依旧存在ZKFC2发现临时节点消失，于是创建这个临时节点，并且通知NameNode2转换为ActiveZKFC2会发现这个临时节点依旧存在，就知道NameNode1没有故障，ZKFC1故障了ZKFC2会通过隔离机制将NameNode1强制转换为Standby状态