大数据技术栈

[TOC]

本文绝大部分内容整理自网络，引用较多，不再逐一标注引用地址。

Hadoop

Hadoop简介

Apache Hadoop是一款支持数据密集型分布式应用并以Apache 2.0许可协议发布的开源软件框架。它支持在商品硬件构建的大型集群上运行的应用程序。Hadoop是根据Google公司发表的MapReduce和GFS论文自行实作而成。

Hadoop框架透明地为应用提供可靠性和数据移动。它实现了名为MapReduce的编程范式：应用程序被分割成许多小部分，而每个部分都能在集群中的任意节点上执行或重新执行。此外，Hadoop还提供了分布式文件系统，用以存储所有计算节点的数据，这为整个集群带来了非常高的带宽。MapReduce和分布式文件系统的设计，使得整个框架能够自动处理节点故障。它使应用程序与成千上万的独立计算的电脑和PB级的数据。　

核心概念

Hadoop 1.x 时期的生态体系架构

Hadoop 2.x时期的生态体系架构

Hadoop Common：在0.20及以前的版本中，包含HDFS、MapReduce和其他项目公共内容，从0.21开始HDFS和MapReduce被分离为独立的子项目，其余内容为Hadoop Common
HDFS：Hadoop分布式文件系统（Distributed File System）－HDFS（Hadoop Distributed File System）
MapReduce：并行计算框架，0.20前使用org.apache.hadoop.mapred旧接口，0.20版本开始引入org.apache.hadoop.mapreduce的新API
Apache HBase：分布式NoSQL列数据库，类似谷歌公司BigTable。
Apache Hive：构建于hadoop之上的数据仓库，通过一种类SQL语言HiveQL为用户提供数据的归纳、查询和分析等功能。Hive最初由Facebook贡献。
Apache Mahout：机器学习算法软件包。
Apache Sqoop：结构化数据（如关系数据库）与Apache Hadoop之间的数据转换工具。
Apache ZooKeeper：分布式锁设施，提供类似Google Chubby的功能，由Facebook贡献。
Hadoop YARN: 一个新的MapReduce框架，任务调度与资源管理

应用场景

大数据收集、存储、分析、展示

参考资料

1、https://blog.csdn.net/u010608720/article/details/80092260
2、https://blog.csdn.net/baiye_xing/article/details/76228522
3、https://www.imooc.com/article/18560

数据采集

Flume

Flume简介

Flume是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的系统。支持在日志系统中定制各类数据发送方，用于收集数据;同时，Flume提供对数据进行简单处理，并写到各种数据接受方(比如文本、HDFS、Hbase等)的能力。

Flume的数据流由事件(Event)贯穿始终。事件是Flume的基本数据单位，它携带日志数据(字节数组形式)并且携带有头信息，这些Event由Agent外部的Source生成，当Source捕获事件后会进行特定的格式化，然后Source会把事件推入(单个或多个)Channel中。你可以把Channel看作是一个缓冲区，它将保存事件直到Sink处理完该事件。Sink负责持久化日志或者把事件推向另一个Source。

Flume的可靠性。当节点出现故障时，日志能够被传送到其他节点上而不会丢失。Flume提供了三种级别的可靠性保障，从强到弱依次分别为：end-to-end（收到数据agent首先将event写到磁盘上，当数据传送成功后，再删除；如果数据发送失败，可以重新发送。），Store on failure（这也是scribe采用的策略，当数据接收方crash时，将数据写到本地，待恢复后，继续发送），Besteffort（数据发送到接收方后，不会进行确认）。

核心概念

Client：Client生产数据，运行在一个独立的线程
Event：一个数据单元，消息头和消息体组成（Events可以是日志记录、 avro 对象等）
Flow：Event从源点到达目的点的迁移的抽象
Agent：一个独立的Flume进程，包含组件Source、 Channel、 Sink。（Agent使用JVM 运行Flume，每台机器运行一个agent，但是可以在一个agent中包含多个sources和sinks）
Source：数据收集组件，从Client收集数据，传递给Channel
Channel：中转Event的一个临时存储，保存由Source组件传递过来的Event（Channel连接 sources 和 sinks ，这个有点像一个队列。）
Sink：从Channel中读取并移除Event，将Event传递到FlowPipeline中的下一个Agent（如果有的话）（Sink从Channel收集数据，运行在一个独立线程）

连接方式

串联

并联

分发

应用场景

数据采集，写入HDFS

参考资料

1、https://www.cnblogs.com/zhangyinhua/p/7803486.html
2、http://flume.apache.org/releases/content/1.9.0/FlumeUserGuide.html

Logstash

Logstash简介

Logstash是一个开源数据收集引擎，具有实时管道功能。Logstash可以动态地将来自不同数据源的数据统一起来，并将数据标准化到你所选择的目的地。

核心概念

Inputs：采集数据。能够以连续的流式传输方式，从日志、指标、Web 应用、数据存储以及各种 AWS 服务采集数据。
Filters：实时解析和转换数据。Logstash 能够动态地转换和解析数据，不受格式或复杂度的影响：
Outputs：存储和导出数据。首选 Elasticsearch ，但并非唯一选择。

Filebeat

Filebeat 是一个轻量级的日志传输工具，它的存在正弥补了 Logstash 的性能缺点：Filebeat 作为一个轻量级的日志传输工具可以将日志推送到中心 Logstash或Elasticsearch。

应用场景

日志采集，可引用Kafka、Redis等做缓存

参考资料

1、https://www.elastic.co/products/logstash
2、https://www.cnblogs.com/cjsblog/p/9459781.html
3、https://www.cnblogs.com/richaaaard/p/6109595.html
4、https://www.elastic.co/guide/en/beats/filebeat/current/filebeat-overview.html

Chukwa

Chukwa简介

Chukwa旨在为分布式数据收集和大数据处理提供一个灵活、强大的平台，这个平台不仅现时可用，而且能够与时俱进的利用更新的存储技术（比如HDFS、HBase等），当这些存储技术变得成熟时。为了保持这种灵活性，Chukwa被设计成收集和处理层级的管道线，在各个层级之间有非常明确和狭窄的界面，下图为Chukwa架构示意图：

其中主要的部件为:

Agents : 负责采集最原始的数据,并发送给 Collectors
Adaptors : 直接采集数据的接口和工具,一个 Agent 可以管理多个 Adaptor 的数据采集
Collectors ：负责收集 Agent 收送来的数据,并定时写入集群中
Map/Reduce Jobs：定时启动,负责把集群中的数据分类、排序、去重和合并
HICC（Hadoop Infrastructure Care Center）负责数据的展示

备注: Chukwa2016年后，没有再更新，业界采用较少

参考资料

1、https://cloud.tencent.com/info/ba535d292e3a417a64064470f3710097.html
2、https://wiki.apache.org/hadoop/Chukwa?action=AttachFile&do=view&target=ChukwaPoster.pdf
3、https://wiki.apache.org/hadoop/Chukwa

对比与建议

对比

Flume与Logstash复杂，但更通用
Flume重点在数据传输，Logstash有更强的数据预处理能力

建议

仅考虑Flume和Logstash，无特殊因素，不使用其他同类组件
通用场景采用Flume
日志+分析+展现场景，采用Logstash。即ELK。

存储框架

HDFS

HDFS简介

HDFS（Hadoop Distributed File System）是Hadoop项目的核心子项目，是分布式计算中数据存储管理的基础，是基于流数据模式访问和处理超大文件的需求而开发的，可以运行于廉价的商用服务器上。它所具有的高容错、高可靠性、高可扩展性、高获得性、高吞吐率等特征为海量数据提供了不怕故障的存储，为超大数据集（Large Data Set）的应用处理带来了很多便利。HDFS 源于 Google 在发表的GFS（Google File System）论文。它其实就是 GFS 的一个克隆版本

HDFS核心概念

1、Client：就是客户端。

文件切分。文件上传 HDFS 的时候，Client 将文件切分成一个一个的Block，然后进行存储。
与 NameNode交互，获取文件的位置信息。
与 DataNode 交互，读取或者写入数据。
Client 提供一些命令来管理HDFS，比如启动或者关闭HDFS。
Client 可以通过一些命令来访问 HDFS。

2、NameNode：就是 master，它是一个主管、管理者。

管理 HDFS 的名称空间
管理数据块（Block）映射信息
配置副本策略
处理客户端读写请求。

3、DataNode：就是Slave。NameNode 下达命令，DataNode 执行实际的操作。

存储实际的数据块。
执行数据块的读/写操作。

4、Blocks：存储单元

Hadoop提供的df、fsck这类运维工具都是在文件系统的Block级别上进行操作。
HDFS的Block块默认为128M。HDFS的文件被拆分成block-sized的chunk，chunk作为独立单元存储。比Block小的文件不会占用整个Block，只会占据实际大小。例如，如果一个文件大小为1M，则在HDFS中只会占用1M的空间，而不是128M。

应用场景

　
适用场景：

高容错场景：数自动保存多个副本。它通过增加副本的形式，提高容错性。某一个副本丢失以后，它可以自动恢复，这是由 HDFS 内部机制实现的，我们不必关心。
批处理场景：它是通过移动计算而不是移动数据。它会把数据位置暴露给计算框架。
大文件存储：集群存储的数据达到PB级别
流式文件访问：一次写入，多次读取。文件一旦写入不能修改，只能追加。它能保证数据的一致性。
运行于商业硬件上:可运行于普通商用机器，商用机器不代表低端机器。在集群中（尤其是大的集群），节点失败率是比较高的HDFS的目标是确保集群在节点失败的时候不会让用户感觉到明显的中断。

不适用场景：

低延时数据访问：比如毫秒级的来存储数据，这是不行的，它做不到。它适合高吞吐率的场景，就是在某一时间内写入大量的数据。但是它在低延时的情况下是不行的，比如毫秒级以内读取数据，这样它是很难做到的。
小文件存储：存储大量小文件(这里的小文件是指小于HDFS系统的Block大小的文件（默认64M）)的话，它会占用 NameNode大量的内存来存储文件、目录和块信息。这样是不可取的，因为NameNode的内存总是有限的。小文件存储的寻道时间会超过读取时间，它违反了HDFS的设计目标。
并发写入、文件随机修改：一个文件只能有一个写，不允许多个线程同时写。仅支持数据 append（追加），不支持文件的随机修改。

参考资料

1、http://hadoop.apache.org/docs/r1.2.1/hdfs_design.html
2、https://www.cnblogs.com/codeOfLife/p/5375120.html
3、https://blog.csdn.net/sjmz30071360/article/details/79877846

HBase

HBase简介

HBase是一个构建在HDFS上的分布式列存储系统；
HBase是基于Google BigTable模型开发的；
HBase是Apache Hadoop生态系统中的重要一员，主要用于海量结构化数据存储；

从逻辑上讲，HBase将数据按照表、行和列进行存储。与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。Hbase表的特点：

大：一个表可以有数十亿行，上百万列；
无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列；
面向列：面向列（族）的存储和权限控制，列（族）独立检索；
稀疏：空（null）列并不占用存储空间，表可以设计的非常稀疏；
数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳；
数据类型单一：Hbase中的数据都是字符串，没有类型。

核心概念

从HBase的架构图上可以看出，HBase中的组件包括Client、Zookeeper、HMaster、HRegionServer、HRegion、Store、MemStore、StoreFile、HFile、HLog等，接下来介绍他们的作用。

1、Client：包含访问HBase的接口，并维护cache来加快对HBase的访问，比如HRegion的位置信息
2、ZooKeeper：

通过选举，保证任何时候，集群中只有一个master，HMaster与HRegionServer启动时会向ZooKeeper注册
存贮所有HRegion的寻址入口
实时监控HRegionServer的上线和下线信息。并实时通知给HMaster
存储HBase的schema和table元数据
默认情况下，HBase 管理ZooKeeper 实例，比如，启动或者停止ZooKeeper
Zookeeper的引入使得HMaster不再是单点故障

3、HMaster

为HRegionServer分配HRegion
负责HRegionServer 的负载均衡
发现失效的HRegionServer 并重新分配其上的HRegion
HDFS上的垃圾文件（HBase）回收
处理 Schema 更新请求（表的创建，删除，修改，列簇的增加等等）

4、HRegionServer

HRegionServer 维护HMaster 分配给它的HRegion，处理对这些HRegion 的 IO 请求
HRegionServer 负责 Split 在运行过程中变得过大的HRegion，负责 Compact 操作

5、HRegion：table在行的方向上分隔为多个Region。Region是HBase中分布式存储和负载均衡的最小单元，即不同的region可以分别在不同的Region Server上，但同一个Region是不会拆分到多个server上。

6、Store：每一个region由一个或多个store组成，至少是一个store，hbase会把一起访问的数据放在一个store里面，即为每个 ColumnFamily建一个store，如果有几个ColumnFamily，也就有几个Store。一个Store由一个memStore和0或者多个StoreFile组成。 HBase以store的大小来判断是否需要切分region
7、MemStore：memStore 是放在内存里的。保存修改的数据即keyValues。当memStore的大小达到一个阀值（默认128MB）时，memStore会被flush到文件，即生成一个快照。目前hbase 会有一个线程来负责memStore的flush操作。

8、StoreFile：memStore内存中的数据写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。当storefile文件的数量增长到一定阈值后，系统会进行合并（minor、major compaction），在合并过程中会进行版本合并和删除工作（majar），形成更大的storefile。

9、HFile：HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对Hfile做了轻量级包装，即StoreFile底层就是HFile。

10、HLog

HLog(WAL log)：WAL意为write ahead log，用来做灾难恢复使用，HLog记录数据的所有变更，一旦region server 宕机，就可以从log中进行恢复。
HLog文件就是一个普通的Hadoop Sequence File， Sequence File的value是key时HLogKey对象，其中记录了写入数据的归属信息，除了table和region名字外，还同时包括sequence number和timestamp，timestamp是写入时间，sequence number的起始值为0，或者是最近一次存入文件系统中的sequence number。 Sequence File的value是HBase的KeyValue对象，即对应HFile中的KeyValue。

应用场景

Hbase适合需对数据进行随机读操作或者随机写操作、大数据上高并发操作，比如每秒对PB级数据进行上千次操作以及读写访问均是非常简单的操作。
它承载在集群普通硬件的顶端是非常大的表。
Apache HBase是此前谷歌Bigtable模拟非关系型数据库。 Bigtable对谷歌文件系统操作，同样类似Apache HBase工作在Hadoop HDFS的顶部。

参考资料

1、https://www.cnblogs.com/seaspring/p/5942844.html
2、https://www.cnblogs.com/frankdeng/p/9310278.html
3、https://www.yiibai.com/hbase/

计算框架

MapReduce

MapReduce简介

MapReduce是一种分布式计算模型，是Hadoop的主要组成之一，承担大批量数据的计算功能。MapReduce分为两个阶段：Map和Reduce。

MapReduce 1.X

MapReduce包含四个组成部分，分别为Client，JobTracker，TaskTracker，Task。
1、client客户端
每一个Job都会在用户端通过Client类将应用程序以及参数配置Configuration打包成Jar文件存储在HDFS，并把路径提交到JobTracker的master服务，然后由master创建每一个Task（即MapTask和ReduceTask），将它们分发到各个TaskTracker服务中去执行。

2、JobTracker
JobTracker负责资源监控和作业调度。JobTracker监控所有的TaskTracker与job的健康状况，一旦发现失败，就将相应的任务转移到其它节点；同时JobTracker会跟踪任务的执行进度，资源使用量等信息，并将这些信息告诉任务调度器，而调度器会在资源出现空闲时，选择合适的任务使用这些资源。在Hadoop中，任务调度器是一个可插拔的模块，用于可以根据自己的需要设计相应的调度器。

3、TaskTracker
TaskTracker会周期性地通过HeartBeat将本节点上资源的使用情况和任务的运行进度汇报给JobTracker，同时执行JobTracker发送过来的命令并执行相应的操作（如启动新任务，杀死任务等）。TaskTracker使用“slot”等量划分本节点上的资源量。“slot”代表计算资源（cpu，内存等）。一个Task获取到一个slot之后才有机会运行，而Hadoop调度器的作用就是将各个TaskTracker上的空闲slot分配给Task使用。slot分为MapSlot和ReduceSlot两种，分别提供MapTask和ReduceTask使用。TaskTracker通过slot数目（可配置参数）限定Task的并发度。

4、Task
Task分为MapTask和Reduce Task两种，均由TaskTracker启动。HDFS以固定大小的block为基本单位存储数据，而对于MapReduce而言，其处理单位是split。split是一个逻辑概念，它只包含一些元数据信息，比如数据起始位置、数据长度、数据所在节点等。它的划分方法完全由用户自己决定。但需要注意的是，split的多少决定了MapTask的数目，因为每一个split只会交给一个MapTask处理

split与block的关系如下图：

MapTask的执行过程如下图所示：由下图可知，Map Task 先将对应的split迭代解析成一个个key-value对，依次调用用户自定义的map()函数进行处理，最终将临时结果存放到本地磁盘上。其中，临时数据被分成若干个partition，每个partition将被一个Reduce Task处理。

Reduce Task 的执行过程如下图所示。该过程分为三个阶段：

从远程节点上读取Map Task中间结果（称为“Shuffle 阶段”）
按照 key 对 key-value 对进行排序（称为 “Sort 阶段”）
依次读取< key， value list >，调用用户自定义的Reduce函数处理，并将最终结果存到HDFS上（称为“Reduce阶段”）
过程如下图：

MapReduce 2.X

MRv2最基本的设计思想是将JobTracker的两个主要功能，即资源管理和作业调度/监控分成两个独立的进程。在该解决方案中包含两个组件：全局的ResourceManager（RM）和与每个应用相关的ApplicationMaster（AM）。这里的“应用”指一个单独的MapReduce作业。RM和与NodeManager（NM，每个节点一个）共同组成整个数据计算框架。RM是系统中将资源分配给各个应用的最终决策者。AM实际上是一个具体的框架库，它的任务是【与RM协商获取应用所需资源】和【与NM合作，以完成执行和监控task的任务】。

1、ResourceManager（RM）包含两个主要的组件：定时调用器(Scheduler)以及应用管理器(ApplicationManager)
（1）调度器（Scheduler）：根据容量，队列等限制条件，将系统中的资源分配给各个正在运行的应用。这里的调度器是一个“纯调度器”，因为它不再负责监控或者跟踪应用的执行状态等，此外，他也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务。调度器仅根据各个应用的资源需求进行调度，这是通过抽象概念“资源容器”完成的，资源容器（Resource Container）将内存，CPU，磁盘，网络等资源封装在一起，从而限定每个任务使用的资源量。总而言之，定时调度器负责向应用程序分配资源，它不做监控以及应用程序的状态跟踪，并且它不保证会重启由于应用程序本身或硬件出错而执行失败的应用程序。
（2）应用管理器（ApplicationsManager，ASM）：ASM主要负责接收作业，协商获取第一个容器用于执行AM和提供重启失败AM container的服务。

2、NodeManager：NM是每个节点上的框架代理，主要负责启动应用所需的容器，监控资源（内存，CPU，磁盘，网络等）的使用情况并将之汇报给调度器（Scheduler）。

3、ApplicationMaster：每个应用程序的ApplicationMaster负责从Scheduler申请资源，以及跟踪这些资源的使用情况以及任务进度的监控。

4、Container：是YARN中资源的抽象，它将内存、CPU、磁盘、网络等资源封装在一起。当AM向RM申请资源时，RM为AM返回的资源便是用Container表示的。

应用场景

大数据离线批处理

参考资料

1、https://blog.csdn.net/u010176083/article/details/53269317
2、https://blog.csdn.net/yu0_zhang0/article/details/78907178
3、https://szjian.iteye.com/blog/2100953

Storm

Storm简介

Apache Storm是一个分布式实时大数据处理系统。Storm设计用于在容错和水平可扩展方法中处理大量数据。它是一个流数据框架，具有最高的摄取率。虽然Storm是无状态的，它通过Apache ZooKeeper管理分布式环境和集群状态。它很简单，您可以并行地对实时数据执行各种操作。

核心概念

Nimbus：即Storm的Master，负责资源分配和任务调度。一个Storm集群只有一个Nimbus。
Supervisor：即Storm的Slave，负责接收Nimbus分配的任务，管理所有Worker，一个Supervisor节点中包含多个Worker进程。
Worker：工作进程，每个工作进程中都有多个Task。
Task：任务，在 Storm 集群中每个 Spout 和 Bolt 都由若干个任务（tasks）来执行。每个任务都与一个执行线程相对应。
Topology：计算拓扑，Storm 的拓扑是对实时计算应用逻辑的封装，它的作用与 MapReduce 的任务（Job）很相似，区别在于 MapReduce 的一个 Job 在得到结果之后总会结束，而拓扑会一直在集群中运行，直到你手动去终止它。拓扑还可以理解成由一系列通过数据流（Stream Grouping）相互关联的 Spout 和 Bolt 组成的的拓扑结构。
Stream：数据流（Streams）是 Storm 中最核心的抽象概念。一个数据流指的是在分布式环境中并行创建、处理的一组元组（tuple）的无界序列。数据流可以由一种能够表述数据流中元组的域（fields）的模式来定义。
Spout：数据源（Spout）是拓扑中数据流的来源。一般 Spout 会从一个外部的数据源读取元组然后将他们发送到拓扑中。根据需求的不同，Spout 既可以定义为可靠的数据源，也可以定义为不可靠的数据源。一个可靠的 Spout能够在它发送的元组处理失败时重新发送该元组，以确保所有的元组都能得到正确的处理；相对应的，不可靠的 Spout 就不会在元组发送之后对元组进行任何其他的处理。一个 Spout可以发送多个数据流。
Bolt：拓扑中所有的数据处理均是由 Bolt 完成的。通过数据过滤（filtering）、函数处理（functions）、聚合（aggregations）、联结（joins）、数据库交互等功能，Bolt 几乎能够完成任何一种数据处理需求。一个 Bolt 可以实现简单的数据流转换，而更复杂的数据流变换通常需要使用多个 Bolt 并通过多个步骤完成。
Stream grouping：为拓扑中的每个 Bolt 的确定输入数据流是定义一个拓扑的重要环节。数据流分组定义了在 Bolt 的不同任务（tasks）中划分数据流的方式。在 Storm 中有八种内置的数据流分组方式。

应用场景

大数据在线实时处理

参考资料

1、https://www.w3cschool.cn/apache_storm/apache_storm_core_concepts.html
2、https://blog.csdn.net/lvbiao_62/article/details/79751568
3、https://www.cnblogs.com/xuwujing/p/8584684.html
4、http://www.cnblogs.com/langtianya/p/5199529.html

Spark

Spark简介

Spark是一个用来实现快速而通用的集群计算的平台。扩展了广泛使用的MapReduce计算模型，而且高效地支持更多的计算模式，包括交互式查询和流处理。在处理大规模数据集的时候，速度是非常重要的。Spark的一个重要特点就是能够在内存中计算，因而更快。即使在磁盘上进行的复杂计算，Spark依然比MapReduce更加高效。

基于MapReduce的计算引擎通常会将中间结果输出到磁盘上，进行存储和容错。出于任务管道承接的，考虑，当一些查询翻译到MapReduce任务时，往往会产生多个Stage，而这些串联的Stage又依赖于底层文件系统（如HDFS）来存储每一个Stage的输出结果。

Spark是MapReduce的替代方案，而且兼容HDFS、Hive，可融入Hadoop的生态系统，以弥补MapReduce的不足。

核心概念

Spark 运行流程：
Spark架构采用了分布式计算中的Master-Slave模型。Master是对应集群中的含有Master进程的节点，Slave是集群中含有Worker进程的节点。Master作为整个集群的控制器，负责整个集群的正常运行；Worker相当于计算节点，接收主节点命令与进行状态汇报；Executor负责任务的执行；Client作为用户的客户端负责提交应用，Driver负责控制一个应用的执行。Spark集群部署后，需要在主节点和从节点分别启动Master进程和Worker进程，对整个集群进行控制。在一个Spark应用的执行过程中，Driver和Worker是两个重要角色。Driver 程序是应用逻辑执行的起点，负责作业的调度，即Task任务的分发，而多个Worker用来管理计算节点和创建Executor并行处理任务。在执行阶段，Driver会将Task和Task所依赖的file和jar序列化后传递给对应的Worker机器，同时Executor对相应数据分区的任务进行处理。

1、Excecutor /Task 每个程序自有，不同程序互相隔离，task多线程并行，
2、集群对Spark透明，Spark只要能获取相关节点和进程
3、Driver 与Executor保持通信，协作处理

Spark核心概念有：

Application：Application都是指用户编写的Spark应用程序，其中包括一个Driver功能的代码和分布在集群中多个节点上运行的Executor代码
Driver：Spark中的Driver即运行上述Application的main函数并创建SparkContext，创建SparkContext的目的是为了准备Spark应用程序的运行环境，在Spark中有SparkContext负责与ClusterManager通信，进行资源申请、任务的分配和监控等，当Executor部分运行完毕后，Driver同时负责将SparkContext关闭，通常用SparkContext代表Driver
Executor：某个Application运行在worker节点上的一个进程，该进程负责运行某些Task，并且负责将数据存到内存或磁盘上，每个Application都有各自独立的一批Executor，在Spark on Yarn模式下，其进程名称为CoarseGrainedExecutor Backend。一个CoarseGrainedExecutor Backend有且仅有一个Executor对象，负责将Task包装成taskRunner，并从线程池中抽取一个空闲线程运行Task，这个每一个CoarseGrainedExecutor Backend能并行运行Task的数量取决于分配给它的cup个数
Cluster Manager：指的是在集群上获取资源的外部服务。目前有三种类型
1、standalone：spaark原生的资源管理，由Master负责资源的分配
2、Apache Mesos：与hadoop MR兼容性良好的一种资源调度框架
3、Hadoop Yarn：主要指Yarn中的ResourceManager
Worker：集群中任何可以运行Application代码的节点，在Standalone模式中指的是通过slave文件配置的Worker节点，在Spark on Yarn模式下就是NoteManager节点
Task：被送到某个Executor上的工作单元，但HadoopMR中的MapTask和ReduceTask概念一样，是运行Application的基本单位，多个Task组成一个Stage，而Task的调度和管理等是由TaskScheduler负责
Job：包含多个Task组成的并行计算，往往由Spark Action触发生成，一个Application中往往会产生多个Job
Stage：每个Job会被拆分成多组Task，作为一个TaskSet，其名称为Stage，Stage的划分和调度是有DAGScheduler来负责的，Stage有非最终的Stage（Shuffle Map Stage）和最终的Stage（Result Stage）两种，Stage的边界就是发生Shuffle的地方
DAGScheduler：根据Job构建基于Stage的DAG（Directed Acyclic Graph有向无环图），并提交Stage给TASKScheduler。其划分Stage的根据是RDD之间的依赖的关系找出开销最小的调度方法，如下图
TaskScheduler：将任务（task）分发给Executor执行。
SparkContext：整个应用的上下文，控制应用的生命周期。
RDD：是Resilient distributed datasets的简称，中文为弹性分布式数据集；是Spark最核心的模块和类。Spark的基础计算单元，一组RDD可形成执行的有向无环图RDD Graph。
SparkEnv：线程级别的上下文，存储运行时的重要组件的引用。

应用场景

复杂的批量处理（Batch Data Processing），偏重点在于处理海量数据的能力，至于处理速度可忍受，通常的时间可能是在数十分钟到数小时；
基于历史数据的交互式查询（Interactive Query），通常的时间在数十秒到数十分钟之间
基于实时数据流的数据处理（Streaming Data Processing），通常在数百毫秒到数秒之间

参考资料

1、http://www.aboutyun.com/thread-21644-1-1.html
2、https://www.cnblogs.com/cxxjohnson/p/8909578.html
3、https://www.jianshu.com/p/c7eef3eb6225
4、https://blog.csdn.net/anningzhu/article/details/60778962

Spark Streaming

Spark Streaming简介

Spark Streaming 是Spark核心API的一个扩展，可以实现高吞吐量的、具备容错机制的实时流数据的处理。支持从多种数据源获取数据，包括Kafk、Flume、Twitter、ZeroMQ、Kinesis 以及TCP sockets，从数据源获取数据之后，可以使用诸如map、reduce、join和window等高级函数进行复杂算法的处理。最后还可以将处理结果存储到文件系统，数据库和现场仪表盘。在“One Stack rule them all”的基础上，还可以使用Spark的其他子框架，如集群学习、图计算等，对流数据进行处理。

Spark的各个子框架，都是基于核心Spark的，Spark Streaming在内部的处理机制是，接收实时流的数据，并根据一定的时间间隔拆分成一批批的数据，然后通过Spark Engine处理这些批数据，最终得到处理后的一批批结果数据。

对应的批数据，在Spark内核对应一个RDD实例，因此，对应流数据的DStream可以看成是一组RDDs，即RDD的一个序列。通俗点理解的话，在流数据分成一批一批后，通过一个先进先出的队列，然后 Spark Engine从该队列中依次取出一个个批数据，把批数据封装成一个RDD，然后进行处理，这是一个典型的生产者消费者模型，对应的就有生产者消费者模型的问题，即如何协调生产速率和消费速率。

核心概念

离散流（discretized stream）或DStream：这是Spark Streaming对内部持续的实时数据流的抽象描述，即我们处理的一个实时数据流，在Spark Streaming中对应于一个DStream 实例。
批数据（batch data）：这是化整为零的第一步，将实时流数据以时间片为单位进行分批，将流处理转化为时间片数据的批处理。随着持续时间的推移，这些处理结果就形成了对应的结果数据流了。
时间片或批处理时间间隔（ batch interval）：这是人为地对流数据进行定量的标准，以时间片作为我们拆分流数据的依据。一个时间片的数据对应一个RDD实例。
窗口长度（window length）：一个窗口覆盖的流数据的时间长度。必须是批处理时间间隔的倍数，
滑动时间间隔：前一个窗口到后一个窗口所经过的时间长度。必须是批处理时间间隔的倍数
Input DStream :一个input DStream是一个特殊的DStream，将Spark Streaming连接到一个外部数据源来读取数据。

应用场景

在线流式计算

参考资料

1、http://spark.apache.org/docs/latest/streaming-programming-guide.html
2、https://www.cnblogs.com/shishanyuan/p/4747735.html

Flink

Flink简介

Apache Flink 是一个分布式大数据处理引擎，可对有限数据流（批处理）和无限数据流（流处理）进行有状态计算。可部署在各种集群环境，对各种大小的数据规模进行快速计算。

核心概念

1、程序与数据流
Flink程序的基础构建模块是流（streams）与转换（transformations）。（需要注意的是，Flink的DataSet API所使用的DataSets其内部也是流——更多内容将在之后讨论。）概念上来讲，流是（可能永无止境的）数据记录流，而转换是一种操作，它取一个或多个流作为输入，并生产出一个或多个输出流作为结果。

执行时，Flink程序映射到流数据流（streaming dataflows），由流以及转换算符构成。每一个数据流起始于一个或多个 source，并终止于一个或多个 sink。数据流类似于任意的有向无环图（DAG）。虽然通过迭代构造允许特定形式的环，但是大多数情况下，简单起见，我们都不考虑这一点。

通常，程序中的转换与数据流中的操作之间是一对一的关系。有时，然而，一个转换可能由多个转换操作构成。

2、并行数据流
Flink程序本质上是并行分布的。在执行过程中，一个流包含一个或多个流分区，而每一个算符包含一个或多个算符子任务。操作子任务间彼此独立，以不同的线程执行，甚至有可能运行在不同的机器或容器上。

算符子任务的数量即这一特定算符的并行度。一个流的并行度即其生产算符的并行度。相同程序中的不同的算符可能有不同级别的并行度。

流在两个算符之间传输数据，可以通过一对一（或称 forwarding ）模式，或者通过 redistributing 模式：

一对一流（例如上图中 Source 与 map() 算符之间）保持了元素的分区与排序。那意味着 map() 算符的子任务[1]将以与 Source 的子任务[1]生成顺序相同的顺序查看到相同的元素。
Redistributing 流（如上图中 map() 与 keyBy/window 之间，以及 keyBy/window 与 Sink 之间）则改变了流的分区。每一个算符子任务根据所选择的转换，向不同的目标子任务发送数据。比如 keyBy() （根据key的哈希值重新分区）， broadcast() ，或者 rebalance() （随机重分区）。在一次 redistributing 交换中，元素间的排序只保留在每对发送与接受子任务中（比如， map() 的子任务[1]与 keyBy/window 的子任务[2]）。因此在这个例子中，每个键的顺序被保留下来，但是并行确实引入了对于不同键的聚合结果到达sink的顺序的不确定性。

3、窗口
聚合事件（比如计数、求和）在流上的工作方式与批处理不同。比如，对流中的所有元素进行计数是不可能的，因为通常流是无限的（无界的）。相反，流上的聚合需要由窗口来划定范围，比如 “计算过去的5分钟” ，或者 “最后100个元素的和” 。

窗口可以是事件驱动的（比如：每30秒）或者数据驱动的（比如：每100个元素）。窗口通常被区分为不同的类型，比如滚动窗口（没有重叠），滑动窗口（有重叠），以及会话窗口（由不活动的间隙所打断）

4、时间
当提到流程序（例如定义窗口）中的时间时，你可以参考不同的时间概念：

事件时间是事件创建的时间。它通常由事件中的时间戳描述，例如附接在生产传感器，或者生产服务。Flink通过时间戳分配器访问事件时间戳。
摄入时间是事件进入Flink数据流源算符的时间。
处理事件是每一个执行时间操作的算符的本地时间。

5、有状态操作
尽管数据流中的很多操作一次只查看一个独立的事件（比如事件解析器），有些操作却会记录多个事件间的信息（比如窗口算符）。这些操作被称为有状态的。

有状态操作的状态保存在一个可被视作嵌入式键/值存储的部分中。状态与由有状态算符读取的流一起被严格地分区与分布。因此，只能访问一个 keyBy() 函数之后的 keyed streams 的键/值状态，并且仅限于与当前事件键相关联的值。对齐流和状态的键确保了所有状态更新都是本地操作，以在没有事务开销的情况下确保一致性。这种对齐还使得Flink可以透明地重新分配状态与调整流的分区。

6、容错检查点
Flink使用流重放与 Checkpoint 的结合实现了容错。Checkpoint与每一个输入流及其相关的每一个算符的状态的特定点相关联。一个流数据流可以可以从一个checkpoint恢复出来，其中通过恢复算符状态并从检查点重放事件以保持一致性（一次处理语义）

检查点间隔是以恢复时间（需要重放的事件数量）来消除执行过程中容错的开销的一种手段。

7、流上的批处理
Flink将批处理程序作为流处理程序的特殊情况来执行，只是流是有界的（有限个元素）。

8、集群架构

当 Flink 集群启动后，首先会启动一个 JobManger 和一个或多个的 TaskManager。由 Client 提交任务给 JobManager， JobManager 再调度任务到各个 TaskManager 去执行，然后 TaskManager 将心跳和统计信息汇报给 JobManager。 TaskManager 之间以流的形式进行数据的传输。上述三者均为独立的 JVM 进程。

Client 为提交 Job 的客户端，可以是运行在任何机器上（与 JobManager 环境连通即可）。提交 Job 后，Client 可以结束进程（Streaming的任务），也可以不结束并等待结果返回。
JobManager 主要负责调度Job并协调Task checkpoint，职责上很像Storm的Nimbus。从Client处接收到Job和JAR包等资源后，会生成优化后的执行计划，并以Task的单元调度到各个TaskManager去执行。
TaskManager在启动的时候就设置好了槽位数（Slot），每个slot能启动一个Task，Task为线程。从JobManager处接收需要部署的Task，部署启动后，与自己的上游建立Netty连接，接收数据并处理。

应用场景

数据驱动的应用
批流数据分析
数据通道和ETL

参考资料

1、https://flink-china.org/doc/concepts/runtime.html
2、https://flink-china.org/doc/concepts/programming-model.html

Tez

Tez简介

运行在YARN之上支持DAG作业的计算框架，对MapReduce数据处理的归纳。它把Map/Reduce过程拆分成若干个子过程，同时可以把多个Map/Reduce任务组合成一个较大的DAG任务，减少了Map/Reduce之间的文件存储。同时合理组合其子过程，也可以减少任务的运行时间。

Tez并不直接面向最终用户——事实上它允许开发者为最终用户构建性能更快、扩展性更好的应用程序。

核心概念

Tez对外提供了6种可编程组件，分别是：

（1）Input：对输入数据源的抽象，它解析输入数据格式，并吐出一个个Key/value

（2）Output：对输出数据源的抽象，它将用户程序产生的Key/value写入文件系统

（3）Paritioner：对数据进行分片，类似于MR中的Partitioner

（4）Processor：对计算的抽象，它从一个Input中获取数据，经处理后，通过Output输出

（5）Task：对任务的抽象，每个Task由一个Input、Ouput和Processor组成

（6）Maser：管理各个Task的依赖关系，并按顺依赖关系执行他们

Tez还提供了两种算子，分别是Sort（排序）和Shuffle（混洗）

应用场景

基于DAG批处理

参考资料

1、https://blog.csdn.net/yamaxifeng_132/article/details/78828038
2、http://tez.apache.org/
3、http://juke.outofmemory.cn/entry/16974

对比与建议

对于小型与需要快速响应地项目，Storm是一个非常好的选择，特别是在你非常关注延迟度的情况下。

对于Spark Streaming而言，如果你的系统的基础架构中已经使用了Spark，那还是很推荐你试试的。另一方面，如果你想使用Lambda架构，那Spark也是个不错的选择。不过你一定要记住，Micro-Batching本身的限制和延迟对于你而言不是一个关键因素。

Flink是一个设计良好的框架，它不但功能强大，而且性能出色。此外它还有一些比较好设计，比如优秀的内存管理和流控。但是，flink目前成熟度较低，还存在着不少问题，比如 SQL支持比较初级；无法像storm一样在不停止任务的情况下动态调整资源；不能像spark一样提供很好的streaming和static data的交互操作等。对于这些问题，flink社区还在积极的跟进，相信在更多公司和贡献者的共同努力下，flink会发展的越来越好。

参考资料：
1、https://segmentfault.com/a/1190000004593949?_ea=665564
2、http://www.cnblogs.com/163yun/p/9010969.html

查询框架

Hive

Hive简介

1、Hive 由 Facebook 实现并开源

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

3、可以将结构化的数据映射为一张数据库表

4、并提供 HQL(Hive SQL)查询功能

5、底层数据是存储在 HDFS 上

6、Hive的本质是将 SQL 语句转换为 MapReduce 任务运行

7、使不熟悉 MapReduce 的用户很方便地利用 HQL 处理和计算 HDFS 上的结构化的数据，适用于离线的批量数据计算。

　　Hive 依赖于 HDFS 存储数据，Hive 将 HQL 转换成 MapReduce 执行，所以说 Hive 是基于 Hadoop 的一个数据仓库工具，实质就是一款基于 HDFS 的 MapReduce 计算框架，对存储在 HDFS 中的数据进行分析和管理

核心概念

从上图看出hive的内部架构由四部分组成：

1、用户接口: shell/CLI, jdbc/odbc, webui Command Line Interface
　　CLI，Shell 终端命令行（Command Line Interface），采用交互形式使用 Hive 命令行与 Hive 进行交互，最常用（学习，调试，生产）

　　JDBC/ODBC，是 Hive 的基于 JDBC 操作提供的客户端，用户（开发员，运维人员）通过这连接至 Hive server 服务

　　Web UI，通过浏览器访问 Hive

2、跨语言服务： thrift server 提供了一种能力，让用户可以使用多种不同的语言来操纵hive
　　Thrift 是 Facebook 开发的一个软件框架，可以用来进行可扩展且跨语言的服务的开发， Hive 集成了该服务，能让不同的编程语言调用 Hive 的接口

3、底层的Driver：驱动器Driver，编译器Compiler，优化器Optimizer，执行器Executor
　　Driver 组件完成 HQL 查询语句从词法分析，语法分析，编译，优化，以及生成逻辑执行计划的生成。生成的逻辑执行计划存储在 HDFS 中，并随后由 MapReduce 调用执行

　　Hive 的核心是驱动引擎，驱动引擎由四部分组成：

　　　　(1) 解释器：解释器的作用是将 HiveSQL 语句转换为抽象语法树（AST）

　　　　(2) 编译器：编译器是将语法树编译为逻辑执行计划

　　　　(3) 优化器：优化器是对逻辑执行计划进行优化

　　　　(4) 执行器：执行器是调用底层的运行框架执行逻辑执行计划

4、元数据存储系统： RDBMS MySQL
　　元数据，通俗的讲，就是存储在 Hive 中的数据的描述信息。

　　Hive 中的元数据通常包括：表的名字，表的列和分区及其属性，表的属性（内部表和外部表），表的数据所在目录

　　Metastore 默认存在自带的 Derby 数据库中。缺点就是不适合多用户操作，并且数据存储目录不固定。数据库跟着 Hive 走，极度不方便管理

　　解决方案：通常存我们自己创建的 MySQL 库（本地或远程）

　　Hive 和 MySQL 之间通过 MetaStore 服务交互

5、执行流程
　　HiveQL 通过命令行或者客户端提交，经过 Compiler 编译器，运用 MetaStore 中的元数据进行类型检测和语法分析，生成一个逻辑方案(Logical Plan)，然后通过的优化处理，产生一个 MapReduce 任务。

应用场景

OLAP，离线查询

参考资料

1、https://www.cnblogs.com/qingyunzong/p/8707885.html

Impala

Impala简介

Impala是用于处理存储在Hadoop集群中的大量数据的MPP（大规模并行处理）SQL查询引擎。它是一个用C ++和Java编写的开源软件。与其他Hadoop的SQL引擎相比，它提供了高性能和低延迟。Impala是性能最高的SQL引擎（提供类似RDBMS的体验），它提供了访问存储在Hadoop分布式文件系统中的数据的最快方法。

使用Impala，与其他SQL引擎（如Hive）相比，用户可以使用SQL查询以更快的方式与HDFS或HBase进行通信。Impala将相同的元数据，SQL语法（Hive SQL），ODBC驱动程序和用户界面（Hue Beeswax）用作Apache Hive，为面向批量或实时查询提供熟悉且统一的平台。

与Apache Hive不同，Impala不基于MapReduce算法。它实现了一个基于守护进程的分布式架构，它负责在同一台机器上运行的查询执行的所有方面。因此，它减少了使用MapReduce的延迟，这使Impala比Apache Hive快。

核心概念

从上图可以看出，Impala自身包含三个模块：Impalad、Statestore和Catalog，除此之外它还依赖Hive Metastore和HDFS。

Imapalad负责接受用户的查询请求，也意味着用户的可以将请求发送给任意一个Impalad进程，该进程在本次查询充当协调者（coordinator）的作用，生成执行计划并且分发到其它的Impalad进程执行，最终汇集结果返回给用户，并且对于当前Impalad和其它Impalad进程而言，他们同时也是本次查询的执行者，完成数据读取、物理算子的执行并将结果返回给协调者Impalad。这种无中心查询节点的设计能够最大程度的保证容错性并且很容易做负载均衡。正如图中展示的一样，通常每一个HDFS的DataNode上部署一个Impalad进程，由于HDFS存储数据通常是多副本的，所以这样的部署可以保证数据的本地性，查询尽可能的从本地磁盘读取数据而非网络。为了实现查询分割的子任务可以做到尽可能的本地数据读取，Impalad需要从Metastore中获取表的数据存储路径，并且从NameNode中获取每一个文件的数据块分布。
Catalog服务提供了元数据的服务，它以单点的形式存在，它既可以从外部系统（例如HDFS NameNode和Hive Metastore）拉取元数据，也负责在Impala中执行的DDL语句提交到Metatstore，由于Impala没有update/delete操作，所以它不需要对HDFS做任何修改。
StateStore服务完成两个工作：消息订阅服务和状态监测功能。Catalog中的元数据就是通过StateStore服务进行广播分发的，它实现了一个Pub-Sub服务，Impalad可以注册它们希望获得的事件类型，Statestore会周期性的发送两种类型的消息给Impalad进程，一种为该Impalad注册监听的事件的更新，基于版本的增量更新（只通知上次成功更新之后的变化）可以减小每次通信的消息大小；另一种消息为心跳信息，StateStore负责统计每一个Impalad进程的状态，Impalad可以据此了解其余Impalad进程的状态，用于判断分配查询任务到哪些节点。由于周期性的推送并且每一个节点的推送频率不一致可能会导致每一个Impalad进程获得的状态不一致，由于每一次查询只依赖于协调者Impalad进程获取的状态进行任务的分配，而不需要多个进程进行再次的协调，因此并不需要保证所有的Impalad状态是一致的。另外，StateStore进程是单点的，并且不会持久化任何数据到磁盘，如果服务挂掉，Impalad则依赖于上一次获得元数据状态进行任务分配。

应用场景

Ad-hoc 查询

参考资料

1、https://www.w3cschool.cn/impala/impala_overview.html
2、https://www.cnblogs.com/wujin/p/6394513.html
3、http://impala.apache.org/overview.html

Spark SQL

Spark SQL简介

Spark SQL是spark的一个模块，主要用于进行结构化数据的处理。与基础的Spark RDD API不同，Spark SQL的接口提供了更多关于数据的结构信息和计算任务的运行时信息。在Spark内部，Spark SQL会能够用于做优化的信息比RDD API更多一些。Spark SQL如今有了三种不同的API：SQL语句、DataFrame API和最新的Dataset API。不过真正运行计算的时候，无论你使用哪种API或语言，Spark SQL使用的执行引擎都是同一个。这种底层的统一，使开发者可以在不同的API之间来回切换，你可以选择一种最自然的方式，来表达你的需求。

（Spark SQL之于Spark，就如Hive之于MapReduce）

核心概念

Spark SQL由Core、Catalyst、Hive、Hive-ThriftServer四部分构成：

Core: 负责处理数据的输入和输出，如获取数据，查询结果输出成DataFrame等

Catalyst: 负责处理整个查询过程，包括解析、绑定、优化等

Hive: 负责对Hive数据进行处理

Hive-ThriftServer: 主要用于对hive的访问

Catalyst处于最核心的部分，其性能优劣将影响整体的性能。由于发展时间尚短，还有很多不足的地方，但其插件式的设计，为未来的发展留下了很大的空间。下面是catalyst的一个设计图：

应用场景

Spark交互查询

参考资料

1、http://spark.apache.org/sql/
2、https://www.cnblogs.com/shishanyuan/p/4723604.html
3、http://www.cnblogs.com/swordfall/p/9006088.html
4、https://www.cnblogs.com/qingyunzong/p/8987579.html

Pig

Pig简介

Apache Pig是MapReduce的一个抽象。它是一个工具/平台，用于分析较大的数据集，并将它们表示为数据流。Pig通常与 Hadoop 一起使用；我们可以使用Apache Pig在Hadoop中执行所有的数据处理操作。

要编写数据分析程序，Pig提供了一种称为 Pig Latin 的高级语言。该语言提供了各种操作符，程序员可以利用它们开发自己的用于读取，写入和处理数据的功能。

要使用 Apache Pig 分析数据，程序员需要使用Pig Latin语言编写脚本。所有这些脚本都在内部转换为Map和Reduce任务。Apache Pig有一个名为 Pig Engine 的组件，它接受Pig Latin脚本作为输入，并将这些脚本转换为MapReduce作业。

Apache Pig提供了许多内置操作符来支持数据操作，如join，filter，ordering等。此外，它还提供嵌套数据类型，例如tuple（元组），bag（包）和MapReduce缺少的map（映射）。

核心概念

Parser（解析器）
最初，Pig脚本由解析器处理，它检查脚本的语法，类型检查和其他杂项检查。解析器的输出将是DAG（有向无环图），它表示Pig Latin语句和逻辑运算符。在DAG中，脚本的逻辑运算符表示为节点，数据流表示为边。
Optimizer（优化器）
逻辑计划（DAG）传递到逻辑优化器，逻辑优化器执行逻辑优化，例如投影和下推。
Compiler（编译器）
编译器将优化的逻辑计划编译为一系列MapReduce作业。
Execution engine（执行引擎）
最后，MapReduce作业以排序顺序提交到Hadoop。这些MapReduce作业在Hadoop上执行，产生所需的结果。

应用场景

Pig并不适合所有的数据处理任务，和MapReduce一样，它是为数据批处理而设计的，如果想执行的查询只涉及一个大型数据集的一小部分数据，Pig的实现不会很好，因为它要扫描整个数据集或其中很大一部分。

随着新版本发布，Pig的表现和原生MapRedece程序差距越来越小，因为Pig的开发团队使用了复杂、精巧的算法来实现Pig的关系操作。除非你愿意花大量时间来优化Java MapReduce程序，否则使用Pig Latin来编写查询的确能帮你节约时间。

参考资料

1、https://www.cnblogs.com/yanghuahui/p/3768270.html
2、https://www.w3cschool.cn/apache_pig/apache_pig_overview.html

Phoenix

Phoenix简介

Phoenix将HBase的数据模型映射到关系型世界。Phoenix是构建在HBase上的一个SQL层，能让我们用标准的JDBC APIs而不是HBase客户端APIs来创建表，插入数据和对HBase数据进行查询。

Phoenix完全使用Java编写，作为HBase内嵌的JDBC驱动。Phoenix查询引擎会将SQL查询转换为一个或多个HBase扫描，并编排执行以生成标准的JDBC结果集。直接使用HBase API、协同处理器与自定义过滤器，对于简单查询来说，其性能量级是毫秒，对于百万级别的行数来说，其性能量级是秒。

（Phoenix之于HBase，相当于Hive之于MapReduce）

核心概念

应用场景

查询HBase

参考资料

1、https://www.jianshu.com/p/d862337247b1

对比与建议

各位组件的场景性很显示，根据场景选用即可

参考资料：
https://www.wikitechy.com/tutorials/apache-pig/pig-vs-hive

调度框架

YARN

YARN简介

Apache Hadoop YARN （Yet Another Resource Negotiator，另一种资源协调者）是一种新的 Hadoop 资源管理器，它是一个通用资源管理系统和调度平台，可为上层应用提供统一的资源管理和调度，它的引入为集群在利用率、资源统一管理和数据共享等方面带来了巨大好处。

可以把 yarn 理解为相当于一个分布式的操作系统平台，而 mapreduce 等运算程序则相当于运行于操作系统之上的应用程序，Yarn 为这些程序提供运算所需的资源（内存、cpu）。

核心概念

ResurceManager(RM)：一个纯粹的调度器，专门负责集群中可用资源的分配和管理。
Container：分配给具体应用的资源抽象表现形式，包括内存、cpu、disk
NodeManager(NM) ：负责节点本地资源的管理，包括启动应用程序的Container，监控它们的资源使用情况，并报告给RM
App Master (ApplicationMaster(AM))：特定框架库的一个实例，负责有RM协商资源，并和NM协调工作来执行和监控-Container以及它们的资源消耗。AM也是以一个的Container身份运行。
客户端（Client）：是集群中一个能向RM提交应用的实例，并且指定了执行应用所需要的AM类型

在 ResourceManager 接受一个新应用程序提交时，Scheduler 选择将用来运行 ApplicationMaster 的容器。在 ApplicationMaster 启动后，它将负责此应用程序的整个生命周期。首先也是最重要的是，它将资源请求发送到 ResourceManager，请求运行应用程序的任务所需的容器。

ResourceManager 会分配一个满足 ApplicationMaster 在资源请求中所请求的需求的容器。分配一个容器后，ApplicationMaster 会要求 NodeManager（管理分配容器的主机）使用这些资源来启动一个特定于应用程序的任务。此任务可以是在任何框架中编写的任何进程（比如一个 MapReduce 任务或一个 Giraph 任务）。NodeManager 不会监视任务；它仅监视容器中的资源使用情况，举例而言，如果一个容器消耗的内存比最初分配的更多，它会结束该容器。

ApplicationMaster 会竭尽全力协调容器，启动所有需要的任务来完成它的应用程序。它还监视应用程序及其任务的进度，在新请求的容器中重新启动失败的任务，以及向提交应用程序的客户端报告进度。应用程序完成后，ApplicationMaster 会关闭自己并释放自己的容器。

尽管 ResourceManager 不会对应用程序内的任务执行任何监视，但它会检查 ApplicationMaster 的健康状况。如果 ApplicationMaster 失败，ResourceManager 可在一个新容器中重新启动它。您可以认为 ResourceManager 负责管理 ApplicationMaster，而 ApplicationMasters 负责管理任务。

应用场景

Hadoop 资源通管

参考资料

1、https://blog.csdn.net/qq_33624952/article/details/79341034
2、https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html
3、https://www.ibm.com/developerworks/cn/data/library/bd-yarn-intro/index.html

Borg

Borg简介

Google的Borg系统是一个运行着成千上万项作业的集群管理器，它同时管理着很多个应用集群，每个集群都有成千上万台机器，这些集群之上运行着Google的很多不同的应用。Borg通过准入控制，高效的任务打包，超额的资源分配和进程级隔离的机器共享，来实现超高的资源利用率。它通过最小化故障恢复时间的运行时特性和减少相关运行时故障的调度策略来支持高可用的应用程序Borg通过提供一个作业声明的标准语言，命名服务的集成机制，实时的作业监控，以及一套分析和模拟系统行为的工具来简化用户的使用。

核心概念

总的来说是一个 server/agent 架构，主要模块包括 Borgmaster 和 Borglet 等。

Borgmaster：包括两个进程：main Borgmaster 进程和 scheduler 进程。main Borgmaster 进程负责处理 client RPC，比如创建 job 或者信息查询等。除此之后还要维护所有 object (machines, tasks, allocs, etc.) 的状态机。为了避免单点故障，Borgmaster 一共有五个，通过 Paxos 选出一个 leader 负责所有服务。Borgmaster 的某个时间点状态叫做 checkpoint，会持久化在 Paxos store 里面。通过 checkpoint 我们查看之前所有的 event，以及在某个特定的 checkpoint 上面进行 debug。
Scheduling：当一个 job 被提交，Borgmaster 会将其记录在 paxos store，然后将 job 的 task 加到 pending 队列。然后 scheduler 会异步地扫描 pending 队列，如果发现有满足条件的机器，就将 task 分配到对应的机器上。
Borglet：Borglet 是运行在每台机器上的 agent，主要作用包括：task 的启停，以及失败重启。通过 OS kernel 相关设置管理 local resource。roll over debug 日志。向 Borgmaster 或者其他的监控系统上报机器的数据。

应用场景

Google内部。

（类似的还有Omega）

参考资料

1、https://blog.csdn.net/karamos/article/details/80128781

Kubernetes（K8s）

Kubernetes简介

Kubernetes是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes的目标是让部署容器化的应用简单并且高效（powerful）,Kubernetes提供了应用部署，规划，更新，维护的一种机制。

核心概念

Master节点负责整个集群的控制和管理，所有的控制命令都是发给它
Node是工作负载节点，运行着Master分配的负载（Pod），但一个Node宕机时，其上的负载会被自动转移到其他Node上
Pod是k8s进行资源调度的最小单位，每个Pod中运行着一个或多个密切相关的业务容器，这些业务容器共享这个Pause容器的IP和Volume，我们以这个不易死亡的Pause容器作为Pod的根容器，以它的状态表示整个容器组的状态。一个Pod一旦被创建就会放到Etcd中存储，然后由Master调度到一个Node绑定，由这个Node上的Kubelet进行实例化。
Service：K8s中一个Service相当于一个微服务的概念，一个Service对应后端多个Pod计算实例，使用LabelSelector将一类Pod都绑定到自己上来。一般还会需要一个Deployment或者RC来帮助这个Service来保证这个Service的服务能力和质量。

应用场景

集群管理

参考资料

1、https://www.kubernetes.org.cn/kubernetes%E8%AE%BE%E8%AE%A1%E6%9E%B6%E6%9E%84
2、https://blog.csdn.net/Dustin_CDS/article/details/79439596

Mesos

Mesos简介

mesos类似于linux kernel，但是更高层次的抽象。

操作系统有多个组成部分，但进程调度绝对算的上是核心之一。linux进程调度将进程调度到某个核心上（假设是多核cpu），对应的，mesos scheduler组件将task调度到某个slave上，这个更高层次的抽象具体的讲就是：

linux内核的进程调度器和进程运行在同一个主机上，进程调度器决定将任务队列中的任务分配某个计算单元上（即某个cpu核心）
在mesos中，scheduler和其调度的task运行在不同的主机上（mesos屏蔽了分布式系统的通信和容灾等细节），scheduler决定将task部署在某个slave的某个executor上。executor在更高层次抽象了一个完整的计算单元（包含cpu和内存等）

核心概念

上图显示了 Mesos 的主要组成部分。 Mesos 由一个 master daemon 来管理 slave daemon 在每个集群节点上的运行, mesos applications （也称为 frameworks ）在这些 slaves 上运行 tasks。

Master 使用 Resource Offers 实现跨应用细粒度资源共享，如 cpu、内存、磁盘、网络等。 master 根据指定的策略来决定分配多少资源给 framework ，如公平共享策略，或优先级策略。为了支持更多样性的策略，master 采用模块化结构，这样就可以方便的通过插件形式来添加新的分配模块。

在 Mesos 上运行的 framework 由两部分组成：一个是 scheduler ，通过注册到　master 来获取集群资源。另一个是在 slave 节点上运行的 executor 进程，它可以执行 framework 的 task 。 Master 决定为每个　framework 提供多少资源， framework 的 scheduler 来选择其中提供的资源。当 framework 同意了提供的资源，它通过 master 将 task发送到提供资源的　slaves 上运行。

应用场景

集群管理

参考资料

1、https://docs.huihoo.com/apache/mesos/mesos-cn/OverView/Mesos-Architecture.html
2、https://www.cnblogs.com/xiaomaohai/p/6158061.html
3、https://www.cnblogs.com/qiankunli/p/4644030.html

Oozie

Oozie简介

Oozie是一个基于工作流引擎的服务器，可以在上面运行Hadoop的Map Reduce和Pig任务。它其实就是一个运行在Java Servlet容器（比如Tomcat）中的Javas Web应用。

对于Oozie来说，工作流就是一系列的操作（比如Hadoop的MR，以及Pig的任务），这些操作通过有向无环图的机制控制。这种控制依赖是说，一个操作的输入依赖于前一个任务的输出，只有前一个操作完全完成后，才能开始第二个。

（类似的还有Azkaban、Zeus）

核心概念

Oozie主要有三个主要概念，分别是workflow，coordinator，bundle。

Workflow：工作流，由我们需要处理的每个工作组成，进行需求的流式处理。
Coordinator：协调器，可以理解为工作流的协调器，可以将多个工作流协调成一个工作流来进行处理。
Bundle：捆，束。将一堆的coordinator进行汇总处理。

简单来说，workflow是对要进行的顺序化工作的抽象，coordinator是对要进行的顺序化的workflow的抽象，bundle是对一堆coordiantor的抽象。层级关系层层包裹。

应用场景

Hadoop工作流

参考资料

1、https://blog.csdn.net/weixin_39198774/article/details/79412726
2、https://blog.csdn.net/qq_16095837/article/details/79827014
3、https://blog.csdn.net/carolzhang8406/article/details/79159391

机器学习

Mahout

Mahout简介

　Apache Mahout提供了一些经典的机器学习的算法，帮助开发人员更加方便快捷地创建智能应用程序。Mahout包括许多实现，包括聚类、分类、推荐引擎、频繁子项挖掘。

　Apache Mahout的主要目标是建立可伸缩的机器学习算法。这种可伸缩性是针对大规模的数据集而言的。Apache Mahout的算法运行在ApacheHadoop平台下，它通过Mapreduce模式实现。但是，Apache Mahout并非严格要求算法的实现基于Hadoop平台，单个节点或非Hadoop平台也可以。Apache Mahout核心库的非分布式算法也具有良好的性能。

应用场景

参考资料

1、https://www.cnblogs.com/ahu-lichang/p/7073836.html
2、https://www.cnblogs.com/zlslch/p/6673584.html

MLib

MLib简介

MLlib(Machine Learnig lib) 是Spark对常用的机器学习算法的实现库，同时包括相关的测试和数据生成器。

MLlib目前支持4种常见的机器学习问题: 分类、回归、聚类和协同过滤

参考资料

1、https://www.cnblogs.com/shishanyuan/p/4747761.html

其它

Sqoop

Sqoop简介

Sqoop这个工具是做数据迁移用的，是关系型数据库和Hive/Hadoop的数据迁移，方便大量数据的导入导出工作。Sqoop底层是通过MapReduce去实现的，将导入或导出命令翻译成 MapReduce 程序来实现在翻译出的 MapReduce 中主要是对 InputFormat 和 OutputFormat 进行定制。

核心概念

用户向 Sqoop 发起一个命令之后，这个命令会转换为一个基于 Map Task 的 MapReduce 作业。Map Task 会访问数据库的元数据信息，通过并行的 Map Task 将数据库的数据读取出来，然后导入 Hadoop 中。当然也可以将 Hadoop 中的数据，导入传统的关系型数据库中。它的核心思想就是通过基于 Map Task （只有 map）的 MapReduce 作业，实现数据的并发拷贝和传输，这样可以大大提高效率。

应用场景

关系型数据库和Hive/Hadoop的数据双向迁移

参考资料

1、https://www.e-learn.cn/content/qita/814144
2、https://www.cnblogs.com/qingyunzong/p/8807252.html
3、https://blog.csdn.net/py_123456/article/details/80761446

Eagle

Eagle简介

Apache Eagle 是由 eBay 公司开源的一个识别大数据平台上的安全和性能问题的开源解决方案。该项目于2017年1月10日正式成为 Apache 顶级项目。 Apache Eagle 提供一套高效分布式的流式策略引擎，具有高实时、可伸缩、易扩展、交互友好等特点，同时集成机器学习对用户行为建立Profile以实现实时智能实时地保护 Hadoop 生态系统中大数据的安全。
Apache Eagle 主要包括三大层：

数据收集及存储层（Data Collection and Storage）
数据处理层（Data Processing）
可视化层（Visualize）

参考资料

1、https://eagle.apache.org/#home_page
2、https://www.iteblog.com/archives/2315.html

综合应用

1、使用Flume+Logstash+Kafka+Spark Streaming进行实时日志处理分析
2、经典大数据架构案例：酷狗音乐的大数据平台重构