HCIA-Big Data华为认证大数据工程师在线课程笔记
文章目录
- 一、简介
- 二、HDFS分布式文件系统
- 三、MapReduce分布式离线批处理和Yarn资源协调
- 四、Spark2.x基于内存的分布式计算
- 五、HBase分布式NoSQL数据库
-
-
-
- HBase架构
- 关键流程和特性
- FusionInsight HBase优化
-
-
- 六、Hive分布式数据仓库
-
-
-
- 概述和架构
- 数据存储模型
-
-
- 七、Streaming分布式流计算引擎
-
-
-
- 简介
- 系统架构
- Streaming特性
- 华为StreamCQL介绍
-
-
- 八、Flink流计算处理和批处理平台
-
-
-
- 概述
- 架构
- 底层原理
- 窗口概念
- 容错机制
- Flink在FusionInsight HD中的集成情况
-
-
- 九、Loader数据转换
-
-
-
- 模块架构
- 作业管理
-
-
- 十、 Flume海量日志聚合
-
-
-
- Flume架构
- Flume组件
-
-
- 十一、Kafka分布式消息订阅系统
-
-
-
- 关键流程
-
-
- 十二、ZooKeeper集群分布式协调服务
-
-
-
- 系统架构
- 关键特性
- ACL访问控制列表
- 常用命令
- 与其它组件的关系
-
-
- 十三、FusionInsight HD解决方案
- 十四、结课测试
一、简介
- 大数据与传统数据
大数据是指利用常用软件工具捕获、管理和处理数据所耗时间超过可容忍时间的数据集。
| 对比项 | 数据库 | 大数据 |
|---|---|---|
| 数据规模 | 小（以MB为处理单位） | 大（以GB、TB、PB为处理单位） |
| 数据类型 | 单一（结构化为主） | 繁多（结构化、半结构化、非结构化） |
| 模式和数据的关系 | 先有模式后有数据 | 先有数据后有模式，模式随数据增多不断演变 |
| 处理对象 | 数据（池塘中的鱼） | 预测（“鱼”，通过某些鱼判断其它种类的鱼是否存在） |
| 处理工具 | One size fits all | No size fits all |
- Hadoop生态体系
Hadoop成为大数据批量处理的基础，但无法提供实时分析。
- Intel M/R Hadoop（商业改进）
- 华为大数据平台架构（FusionInsight HD）
- Hadoop层提供大数据处理环境，基于社区开源原件增强；
- DataFarm层提供支撑端到移动端数据洞察，构建数据到信息到知识到智慧的数据供应链，其中数据集成服务Porter，数据挖掘服务Miner和数据服务框架Farmer；
- Manager是一个分布式系统管理框架，管理员可以从单一接入点操控分布式集群，包括系统管理、数据安全管理和数据治理。
二、HDFS分布式文件系统
HDFS(Hadoop Distributed File System)是Hadoop技术框架中的分布式文件系统，对部署在多台独立物理机器上的文件进行管理；
HDFS架构包含三个部分：NameNode，DataNode，Client。
- HDFS特性
- 高容错性：认为硬件总是不可靠的；
- 高吞吐量：对大量数据访问的应用提供吞吐量支持；
- 大文件存储：支持存储TB-PB级别的数据。
- 擅长：大文件存储与访问、流式数据访问
- 不擅长：大量小文件存储、随机写入、低延迟读取
- HDFS基本系统架构
- Client：接收数据处理请求转发给NameNode
- NameNode：数据存储的元数据信息（基于内存）
- DadaNode：数据实际存储的地方（基于磁盘，最小单位block大小为128M）
- HDFS高可靠性
NameSpace内存元数据的实时变化被实时计算并写入主备磁盘中；
当主NameNode故障时通过Zookeeper启动备NameNode加载最新元数据进内存向外提供服务；
当DataNode故障时（未及时向NameNode发送心跳），NameNode开启副本复制。
- HDFS联邦机制
数据存储的元数据存储在NameNode的内存中，默认情况下只有一个NameNode被设置为活跃状态；
当元数据的大小超过单个NameNode的内存存储能力，采用联邦机制将元数据通过Namespace划分并派发至多个NameNode向外提供服务。
- HDFS数据存储策略
- 分级存储：DataNode上存在不同的存储设备，数据需要选择一个合适的存储设备分级存储数据；
HDFS的分级存储框架提供了RAM_DISK（内存盘）、DISK（机械硬盘）、ARCHIVE（高密度低成本存储介质）、SSD（固态硬盘）四种存储类型的存储设备。
通过对四种存储类型进行合理组合，即可形成适用于不同场景的存储策略。
注：策略ID=15即第一个副本存储在RAM_DISK（或备选的DISK），其余副本存储在DISK；
- 标签存储：DataNode不同目录中的数据重要程度不同，数据需要根据目录标签选择一个合适的DataNode节点保存；
NameNode可以为目录和DataNode指定标签，数据存储时会进行模式匹配。
注：/Flume数据只可以存储在DataNode E和DataNode F。
- 节点组存储：DataNode集群使用了异构服务器，关键数据需要保存在具有高度可靠性的节点组中。
每份数据必须要有一个副本存储在指定的机架组中。
三、MapReduce分布式离线批处理和Yarn资源协调
MapReduce基于Google发布的MapReduce论文设计开发，用于大规模数据（大于1TB）的并行计算；
Apache Hadoop YARN（Yet Another Resource Negotiator）是一种新的Hadoop资源管理器，它是一个通用资源管理系统，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。
- Without Yarn：HIVE、M/R、Spark、Storm、Flink各自向HDFS/HBase申请资源，其申请的资源互相不通；
- With Yarn：HIVE、M/R、Spark、Storm、Flink统一交由Yarn协调HDFS/HBase资源，资源统一由Yarn分配回收。
- Yarn高可用方案
Yarn中的ResourceManager负责整个集群的资源管理和任务调度。
当前Yarn支持内存和CPU两种资源类型的管理和分配。
四、Spark2.x基于内存的分布式计算
Apache Spark是一种基于内存的快速、通用、可扩展的集批处理、实时流处理、交互式查询、图计算与机器学习于一体的大数据计算引擎；其核心组件是Spark Core。
- 生态圈
- 对比HDFS
M/R计算流程中存在多个落地磁盘的操作，而Spark一直是基于内存。
- Spark Core核心概念
- RDD（Resilient Distributed Datasets）即弹性分布式数据集，是一个只读的，可分区的分布式数据集；
- RDD默认存储在内存，当内存不足时，溢写到磁盘；
- RDD数据以分区的形式在集群中存储；
- RDD具有血统机制（Lineage），发生数据丢失时，可快速进行数据恢复。
- Spark引擎
| 引擎 | 说明 |
|---|---|
| Spark SQL | Spark的一个模块，主要用于进行结构化数据的处理，DataFrame是核心的编程抽象； |
| Spark Streaming | Spark核心API的一个扩展，可以实现高吞吐量的、具备容错机制的实时流数据处理； |
| Structured Streaming | 构建在Spark SQL引擎上的流式数据处理引擎，可以实现用处理静态数据的方式去处理流数据。 |
- Spark在FusionInsight集群中
- HDFS：Spark在HDFS文件系统中读写数据（必选）
- YARN：Spark任务依赖Yarn来进行资源的调度管理（必选）
- Hive：Spark-SQL的元数据和数据文件与Hive完全共用（必选）
- Zookeeper：JDBCServer的HA实现依赖于Zookeeper的协调（必选）
- Kafka：Spark可以接收Kafka发送的数据流（可选）
- HBase：Spark可以操作HBase中的表（可选）
五、HBase分布式NoSQL数据库
- HBase：是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统；
- 利用Hadoop HDFS（Hadoop Distributed File System）作为其文件存储系统，提供实时读写的分布式数据库系统；
- 利用Zookeeper作为协同服务；
- 集群有HMaster和HRegionServer两个角色 。
- 与关系型数据库的区别
| RDS | HBase |
|---|---|
| 数据结构固定 | 分布式存储，面向列 |
| 需要预先定义好数据结构 | 列无需事先定义，可实时扩展 |
| 需要大量IO，扩展成本大 | 普通商用硬件支持，扩容成本低 |
HBase架构
- HMaster
- 负责管理所有的HRegionServer；
- 负责建表、修改表、删除表以及一些集群操作；
- 负责所有HRegion的转移操作：
3.1 新表创建时的HRegion分配
3.2 运行期间的负载均衡保障
3.3 HRegionServer Failover后的HRegion接管
- HRegionServer
- 是HBase的数据库服务进程，负责处理用户数据的读写请求；
- HRegion由HRegionServer管理，所有用户数据的读写请求，都是和HRegionServer上的HRegion进行交互；
- HRegion可以在HRegionServer之间迁移。
- HRegion
- 将一个数据表按RowKey范围连续划分为多个的子表，这个子表，在HBase中被称作Region；
- 每一个Region都关联一个Key值范围，即一个使用StartKey和EndKey描述的区间；
- Region是HBase分布式存储的最基本单元；
- Region分为Meta Region及User Region两类；
- Meta Region记录了每一个User Region的路由信息；
- 读写Region数据时先找寻Meta Region地址，再通过Meta Region找寻User Region的地址。
- HRegionServer中其它组件
- Hlog：日志保证了当RegionServer故障的情况下用户写入的数据不丢失，RegionServer的多个Region共享一个相同的Hlog；
- Store：一个Region由一到多个Store组成，每个Store对应一个Column Family（列族）；
- MemStore：一个Store包含一个MemStore，用来缓存客户端向Region插入的数据；
- StoreFile：MemStore的数据flush到HDFS后成为StoreFile；
- HFile：定义了StoreFile在文件系统中的存储格式，它是当前HBase系统中StoreFile的具体实现；
- Cloumn Family
- 是Region的一个物理存储单元，同一个Region下面的多个Column Family位于不同的路径下面；
- Column Family信息是表级别的配置，也就是说同一表的多个Region都拥有相同的Column Family信息。
- Zookeeper与HBase
- 分布式锁服务：多个HMaster进程都尝试去Zookeeper中写入一个对应的节点，该节点只能被一个HMaster进程创建成功，创建成功的HMaster进程就是Active；
- 事件监听机制：主HMaster进程宕机后，该节点会被删除，其它的备HMaster就可以收到相应的消息；
- 微型数据库角色：Zookeeper中存放了Region Server的地址。
- Meta Region
- 元数据表：记录User Region的信息，用来帮助HClient定位到具体的Region；
- 元数据表也会被切分为多个Region，Region的元数据信息保存在Zookeeper中。
关键流程和特性
- 写流程
- 定位Region：通过Zookeeper中的Meta Region确认RegionServer、Region及RowKey信息（图书管理员询问一本图书应放置于图书馆哪一层RegionServer的哪个区域Region的哪个范围RowKey）
- 数据分组：根据RowKey将数据划分到指定的Region中
- 数据发送：利用HBase自身封装的RPC框架，将分好组的数据并行发送各个RegionServer；
- 数据刷写：数据默认写入MemStore，当其到达阈值、内存占比、文件数量、刷写周期或指定shell命令将数据刷写到磁盘。
- Compaction
目的是为了减少同一个Region中同一个ColumnFamily下面的小文件（HFile）数目，从而提升读写性能。
- Region Split
- 指集群运行期间某一个Region的大小超出了预设的阈值，需要对其进行拆分；
- 分裂过程中，该Region会暂停读写服务；
- 分裂完成后，客户端缓存的父Region的路由信息需要被更新。
- 读流程
- Get：提供精确RowKey读取单行用户数据；
- Scan：批量扫描限定Key值范围内的用户数据
- BloomFilter：优化Get场景中判断一条用户数据是否存在于一个大的数据集合
- Filter：在Scan过程中设定一定的过滤条件
FusionInsight HBase优化
- 二级索引
二级索引为HBase提供了按照某些列的值进行索引的能力。
- MOB：解决需要在HDFS需要存储海量小文件的场景
- 将小文件直接以HFile的格式存储在文件系统上，然后把这个文件的地址信息及大小信息作为value存储在普通HBase的store上，然后通过工具集中管理这些文件。
- HFS：解决需要在HDFS需要存储（检索）海量小文件的场景
六、Hive分布式数据仓库
Hive是基于Hadoop的数据仓库软件，可以查询和管理PB级别的分布式数据；
Hive的基本原理是将HQL语言自动转换成MapReduce任务；
Hive是一种数据仓库处理工具，使用类SQL的HiveQL语言实现数据查询功能，所有的Hive数据都存储在HDFS中。
概述和架构
- 特性
- 灵活方便的ETL（extract/transform/load）
- 支持MapReduce（默认）、Tez、Spark等多种计算引擎
- 可直接访问HDFS文件以及HBase
- 架构
- Driver：负责HQL的编译、优化和执行
- Command Line Interface … JDBC：对外访问接口（数据直接存储在HDFS）
- MetaStore：存储元数据（元数据可以存储在MySQL）
- FusionInsight HD中Hive的架构
Hive分为三个角色HiveServer、WebHcat、MetaStore；
- HiveServer：将用户提交的HQL语句进行编译，解析成对应的Yarn任务、Spark任务或者HDFS操作，从而完成数据的提取、转换、分析；
- WebHcat：对外提供基于https协议的元数据访问、DDL查询等服务。
- MetaStore：提供元数据服务；
数据存储模型
Hive数据表可以按照某个字段的值划分分区，可以根据桶的方式将不同数据放入不同的桶中。
- 分区：数据表可以按照某个字段的值划分分区
- 每个分区是一个目录
- 分区数量不固定
- 分区下可再有分区或者桶
- 桶：数据可以按照桶的方式将不同数据放入不同的桶中
- 每个桶是一个文件
- 建表时指定桶个数，桶内可排序
- 数据按照某个字段的值Hash后放入某个桶中
- 托管表和外部表
- 默认创建托管表，Hive会将数据移动到数据仓库目录；
- 创建外部表，这时Hive不会生成数据仓库目录，元数据中指向外部访问位置；
- 如果所有处理都由Hive完成，建议使用托管表；
- 如果要用Hive和其它工具来处理同一个数据集，建议使用外部表。
| 操作 | 托管表 | 外部表 |
|---|---|---|
| CREATE/LOAD | 数据移动到仓库目录 | 数据位置不移动 |
| DROP | 元数据和数据会被一起删除 | 只删除元数据 |
- Hive SQL
- DDL数据定义语言：建表、修改表、删表、分区、数据类型
- DML数据管理语言：数据导入、数据导出
- DQL数据查询语言：简单查询和复杂查询Group by、Order by、Join等
七、Streaming分布式流计算引擎
Streaming基于开源Storm，是一个分布式、实时计算框架；
简介
- 特点
- 实时响应，低延迟
- 数据不存储，先计算
- 连续查询
- 事件驱动
| 对比项 | SparkStreaming | Streaming |
|---|---|---|
| 任务执行方式 | 执行逻辑即时启动，运行完回收 | 执行逻辑预先启动，持续存在 |
| 事件处理方式 | 事件积累到一定量时才进行处理 | 事件实时处理 |
| 时延 | 秒级 | 毫秒级 |
| 吞吐量 | 高（约为Streaming的2~5倍） | 较高 |
系统架构
- 基本概念
- Topology：Streaming中运行的一个实时应用程序；
- Nimbus（主备HA）：负责资源分配和任务调度；
- Supervisor：负责接受Nimbus分配的任务，启动和停止属于自己管理的worker进程；
- Worker：Topology运行时的物理进程，每个Worker是一个JVM进程；
- Spout：在一个Topology中产生源数据流的组件；
- Bolt：在一个Topology中接受数据然后执行处理的组件；
- Task：Worker中每一个Spout/Bolt的线程称为一个Task；
- Tuple：Streaming的核心数据结构，是消息传递的基本单元，不可变Key-Value对，这些Tuple会以一种分布式的方式进行创建和处理；
- Stream：一个无边界的连续Tuple序列；
- Zookeeper：为Streaming服务中各进程提供分布式协作服务。主备Nimbus、Supervisor、Worker将自己的信息注册到Zookeeper中，Nimbus据此感知各个角色的健康状态。
Nimbus不直接向Supervisor分配任务而是通过Zookeeper。
- Topology
一个Topology是由一组Spout组件（数据源）和Bolt组件（逻辑处理）通过Stream Groupings进行连接的有向无环图（DAG）；
业务处理逻辑被封装进Streaming中的Topology中。
- Worker
- Worker：一个Worker是一个JVM进程，所有的Topology都是在一个或者多个Worker中进行的；Worker启动后是长期运行的，除非人工停止；Worker进程的个数取决于Topology的设置，且无设置上限，具体可获得调度并启动的Worker个数取决于Supervisor配置的slot个数；
- Executor：在一个单独的Worker进程中会运行一个或多个Executor线程；每个Executor只能运行Spout或者Bolt的一个或多个task实例；
- Task：最终完成数据处理的实体单元。
- Task
Topology里面的每一个Component（Spout/Bolt）节点都是并行运行的。在Topology里面，可以指定每个节点的并发度，Streaming则会在集群里面分配相应的Task来同时计算，以增强系统的处理能力。
Streaming特性
- 消息可靠性
在Streaming里面一个tuple被完全处理的意思是：这个tuple以及由这个tuple所派生的所有tuples都被成功处理；如果这个消息在Timeout所指定的时间内没有成功处理，这个tuple就被认为处理失败了。
| 可靠级别 | 处理机制 | 说明 |
|---|---|---|
| 最多一次 | 无 | 吞吐量最大，适用于消息可靠性较低的场景 |
| 最少一次 | ack | 吞吐量较低，要求数据被完整处理，适用于消息可靠性要求较高的场景 |
| 精确一次 | trident | Trident是Streaming提供的特殊的事务性API，吞吐量最低 |
- ACK机制
华为StreamCQL介绍
StreamCQL是建立在分布式流处理平台基础上的查询语言(CQL)，架构支持构建在多种流处理引擎之上，目前主要适配Streaming 。
StreamCQL提供了较丰富的分布式计算功能，除了具有过滤、转换等传统的SQL基本能力以外，StreamCQL引入基于流的时间窗口的计算，提供窗口数据的统计、关联等能力，以及流数据的拆分、合并等功能。
八、Flink流计算处理和批处理平台
概述
Flink是一个批处理和流计算处理结合的统一计算框架，其核心是提供了数据分发以及并行计算的流数据处理引擎。它的最大亮点是流处理，是业界最顶级的开源流处理引擎。
- 事件驱动/时间驱动
- Spark：时间驱动，电梯，波次
- Storm（Streaming）：事件驱动，扶梯，源源不断
- Flink：事件驱动，且能够保证数据只处理一次
- Hadoop兼容性
- Flink能够支持Yarn，能够从HDFS和HBase中获取数据；
- 能够使用所有的Hadoop的格式化输入和输出；
- 能够使用Hadoop原有的Mappers和Reducers，并且能与Flink的操作混合使用；
- 能够更快的运行Hadoop作业。
架构
- 核心概念：DataStream
Flink用类DataStream来表示程序中的流式数据。用户可以认为它们是含有重复数据的不可修改的集合（collection），DataStream中元素的数量是无限的。
- DataStream组成
- Data source：流数据源的接入，支持HDFS文件、Kafka、文本等；
- Transformations：流数据转换；
- Data sink：数据输出，支持HDFS文件、Kafka、文本等。
- 运行流程中的关键角色
- Client：需求提出方，负责提交需求（应用），构造流图；
- JobManager：负责应用的资源管理，根据应用的需要，向资源管理部门（ResourceManager）申请资源；
- Yarn的ResourceManager：资源管理部门，负责整个集群的资源统一调度和分配；
- TaskManager：负责实际计算工作，一个应用会拆分给多个TaskManager来进行计算。
Stand alone模式
Flink on YARN
底层原理
用户实现的Flink程序是由Stream数据和Transformation算子组成；
Stream是一个中间结果数据，而Transformation是算子，它对一个或多个输入Stream进行计算处理，输出一个或多个结果Stream。
窗口概念
窗口是处理无限流的核心，Flink 认为 Batch 是 Streaming 的一个特例；
Flink 底层的引擎是一个流式引擎，在上面实现了流处理和批处理，而窗口（Window）就是从streaming 到 batch 的一个桥梁。
- 窗口：Flink支持基于事件窗口操作，也支持基于数据的窗口操作
- 按分割标准划分：timeWindow（按时间）、countWindow（按次数）
- 按窗口行为划分：Tumbling Window、Sliding Window、自定义窗口
timeWindow和countWindow
Tumbling Window：滚动窗口，窗口之间事件不重叠，但数据点可能被切割
Sliding Window：滑动窗口，窗口之间时间点存在重叠
Session Window：会话窗口，经过一段设置时间无数据认为窗口完成
容错机制
- 容错功能
- checkpoint机制是Flink运行过程中容错的重要手段；
- checkpoint机制不断绘制流应用的快照，流应用的状态快照被保在配置的位置（如JobManager的内存里或者HDFS上）；
- Flink分布式快照机制的核心是barriers，这些barriers周期性插入到数据流中，并作为数据流的一部分随之流动。
- Checkpoint机制
- Checkpoint机制是Flink可靠性的基石，可以保证Flink集群在某个算子因为某些原因（如异常退出）出现故障时，能够将整个应用流程图的状态恢复到故障之前的某一状态，保证应用流图状态的一致性；
- 该机制可以保证应用在运行过程中出现失败时，应用的所有状态能够从某一个检查点恢复，保证数据仅被处理一次（Exactly Once）；另外，也可以选择至少处理一次（at least once）。
Flink在FusionInsight HD中的集成情况
FusionInsight HD提供大数据处理环境，基于社区开源软件增强，按照场景选择业界最佳实践；
Flink是批处理和流处理结合的统一计算框架，用于高并发pipeline处理数据，时延毫秒级的场景响应，且兼具可靠性。
- Flink与其它组件交互
- HDFS：Flink在HDFS文件系统中读写数据（必选）；
- YARN：Flink任务的运行依赖YARN来进行资源的调度管理（必选）；
- Zookeeper：Flink的checkpoint的实现依赖于Zookeeper（必选）；
- Kafka：Flink可以接收Kafka发送的数据流（可选）
九、Loader数据转换
Loader基于开源软件Sqoop增强，是实现FusionInsight HD与关系型数据库、文件系统之间交换数据和文件的数据加载工具。
Loader提供可视化向导式的作业配置管理界面；提供定时调度任务，周期性执行Loader作业；在界面中可指定多种不同的数据源、配置数据的清洗和转换步骤、配置集群存储系统等。
- 应用场景
- 与Flume的区别
- Loader用来进行批数据的加载；
- Flume用来进行流数据的采集。
模块架构
| 名称 | 说明 |
|---|---|
| Loader Client | 客户端，包括WebUI和CLI两种交互界面； |
| Loader Server | 服务端，主要功能包括：处理客户端请求，管理连接器和元数据，提交MapReduce作业和监控MapReduce作业状态等； |
| REST API | 实现RESTful（HTTP+JSON）接口，处理来自客户端的请求； |
| Job Scheduler | 简单的作业调度模块，支持周期性的执行Loader作业； |
| Transform Engine | 数据转换处理引擎，支持字段合并、字符串剪切、字符串反序等； |
| Execution Engine | 作业执行引擎，包含MapReduce作业的详细处理逻辑； |
| Submission Engine | 作业提交引擎，支持将作业提交给MapReduce执行； |
| Job Manager | 管理Loader作业，包括创建、查询、更新、删除、激活、去激活、启动和停止作业； |
| Metadata Repository | 元数据仓库，存储和管理Loader的连接器、转换步骤、作业等数据； |
| HA Manager | 管理Loader Server进程的主备状态，Loader Server包含2个节点，以主备方式部署。 |
作业管理
作业用来描述将数据从数据源经过抽取、转换和加载至目的端的过程；它包括数据源位置及属性、从源数据到目标数据的转换规则、目标端属性。
- 作业流程（UI界面）
- 基本信息：指定YARN租户队列
- 输入配置：指定输入路径和文件分割方式，可选过滤器
- 转换：指定输入算子、转换算子（可选）和输出算子
- 输出配出：指定存储类型和输出目录
- 客户端脚本
Loader除了提供图形化操作界面外，还提供了一套完整的shell脚本。
- lt-ctl：作业控制工具，用于查询作业状态、启动/停止作业以及判断作业是否正在运行中；
- lt-ucj：作业管理工具，用于查询、创建、修改和删除作业；
- lt-ucc：数据源管理工具，用于查询、创建、修改和删除数据源连接信息。
十、 Flume海量日志聚合
Flume是流式日志采集工具，提供对数据进行简单处理并且写到各种数据接受方的能力。
- Power of Flume
- 从固定目录下采集日志信息到目的地（HDFS，HBase，Kafka）；
- 实时采集日志信息（taildir）到目的地；
- 支持级联（多个Flume对接起来），合并数据的能力；
- 支持按照用户定制采集数据的能力。
- 在FusionInsight中
Flume架构
- 基础架构：从单点直接采集数据，主要应用于集群内数据
- 多Agent架构：将多个节点连接起来，将最初的数据源经过收集，存储到最终的存储系统中；主要应用于集群外的数据导入到集群内。
Flume组件
Source采集数据经过Interceptor简单清洗后进行Channel Selector进入不同的Channel最终Sink到不同目的地。
- Source：必须至少与一个Channel相连
- 负责接收events或通过特殊机制产生events，并将events批量放到一个或多个Channels；
- Channel：可以连接任意数量的Source和Sink
- 位于Source和Sink之间，作用类似于队列用来临时缓存进来的events，当Sink成功地将events发送到下一跳的Channel或最终目的，events从Channel移除；
- Memory Channel不会持久化；File Channel基于WAL预写式日志Write Ahead Log实现；JDBC Channel基于嵌入式Database实现；
- Channel支持事务，提供较弱的顺序保证。
- Sink：必须确切与一个Channel相连
Sink负责将events传输到下一跳或最终目的，成功完成后将events从channel删除。
| 类型 | 说明 |
|---|---|
| hdfs sink | 将数据写到hdfs |
| avro sink | 使用avro协议将数据发送给另一跳的flume |
| thrift sink | 同avro，不过传输协议为thrift |
| file roll sink | 将数据保存在本地文件系统中 |
| hbase sink | 将数据写到hbase |
| kafka sink | 将数据写入到kafka |
| MorphlineSolr sink | 将数据写入到solr |
十一、Kafka分布式消息订阅系统
Kafka 是一个高吞吐、分布式、基于发布订阅的消息系统；
一个典型的Kafka集群中包含若干Producer、若干Broker、若干Consumer，以及一个Zookeeper集群 。
- 应用场景
Kafka和其它组件比较，具有消息持久化、高吞吐、实时等特性，适用于离线和实时的消息消费，如网站活动跟踪、聚合统计系统运营数据（监控数据）、日志收集等大量数据的收集场景。
- 在FusionInsight产品中
-
拓扑结构图
-
Topis
- Partition
每个Topic都有一个或者多个Partition构成；每个Partition都是有序且不可变的消息队列；引入Partition机制，保证了Kafka的高吞吐能力。
某个Partition只能被同一个Cousumer Group中的一个Cousumer消费。
- Partition偏移量
每条消息在文件中的位置成为offset（偏移量），是一个long长整型数字，它唯一标记一条消息；消费者通过topic、partition和offset跟踪记录消息。
- Partition副本
Partition拥有副本
Follower Partition主动向Leader Partition拉取数据
- Logs数据文件和index索引文件
Kafka把Topic中一个Partition大文件分成多个小文件段，通过多个小文件段，就容易定期清理或删除已经消费完的文件，减少磁盘占用。
通过index文件快速定位segment数据文件进行delete/reads/append操作
- Log Cleanup日志清理
- 日志的清理方式有两种：delete和compact
- 删除的阈值有两种：过期的时间和分区内总日志大小
| 配置参数 | 默认值 | 参数解释 | 取值范围 |
|---|---|---|---|
| log.cleanup.policy | delete | 当日志过期时（超过了要保存的时间）采用的清除策略，可以取值为删除或压缩 | delete或compact |
| log.retention.hours | 168 | 日志保存时间（小时） | 1~2147483647 |
| log.retention.bytes | -1 | 指定每个Partition上的日志数据能够达到的最大字节，默认无限制 | -1~9223372036854775807 |
- Message Delivery Semantics数据传输机制
- 最多一次（At Most Once）：消息可能丢失，消息不会丢失，
- 最少一次（At Least Once）：消息不会丢失，消息可能会重复发送和处理
- 仅有一次（Exactly Once）：消息不会丢失，仅会被处理一次
- Cluster Mirroring：集群间复制数据
关键流程
- 写流程：明确要写入哪个Topic下、哪个Partition中
- 读流程：连接指定TopicPartition所在的Leader Broker，主动获取消息
十二、ZooKeeper集群分布式协调服务
ZooKeeper 分布式服务框架主要是用来解决分布式应用中经常遇到的一些数据管理问题，提供分布式、高可用性的协调服务能力;
安全模式下ZooKeeper依赖于Kerberos和LdapServer进行安全认证；
系统架构
- ZooKeeper集群由一组Server节点组成，这一组Server节点中只存在一个Leader节点，其他节点都为Follower ;
- 启动时选举出Leader，拿到半数以上票数；
- ZooKeeper使用自定义的原子消息协议，保证了整个系统中的节点数据一致性；
- Leader节点在接收到数据变更请求后，先写磁盘再写内存。
关键特性
- 关键特性
- 最终一致性：无论哪个server，对外展示的均是同一视图
- 实时性：保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息；
- 可靠性：一条消息被一个server接收，它将被所有的server接受；
- 等待无关性：慢的或者失效的client不会干预快速的client的请求，使得每个client都能有效的等待；
- 原子性：更新只能成功或者失败，没有中间状态；
- 顺序一致性：客户端所发送的更新会按照它们被发送的顺序进行应用。
- 读特性
由ZooKeeper的一致性可知，客户端无论连接哪个server，获取的均是同一个视图；所以，读操作是可以在客户端与任意server节点间完成。
- 写特性
只有Leader Server可以执行写操作，之后分发各个Follower Server且只要半数以上从节点回复ACK后就认为本次写操作执行成功。
ACL访问控制列表
ACL可以控制访问ZooKeeper的节点，只能应用于特定的znode上，而不能应用于该znode的所有子节点上；设置ACL命令为
setACL /znode schema:id:perm
- Schema为认证方式
- world：一个单独的ID，表示任何人都可以访问
- auth：不使用ID，只有认证的用户可以访问
- digest：使用username:password生成MD5哈希值作为认证ID
- IP：使用客户端主机IP地址来进行认证
- ID：用来认证的字段，不同的schema的认证方式不同
- Perm：权限，通过ACL认证的用户对该节点可拥有的操作权限
常用命令
| 命令 | 说明 |
|---|---|
| 调用客户端 | zkCli.sh -server IP:24002 |
| 创建节点 | create /node |
| 列出节点子节点 | ls /node |
| 创建节点数据 | set /node data |
| 获取节点数据 | get /node |
| 删除节点 | delete /node |
| 删除节点及所有子节点 | deleteall /node |
与其它组件的关系
- 日志增强
- Ephemeral Node（临时节点）在session过期之后就会被系统删除；
- 在审计日志添加Ephemeral Node被删除的审计日志，以便了解当时Ephemeral Node的状态信息。
- Streaming
- HDFS
- YARN
- HBase
十三、FusionInsight HD解决方案
FusionInsight解决方案由4个子产品FusionInsight HD、FusionInsight MPPDB、FusionInsight Miner、FusionInsight Farmer和1个操作运维系统FusionInsight Manager构成；
FusionInsight HD：企业级的大数据处理环境，是一个分布式数据处理系统，对外提供大容量的数据存储、分析查询和实时流式数据处理分析能力。
- 平台架构
- 双平面组网
- 华为端优化
- HBase易开发增强API
- SparkSQL
- SparkSQL多租户
-
SparkSQL小文件优化
-
HBase可视化建模
-
HBase应用透明的冷字段合并
-
HBase二级索引
-
HFS小文件存储与检索引擎
- NTP自动配置
- 营销系统架构
十四、结课测试
- 大数据的4V特征：Volume、Veracity、Value、Velocity
- 计算机存储单位：bit、B、KB、MB、GB、TB、PB、EB、ZB、YB
- 华为大数据平台架构：Porter数据集成服务、Miner数据挖掘服务、Farmer数据框架服务、LibrA数据仓库服务
- HDFS副本存放机制：本地节点B1->不同机架的不同节点B2/B4->同机架的不同节点B3
- Hive建表时的文件存储格式：TextFile（默认的文件不压缩）、SequenceFile、RcFile、OrcFile
- Streaming相对于Spark Streaming时延更低，但同时吞吐量也更低
- Flink部署方式：Local、Cluster、Cloud