大数据基础

分手后的思念是犯贱 2022-09-02 03:46 159阅读 0赞

### 文章目录 ###

*  一、大数据存储与管理
 *   *  1. 分布式文件系统HDFS
     *   *  1.1 HDFS核心概念
         *  1.2 HDFS体系结构
         *  1.3 HDFS存储原理
         *  1.4 HDFS 2.0
     *  2. 分布式数据库HBase
     *   *  2.1 HBase简介
         *  2.2 HBase数据模型
         *  2.3 HBase实现原理
 *  二、大数据处理与分析
 *   *  1. 静态数据：批处理
     *   *  1.1 分布式并行编程框架MapReduce工作流程
         *  1.2 基于内存的分布式计算框架Spark
     *  2. 流数据：实时计算
     *  3. 资源管理调度框架YARN
     *   *  3.1 YARN体系结构
         *  3.2 YARN工作流程
 *  三、Hadoop相关开源项目
 *   *  1. Avro
     *  2. 数据传输框架
     *   *  2.1 Maxwell
         *  2.2 Flume
         *  2.3 Sqoop
     *  3. Hive
     *  4. Kafka
     *   *  4.1 Kafka简介
         *   *  4.1.1 Kafka消费模式
             *  4.1.2 Kafka基础架构
         *  4.2 Kafka高级
     *  5. Zookeeper
 *  总结

# 一、大数据存储与管理 #

## 1. 分布式文件系统HDFS ##

### 1.1 HDFS核心概念 ###

1.  块：块是数据读写的基本单元。HDFS中的文件会被拆分成多个块，每个块作为独立的单元进行存储。
2.  数据节点（DataNode）：分布式文件系统HDFS的工作节点，负责数据的存储和读取，会根据客户端或者名称节点的调度来进行数据的存储和检索，并且向名称节点定期发送自己所存储的块的列表。每个数据节点中的数据会被保存在各自节点的本地Linux文件系统中。
3.  名称节点（NameNode）：负责管理分布式文件系统的命名空间（Name Space），保存了两个核心的数据结构，即FsImage和EditLog：  
    FsImage用于维护文件系统树中所有的文件和目录的元数据；  
    EditLog中记录了所有针对文件的创建、删除、重命名等操作。

*  名称节点在启动时，会将FsImage的内容加载到内存当中，然后执行EditLog文件中的各项操作，使得内存中的元数据保持最新。
 *  创建一个新的FsImage文件和一个空的EditLog文件。
 *  名称节点启动成功并进入正常运行状态以后，HDFS中的更新操作都会被写入到EditLog，而不是直接写入FsImage。（因为对于分布式文件系统而言，FsImage文件通常都很庞大，如果所有的更新操作都直接往FsImage文件中添加，那么系统就会变得非常缓慢。相对而言，EditLog通常都要远远小于FsImage，更新操作写入到EditLog是非常高效的。）
 *  名称节点在启动的过程中处于“安全模式”，只能对外提供读操作，无法提供写操作。启动过程结束后，系统就会退出安全模式，进入正常运行状态，对外提供读写操作。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center]

1.  第二名称节点（Secondary Namenode ）：可以完成EditLog和FsImage的合并操作，减小EditLog文件大小，缩短名称节点重启时间；作为名称节点的检查点，保存名称节点中元数据信息。

### 1.2 HDFS体系结构 ###

HDFS采用了主从（Master/Slave）结构模型，一个HDFS集群包括了一个名称节点（NameNode）和若干个数据节点（DataNode）。  
每个数据节点会周期性的向名称节点发生“心跳“信息，报告自己的状态，没有按时发送“心跳”信息的数据节点被标记为宕机，不再给他分配任何IO请求。  
在系统内部，一个文件被切分成多个数据块，这些数据块被分布到若干个数据节点上。当客户，端要访问一个文件时：

1.  把文件名发给NN；
2.  由NN根据文件名找到对应的数据块；
3.  根据每个数据块信息找到实际存储数据块的DN的位置；
4.  把DN位置发送给客户端；
5.  客户端直接访问DN获取数据。  
    在整个访问过程中，NN并不参与数据传输。这种设计方式，使得一个文件的数据能够在不同的数据节点上实现并发访问，大大提高了数据访问速度。

### 1.3 HDFS存储原理 ###

1.  数据的冗余存储：作为一个分布式文件系统，为了保证系统的容错性和可用性，HDFS采用了多副本方式对数据进行冗余存储，通常一个数据块的多个副本会被分布到不同的数据节点。
2.  数据存取策略  
    （1）数据存放

*  如果是在集群内发起写操作请求，则把第一个副本放置在发起写操作请求的数据节点上，实现就近写入数据。如果是来自集群外部的写操作请求，则从集群内部挑选一台磁盘不太满、CPU不太忙的数据节点，作为第一个副本的存放地；
 *  第二个副本会被放置在与第一个副本不同的机架的数据节点上；
 *  第三个副本会被放置在与第一个副本相同的机架的其他节点上；
 *  如果还有更多的副本，则继续从集群中随机选择数据节点进行存放。  
    （2）数据读取  
    HDFS提供了一个API可以确定一个数据节点所属的机架ID，客户端也可以调用API获取自己所属的机架ID。当客户端读取数据时，从名称节点获得数据块不同副本的存放位置列表，列表中包含了副本所在的数据节点，可以调用API来确定客户端和这些数据节点所属的机架ID。  
    当发现某个数据块副本对应的机架ID和客户端对应的机架ID相同时，就优先选择该副本读取数据，如果没有发现，就随机选择一个副本读取数据。

1.  数据错误与恢复  
    （1）名称节点出错  
    NameNode核心FsImage和EditLog，这两个文件发生损坏，那么整个HDFS实例将失效。Hadoop采用两种机制来确保名称节点的安全：第一，把名称节点上的元数据信息同步存储到其他文件系统中；第二，运行一个第二名称节点，当名称节点宕机以后，可以把第二名称节点作为一种弥补措施，利用第二名称节点中的元数据信息进行系统恢复，但是从前面对第二名称节点的介绍中可以看出，这样做仍然会丢失部分数据。因此，一般会把上述两种方式结合使用，当名称节点发生宕机时，首先到远程挂载的网络文件系统中获取备份的元数据信息，放到第二名称节点上进行恢复，并把第二名称节点作为名称节点来使用。  
    （2）数据节点出错  
    当数据节点发生故障，或者网络发生断网时，名称节点就无法收到来自一些数据节点的“心跳”信息，这时这些数据节点就会被标记为“宕机”，节点上面的所有数据都会被标记为“不可读”，名称节点不会再给它们发送任何I/O请求。  
    这时，由于一些数据节点的不可用，会导致一些数据块的副本数量小于冗余因子。  
    名称节点会定期检查这种情况，一旦发现某个数据块的副本数量小于冗余因子，就会启动数据冗余复制，为它生成新的副本。  
    （3）数据出错  
    在文件被创建时，客户端就会对每一个文件块进行信息摘录，并把这些信息写入同一个路径的隐藏文件里面。  
    当客户端读取文件的时候，会先读取该信息文件，然后利用该信息文件对每个读取的数据块进行校验，如果校验出错，客户端就会请求到另外一个数据节点读取该文件块，并且向名称节点报告这个文件块有错误，名称节点会定期检查并且重新复制这个块。

### 1.4 HDFS 2.0 ###

1.  HDFS HA  
    为了解决单点故障问题，HDFS2.0采用了HA（HighAvailability）架构。  
    在一个典型的HA集群中，一般设置两个名称节点，其中一个名称节点处于“活跃（Active）”状态，另一个处于“待命（Standby）”状态。  
    处于活跃状态的名称节点负责对外处理所有客户端的请求，而处于待命状态的名称节点则作为备用节点，保存了足够多的系统元数据，当名称节点出现故障时提供快速恢复能力。  
    也就是说，在HDFSHA中，处于待命状态的名称节点提供了“热备份”，一旦活跃名称节点出现故障，就可以立即切换到待命名称节点，不会影响到系统的正常对外服务。  
    在某个时刻也只会有一个名称节点处于活跃状态，另一个则处于待命状态。因而，HDFS HA在本质上还是单名称节点，只是通过“热备份”设计方式解决了单点故障问题，并没有解决可扩展性、系统性能和隔离性三个方面的问题
2.  HDFS联邦  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 1]

HDFS联邦中的名称节点提供了命名空间和块管理功能。  
在HDFS联邦中，所有名称节点会共享底层的数据节点存储资源。每个数据节点要向集群中所有的名称节点注册，并周期性地向名称节点发送“心跳”和块信息，报告自己的状态，同时也会处理来自名称节点的指令。  
与HDFS1.0不同的是，HDFS联邦拥有多个独立的命名空间，其中，每一个命名空间管理属于自己的一组块，这些属于同一个命名空间的块构成一个“块池”（BlockPool）。每个数据节点会为多个块池提供块的存储。  
可以看出，数据节点是一个物理概念，而块池则属于逻辑概念，一个块池是一组块的逻辑集合，块池中的各个块实际上是存储在各个不同的数据节点中的。因此，HDFS联邦中的一个名称节点失效，也不会影响到与它相关的数据节点继续为其他名称节点提供服务。

## 2. 分布式数据库HBase ##

### 2.1 HBase简介 ###

HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库，是谷歌BigTable的开源实现，主要用来存储非结构化和半结构化的松散数据。  
HBase的目标是处理非常庞大的表，可以通过水平扩展的方式，利用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 2]

图中描述了Hadoop生态系统中HBase与其他部分的关系。  
HBase利用HadoopMapReduce来处理HBase中的海量数据，实现高性能计算；利用Zookeeper作为协同服务，实现稳定服务和失败恢复；使用HDFS作为高可靠的底层存储，利用廉价集群提供海量数据存储能力。此外，为了方便在HBase上进行数据处理，Sqoop为HBase提供了高效、便捷的RDBMS数据导入功能，Pig和Hive为HBase提供了高层语言支持。

### 2.2 HBase数据模型 ###

1.  HBase实际上就是一个稀疏、多维、持久化存储的映射表，它采用行键（RowKey）、列族（ColumnFamily）、列限定符（ColumnQualifier）和时间戳（Timestamp）进行索引，每个值都是未经解释的byte\[\]。
2.  数据模型相关概念  
    （1）表：由行和列组成，列划分为若干个列族  
    （2）行：由行键标识，存储时，按照行键字典序排序  
    （3）列族：它是基本的访问控制单元，列族要在表创建时就定义好，通常将同一数据类型的数据存储于一个列族  
    （4）列限定符：不用事先定义  
    （5）单元格：通过行、列族、列限定符确定一个单元格。每个单元格都是一个数据的多个版本  
    （6）时间戳：类似版本号，按降序存储，最新版本最先被读取
3.  物理视图和概念视图  
    （1）概念视图  
    从概念视图层面，HBase中的每个表是由许多行组成的  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 3]  
    （2）物理视图  
    在物理存储层面，它是采用了基于列的存储方式，而不是像传统关系数据库那样采用基于行的存储方式，这也是HBase和传统关系数据库的重要区别。  
    在概念视图中，有些列是空的，即这些列上面不存在值。在物理视图中，这些空的列不会被存储成null，而是根本就不会被存储，当请求这些空白的单元格的时候，会返回null值。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 4]

### 2.3 HBase实现原理 ###

1.  功能组件  
    （1）库函数，链接到每个客户端；  
    （2）一个Master主服务器：主服务器Master负责管理和维护HBase表的分区信息，比如，一个表被分成了哪些Region，每个Region被存放在哪台Region服务器上，同时也负责维护Region服务器列表。因此，如果Master主服务器死机，那么整个系统都会无效。  
    （3）许多个Region服务器：Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求。
2.  Region：Region类似于高表的切分，初始时只有一个Region，而后表越来越高，被分成多个Region，每个不同的Region被存储在不同的Region服务器上。
3.  Region的定位  
    HBase使用了三层结构保存Region位置信息  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 5]

Region标识符：表名+开始主键+RegionID  
“元数据表”，又名“.META.表”：每个条目包含两项内容，一个是Region标识符，另一个是Region服务器标识，这个条目就表示Region和Region服务器之间的对应关系，从而就可以知道某个Region被保存在哪个Region服务器中。这个映射表包含了关于Region的元数据（即Region和Region服务器之间的对应关）。  
“根数据表”，又名“ROOT表”：当一个HBase表中的Region数量非常庞大的时候，.META.表的条目就会非常多，一个服务器保存不下，也需要分区存储到不同的服务器上，因此.META.表也会被分裂成多个Region，这时，为了定位这些Region，就需要再构建一个新的映射表，记录所有元数据的具体位置。ROOT不可再分割。  
也就是永远只存在一个Region用于存放ROOT表，因此这个用来存放ROOT表的唯一一个Region，它的名字是在程序中被写死的，Master主服务器永远知道它的位置。

# 二、大数据处理与分析 #

## 1. 静态数据：批处理 ##

### 1.1 分布式并行编程框架MapReduce工作流程 ###

1.  工作流程  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 6]  
    一个大的MapReduce作业，首先会被拆分成许多个Map任务在多台机器上并行执行，每个Map任务通常运行在数据存储的节点上，这样，计算和数据就可以放在一起运行，不需要额外的数据传输开销。  
    当Map任务结束后，会生成以<key,value>形式表示的许多中间结果。  
    然后，这些中间结果会被分发到多个Reduce任务在多台机器上并行执行，具有相同key的<key,value>会被发送到同一个Reduce任务那里，Reduce任务会对中间结果进行汇总计算得到最后结果，并输出到分布式文件系统中。  
    不同的Map任务之间不会进行通信，不同的Reduce任务之间也不会发生任何信息交换；用户不能显式地从一台机器向另一台机器发送消息，所有的数据交换都是通过MapReduce框架自身去实现的。  
    在MapReduce的整个执行过程中，Map任务的输入文件、Reduce任务的处理结果都是保存在分布式文件系统中的，而Map任务处理得到的中间结果则保存在本地存储中（如磁盘）。  
    只有当Map处理全部结束后，Reduce过程才能开始；只有Map需要考虑数据局部性，实现“计算向数据靠拢”，而Reduce则无需考虑数据局部性。
2.  Shuffle过程  
    所谓Shuffle，是指对Map输出结果进行分区（Partition）、排序（Sort）、合并（Combine）等处理，得到<key,valuelist>形式的中间结果，并交给Reduce的过程。因此，Shuffle过程分为Map端的操作和Reduce端的操作。  
    （1）Map端

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 7]

①Map的输出结果首先被写入缓存（在写入缓存之前，key与value值都会被序列化成字节数组）  
②当缓存满时，就启动溢写操作，把缓存中的数据写入磁盘文件，并清空缓存。当启动溢写操作时，首先需要把缓存中的数据进行分区，然后对每个分区的数据进行排序（Sort）和合并（Combine），之后再写入磁盘文件。  
③每次溢写操作会生成一个新的磁盘文件，随着Map任务的执行，磁盘中就会生成多个溢写文件。在Map任务全部结束之前，这些溢写文件会被归并（Merge）成一个大的磁盘文件，然后通知相应的Reduce任务来领取属于自己处理的数据。  
（2）Reduce端  
相对于Map端而言，Reduce端的Shuffle过程非常简单，只需要从Map端读取Map结果，然后执行归并操作，最后输送给Reduce任务进行处理。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 8]

### 1.2 基于内存的分布式计算框架Spark ###

在实际应用中，大数据处理主要包括以下三个类型。①复杂的批量数据处理：时间跨度通常在数十分钟到数小时之间。②基于历史数据的交互式查询：时间跨度通常在数十秒到数分钟之间。③基于实时数据流的数据处理：时间跨度通常在数百毫秒到数秒之间。  
Spark是基于内存计算的大数据并行计算框架，可用于构建大型的、低延迟的数据分析应用程序，他 的设计遵循“一个软件栈满足不同应用场景”的理念，逐渐形成了一套完整的生态系统，既能够提供内存计算框架，也可以支持SQL即席查询、实时流式计算、机器学习和图计算等。Spark可以部署在资源管理器YARN之上，提供一站式的大数据解决方案。因此，Spark所提供的生态系统足以应对上述三种场景，即同时支持批处理、交互式查询和流数据处理。  
Spark生态系统主要包含了SparkCore、SparkSQL、SparkStreaming、MLlib和GraphX等组件，各个组件的具体功能如下。  
（1）SparkCore：SparkCore包含Spark的基本功能，如内存计算、任务调度、部署模式、故障恢复、存储管理等，主要面向批数据处理。Spark建立在统一的抽象RDD之上，使其可以以基本一致的方式应对不同的大数据处理场景。  
（2）SparkSQL：SparkSQL允许开发人员直接处理RDD，同时也可查询Hive、HBase等外部数据源。  
（3）SparkStreaming：SparkStreaming支持高吞吐量、可容错处理的实时流数据处理，其核心思路是将流数据分解成一系列短小的批处理作业，每个短小的批处理作业都可以使用SparkCore进行快速处理。SparkStreaming支持多种数据输入源，如Kafka、Flume和TCP套接字等。  
（4）MLlib（机器学习）  
（5）GraphX（图计算）

## 2. 流数据：实时计算 ##

SparkStreaming是Spark的核心组件之一，为Spark提供了可拓展、高吞吐、容错的流计算能力。  
SparkStreaming可整合多种输入数据源，如Kafka、Flume、HDFS，甚至是普通的TCP套接字。经处理后的数据可存储至文件系统、数据库。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 9]  
SparkStreaming的基本原理是将实时输入数据流以时间片（秒级）为单位进行拆分，然后经Spark引擎以类似批处理的方式处理每个时间片数据。

## 3. 资源管理调度框架YARN ##

### 3.1 YARN体系结构 ###

YARN体系结构中包含了三个组件：ResourceManager、ApplicationMaster和NodeManager。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 10]

### 3.2 YARN工作流程 ###

在YARN框架中执行一个MapReduce程序时，从提交到完成需要经历如下8个步骤。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 11]

①用户编写客户端应用程序，向YARN提交应用程序，提交的内容包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。  
②YARN中的ResourceManager负责接收和处理来自客户端的请求。接到客户端应用程序请求后，ResourceManager里面的调度器会为应用程序分配一个容器。同时，ResourceManager的应用程序管理器会与该容器所在的NodeManager通信，为该应用程序在该容器中启动一个ApplicationMaster（即图中的“MRAppMstr”）。  
③ApplicationMaster被创建后会首先向ResourceManager注册，从而使得用户可以通过ResourceManager来直接查看应用程序的运行状态。  
④ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请资源。  
⑤ResourceManager以“容器”的形式向提出申请的ApplicationMaster分配资源，一旦ApplicationMaster申请到资源后，就会与该容器所在的NodeManager进行通信，要求它启动任务。  
⑥当ApplicationMaster要求容器启动任务时，它会为任务设置好运行环境（包括环境变量、JAR包、二进制程序等），然后将任务启动命令写到一个脚本中，最后通过在容器中运行该脚本来启动任务。  
⑦各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度，让ApplicationMaster可以随时掌握各个任务的运行状态，从而可以在任务失败时重新启动任务。⑧应用程序运行完成后，ApplicationMaster向ResourceManager的应用程序管理器注销并关闭自己。若ApplicationMaster因故失败，ResourceManager中的应用程序管理器会监测到失败的情形，然后将其重新启动，直到所有的任务执行完毕。

# 三、Hadoop相关开源项目 #

## 1. Avro ##

Avro是Hadoop中的一个子项目，也是Apache中一个独立的项目，Avro是一个基于二进制数据传输中间件。Avro是一个数据序列化的系统，可以将数据结构或对象转化成便于存储或传输的格式。  
Avro依赖于模式(Schema)。通过模式定义各种数据结构，只有确定了模式才能对数据进行解释，所以在数据的序列化和反序列化之前，必须先确定模式的结构。Schema定义了简单数据类型和复杂数据类型，其中复杂数据类型包含不同属性。通过各种数据类型用户可以自定义丰富的数据结构。

## 2. 数据传输框架 ##

### 2.1 Maxwell ###

Maxwell是一个MySQL实时抓取软件，实时读取MySQL的二进制日志Binlog，并生成JSON格式消息。作为Producer发送给Kafka、Redis、RabbitMQ等。

### 2.2 Flume ###

1.  概念：Flume是一个高可用的，高可靠的，分布式的海量**日志**采集、聚合和传输系统。
2.  目的：Flume最主要的作业就是，实时读取服务器本地磁盘的数据，将数据写入HDFS。
3.  基础架构  
    （1）Agent是一个JVM进程，他以Event的形式将数据从源头送至目的地。  
    Agent主要有三个组成部分：Source、Channel、Sink  
    （2）Source是负责接收数据到FAgent的组件，采集数据并包装成Event。Source组件可以处理各种类型、各种格式的日志数据。  
    （3）Channel是位于Source和Sink之间的缓冲区。因此，Channel允许Source和Sink运作在不同的速率上。Channel是线程安全的，可以同时处理几个Source的写入操作和几个Sink的读取操作。  
    （4）Sink不断地轮询Channel中的事件且批量地移除它们，并将这些事件批量写入到存储或索引系统、或者被发送到另一个Flume Agent。Sink组件目的地包括HDFS、Avro、IPC、file、HBase等。  
    （5）Event是Flume数据传输的基本单元，以Event的形式将数据从源头送至目的地。Event由Header和Body两部分组成，Header用来存放该event的一些属性，为K-V结构，Body用来存放该条数据，形式为字节数组。

### 2.3 Sqoop ###

1.  概念Apache Sqoop是在Hadoop生态体系和RDBMS体系之间传送数据的一种工具（Sqoop 的本质还是一个命令行工具）。
2.  核心的功能：  
    （1）导入数据：MySQL，Oracle 导入数据到 Hadoop 的 HDFS、Hive、HBase 等数据存储系统；  
    （2）导出数据：从 Hadoop 的文件系统中导出数据到关系数据库 MySQL等 。
3.  Sqoop工作机制：  
    是将导入或导出命令翻译成MapReduce程序来实现，在翻译出的MapReduce中主要是对InputFormat和OutputFormat进行定制

## 3. Hive ##

1.  什么是Hive？  
    用于解决海量结构化日志的数据统计；  
    基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射成一张表，并且提供类SQL的查询功能；  
    Hive提供了一系列的工具，可以用来进行数据提取、转化、加载（ETL Extract-Transform-Load ），本身不存储数据只提供一种管理方式，同时也不涉及分布式概念，就是个软件而已。
2.  与传统数据库比较  
    （1）Hive是建立在Hadoop之上，所有的Hive数据都是存储在HDFS上；传统数据库将数据保存在本地文件系统中；因此Hive能够处理更大更多的数据；  
    （2）Hive是针对数据仓库应用设计，因此数据一次写入多次读出，即Hive中不建议对数据进行改写操作，所有数据都是在加载的时候确定好；对于数据库通常需要进行频繁的增删查改；  
    （3）Hive访问数据中满足特定值需要暴力扫描真个数据，因此访问延迟高。由于MapReduce的引入，Hive可以并行访问数据，即便没有索引也可用于大数据量的访问；传统数据库通常针对一个或多个列建立索引，因此在访问数据是延迟低效率高，即Hive不适合实时数据分析；  
    （4）Hive 的执行引擎为MR/Spark，传统数据库都有自己的执行引擎；  
    （5）Hive可以利用MapReduce进行大规模数据的并行计算；传统数据库支持的数据规模较小。

## 4. Kafka ##

### 4.1 Kafka简介 ###

Kafka是一种消息队列，主要用来处理大量数据状态下的消息队列，一般用来做日志的处理。  
优点：

*  高吞吐量、低延迟：kafka每秒可以处理几十万条消息，它的延迟最低只有几毫秒，每个topic可以分多个partition, consumer group 对partition进行consume操作。
 *  可扩展性：kafka集群支持热扩展
 *  持久性、可靠性：消息被持久化到本地磁盘，并且支持数据备份防止数据丢失
 *  容错性：允许集群中节点失败（若副本数量为n,则允许n-1个节点失败）
 *  高并发：支持数千个客户端同时读写

#### 4.1.1 Kafka消费模式 ####

一对一：消息生产者发布消息到Queue队列中，通知消费者从队列中拉取消息进行消费。消息被消费之后则删除，Queue支持多个消费者，但对于一条消息而言，只有一个消费者可以消费，即一条消息只能被一个消费者消费。  
一对多：这种模式也称为发布/订阅模式，即利用Topic存储消息，消息生产者将消息发布到Topic中，同时有多个消费者订阅此topic，消费者可以从中消费消息，发布到Topic中的消息会被多个消费者消费，消费者消费数据之后，数据不会被清除，Kafka会默认保留一段时间，然后再删除。

#### 4.1.2 Kafka基础架构 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 12]  
整体来看，kafka架构中包含四大组件：生产者、消费者、kafka集群、zookeeper集群。  
1、broker  
kafka 集群包含一个或多个服务器，每个服务器节点称为一个broker。  
2、topic  
每条发布到kafka集群的消息都有一个类别，这个类别称为topic，其实就是将消息按照topic来分类，topic就是逻辑上的分类，同一个topic的数据既可以在同一个broker上也可以在不同的broker结点上。  
3、partition  
分区，每个topic被物理划分为一个或多个分区，每个分区在物理上对应一个文件夹，该文件夹里面存储了这个分区的所有消息和索引文件。在创建topic时可指定parition数量，生产者将消息发送到topic时，消息会根据分区策略追加到分区文件的末尾，属于顺序写磁盘，因此效率非常高。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 13]  
所谓分区策略就是决定生产者将消息发送到哪个分区的算法。Kafka 提供了默认的分区策略，同时它也支持自定义分区策略。kafka允许为每条消息设置一个key，一旦消息被定义了 Key，那么就可以保证同一个 Key 的所有消息都进入到相同的分区，这种策略属于自定义策略的一种，被称作Key-ordering 策略。  
分区原则：

*  指明partition（这里的指明是指第几个分区）的情况下，直接将指明的值作为partition的值；
 *  没有指明partition的情况下，但是存在值key，此时将key的hash值与topic的partition总数进行取余得到partition值；
 *  值与partition均无的情况下，第一次调用时随机生成一个整数，后面每次调用在这个整数上自增，将这个值与topic可用的partition总数取余得到partition值，即round-robin算法。

同一topic的多个partition可以部署在多个机器上，以此来实现 kafka 的伸缩性。同一partition中的数据是有序的，但topic下的多个partition之间在消费数据时不能保证有序性，在需要严格保证消息顺序消费的场景下，可以将partition数设为1。  
4、offset  
partition中的每条消息都被标记了一个序号，这个序号表示消息在partition中的偏移量，称为offset，每一条消息在partition都有唯一的offset，消息者通过指定offset来指定要消费的消息。  
正常情况下，消费者在消费完一条消息后会递增offset，准备去消费下一条消息，但也可以将offset设成一个较小的值，重新消费一些消费过的消息，可见offset是由consumer控制的，consumer想消费哪一条消息就消费哪一条消息，所以kafka broker它不需要标记哪些消息被消费过。  
5、producer  
生产者，生产者发送消息到指定的topic下，消息再根据分配规则append到某个partition的末尾。  
6、consumer  
消费者，消费者从topic中消费数据。  
7、consumer group  
消费者组，每个consumer属于一个特定的consumer group，可为每个consumer指定consumer group，若不指定则属于默认的group。  
同一topic的一条消息只能被同一个consumer group内的一个consumer消费，但多个consumer group可同时消费这一消息。这也是kafka用来实现一个topic消息的广播和单播的手段，如果需要实现广播，一个consumer group内只放一个消费者即可，要实现单播，将所有的消费者放到同一个consumer group即可。  
用consumer group还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。  
8、leader  
每个partition有多个副本，其中有且仅有一个作为leader，leader会负责所有的客户端读写操作。  
9、follower  
follower不对外提供服务，只与leader保持数据同步，如果leader失效，则选举一个follower来充当新的leader。当follower与leader挂掉、卡住或者同步太慢，leader会把这个follower从ISR列表中删除，重新创建一个follower。  
10、rebalance  
同一个consumer group下的多个消费者互相协调消费工作，一个topic分为多个分区，一个consumer group里面的所有消费者合作，一起去消费所订阅的某个topic下的所有分区(每个消费者消费部分分区)，kafka会将该topic下的所有分区均匀的分配给consumer group下的每个消费者。rebalance表示"重平衡"，consumer group内某个消费者挂掉后，其他消费者自动重新分配订阅主题分区的过程。

### 4.2 Kafka高级 ###

1.  kafka中zookeeper的作用  
    Kakfa Broker集群受Zookeeper管理。所有的Kafka Broker节点一起去Zookeeper上注册一个临时节点，因为只有一个Kafka Broker会注册成功，其他的都会失败，所以这个成功在Zookeeper上注册临时节点的这个Kafka Broker会成为Kafka Broker Controller，其他的Kafka broker叫Kafka Broker follower。（这个过程叫Controller在ZooKeeper注册Watch）。这个Controller会监听其他的Kafka Broker的所有信息，如果这个kafka broker controller宕机了，在zookeeper上面的那个临时节点就会消失，此时所有的kafka broker又会一起去 Zookeeper上注册一个临时节点。
2.  工作流程  
    kafka的生产者生产和消费者消费都是面向topic的  
    Topic是逻辑上的改变，Partition是物理上的概念，每个Partition对应着一个log文件，该log文件中存储的就是producer生产的数据。  
    Producer生产的数据会被不断的追加到该log文件的末端，且每条数据都有自己的offset，consumer组中的每个consumer，都会实时记录自己消费到了哪个offset，以便出错恢复的时候，可以从上次的位置继续消费。
3.  文件存储  
    Kafka文件存储也是通过本地落盘的方式存储的，主要是通过相应的log与index等文件保存具体的消息文件。每个log被分成多个Segment，每个Segment对应一个.index和.log。  
    生产者不断的向log文件追加消息文件，为了防止log文件过大导致定位效率低下，Kafka的log文件以1G为一个分界点，当.log文件大小超过1G的时候，此时会创建一个新的.log文件，同时为了快速定位大文件中消息位置，Kafka采取了分片和索引的机制来加速定位。  
    在kafka的存储log的地方，即文件的地方，会存在消费的偏移量以及具体的分区信息，分区信息主要包括.index和.log文件组成，  
    分区目的是为了备份，所以同一个分区存储在不同的broker上，即当third-2存在当前机器kafka01上，实际上再kafka03中也有这个分区的文件（副本），分区中包含副本，即一个分区可以设置多个副本，副本中有一个是leader，其余为follower。
4.  数据可靠性保证  
    kafka默认ack机制是全部同步完成，才发送ack，优点是选举新的leader时容忍n台节点故障，需要n+1个副本  
    在此基础上，还有ISR，意为和leader保持同步的follower集合，当ISR中所有follower同步完成就ack；若某follower长时间未同步，就踢出ISR，时间阈值由replica.lag.time.max.ms参数设定；若leader故障，从ISR中选新的leader。  
    三种可靠性级别：  
    acks参数配置：  
    0:producer不等broker的ack，broker一接收到还没有写入磁盘就立即返回，数据可能丢失  
    1:producer等broker的ack，partition的leader落盘成功后返回，follower同步之前leader故障，数据丢失  
    \-1（默认）:producer等broker的ack，partition的leader和follower全部落盘才返回；但在follower落盘后，broker返回之前leader故障，会发生数据重复  
    Exactly Once：0.11版本后，引入幂等性，也就是无论向server发送多少数据，server只会持久化一条。  
    要启用幂等性，只要将producer的参数中enable.idempotence设置为true即可。将下游要做的去重放在上游去做。

## 5. Zookeeper ##

1.  什么是分布式协调系统？  
    举例：  
    比如搭建了一个数据库集群，里面有一个Master，多个Slave，我们需要一个系统，来告诉客户端，哪个是Master。  
    如果我在其中一台机器修改了Master的ip，数据还没同步到其他两台，这时候客户端过来查询，如果查询走的是另外两台还没有同步到的机器，就会拿到旧的数据。  
    所以我们需要这个存储master信息的服务器集群，做到当信息还没同步完成时，不对外提供服务，阻塞住查询请求，等待信息同步完成，再给查询请求返回信息。这样一来，请求就会变慢，变慢的时间取决于什么时候这个集群认为数据同步完成了。  
    假设数据同步时间无限短，可以忽略不计，那么其实这个分布式系统，就和之前单机的系统一样，既可以保证数据的一致，又让外界感知不到请求阻塞，同时，又不会有SPOF（Single Point of Failure）的风险，即不会因为一台机器的宕机，导致整个系统不可用。  
    这样的系统，就叫分布式协调系统。谁能把这个数据同步的时间压缩的更短，谁的请求响应就更快，谁就更出色，Zookeeper就是其中的佼佼者。  
    它用起来像单机一样，能够提供数据强一致性，但是其实背后是多台机器构成的集群，不会有SPOF。
2.  zookeeper简单理解就是文件系统+监听通知机制

（1）Zookeeper维护一个类似文件系统的数据结构，每个子目录项都被称作为 znode(目录节点)，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。  
有四种类型的znode：

*  PERSISTENT-持久化目录节点  
    客户端与zookeeper断开连接后，该节点依旧存在
 *  PERSISTENT\_SEQUENTIAL-持久化顺序编号目录节点  
    客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
 *  EPHEMERAL-临时目录节点  
    客户端与zookeeper断开连接后，该节点被删除
 *  EPHEMERAL\_SEQUENTIAL-临时顺序编号目录节点  
    客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号  
    （2）客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。

--------------------

# 总结 #

未完待续。。。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center]: /images/20220829/b1889878db0f408b80229321232029d4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20220829/fed0f2980a8644ad8b61d3a4e4ee95e2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20220829/94743fc7d64c48f0aece685f866fad97.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20220829/0ce812ba887a466bb883c4db0a523a91.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20220829/4406cde32dc847818768624ee3cb2014.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20220829/459dfdf49c1b459bbe6a399627ee975a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20220829/66b620f01f354813b90dd019fc593599.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20220829/366db33a515a4908b37c3b5cc3c376cb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20220829/49568e2a04fd4d14878c69045b3dc2e7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20220829/779d9fc8447248abb04ca45b4ab051ae.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20220829/fcec6f88ce4642939aedc22b5638ddcd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 11]: /images/20220829/dee195eb4fbd44f0bd5503338ce27e18.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 12]: /images/20220829/6ddf13c91378484abca492a34ed7c117.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0Nlbm55Xw_size_16_color_FFFFFF_t_70_pic_center 13]: /images/20220829/873c5bebf76e4072a015b782df29d9aa.png