大数据各类服务组件架构笔记

1 Hadoop

Hadoop是Apache软件基金会旗下的开源分布式存储 计算 平台，它以HDFS（Hadoop Distributed File System）和MapReduce为核心，为用户提供了系统底层细节透明的分布式基础架构。

下图是Hadoop生态应用场景：

1.1 HDFS

Hadoop 分布式文件系统 (HDFS) 是 Hadoop 应用程序使用的主要存储系统。

1.1.1 架构

1.1.2 节点

HDFS集群由NameNode和DataNode组成，NameNode管理文件系统的元数据，DataNode存储实际的数据。

客户端联系NameNode获取文件的元数据，而真正的文件I/O操作直接和DataNode进行交互。

• NameNode：元数据节点，用来管理文件系统的命名空间 、 集群配置信息和存储块的复制等；元数据保存在一个文件系统树中，硬盘上保存为文件——命名空间镜像(FS image)及修改日志(edit log)
• NameNode备节点：从元数据节点是元数据节点出现问题时候的备用节点，帮助元数据节点将内存中的元数据信息checkpoint到硬盘上

下图为命名空间映像文件的checkpoint

• DataNode：文件存储的基本单元，它将Block存储在本地文件系统中，保存了Block的Meta-data，同时周期性地将所有存在的Block信息发送给NameNode

1.1.3 可靠机制

一个名字节点和多个数据节点	数据节点故障检测 ZKFC
1、 数据复制（冗余机制）	1、 心跳包（检测是否宕机）
2、 存放的位置（机架感知策略）	2、 块报告（安全模式下检测）
3、 名字节点（日志文件，镜像文件）	3、 数据完整性检测（校验和比较
4、 空间回收机制

1.2 MapReduce

MapReduce是一种编程模型，用于大规模数据集（大于1TB）的并行运算。

• Map（映射）：Mapper负责“分”，即把复杂的任务分解为若干个“简单的任务”来处理
• Reduce（归约）：Reducer负责对map阶段的结果进行汇总
  

1.2.1 引擎架构

MapReduce 引擎由一个单独运行在主节点Master上的ResourceManager 和运行在每个集群从节点Slave上的NodeManager 共同组成。

ResourceManager 由 调度器（scheduler） 和 应用管理器（ApplicationManager） 构成；

• 调度器仅负责资源的分配
• 应用管理器负责接收提交的任务，协商获取第一个资源容器用于执行应用的任务主体并为重启失败的应用主体分配容

NodeManager负责启动应用的容器（Container），监控容器的资源使用（包括CPU、内存、硬盘和网络带宽等），并把这些信息汇报给调度器。

应用对应的应用主体通过协商从调度器处获取资源容器，并跟踪这些容器的状态和应用执行情况。

1.3 Yarn

Yarn组件是Hadoop体系中的分布式计算基础组件，它与HDFS构成了Hadoop体系中分布式应用的基础。

Yarn提供集群分布式计算服务，可实现多任务管理和多种资源调度算法，充分利用集群实现高效运算。

MapReduce(MR)是Yarn上面最重要的运算之一，它是一种编程运算模型或方法，将大的作业分拆成多个任务、分布运算、再汇总得出结果。

其它众多Hadoop组件也支持基于Yarn进行运算，如Hbase,Hive,Spark等。

1.3.1 架构

容器（Container）：

• 容器是单个节点上物理资源（如RAM，CPU核或磁盘）的集合
• 单个节点上可以有多个Container；系统中的每个节点由内存（如512M或1G)和CPU最小容量的多个Container组成。应用主体可以请求任何Container来占据最小容量的整数倍的资源。
• 容器代表了任何节点上的一组资源，由NodeManager监控，由ResourceManager调度
• 每一个应用程序都是从ApplicationMaster开始，它本身就是一个容器。一旦启动ApplicationMaster可以向ResourceManager协商更多的容器。在运行的过程中可以动态申请和释放容器。

资源管理器（ResouceManager）

根据功能不同将资源管理器分成两个组件

• 调度器（scheduler）
  • 调度器根据集群中容量、队列和资源等限制，将资源分配给各个正在运行的应用。
  • 调度器，仅负责资源的分配，而不负责监控各个应用执行情况和任务失败、应用失败或硬件失败时的重启任务。
  • 调度器根据各个应用的资源需求和集群各个节点的资源容器（Resource Containner，是集群节点将自身内存、CPU、磁盘等资源封装在一起的抽象概念）进行调度。
• 应用管理器（ApplicationManager）
  • 应用管理器负责接收作业，协商获取第一个资源容器用于执行应用的任务主体并为重启失败的应用主体分配容器。

调度器（scheduler）

CapaCity调度器

1. 层次化的队列设计
2. 容量保证，队列上都会设置一个资源的占比。
3. 安全，每个队列有严格的访问控制。
4. 弹性分配，
5. 多租户租用，
6. 操作性，Yarn支持动态修改调整容量、权限等的分配，可以在运行时直接修改。
7. 基于资源的调度，协调不同资源需求的应用程序，比如内存、CPU、磁盘等等

节点管理器（NodeManager）

是每个节点的框架代理。 集群每个节点上都有一个节点管理器，它主要负责:

• 为应用启用调度器已分配给应用的容器。
• 保证已启动的容器不会使用超过分配的资源量。
• 为task构建容器环境，包括二进制可执行文件,jar等；
• 为所有的节点提供一个管理本地存储资源的简单服务。
• 应用程序可以继续使用本地存储资源，即使它没有从资源管理器处申请。
  比如：MapReduce可以利用这个服务存储Map Task的中间输出结果并将
  其shuffle给Reduce Task。

应用主体（ApplicationMaster）

• 事件调度组件，是应用主体中各个组件的管理者，负责为其他组件生成事件。
• 容器分配组件，负责将Task的资源请求翻译成发送给调度器的应用主体的资源请求，并与资源管理器协商获取资源。
• 用户服务组件，将作业的状态、计数器、执行进度等信息反馈给Hadoop Mapreduce的用户。
• 任务监听组件，负责接收Map或Reduce Task发送的心跳信息。
• 任务组件，负责接收Map或Reduce Task形成的心跳信息和状态更新信息。
• 容器启动组件，通过使节点管理器运行来负责容器的启动。
• 作业历史事件处理组件，将作业运行的历史事件写入HDFS。
• 作业组件，维护作业和组件的状态。

1.4 ES（Elastic Search）

ES 是一个基于Lucene的高性能，高可用，开源的分布式全文搜索引擎；

1.4.1 ES架构

集群：ES可以独立的作为单个搜索服务器；为了处理大型数据集，实现容错和高可用性，ES可以运行在多台服务器上，这些服务器组成集群；

节点（Cluster）：形成集群的每台服务器，其实是指ES进程；

Master主节点：集群的状态由Master节点维护，生产中建议不存储数据，减轻主节点压力，普通服务器即可；

Data数据节点：存储索引数据，并且提供索引查询，消耗内存和磁盘；

Client节点：协调节点，接收客户端请求，并分发到数据节点，普通服务器即可；

1.4.2 Shard（分片）和 Replica（副本分片）

Shard：

其实叫 Primary shard（主分片），一般简称为 Shard；

单台机器无法存储大量数据，es可以将一个索引中的数据切分为多个shard，每个shard就会存储这个index的一部分数据，这些shard分布在多台服务器上存储；

• 横向扩展，存储更多数据；
• 数据分布在多个shard上 ，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能；

Replica：

其实叫 Replica shard（副本分片），一般简称为Replica；

任何一个服务器随时可能故障或宕机，此时shard可能就会丢失，因此可以为每个shard创建多个replica副本；

replica可以在shard故障时提供备用服务，保证数据不丢失，多个replica还可以提升搜索操作的吞吐量和性能；

• 高可用性，一个shard宕机，数据不丢失，服务继续提供；
• 提升了搜索请求的吞吐量和性能；

1.4.3 es核心基础概念

1.4.4 查看集群状态：

• green：所有分片都可用；

• yellow：主分片可用，副本分片不可用

• red：存在主分片不可用，出现数据丢失；

1.5 Flume

Apache Flume是一个分布式的、可靠的、高效的日志数据收集组件；我们通常使用Flume将分散在集群中多个Servers的log文件，汇集到中央式的数据平台中，以解决“从离散的日志文件中查看、统计数据困难”的问题。当然，Flume不仅仅可以收集log文件，它也支持比如TCP、UDP等消息数据的收集；无论如何，我们最终解决的问题就是“将离散的数据进行收集”。

1.5.1 架构

Flume的核心就是一个agent，agent本身是一个java进程，运行在日志收集节点—所谓日志收集节点就是服务器节点。

agent里面包含3个核心的组件：source—->channel—–>sink,类似生产者、仓库、消费者的架构。

source接收到数据之后，将数据发送给channel，channel作为一个数据缓冲区会临时存放这些数据，随后sink 会将channel中的数据发送到指定的地方—-例如HDFS等，注意：只有在sink 将channel中的数据成功发送出去之后，channel才会将临时数据进行删除，这种机制保证了数据传输的可靠性与安全性。

1.6 HBase

HBase – Hadoop Database，建立在HDFS之上，提供高可靠性、高性能、可伸缩、实时读写的分布式存储系统；

只能通过Rowkey进行检索，仅支持单行事务；

与Hadoop一样，HBase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力；

1.6.1 整体架构

zookeeper作用：

1. 确保Hbase集群只有一个HMaster处于avtive状态，出问题也可唤醒其他noactive的HMaster；
2. 实时监控HRegionServer的状态信息并将其上下线信息通知给HMaster；
3. 存储hbase:meta表的region的寻址入口；
4. 存储HBase的schema，table,column family信息；

HMaster作用：

1. 管理用户对table的DDL操作；
2. 管理HRegionServer的负载均衡、调整region的分布；
   HRegionServer宕机后，将其所管理的Region分配到其他机器；
3. 跨HRegionServer的操作由HMaster完成，其他client直接与HRegionServer通信；

HRegionServer作用：

1. 最核心进程，维护HMaster分配的HRegion，处理对HRegion的IO请求，进而 跟HDFS交互，从HDFS读写数据；
2. 对在运行过程中变得过大的HRegion进行切分；
3. 将存储在HDFS上的数据文件–HFile进行多个合并；

1.6.2 存储结构

• Rowkey：行键，用来检所记录的主键
• ColumnFamily：列族，是表元数据的一部分，创表前需定义；列名以列族为前缀，ex: info:height；一个列族对应一个store，HFile放在Store下面；
• Timestamp：时间戳；数据的每个版本都有一个时间戳可以对应；倒序排列
• Column：列；每个唯一单元由 行键+列族+列+时间戳

1.6.3 逻辑结构

1. 表中所有行都按照行键字典序排列，表在行的方向上分割为多个Region；这些Region分布在不同的Regionserver上；
2. Region由一个或者多个Store（列族）组成，每个Region只属于一台RegionServer；
3. 每一个Store又由一个MemStore和多个StoreFile组成；
4. MemStore：写缓存，HBase写入数据，先写到内存中，当达到一定阈值时再写入磁盘，生成HFile；

1.7 HIVE

Hive是基于Hadoop的一个数据仓库工具

• 将结构化的数据文件映射为一张数据库表
• 提供简单的SQL查询功能
• 将SQL语句转换为MapReduce任务进行运行
• 灵活的数据存储格式，支持JSON，CSV，TEXTFILE，RCFILE，SEQUENCEFILE等存储格式，并支持自定义扩展

1.8 SPARK

Spark是一个分布式计算框架，专注于分布式计算

1.8.1 spark生态圈

• Spark提供了多种高级工具： Spark SQL应用于即席查询（Ad-hoc query）、Spark Streaming应用于流式计算、 MLlib应用于机器学习、GraphX应用于图处理。
• Spark可以基于自带的standalone集群管理器独立运行，也可以部署在Apache Mesos 和 Hadoop YARN 等集群管理器上运行。
• Spark可以访问存储在HDFS、 Hbase、Cassandra、Amazon S3、本地文件系统等等上的数据，Spark支持文本文件，序列文件，以及任何Hadoop的InputFormat。
  

1.8.2 SPARK结构设计

Spark运行架构包括集群资源管理器（Cluster Manager）、运行作业任务的工作节点（Worker Node）、每个应用的任务控制节点（Driver）和每个工作节点上负责具体任务的执行进程（Executor）。

其中，集群资源管理器可以是Spark自带的资源管理器，也可以是YARN或Mesos等资源管理框架。

1.8.3 Spark运行基本流程

Spark的基本运行流程如下：

1. 当一个Spark应用被提交时，首先需要为这个应用构建起基本的运行环境，即由任务控制节点（Driver）创建一个SparkContext，由SparkContext负责和资源管理器（Cluster Manager）的通信以及进行资源的申请、任务的分配和监控等。
   SparkContext会向资源管理器注册并申请运行Executor的资源；

2. 资源管理器为Executor分配资源，并启动Executor进程，Executor运行情况将随着“心跳”发送到资源管理器上；

3. SparkContext根据RDD的依赖关系构建DAG图，DAG图提交给DAG调度器（DAGScheduler）进行解析，将DAG图分解成多个“阶段”（每个阶段都是一个任务集），并且计算出各个阶段之间的依赖关系，然后把一个个“任务集”提交给底层的任务调度器（TaskScheduler）进行处理；
   Executor向SparkContext申请任务，任务调度器将任务分发给Executor运行，同时，SparkContext将应用程序代码发放给Executor；

4. 任务在Executor上运行，把执行结果反馈给任务调度器，然后反馈DAG调度器，运行完毕后写入数据并释放所有资源。

引用 《【Spark】Spark基础教程》

1.9 Kafka

Kafka 是由 LinkedIn 开发的一个分布式的消息系统，因分布式水平扩展和高吞吐率受到广泛关注与使用。

Kafka的优势在于同时具有以下两种特性：可以扩展处理并且允许多订阅者模式（不需要只选择其中一个）。

1.9.1 Kafka拓扑结构

一个典型的Kafka集群中包含若干 producer（可以是 web 前端，或者是系统服务等），若干 broker（服务器），若干 consumer，以及一个 Zookeeper 集群。

kafka系统角色：

主题(topic)	生产者(producer)	消费者(consumer)	代理(broker)
每条发布到 Kafka 集群的消息都有一个类别，这个类别被称为主题	生产者，负责使用 push 模式发布消息到 Kafka 的主题中	消费者，从 Kafka 中读取消息的客户端 Kafka	集群包含一台或多台服务器，这种服务器被称为代理
用户只需制定消息的主题，即可生产或消费数据，而不必关心数据存放在何处	生产者负责将消息分配到主题的哪一个分区中	消费者使用 pull 模式从 Kafka 订阅并消费消息	Kafka 支持水平扩展，一般代理服务器数量越多，集群吞吐率越高

1.9.2 读物消息流程

1.9.3 Zookeeper 协调控制

• 管理broker与consumer的动态加入与离开。(Producer不需要管理，随便一台计算机都可以作为Producer向Kakfa Broker发消息)
• 触发负载均衡，当broker或consumer加入或离开时会触发负载均衡算法，使得一个consumer group内的多个consumer的消费负载平衡。（因为一个comsumer消费一个或多个partition，一个partition只能被一个consumer消费）
• 维护消费关系及每个partition的消费信息。