hdfs zookeeper 关系 hadoop与zookeeper

1. Volume（大量）
2. Velocity（高速）
   快速计算
3. Variety（多样）
   结构化数据、非结构化数据
4. Value（低价值密度）
   快速对有价值数据“提纯”

工作机制
基于观察者模式设计的分布式服务管理框架，负责存储和管理大家都关心的数据，然后接受观察者的 注册，一旦这些数据的状态发生变化，Zookeeper就将负责通知已经在Zookeeper上注册的那些观察 者做出相应的反应

应用环境
提供服务：统一命名服务、统一配置管理、统一集群管理、服务器节点动态上下线、软负载均衡等。

2. 统一命名服务
4. 统一配置管理
5. 统一集群管理
6. 服务器节点动态上下线
7. 软负载均衡

架构

1. Zookeeper：一个领导者（Leader），多个跟随者（Follower）组成的集群。
2. 集群中有半数以上节点存活，集群就能正常服务。所以Zookeeper适合安装奇数台服务器。
3. 全局数据一致：每个Server保存一份相同的数据副本，Client连接到任何Server，数据都是一致的。
4. 更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行。
5. 数据更新原子性，一次数据更新要么成功，要么失败。
6. 实时性，在一定时间范围内，Client能读到最新数据。

数据结构

ZooKeeper 数据模型的结构与 Unix 文件系统很类似，整体上可以看作是一棵树，每个节点称做一个 ZNode。每一个 ZNode 默认能够存储 1MB 的数据，每个 ZNode 都可以通过其路径唯一标识。

角色

Leader:接受所有的Follower请求并统一协调发起投票；负责所有follower内部数据交换，所有写相 关操作

Follower:为客户端服务，参加提案的投票，与Leader数据交换，读操作与响应leader提议

Observer:不参提案的加投票；与Leader数据交换，接收客户端请求，并把写请求转发给leader，但 是leader不会要求Obserber参加投票

选举机制

1. 第一次启动
   

1）服务器1启动，发起一次选举。服务器1投自己一票。此时服务器1票数一票，不够半数以 上（3 票），选举无法完成，服务器1状态保持为LOOKING；

2）服务器2启动，再发起一次选举。服务器1和2分别投自己一票并交换选票信息：此时服务 器1发现服务器2的myid比自己目前投票推举的（服务器1）大，更改选票为推举服务器 2。此时服务器1票数0票，服务器2票数2票，没有半数以上结果，选举无法完成，服 务器1，2状态保持LOOKING

3）服务器3启动，发起一次选举。此时服务器1和2都会更改选票为服务器3。此次投票结果： 服务器1为0票，服务器2为0票，服务器3为3票。此时服务器3的票数已经超过半数， 服务器3当选Leader。服务器1，2更改状态为FOLLOWING，服务器3更改状态为LEADING；

4）服务器4启动，发起一次选举。此时服务器1，2，3已经不是LOOKING状态，不会更改选票 信息。交换选票信息结果：服务器3为3票，服务器4为 1票。此时服务器4服从多数， 更改选票信息为服务器3，并更改状态为FOLLOWING；

5）服务器5启动，同4一样当小弟。

1. 非第一次启动
   
   1）当ZooKeeper集群中的一台服务器出现以下两种情况之一时，就会开始进入Leader选举
   • 服务器初始化启动。
   • 服务器运行期间无法和Leader保持连接。
   2）而当一台机器进入Leader选举流程时，当前集群也可能会处于以下两种状态：
   • 集群中本来就已经存在一个Leader。
   已经存在Leader的情况，机器试图去选举Leader时，会被告知当前服务器的Leader信息，对于该机器来说，仅仅需要和Leader机器建立连接，并进行状态同步即可。
   • 集群中确实不存在Leader。
   假设ZooKeeper由5台服务器组成，
   SID分别为1、2、3、4、5，
   ZXID分别为8、8、8、7、7，
   并且此时SID为3的服务器是Leader。
   某一时刻，3和5服务器出现故障，因此开始进行Leader选举。
   SID为1、2、4的机器投票情况： （1，8，1） （1，8，2） （1，7，4）
   （EPOCH，ZXID，SID ）
   选举Leader规则：
   ①EPOCH大的直接胜出
   ②EPOCH相同，事务id大的胜出
   ③事务id相同，服务器id大的胜出

监听器原理

1）首先要有一个main()线程

2）在main线程中创建Zookeeper客户端，这时就会创建两个线程，
一个负责网络连接通信（connet），
一个负责监听（listener）

3）通过connect线程将注册的监听事件发送给Zookeeper。

4）在Zookeeper的注册监听器列表中将注册的监听事件添加到列表中。

5）Zookeeper监听到有数据或路径变化，就会将这个消息发送给listener线程。

6）listener线程内部调用了process()方法。

HDFS:分布式文件系统

1. 使用场景
   一次写入，多次读取
2. 优缺点
   优点
   1)、高可靠性
   Hadoop底层维护多个数据副本，所以即使Hadoop某个计算元素或存储出现故障，也不会导致数据的丢失。
   
   2)、高扩展性
   在集群间分配任务数据，可方便的扩展数以千计的节点
   
   3)、高效性
   在MapReduce的思想下，Hadoop是并行工作的，以加快任务处理速度。
   
   4)、高容错性
   能够自动将失败的任务重新分配。
   
   缺点
   1)、不适合低延时数据访问
   2)、无法高效对大量小文件进行存储，
   存储大量小文件的话，它会占用NameNode大量的内存来存储文件目录和块信息。这 样是不可取的，因为NameNode的内存总是有限的；
   小文件存储的寻址时间会超过读取时间，它违反了HDFS的设计目标
   3)、不支持并发写入、文件随机修改。
   一个文件只能有一个写，不允许多个线程同时写；
   仅支持数据append（追加），不支持文件的随机修改
3. 架构与角色
   
   Namenode（nn）
   （1）存储文件的元数据，如文件名，文件目录结构，文件属性（生成时间、副本数、文 件权限），以及每个文件的块列表和块所在的DataNode等
   （2）设置副本策略
   （3）管理数据快的映射信息
   （4）处理客户端读写请求
   Datanode（dn）
   （1）在本地文件系统存储文件块数据，以及块数据的校验和。
   （2）执行数据快的读写操作
   Seecondary namenode(2nn)、高可用的时候不用创建
   （1）每隔一段时间对NameNode元数据备份。
   Client:客户端
   （1）文件切分。文件上传HDFS的时候，Client将文件切分成一个一个的Block(每块数 据默认128M)，然后进行上传；
   （2）与NameNode交互，获取文件块的位置信息；
   （3）与DataNode交互，读写块数据；
   （4）Client提供一些命令来管理HDFS，比如NameNode格式化；
   （5）Client可以通过一些命令来访问HDFS，比如对HDFS增删查改操作
4. 流程
   4.1)角色流程
   NameNode 和 SecondaryNameNode
   Fsimage和Edits概念
   NameNode被格式化之后，将在/hadoop-3.1.3/data/tmp/dfs/name/current目录 中产生如下文件
   fsimage_0000000000000000000
   fsimage_0000000000000000000.md5
   seen_txid
   VERSION
   Fsimage文件：HDFS文件系统元数据的一个永久性的检查点，其中包含 HDFS文件系统的所有目录和文件inode的序列化信息。
   Edits文件：存放HDFS文件系统的所有更新操作的路径，文件系统客户 端执行的所有写操作首先会被记录到Edits文件中。
   seen_txid文件保存的是一个数字，就是最后一个edits_的数字
   每 次NameNode启动的时候都会将Fsimage文件读入内存，加 载Edits 里面的更新操作，保证内存中的元数据信息是最新的、同步的，可以看 成NameNode启动的时候就将Fsimage和Edits文件进行了合并。
   
   第一阶段：NameNode 启动
   （1）第一次启动 NameNode 格式化后，创建 Fsimage 和 Edits 文件。如果 不是第一次启动，直接加载编辑日志和镜像文件到内存。
   （2）客户端对元数据进行增删改的请求。
   （3）NameNode 记录操作日志，更新滚动日志。
   （4）NameNode 在内存中对元数据进行增删改。
   第二阶段：Secondary NameNode 工作
   （1）Secondary NameNode 询问 NameNode 是否需要 CheckPoint。直接带回 NameNode是否检查结果。
   （2）Secondary NameNode 请求执行 CheckPoint。
   （3）NameNode 滚动正在写的 Edits 日志。
   （4）将滚动前的编辑日志和镜像文件拷贝到 Secondary NameNode。
   （5）Secondary NameNode 加载编辑日志和镜像文件到内存，并合并。
   （6）生成新的镜像文件 fsimage.chkpoint。
   （7）拷贝 fsimage.chkpoint 到 NameNode。
   （8）NameNode 将 fsimage.chkpoint 重新命名成 fsimage。
   DataNode
   
   
   （1）一个数据块在 DataNode 上以文件形式存储在磁盘上，包括两个文件，一个是 数据本身，一个是元数据包括数据块的长度，块数据的校验和，以及时间戳。 （2）DataNode 启动后向 NameNode 注册，通过后，周期性（6 小时）的向 NameNode 上报所有的块信息
   （3）心跳是每 3 秒一次，心跳返回结果带有 NameNode 给该 DataNode 的命令 如复制块数据到另一台机器，或删除某个数据块。如果超过 10 分钟没有收到 某个 DataNode 的心跳，则认为该节点不可用。
   （4）集群运行中可以安全加入和退出一些机器。
   4.2)写流程
   
   （1）客户端通过 Distributed FileSystem 模块向 NameNode 请求上传文件，NameNode 检
   查目标文件是否已存在，父目录是否存在。
   （2）NameNode 返回是否可以上传。
   （3）客户端请求第一个 Block 上传到哪几个 DataNode 服务器上。
   （4）NameNode 返回 3 个 DataNode 节点，分别为 dn1、dn2、dn3。
   （5）客户端通过 FSDataOutputStream 模块请求 dn1 上传数据，dn1 收到请求会继续调 用dn2，然后 dn2 调用 dn3，将这个通信管道建立完成。
   （6）dn1、dn2、dn3 逐级应答客户端。
   （7）客户端开始往 dn1 上传第一个 Block（先从磁盘读取数据放到一个本地内存缓存），
   以 Packet 为单位，dn1 收到一个 Packet 就会传给 dn2，dn2 传给 dn3；dn1 每 传一个 packet会放入一个应答队列等待应答。
   （8）当一个 Block 传输完成之后，客户端再次请求 NameNode 上传第二个 Block 的服 务器。（重复执行 3-7 步）。
   4.3)读流程
   
   （1）客户端通过 DistributedFileSystem 向 NameNode 请求下载文件，NameNode 通过 查询元数据，找到文件块所在的 DataNode 地址。
   （2）挑选一台 DataNode（就近原则，然后随机）服务器，请求读取数据。
   （3）DataNode 开始传输数据给客户端（从磁盘里面读取数据输入流，以 Packet 为单位 来做校验）
   （4）客户端以 Packet 为单位接收，先在本地缓存，然后写入目标文件。
   4.4)节点距离计算
   
   节点距离：两个节点到达最近的共同祖先的距离总和。
   写数据的过程中，NameNode 会选择距离待上传数据最近距离的 DataNode 接
   收数据。那么这个最近距离怎么计算呢
   4.5)副本节点选择
   
   第一个副本在Client所处的节点上。如果客户端在集群外，随机选一 个。
   第二个副本在另一个机架的随机一个节点
   第三个副本在第二个副本所在机架的随机节点
   4.6)数据完整性
   原始数据封装 对接收到的数据重新校验
   
   4.7)快大小调整
   HDFS块的大小设置主要取决于磁盘传输速率。
   普通机械硬盘128m，固态硬盘258m

MapReduce:分布式计算框架

1. 使用场景
   将用户编写的业务逻辑代码和自带默认组件整合成一个完整的分布式运算程序，并发运行在一个 Hadoop 集群上。
2. 优缺点
   优点
   1)、MapReduce 易于编程
   写一个分布式程序，跟写一个简单的串行程序是一模一样的
   2)、良好的扩展性
   计算资源不能得到满足的时候，通过简单的增加机器来扩展它的计算能力。
   3)、高容错性
   一台机器挂了，可以把上面的计算任务转移到另外一个节点运行
   4)、海量数据的离线处理（适合 TB/PB 级以上）
   可以实现上千台服务器集群并发工作，提供数据处理能力
   缺点
   1)、不擅长实时计算
   MapReduce 无法像 MySQL 一样，在毫秒或者秒级内返回结果。
   2)、不擅长流式计算
   流式计算的输入数据是动态的，而 MapReduce 的输入数据集是静态的，不能动态变化。
   3)、不擅长 DAG（有向无环图）计算
   多个应用程序存在依赖关系，后一个应用程序的输入为前一个的输出。在这种情况下，MapReduce 并不是不能做，而是使用后，每个 MapReduce 作业的输出结果都会写入到磁盘，会造成大量的磁盘 IO，导致性能非常的低下。
3. 架构与角色
   架构过程分为两个阶段：Map和Reduce
   
   （1）分布式的运算程序往往需要分成至少 2 个阶段。
   （2）第一个阶段的 MapTask 并发实例，完全并行运行，互不相干。
   （3）第二个阶段的 ReduceTask 并发实例互不相干，但是他们的数据依赖于上一个阶段
   的所有 MapTask 并发实例的输出。
   （4）MapReduce 编程模型只能包含一个 Map 阶段和一个 Reduce 阶段，如果用户的业
   务逻辑非常复杂，那就只能多个 MapReduce 程序，串行运行。
   JobTracker
   管理任务监控，报错处理；分配分任务给taskTracker
   Tasktracker
   运行map task和reducer task；与jobTracker交互汇报工作
   map task
   解析数据记录，传递给用户编写的map()并执行，输出结果写入本地磁盘
   Reducer task
   从map task的执行结果中，远程读取输入数据，对数据进行排序
4. 流程
   Map task工作机制
   
   Read阶段
   1、数据切片划分
   2、yarn计算MapTask数量，开启MrAppMaster
   3、MrAppMaster开启MapTast（多个）
   4、InputFormat调用RecorderReader（K,v reader()）去读取数据
   Map阶段
   6、进入用户写的mao(K，v)写的逻辑
   7、outputCollector输出结果到环形缓冲区
   Collect阶段
   8、一侧存数据、一侧存索引，默认大小100M，到达80%，进行分区快排
   溢写阶段
   9、写出数据
   Merge阶段
   10、写出的数据进行归并排序，分区的组
   Reduce task工作机制
   
   Copy 阶段
   ReduceTask 从各个 MapTask 上远程拷贝一片数据，并针对某一片数据，如果其大 小超过一定阈值，则写到磁盘上，否则直接放到内存中。
   Sort 阶段
   在远程拷贝数据的同时，ReduceTask 启动了两个后台线程对内存和磁盘上的文件进 行合并，以防止内存使用过多或磁盘上文件过多。
   #按照 MapReduce 语义，用户编写 reduce()函数输入数据是按 key 进行聚集的一组 数据。为了将 key 相同的数据聚在一起，Hadoop 采用了基于排序的策略。 由于各个 MapTask 已经实现对自己的处理结果进行了局部排序，因此， ReduceTask 只需对所有数据进行一次归并排序即可。
   Reduce 阶段
   reduce()函数将计算结果写到 HDFS 上
   压缩机制
   3.x版本以后默认支持DEFLATE、Gzip、bzip2、Snappy

Yarn集群资源管理系统

1. 使用场景
   资源调度平台，负责为运算程序提供服务器运算资源，相当于一个分布式的操作系统平台，而 MapReduce 等运算程序则相当于运行于操作系统之上的应用程序。
2. 架构与角色
   
   ResourceManager(RM)
   1、整个集群资源（内存、cpu等）的老大，资源的分配与调度
   2、处理客户端请求
   3、监控NodeManager
   4、启动和监控ApplicationMaster
   NodeManager(NM)
   1、单个节点服务器资源老大，管理单个节点上的资源
   2、处理来着ResourceManager、ApplicationMaster的命令
   ApplicationMaster（AM）
   1、单个任务运行的老大，为应用程序申请资源并分配任务
   2、任务的监控与容错
   Container
   容器，相当于一台独立服务器，里面封装了任务运行需要资源
3. 流程
   工作流程
   
   （1）MR 程序提交到客户端所在的节点。
   （2）YarnRunner 向 ResourceManager 申请一个 Application。
   （3）RM 将该应用程序的资源路径返回给 YarnRunner。
   （4）该程序将运行所需资源提交到 HDFS 上。
   （5）程序资源提交完毕后，申请运行 mrAppMaster。
   （6）RM 将用户的请求初始化成一个 Task。
   （7）其中一个 NodeManager 领取到 Task 任务。
   （8）该 NodeManager 创建容器 Container，并产生 MRAppmaster。
   （9）Container 从 HDFS 上拷贝资源到本地。
   （10）MRAppmaster 向 RM 申请运行 MapTask 资源。
   （11）RM 将运行 MapTask 任务分配给另外两个 NodeManager，另两个 NodeManager 分
   别领取任务并创建容器。
   （12）MR 向两个接收到任务的 NodeManager 发送程序启动脚本，这两个 NodeManager
   分别启动 MapTask，MapTask 对数据分区排序。
   （13）MrAppMaster 等待所有 MapTask 运行完毕后，向 RM 申请容器，运行 ReduceTask。
   （14）ReduceTask 向 MapTask 获取相应分区的数据。
   （15）程序运行完毕后，MR 会向 RM 申请注销自己
   Yarn 调度器和调度算法
   先进先出调度器（FIFO）
   
   特点
   1、单队列
   根据提交作业的先后顺序，先来先服务。简单易懂；
   2、不支持多队列
   生产环境很少使用；
   容量（Capacity Scheduler）（默认）
   
   特点
   1、多队列
   每个队列可配置一定的资源量，每个队列采用FIFO调度策略。
   2、容量保证
   管理员可为每个队列设置资源最低保证和资源使用上限
   3、灵活性
   如果一个队列中的资源有剩余，可以暂时共享给那些需要资源的队列， 而一旦该队列有新的应用程序提交，则其他队列借调的资源会归还给该 队列。
   4、多租户
   支持多用户共享集群和多应用程序同时运行。为了防止同一个用户的作 业独占队列中的资源，该调度器会对同一用户 提交的作业所占资源 量进行限定。
   分配算法
   
   1、队列资源分配
   从root开始，使用深度优先算法，优先选择资源占用率最低的队列分 配资源。
   2、作业资源分配
   默认按照提交作业的优先级和提交时间顺序分配资源。
   3、容器资源分配
   按照容器的优先级分配资源；
   如果优先级相同，按照数据本地性原则：
   （1）任务和数据在同一节点
   （2）任务和数据在同一机架
   （3）任务和数据不在同一节点也不在同一机架
   公平（Fair Scheduler）。（CDH默认）
   
   特点
   1、与容量调度器相同点
   （1）多队列：支持多队列多作业
   （2）容量保证：管理员可为每个队列设置资源最低保证和资源使用上 线
   （3）灵活性：如果一个队列中的资源有剩余，可以暂时共享给那些需 要资源的队列，而一旦该队列有新的应用程序提交，则其他队列 借调的资源会归还给该队列。
   2、与容量调度器不同点
   （1）核心调度策略不同
   容量调度器：优先选择资源利用率低的队列
   公平调度器：优先选择对资源的缺额比例大的
   （2）每个队列可以单独设置资源分配方式
   容量调度器：FIFO、 DRF
   公平调度器：FIFO、FAIR、DRF
   资源分配方式
   1、FIFO策略
   公平调度器每个队列资源分配策略如果选择FIFO的话，此时公平调度 器相当于上面讲过的容量调度器。
   2、Fair策略
   Fair 策略（默认）是一种基于最大最小公平算法实现的资源多路复用 方式，默认情况下，每个队列内部采用该方式分配资源。这意味着，如 果一个队列中有两个应用程序同时运行，则每个应用程序可得到1/2的 资源；如果三个应用程序同时运行，则每个应用程序可得到1/3的资源。 分别计算比较对象的（实际最小资源份额、是否饥饿、资源分配比、资 源使用权重比
4. 三者关系
   Hdfs、yarn、mapreduce三者关系流程
   
   作业提交过程之YARN & HDFS & MapReduce
   
   
   （1）作业提交
   第 1 步：Client 调用 job.waitForCompletion 方法，向整个集群提交MapReduce 作业。
   第 2 步：Client 向 RM 申请一个作业 id。
   第 3 步：RM 给 Client返回该 job 资源的提交路径和作业 id。
   第 4 步：Client 提交jar 包、切片信息和配置文件到指定的资源提交路径。
   第 5 步：Client 提交完资源后，向 RM 申请运行 MrAppMaster。
   （2）作业初始化
   第 6 步：当 RM 收到 Client 的请求后，将该 job 添加到容量调度器中。
   第 7 步：某一个空闲的 NM 领取到该 Job。
   第 8 步：该 NM 创建 Container，并产生 MRAppmaster。
   第 9 步：下载 Client 提交的资源到本地。
   （3）任务分配
   第 10 步：MrAppMaster 向 RM 申请运行多个 MapTask 任务资源。
   第 11 步：RM 将运行 MapTask 任务分配给另外两个NodeManager，另两个 NodeManager 分别领取任务并创建容器。
   （4）任务运行
   第 12 步：MR 向两个接收到任务的 NodeManager 发送程序启动脚本，这两个NodeManager 分别启动 MapTask，MapTask 对数据分区排序。
   第13步：MrAppMaster等待所有MapTask运行完毕后，向RM申请 容器，运ReduceTask。
   第 14 步：ReduceTask 向 MapTask 获取相应分区的数据。
   第 15 步：程序运行完毕后，MR 会向 RM 申请注销自己。
   （5）进度和状态更新
   YARN 中的任务将其进度和状态(包括 counter)返回给应用管理器,客户端每秒(通过 mapreduce.client.progressmonitor.pollinterval设置)向应用管理器请求进度更 新, 展示给用户。
   （6）作业完成
   除了向应用管理器请求作业进度外, 客户端每 5 秒都会通过调用 waitForCompletion()来检查作业是否完成。时间间隔可以通过 mapreduce.client.completion.pollinterval 来设置。作业完成之后, 应用管理器和 Container 会清理工作状态。作业的信息会被作业历史服务器存储以备之后用户核查。

定义
分布式、可扩展、支持海量数据库存储的NoSql数据库

HBase特点

1. 海量存储
   Hbase适合存储PB级别的海量数据，能在几十到百毫秒内返回数据。
2. 列式存储
   这里的列式存储其实说的是列族存储，Hbase是根据列族来存储数据的。列族下面可以有非常多 的列
3. 极易扩展
   基于上层处理能力（RegionServer）的扩展
   基于存储的扩展（HDFS）。
4. 高并发
   并发的情况下，Hbase的单个IO延迟下降并不多。能获得高并发、低延迟的服务。
5. 稀疏
   针对Hbase列的灵活性，列族中，可以指定任意多的列，在列数据为空的情况下，是不会占用 存储空间的。

数据模型

1. 定义
   逻辑上，HBase 的数据模型同关系型数据库很类似，数据存储在一张表中，有行有列。
   但从 HBase 的底层物理存储结构（K-V）来看，HBase 更像是一个 multi-dimensional map。
2. 逻辑结构
3. 物理存储结构
   
   相同的列名更具timeStamp的版本取最大的显示

HBase架构与角色

1. 角色
   #Hlog相当于mysql的binlog，先写入log在写入内存
   #Mem Store:写缓存，由于 HFile 中的数据要求是有序的，所以数据是先存储在内存中，排好
   序后，等到达刷写时机才会刷写到 HFile，每次刷写都会形成一个新的 HFile。
   #StoreFile:保存实际数据的物理文件，以 HFile 的形式存储在 HDFS 上。每个 Store 会有
   一个或多个 StoreFile（HFile），数据在每个 StoreFile 中都是有序的。
   1、Client
   Client包含了访问Hbase的接口，另外Client还维护了对应的cache来加速Hbase的访问，比 如cache的.META.元数据的信息。
   2、Zookeeper
   HBase通过Zookeeper来做master的高可用、RegionServer的监控、元数据的入口以及集群配 置的维护等工作。具体工作如下：
   （1）保证集群中只有1个master在运行
   （2）监控RegionServer的状态
   （3）通过Zoopkeeper存储元数据的统一入口地址
   （4）客户端直接通过ZK获取HregionServer交互数据
   3、Hmaster（RegionServer的管理）
   1）监控RegionServer、为RegionServer分配Region
   2）处理RegionServer故障转移、当RegionSever失效的时候，协调对应Hlog的拆分
   3）处理元数据的变更、维护集群的元数据信息
   4）处理region分配或转移、发现失效Region，并将失效Region分配到正常RegionServer上
   5）在空闲时间进行数据的负载均衡
   6）通过Zookeeper发布自己的位置给客户端
   4、HRegionServer（数据管理）
   HRegionServer直接对接用户的读写请求，是真正的“干活”的节点
   1）负责存储HBase的实际数据,刷新缓存到HDFS、负责和底层HDFS的交互，存储数据到HDFS
   2）管理master为其分配的Region
   3）处理来自客户端的读写请求
   4）维护Hlog
   5）执行压缩
   6）负责Region变大以后的拆分
   7)负责Storefile的合并工作
   5、HDFS
   HDFS为Hbase提供最终的底层数据存储服务，同时为HBase提供高可用（Hlog存储在HDFS）
   (1)提供元数据和表数据的底层分布式存储服务
   (2)数据多副本，保证的高可靠和高可用性

流程

1. 读流程

1)、Client先访问zookeeper，从meta表读取region的位置，然后读取meta表中的数据。Meta 中又存储了用户表的region信息；
2)、访问对应的 Region Server，获取 hbase:meta 表，查询出目标数据位于哪个Region 中。 并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的meta cache，方 便下次访问。
3)、找到这个region对应的regionserver，与目标 Region Server 进行通讯；
4)、查找对应的region，先从MemStore找数据，如果没有，再到BlockCache里面读；
6)、BlockCache还没有，再到StoreFile上读(为了读取的效率)，写入BlockCache
7)、将合并后的最终结果返回给客户端

1. 写流程
   
   1)、访问 zookeeper，获取 hbase:meta 表位于哪个 Region Server；
   2)、访问对应的 Region Server，获取 hbase:meta 表，查询出目标数据位于哪个Region 中。 并将该 table 的 region 信息以及 meta 表的位置信息缓存在客户端的meta cache，方 便下次访问。
   3)、HregionServer将数据写到HLog（write ahead log）。为了数据的持久化和恢复；
   4)、HregionServer将数据写到内存（MemStore）；
   5)、反馈Client写成功。
2. 数据Flush过程
   
   1、当MemStore数据达到阈值（默认是128M，老版本是64M），将数据刷到硬盘，将内存中 的数据删除，同时删除HLog中的历史数据；
   2、并将数据存储到HDFS中；
   3、在HLog中做标记点。
3. 数据合并过程-StoreFile Compaction
   
   1、当数据块达到4块，Hmaster触发合并操作，Region将数据块加载到本地，进行合并；
   2、当合并的数据超过256M，进行拆分，将拆分后的Region分配给不同的HregionServer管理；
   3、当HregionServer宕机后，将HregionServer上的hlog拆分，然后分配给不同的HregionServer 加载，修改.META.；
   注意：HLog会同步到HDFS。
4. 数据切分过程-Region Split
   每个 Table 起初只有一个 Region，随着数据的不断写入，Region 会自动进行拆分。刚拆分时， 两个子 Region 都位于当前的 Region Server，但处于负载均衡的考虑，HMaster 有可能会将 某个 Region 转移给其他的 Region Server。

定义
分布式的基于发布/订阅模式的消息队列（Message Queue）
主要应用于大数据实时处理领域

优点

1. 解耦：
   允许独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。
2. 可恢复性：
   系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所
   以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理
3. 缓冲：
   有助于控制和优化数据流经过系统的速度，解决生产消息和消费消息的处理速度不一致
   的情况
4. 削峰：
   在访问量剧增的情况下，使用消息队列能够使关键组件顶住突发的访问 压力，而不会因为突发的超负荷的请求而完全崩溃。
5. 异步通信：
   很多时候，用户不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户
   把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要
   的时候再去处理它们。

消费模式，同步处理-异步处理

1. 点对点模式（一对一，消费者主动拉取数据，消息收到后消息清除）

发送到队列的消息被一个且只有一个接收者接收处理，即使有多个消息监听者也是如此。

1. 发布/订阅模式（一对多，数据生产后，推送给所有订阅者，消费者消费数据之后不会清除消息）

消息生产者（发布）将消息发布到 topic 中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到 topic 的消息会被所有订阅者消费。

架构与角色

1. 角色
   Consumer Group （CG）：消费者组。同一个分区Partition，同时只能被同一个消费者组里面的莫一 个消费
   Broker ：一台服务器就是一个broker。一个集群由多个broker组成。一个broker可以容纳多个topic
   Topic ：可以理解为一个队列，相当于主题把消息分类；
   Partition：topic负载，一个非常大的topic可以分布到多个broker（即服务器）上，一个topic 可以分为多个partition，每个partition是一个有序的队列。
   partition中的每条消息都会被分配一个有序的id（offset）。kafka只保证按一个partition 中的顺序将消息发给consumer，不保证一个topic的整体（多个partition间）的顺序；
   Offset：存储文件都是按照offset.kafka来命名，用offset做名字的好处是方便查找。例如你想 找位于2049的位置，只要找到2049.kafka的文件即可。
   Replica：副本，为保证集群中的某个节点发生故障时，该节点上的 partition 数据不丢失，
   且 kafka 仍然能够继续工作

定义
Flume 是 Cloudera 提供的一个高可用的，高可靠的，分布式的海量日志采集、聚合和传
输的系统。Flume 基于流式架构，灵活简单。

Flume最主要的作用就是，实时读取服务器本地磁盘的数据，将数据写入到HDFS

组成架构与角色

1. Agen
   定义
   是一个JVM进程，它以事件的形式将数据从源头送至目的，是Flume数据传输的基本单元。
   Agent主要有3个部分组成
   Source
   定义：是负责接收数据到 Flume Agent 的组件
   Channel
   定义：位于 Source 和 Sink 之间的缓冲区，可以同时处理几个 Source 的写入操作和几 个Sink 的读取操作
   缓冲方式
   Memory Channel
   是内存中的队列。Memory Channel 在不需要关心数据丢失的情景下适
   用。如果需要关心数据丢失，那么 Memory Channel 就不应该使用，因为程序 死亡、机器宕机或者重启都会导致数据丢失。
   File Channel
   将所有事件写到磁盘。因此在程序关闭或机器宕机的情况下不会丢失数据。
   Kafka Channel
   传输单元：Event
   Flume数据传输的基本单元，以事件的形式将数据从源头送至目的地。
   Header：存放该 event 的一些属性，为 K-V 结构，
   Body ：用来存放该条数据，形式为字节数组。
   Sink
   定义：不断地轮询 Channel 中的事件且批量地移除它们，并将这些事件批量写入到存储
   或索引系统、或者被发送到另一个 Flume Agent。

Flume Agent内部原理

1.ChannelSelector

ChannelSelector的作用就是选出Event将要被发往哪个Channel，其共有两种类型
1）Replicating（复制）
ReplicatingSelector会将同一个Event发往所有的Channel，

2）和Multiplexing（多路复用）
Multiplexing会根据相应的原则，将不同的Event发往不同的Channel

2.SinkProcessor

SinkProcessor共有三种类型
1）DefaultSinkProcessor
对应单个sink，发送至单个sink
2）LoadBalancingSinkProcessor
LoadBalancingSinkProcessor对应的是Sink Group，Loa dBalancingSinkProcessor 可以实现负载均衡的功能
3）FailoverSinkProcessor
FailoverSinkProcessor对应的是Sink Group，
FailoverSinkProcessor可以错误恢复的功能

Flume的拓扑结构

1. 简单串联

这种模式是将多个flume顺序连接起来了，从最初的source开始到最终sink传送的目的存储 系统。
优点
多个flume并联，可以增加event缓存数量
缺点
此模式不建议桥接过多的flume数量， flume数量过多不仅会影响传输速率，而且一旦传 输过程中某个节点flume宕机，会影响整个传输系统。

1. 复制和多路复用
   
   Flume支持将事件流向一个或者多个目的地。这种模式可以将相同数据复制到多个channel中， 或者将不同数据分发到不同的channel中，sink可以选择传送到不同的目的地。
2. 负载均衡和故障转移

Flume支持使用将多个sink逻辑上分到一个sink组，sink组配合不同的SinkProcessor可以 实现负载均衡和错误恢复的功能。

1. 聚合

这种模式是我们最常见的，也非常实用，日常web应用通常分布在上百个服务器，大者甚至上 千个、上万个服务器。产生的日志，处理起来也非常麻烦。用flume的这种组合方式能很 好的解决这一问题，每台服务器部署一个flume采集日志，传送到一个集中收集日志的 flume，再由此flume上传到hdfs、hive、hbase等，进行日志分析。

使用场景
数据仓库工具，可以将结构化的数据文件映射为一张表，并提供类 SQL 查询功能

本质

将 HQL 转化成 MapReduce 程序

Hive 处理的数据存储在 HDFS
Hive 分析数据底层的实现是 MapReduce
执行程序运行在 Yarn 上

优缺点

1. 优点
   1、操作接口采用类 SQL 语法，提供快速开发的能力（简单、容易上手）。
   2、避免了去写 MapReduce，减少开发人员的学习成本。
   3、Hive 的执行延迟比较高，因此 Hive 常用于数据分析，对实时性要求不高的场合。
   4、Hive 优势在于处理大数据，对于处理小数据没有优势，Hive 的执行延迟比较高。
   5、Hive 支持用户自定义函数，用户可以根据自己的需求来实现自己的函数。
2. 缺点
   1、Hive 的 HQL 表达能力有限
   迭代式算法无法表达
   数据挖掘方面不擅长，MapReduce 数据处理流程限制，效率高算法无法实现。
   2、Hive 的效率比较低
   Hive 自动生成的 MapReduce 作业，通常情况下不够智能化
   Hive 调优比较困难，粒度较粗
   架构原理与角色

角色
1、Client：用户接口
CLI（command-line interface）、JDBC/ODBC(jdbc 访问 hive)、WEBUI（浏览器访问 hive）
2、元数据：Metastore
元数据包括：表名、表所属的数据库（默认是 default）、表的拥有者、列/分区字段、
表的类型（是否是外部表）、表的数据所在目录等；
默认存储在自带的 derby 数据库中，推荐使用 MySQL 存储 Metastore
3、Hadoop
使用 HDFS 进行存储，使用 MapReduce 进行计算。
4、驱动器：Driver
（1）解析器（SQL Parser）：将 SQL 字符串转换成抽象语法树 AST
（2）编译器（Physical Plan）：将 AST 编译生成逻辑执行计划。
（3）优化器（Query Optimizer）：对逻辑执行计划进行优化。
（4）执行器（Execution）：把逻辑执行计划转换成可以运行MapReduce任务

运行机制

Hive 通过给用户提供的一系列交互接口，接收到用户的指令(SQL)，使用自己的 Driver，
结合元数据(MetaStore)，将这些指令翻译成 MapReduce，提交到 Hadoop 中执行，最后，将
执行返回的结果输出到用户交互接口。

一个用于 Hadoop 数据的快速通用计算引擎。Spark 提供了一个简单而富有表现力的编程模型，支持广泛的 应用程序，包括 ETL、机器学习、流处理和图计算。具有数学表达能力的 Scala DSL。支持多个分布 式后端（包 括 Apache Spark）。用于 CPU/GPU/CUDA 加速的模块化本机求解器
通常用于：实时流处理
角色：

1. Master集群资源管理
   支持：Standalone,Yarn,Mesos；
2. Worker运行任务的工作节点
   每个工作节点上负责任务的执行进程（Executor）；
   Executor包括cache、分配到Executor上的task任务（task1、task2…tasksN）
3. Driver应用程序的控制节点
   该进程运行应用的main()方法并且创建SparkContext。
   由Cluster Manager分配资源，SparkContext将发送Task到Executor上执行。

定义

通过简单的 key:value 对的方式，通过配置中 Dependencies 设置依赖关系。Azkaban 使用 job配 置文件建立任务之间的依赖关系，并提供一个易于使用的 web 用户界面维护和跟踪你的工作流

特点
1、兼容任何版本的 hadoop
2、易于使用的 Web 用户界面
3、简单的工作流的上传
4、方便设置任务之间的关系
5、调度工作流
6、模块化和可插拔的插件机制
7、认证/授权(权限的工作)
8、能够杀死并重新启动工作流
9、有关失败和成功的电子邮件提醒

组成

AzkabanWebServer：是整个 Azkaban 工作流系统的主要管理者，它用户登录认证、负责 project 管 理、定时执行工作流、跟踪工作流执行进度等一系列任务。

AzkabanExecutorServer：负责具体的工作流的提交、执行，它们通过 mysql 数据库来协调任务的执 行。

关系型数据库（MySQL）：存储大部分执行流状态，AzkabanWebServer 和AzkabanExecutorServer 都 需要访问数据库。

特点
1、通过拖拽图的方式将Task按照任务的依赖关系关联起来，可实时可视化监控任务的运行状态；
2、支持工作流定时调度、依赖调度、手动调度、手动暂停/停止/恢复，同时支持失败重试/告警、从 指定节点恢复失败、Kill 任务等操作；
3、支持工作流全局参数及节点自定义参数设置；
4、支持集群HA，通过 Zookeeper实现 Master 集群和 Worker 集群去中心化；
5、支持工作流运行历史树形/甘特图展示、支持任务状态统计、流程状态统计；

架构原理与角色

1. MasterServer
   作用
   1、采用分布式无中心设计理念，启动时向Zookeeper注册临时节点，并维持心跳。
   2、负责 DAG 任务切分、任务提交监控，并同时监听其它MasterServer和WorkerServer 的健康状态。
   角色
   1、Distributed Quartz
   分布式调度组件负责定时任务的启停操作，当quartz调起任务后，Master内部会 有线程池具体负 责处理任务的后续操作
   2、MasterSchedulerThread
   扫描线程，定时扫描数据库中的 command 表，根据不同的命令类型进行不同的业务操作
   3、MasterExecThread
   负责DAG任务切分、任务提交监控、各种不同命令类型的逻辑处理
   4、MasterTaskExecThread
   负责任务的持久化
2. WorkerServer
   作用
   1、分布式无中心设计理念，启动时向Zookeeper注册临时节点，并维持心跳。
   2、负责任务的执行和提供日志服务。
   角色
   1、FetchTaskThread
   不断从Task Queue中领取任务，并根据不同任务类型调用TaskScheduleThread对应执行器。
   2、LoggerServer
   提供日志分片查看、刷新和下载等功能

定义
用于在线分析处理查询（OLAP），不适合初始存储，适合大量的宽表存储
特点

1. 列式存储

（1）查询效率高，对于列的聚合，计数，求和等统计操作原因优于行式存储。
（2）压缩比重高，由于某一列的数据类型都是相同的，针对于数据存储更容易进行数据 压缩，每一列选择更优的数据压缩算法

1. DBMS 标准 SQL 的大部分语法
2. 引擎多样化有合并树(默认)、日志、接口和其他四大类 20 多种引擎
3. 高吞吐写入能力
4. 数据分区与线程级并行
   ClickHouse 将数据划分为多个 partition，每个 partition 再进一步划分为多个 index
   granularity(索引粒度)，
   然后通过多个 CPU核心分别处理其中的一部分来实现并行数据处理。
   单条 Query 就能利用整机所有 CPU。极致的并行处理能力，极大的降低了查询延时。

流程

1. 副本写入流程
2. 集群写入流程
3. 集群读取流程
4. 数据类型
   整型
   整型范围（-2n-1~2n-1-1）：
   Int8 - [-128 : 127]
   Int16 - [-32768 : 32767]
   Int32 - [-2147483648 : 2147483647]
   Int64 - [-9223372036854775808 : 9223372036854775807]
   无符号整型范围（0~2n-1）：
   UInt8 - [0 : 255]
   UInt16 - [0 : 65535]
   UInt32 - [0 : 4294967295]
   UInt64 - [0 : 18446744073709551615]
   使用场景：个数、数量、也可以存储型 id
   浮点型
   Float32 - float
   Float64 – double
   使用场景：数据值比较小，没有大量统计计算，精度不高的时候。比如保存商品的重量。
   Decimal 型
   有符号的浮点数，可在加、减和乘法运算过程中保持精度
   Decimal32(s)，相当于 Decimal(9-s,s)，有效位数为 1~9
   Decimal64(s)，相当于 Decimal(18-s,s)，有效位数为 1~18
   Decimal128(s)，相当于 Decimal(38-s,s)，有效位数为 1~38
   使用场景： 金额字段、汇率等字段为了保证小数点精度，都使用 Decimal进行存储。
   布尔型
   没有单独的类型来存储布尔值。可以使用 UInt8 类型，取值限制为 0 或 1
   字符串
   String：
   字符串可以任意长度的。它可以包含任意的字节集，包含空字节。
   FixedString(N)
   固定长度 N 的字符串
   使用场景：名称、文字描述、字符型编码。
   枚举类型，Enum 保存 ‘string’= integer 的对应关系
   Enum8
   Enum8 用 ‘String’= Int8 对描述。
   Enum16
   Enum16 用 ‘String’= Int16 对描述。
   使用场景：对一些状态、类型的字段算是一种空间优化，也算是一种数据约束。
   时间类型
   Date 年-月-日
   Datetime 年-月-日 时:分:秒
   Datetime64 年-月-日 时:分:秒.亚秒
   数组
   不能在 MergeTree 表中存储多维数组。
   创建数组方式 1，使用 array 函数
   SELECT array(1, 2) AS x, toTypeName(x) ;
   创建数组方式 2：使用方括号
   SELECT [1, 2] AS x, toTypeName(x);
5. 表引擎
   #引擎的名称大小写敏感
   1、TinyLog（列文件引擎）
   以列文件的形式保存在磁盘上，不支持索引，没有并发控制。一般保存少量数据的小表，
   生产环境上作用有限。可以用于平时练习测试用。
   2、Memory（内存引擎）
   内存引擎，数据以未压缩的原始形式直接保存在内存当中，服务器重启数据就会消失。
   3、ReplacingMergeTree
   存储特性完全继承 MergeTree，只是多了一个去重的功能
   1）去重时机
   数据的去重只会在合并的过程中出现。合并会在未知的时间在后台进行，所以你无法预
   先作出计划。有一些数据可能仍未被处理。
   2）去重范围
   如果表经过了分区，去重只会在分区内部进行去重，不能执行跨分区的去重。 ReplacingMergeTree 适用于在后台清除重复的数据以节省空间，但是它不保证没有重复 的数据出现
   4、SummingMergeTree
   存储特性完全继承 MergeTree，只是多了定期分区内预聚合
   5、MergeTree（合并树）
   partition by 分区(可选)
   （1）作用
   分区的目的主要是降低扫描的范围，优化查询速度
   （2）如果不填
   只会使用一个分区。
   （3）分区目录
   以列文件+索引文件+表定义文件组成的，但是如果设定了分区那么这些文
   件就会保存到不同的分区目录中。
   （4）并行
   分区后，面对涉及跨分区的查询统计，ClickHouse 会以分区为单位并行处理。
   （5）数据写入与分区合并
   任何一个批次的数据写入都会产生一个临时分区，不会纳入任何一个已有的分区。 写入后的某个时刻（大概 10-15 分钟后），ClickHouse 会自动执行合并操作（等 不及也可以手动通过 optimize 执行），把临时分区的数据，合并到已有分区中。
6. primary key 主键(可选)
   只提供了数据的一级索引，但是却不是唯一约束。这就意味着是可以存在相同 primary key 的数据的。主键的设定主要依据是查询语句中的 where 条件。
   稀疏索引：
   
   稀疏索引的好处就是可以用很少的索引数据，定位更多的数据，代价就是只能定位 到索引粒度的第一行，然后再进行进行一点扫描
7. order by（必选）
   设定了分区内的数据按照哪些字段顺序进行有序保存。
8. 二级索引
   二级索引对一级索引的粒度，GRANULARITY n
9. 数据 TTL
   管理数据表或者列的生命周期的功能