一、大数据的特点
数据量大；数据生成快；数据形式多样；数据价值大。
二、HDFS
hadoop分布式文件系统。
特点
1、建立在大量廉价的机器上，所以硬件错误是常态，但是提供容错机制。
2、简单一致性模型：只允许追加写，不能修改，保证了数据的一致性。
3、批量读而不能随机读，关注的是吞吐量而不是效率。
优点
高容错：数据多副本，副本丢失自动恢复。
高可用：NameNode的HA（主备切换，元数据高可用，AN的选举）和安全模式机制。
高扩展：10K节点规模。
适合大规模离线批处理。
缺点
不适合低延迟的数据访问；不适合大量小文件的存储；不支持并发写；不支持随机修改。
HDFS中的角色
Active NameNode（AN）
集群中唯一的活动的管理节点（Master）。负责管理命名空间和元数据，处理客户端的读写请求，为DataNode分配任务。
Standby NameNode(SN)
AN的热备节点。当AN宕机时，升级为新的AN。
负责周期性同步edits日志，合并edits和fsimage到本地磁盘。
NameNode元数据
包括edits（编辑日志文件，记录了自上一个检查点以来所有的文件更新操作）和fsimage（元数据检查点镜像文件，保存了文件系统所有的目录和文件信息）。
DataNode
执行客户端的读写请求；储存block数据和校验和，通过心跳机制定期向NameNode反馈运行状态和block列表信息。
Block数据块
HDFS最小的存储单元，默认128M一个块，三副本。
edits和fsimage的合并
hadoop1.x：将edits和fsimage从AN复制到SN中，在SN中进行合并，然后把结果再复制回AN。
hadoop2.x：通过将edits保存到QJM共享存储系统中，每次SN只要从QJM中拿到edits，然后和保存在自己这的fsimage合并，再将结果复制给AN即可。
安全模式
概念：安全模式是HDFS的一种保护机制，此模式下只允许读请求，不接受写等更新请求。
触发的条件
1、NameNode重启。2、NameNode磁盘空间不足。3、block上报率低于阈值。4、DataNode无法正常启动。
三、MapReduce
面向批处理的分布式计算
核心思想
分而治之，并行计算；移动计算，而非移动数据。
执行过程
split：将输入数据分成大小相等的数据片；一个切片对应一个map任务，切片数决定map任务数；注意split只是逻辑概念，只包含元数据信息。
map阶段：任务数由切片数决定，输出的是中间结果（如key-value形式）。
reduce阶段：由若干reduce任务组成，输出的是最终结果。
shuffle阶段：是Map-Reduce的中间环节，负责分区（partition），排序（sort），溢写（spill），合并（merge），抓取（fetch）等操作。
shuffle过程详解
map部分的shuffle：map任务将中间结果写入缓存中，同时对数据进行分区排序；当缓存到达阈值，便会溢写到磁盘的临时文件中，临时文件也会分区排序；当map任务结束时，将多个临时文件合并成一个文件，文件也会分区排序。
reduce部分的shuffle：reduce任务抓取自己需要的分区数据，保存在缓存中，到达阈值再溢写到磁盘的一个临时文件中；当抓取结束时，将多个临时文件合并为一个reduce的输入文件，文件中的值按key排序。
局限性
只有map和reduce两种操作；执行效率低，时间开销大；不适合迭代计算、交互式计算、流式计算。
四、Spark
spark由spark core、spark SQL、spark Streaming、spark MLib、spark GraphX组成。
由于spark的计算是基于RDD实现的。所以主要介绍一下RDD。
RDD
RDD（弹性分布式数据集），分布在集群中的只读对象，由多个partition组成，失效后可以自动重构（弹性）。
RDD操作
transformation：通过已有的RDD产生新的RDD，但是不触发计算。
action：通过RDD计算得到一个或一组值，真正触发计算。
RDD依赖
窄依赖：父RDD的一个分区只能被一个子RDD的一个分区使用。
宽依赖：子RDD的一个分区使用所有父RDD的所有分区。
宽依赖会触发shaffle阶段，所以开销大，应尽量避免宽依赖。
Spark的master/slave架构
Master：负责集群的管理。
Worker：工作节点，其中可有多个Executor，每个Executor用来执行多个task。
Zookeeper负责Master的HA，避免单点故障。
五、Storm
分布式实时计算流式处理系统。
核心概念
Nimbus：集群的主节点，负责任务的分配
Supervisor：集群的从节点，负责其上的worker进程的管理。一个worker进程可以有多个线程，每个线程可以执行多个任务。
Zookeeper：负责Supervisor的心跳机制和状态管理。从而帮助Nimbus进行任务分配。
Topology：真正的storm程序，其由一个Spout和多个Bolt构成。
Spout：负责从数据源获取数据，然后形成Tuple（Storm的数据格式，支持所有类型的有序元组）分发给Bolt。
Bolt：真正执行task的单元，在execute方法中具体实现操作。
Storm、Spark Streaming和Map-Reduce的对比
计算模型：纯实时，来一条数据处理一条。准实时，一次处理一个时间段的数据。非实时，适合离线大批量数据处理。
计算延迟：低。较低。高。
计算吞吐量：低。中。高。
动态调整并行度：支持。不支持。不支持。
六、Kafka
基于发布/订阅的分布式消息系统
基本概念
Broker：Kafka的一个节点，多个Broker组成Kafka集群。
Topic：一个topic是一类数据的集合。topic是逻辑概念，用户只需知道数据属于哪个topic，而不必关心它的实际存储位置。
Partition：有序、不可修改的消息队列（FIFO）。一个topic可以分成多个分区，一个分区有多个Replication（副本），分别存放在不同的broker上。partition是物理概念，一个分区对应一个文件，文件中保存着数据和索引信息。
Offset：数据在Partition中的偏移量，由Zookeeper进行维护。
Producer：向Kafka发送数据的客户端。
Consumer：从Kafka消费数据的客户端。
Consumer Group：不同消费者组可以同时消费一个topic，但是一个topic只能被同组里的一个consumer消费。
Zookeeper：保存着Kafka的元数据。负责Kafka的管理，包括配置管理，动态扩展，broker负载均衡，Kafka Controller Leader选举等。
工作机制
Kafka高可用
多分区多副本：一个topic被分成多个分区，每个分区有多个副本，其中一个是partition leader，负责数据的读写，其余的副本作为follower定期从leader同步数据。
Kafka Controller Leader：每个broker启动时都会创建一个kafka controller。而leader是由zookeeper负责选举，leader负责集群分区和副本的管理。
Kafka Partition Leader：在zookeeper中维护着一个保存有分区副本信息的ISR列表。当Partition Leader宕机时，Controller Leader会从ISR中选择一个副本作为新的Partition Leader。ISR列表则是由Partition Leader负责追踪和维护。
七、Redis
所有数据以key-value存储的数据服务器。
支持的value类型有String、List、Set、Sorted Set、Hash。
Redis持久化
方法一：快照。将内存中的数据以快照的形式存入二进制文件中。
方法二：AOF(Append of File)，此方法通过记录在数据集上的操作来进行数据持久化。
主从复制
Redis的Master将数据复制到Slave的时候，不会阻塞Master，Master还是可以继续处理客户端的数据请求。
Redis事务
简单的事务机制，保证单个客户端发起的事务的原子性。
发布/订阅
和Kafka类似但是，没有消费者分组机制。
八、Redis、Kafka和RabittMQ的对比
Redis基于内存来存储数据，所以速度很快，但是吞吐量小，要是作为消息队列还得自己实现消息队列的具体细节。
Kafka对消息进行分区存储、分组消费，具备高吞吐、高容量的特点，能很好的做到负载均衡，且可以给数据设置过期时间。
RabittMQ是典型的消息队列形式，数据在队列中排队，然后发送给客户端，具有良好的路由和负载均衡。
