一、大数据的特点

数据量大；数据生成快；数据形式多样；数据价值大。

二、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

面向批处理的分布式计算

核心思想

分而治之，并行计算；移动计算，而非移动数据。

执行过程

Map-Reduce程序执行过程

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是典型的消息队列形式，数据在队列中排队，然后发送给客户端，具有良好的路由和负载均衡。

九、Kubernetes