大数据基础 分手后的思念是犯贱 2022-09-02 03:46 111阅读 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
还没有评论,来说两句吧...