大数据架构之端到端方案综述（2）数据处理

序言：大数据处理的核心问题，一是海量数据如何存储？二是海量数据如何计算？传统的数据库处理，无论是存储数据的能力，还是处理数据的能力，在面对大量数据时，瓶颈渐显。大数据的诞生很好地处理了以上两个问题，传统数据处理体系和大数据体系的区别如下图所示：

本文将介绍大数据系统最基本组件之处理框架，按之前看过的文章，将其分为三大类：

仅批处理框架，Apache Hadoop，指处理大量数据的任务，无论直接从持久存储设备处理数据集或首先将数据集载入内存，批处理系统在设计过程中充分考虑了数据的量，可提供充足的处理资源。由于批处理在应对大量持久数据方面的表现极为出色，因此经常被用于对历史数据进行分析。

仅流处理框架，Apache Storm，流处理系统可以处理几乎无限量的数据，但同一时间只能处理一条（真正的流处理）或很少量（微批处理，Micro-batch Processing）数据。

混合框架，Apache Spark，Apache Flink，一些处理框架可同时处理批处理和流处理工作负载。这些框架可以用相同或相关的组件和API处理两种类型的数据，借此让不同的处理需求得以简化。

1 Hadoop介绍

1.1 Hadoop简介

Hadoop 是一个由 Apache 基金会所开发的分布式系统基础架构，它可以使用户在不了解分布式底层细节的情況下开发分布式程序，充分利用集群的威力进行高速运算和存储。从其定义就可发现，它解決了两大问题，大数据存储和大数据分析，也就是 Hadoop 的两大核心，HDFS 和 MapReduce。（from https://www.cnblogs.com/binarylei/p/8903601.html）

HDFS(Hadoop Distributed File System)是可扩展、容错、高性能的分布式文件系统，异步复制，一次写入多次读取，主要负责存储。

MapReduce 为分布式计算框架，包含map(映射)和 reduce(归约)过程，负责在 HDFS 上进行计算。

我们先来了解下 Hadoop 的发展历史

2002~2004 年，第一轮互联网泡沫刚刚破灭，很多互联网从业人员都失业了。我们们的“主角" Doug Cutting 也不例外，他只能写点技术文章赚点稿费来养家糊口。但是 Doug Cutting 不甘寂寞，怀着对梦想和未来的渴望，与他的好朋友 Mike Cafarella 一起开发出一个开源的搜索引擎 Nutch，并历时一年把这个系统做到能支持亿级网页的搜索。但是当时的网页数量远远不止这个规模，所以两人不断改进，想让支持的网页量再多一个数量级。

在 2003 年和 2004 年， Googles 分別公布了 GFS 和 Mapreduce 两篇论文。 Doug Cutting 和 Mike Cafarella 发现这与他们的想法不尽相同，且更加完美，完全脱离了人工运维的状态，实现了自动化。

在经过一系列周密考虑和详细总结后，2006 年， Dog Cutting 放奔创业，随后几经周折加入了 yahoo 公司(Nutch 的部分也被正式引入)，机绿巧合下，他以自己儿子的一个玩具大象的名字 Hadoop 命名了该项。

当系统进入 Yahoo 以后，项目逐渐发展并成熟了起来。首先是集群规模，从最开始几十台机器的规模发展到能支持上千个节点的机器，中间做了很多工程性质的工作；然后是除搜索以外的业务开发， Yahoo 逐步将自己广告系统的数据挖掘相关工作也迁移到了 Hadoop 上，使 Hadoop 系统进一步成熟化了。

2007 年，纽约时报在 100 个亚马逊的虚拟机服务器上使用 Hadoop 转换了 4TB 的图片数据更加加深了人们对 Hadoope 的印象。

在 2008 年的时侯，一位 Google 的工程师发现要把当时的 Hadoop 放到任意一个集群中去运是一件很困难的事情，所以就与几个好朋友成立了ー个专门商业化 Hadoop 的公司 Cloudera。同年， Facebook 团队发现他们很多人不会写 Hadoop 的程序，而对 SQL 的一套东西很熟，所以他们就在 Hadoop 上构建了一个叫作 Hive 的软件，专把 SQL 转换为 Hadoop 的 Mapreduce 程序。

2011年， Yahoo 将 Hadoop 团队独立出来，成立了ー个子公司 Hortonworks，专门提供 Hadoop 相关的服务。

说了这么多，那 Hadoop 有哪些优点呢？

Hadoop 是一个能够让用户轻松架构和使用的分布式计算的平台。用户可以轻松地在 Hadoop 发和运行处理海量数据的应用程序。其优点主要有以下几个：

(1) 高可靠性 ： Hadoop 按位存储和处理数据的能力值得人们信赖。

(2) 高扩展性 ： Hadoop 是在可用的计算机集簇间分配数据并完成计算任务的，这些集簇可以方便地扩展到数以干计的节点中。

(3) 高效性 ： Hadoop能够在节点之间动态地移动数据，并保证各个节点的动态平衡，因此处理速度非常快。

(4) 高容错性 ： Hadoop能够自动保存数据的多个副本，并且能够自动将失败的任务重新分。

(5) 低成本 ： 与一体机、商用数据仓库以及 QlikView、 Yonghong Z- Suites 等数据集市相比，Hadoop 是开源的，项目的软件成本因此会大大降低。

Hadoop 带有用 Java 语言编写的框架，因此运行在 linux 生产平台上是非常理想的， Hadoop 上的应用程序也可以使用其他语言编写，比如 C++。

1.2 Hadoop架构

1.2.1 Hadoop 存储 - HDFS

Hadoop 的存储系统是 HDFS(Hadoop Distributed File System)分布式文件系统，对外部客户端而言，HDFS 就像一个传统的分级文件系统，可以进行创建、删除、移动或重命名文件或文件夹等操作，与 Linux 文件系统类似。

但是，Hadoop HDFS 的架构是基于一组特定的节点构建的，名称节点(NameNode)，它在 HDFS 内部提供元数据服务；第二名称节点(Secondary NameNode)，名称节点的帮助节点，主要是为了整合元数据操作(注意不是名称节点的备份)；数据节点(DataNode)，它为 HDFS 提供存储块。

存储在 HDFS 中的文件被分成块，然后这些块被复制到多个数据节点中(DataNode)，这与传统的 RAID 架构大不相同。块的大小(通常为 128M)和复制的块数量在创建文件时由客户机决定。名称节点可以控制所有文件操作。HDFS 内部的所有通信都基于标准的 TCP/IP 协议。

关于各个组件的具体描述如下所示：

（1）名称节点（NameNode）

它是一个通常在HDFS架构中单独机器上运行的组件，负责管理文件系统名称空间和控制外部客户机的访问。NameNode决定是否将文件映射到DataNode上的复制块上。对于最常见的3个复制块，第一个复制块存储在同一机架的不同节点上，最后一个复制块存储在不同机架的某个节点上。

（2）数据节点（DataNode）

数据节点也是一个通常在HDFS架构中的单独机器上运行的组件。Hadoop集群包含一个NameNode和大量DataNode。数据节点通常以机架的形式组织，机架通过一个交换机将所有系统连接起来。

数据节点响应来自HDFS客户机的读写请求。它们还响应来自NameNode的创建、删除和复制块的命令。名称节点依赖来自每个数据节点的定期心跳（heartbeat）消息。每条消息都包含一个块报告，名称节点可以根据这个报告验证块映射和其他文件系统元数据。如果数据节点不能发送心跳消息，名称节点将采取修复措施，重新复制在该节点上丢失的块。

（3）第二名称节点（Secondary NameNode）

第二名称节点的作用在于为HDFS中的名称节点提供一个Checkpoint，它只是名称节点的一个助手节点，这也是它在社区内被认为是Checkpoint Node的原因。

只有在NameNode重启时，edits才会合并到fsimage文件中，从而得到一个文件系统的最新快照。但是在生产环境集群中的NameNode是很少重启的，这意味着当NameNode运行很长时间后，edits文件会变得很大。而当NameNode宕机时，edits就会丢失很多改动，如何解决这个问题呢？

fsimage 是 NameNode 启动时对整个文件系统的快照；edits 是在 NameNode 启动后对文件系统的改动序列。

Secondary NameNode 会定时到 NameNode 去获取名称节点的 edits，并及时更新到自己 fsimage 上。这样，如果 NameNode 宕机，我们也可以使用 Secondary-NameNode 的信息来恢复 NameNode。并且，如果 Secondary NameNode 新的 fsimage 文件达到一定阈值，它就会将其拷贝回名称节点上，这样 NameNode 在下次重启时会使用这个新的 fsimage 文件，从而减少重启的时间。

举个数据上传的例子来深入理解下HDFS内部是怎么做的。

文件在客户端时会被分块，这里可以看到文件被分为 5 个块，分别是：A、B、C、D、E。同时为了负载均衡，所以每个节点有 3 个块。下面来看看具体步骤：

1. 客户端将要上传的文件按 128M 的大小分块。
2. 客户端向名称节点发送写数据请求。
3. 名称节点记录各个 DataNode 信息，并返回可用的 DataNode 列表。
4. 客户端直接向 DataNode 发送分割后的文件块，发送过程以流式写入。
5. 写入完成后，DataNode 向 NameNode 发送消息，更新元数据。

这里需要注意：

1. 写 1T 文件，需要 3T 的存储，3T 的网络流量。
2. 在执行读或写的过程中，NameNode 和 DataNode 通过 HeartBeat 进行保存通信，确定 DataNode 活着。如果发现 DataNode 死掉了，就将死掉的 DataNode 上的数据，放到其他节点去，读取时，读其他节点。
3. 宕掉一个节点没关系，还有其他节点可以备份；甚至，宕掉某一个机架也没关系；其他机架上也有备份。

1.2.2 Hadoop 计算 — MapReduce

MapReduce 是 Google 提出的一个软件架构，用于大规模数据集（大于1TB）的并行运算。概念“Map（映射）”和“Reduce（归纳）”以及它们的主要思想，都是从函数式编程语言借来的，还有从矢量编程语言借来的特性。

当前的软件实现是指定一个 Map（映射）函数，用来把一组键值对映射成一组新的键值对，指定并发的 Reduce（归纳）函数，用来保证所有映射的键值对中的每一个共享相同的键组。

下面将以 Hadoop 的“Hello World”例程—单词计数来分析MapReduce的逻辑。一般的 MapReduce 程序会经过以下几个过程：输入（Input）、输入分片（Splitting）、Map阶段、Shuffle阶段、Reduce阶段、输出（Final result）。

1. 输入就不用说了，数据一般放在 HDFS 上面就可以了，而且文件是被分块的。关于文件块和文件分片的关系，在输入分片中说明。
2. 输入分片：在进行 Map 阶段之前，MapReduce 框架会根据输入文件计算输入分片（split），每个输入分片会对应一个 Map 任务，输入分片往往和 HDFS 的块关系很密切。例如，HDFS 的块的大小是 128M，如果我们输入两个文件，大小分别是 27M、129M，那么 27M 的文件会作为一个输入分片（不足 128M 会被当作一个分片），而 129MB 则是两个输入分片（129-128＝1，不足 128M，所以 1M 也会被当作一个输入分片），所以，一般来说，一个文件块会对应一个分片。如图 1-7 所示，Splitting 对应下面的三个数据应该理解为三个分片。
3. Map 阶段：这个阶段的处理逻辑其实就是程序员编写好的 Map 函数，因为一个分片对应一个 Map 任务，并且是对应一个文件块，所以这里其实是数据本地化的操作，也就是所谓的移动计算而不是移动数据。如图 1-7 所示，这里的操作其实就是把每句话进行分割，然后得到每个单词，再对每个单词进行映射，得到单词和1的键值对。
4. Shuffle 阶段：这是“奇迹”发生的地方，MapReduce 的核心其实就是 Shuffle。那么 Shuffle 的原理呢？Shuffle 就是将 Map 的输出进行整合，然后作为 Reduce 的输入发送给 Reduce。简单理解就是把所有 Map 的输出按照键进行排序，并且把相对键的键值对整合到同一个组中。如图 1-7 所示，Bear、Car、Deer、River 是排序的，并且 Bear 这个键有两个键值对。
5. Reduce 阶段：与 Map 类似，这里也是用户编写程序的地方，可以针对分组后的键值对进行处理。如图 1-7 所示，针对同一个键 Bear 的所有值进行了一个加法操作，得到 <Bear，2> 这样的键值对。
6. 输出：Reduce 的输出直接写入 HDFS 上，同样这个输出文件也是分块的。

说了这么多，其实 MapReduce 的本质用一张图可以完整地表现出来。

MapReduce 的本质就是把一组键值对 <K1，V1> 经过 Map 阶段映射成新的键值对 <K2，V2>；接着经过 Shuffle/Sort 阶段进行排序和“洗牌”，把键值对排序，同时把相同的键的值整合；最后经过 Reduce 阶段，把整合后的键值对组进行逻辑处理，输出到新的键值对 <K3，V3>。这样的一个过程，其实就是 MapReduce 的本质。

Hadoop MapReduce 可以根据其使用的资源管理框架不同，而分为 MR v1 和 YARN/MR v2 版本。

在 MR v1 版本中，资源管理主要是 Jobtracker 和 TaskTracker。Jobtracker 主要负责：作业控制（作业分解和状态监控），主要是 MR 任务以及资源管理；而 TaskTracker 主要是调度 Job 的每一个子任务 task；并且接收 JobTracker 的命令。

在 YARN/MR v2 版本中，YARN 把 JobTracker 的工作分为两个部分：

1. ResourceManager（资源管理器）全局管理所有应用程序计算资源的分配。
2. ApplicationMaster 负责相应的调度和协调。

NodeManager 是每一台机器框架的代理，是执行应用程序的容器，监控应用程序的资源（CPU、内存、硬盘、网络）使用情况，并且向调度器汇报。

1.2.3 Hadoop 资源管理 — YARN

在上一节中我们看到，当 MapReduce 发展到 2.x 时就不使用 JobTracker 来作为自己的资源管理框架，而选择使用 YARN。这里需要说明的是，如果使用 JobTracker 来作为 Hadoop 集群的资源管理框架的话，那么除了 MapReduce 任务以外，不能够运行其他任务。也就是说，如果我们集群的 MapReduce 任务并没有那么饱满的话，集群资源等于是白白浪费的。所以提出了另外的一个资源管理架构 YARN（Yet Another Resource Manager）。这里需要注意，YARN 不是 JobTracker 的简单升级，而是“大换血”。同时 Hadoop 2.X 也包含了此架构。Apache Hadoop 2.X 项目包含以下模块。

• Hadoop Common：为 Hadoop 其他模块提供支持的基础模块。
• HDFS：Hadoop：分布式文件系统。
• YARN：任务分配和集群资源管理框架。
• MapReduce：并行和可扩展的用于处理大数据的模式。

YARN 资源管理框架包括 ResourceManager（资源管理器）、Applica-tionMaster、NodeManager（节点管理器）。各个组件描述如下。

（1）ResourceManager

ResourceManager 是一个全局的资源管理器，负责整个系统的资源管理和分配。它主要由两个组件构成：调度器（Scheduler）和应用程序管理器（ApplicationManager，AM）。

Scheduler 负责分配最少但满足 Application 运行所需的资源量给 Application。Scheduler 只是基于资源的使用情况进行调度，并不负责监视/跟踪 Application 的状态，当然也不会处理失败的 Task。

ApplicationManager 负责处理客户端提交的 Job 以及协商第一个 Container 以供 App-licationMaster 运行，并且在 ApplicationMaster 失败的时候会重新启动 ApplicationMaster（YARN 中使用 Resource Container 概念来管理集群的资源，Resource Container 是资源的抽象，每个 Container 包括一定的内存、IO、网络等资源）。

（2）ApplicationMaster

ApplicatonMaster 是一个框架特殊的库，每个 Application 有一个 ApplicationMaster，主要管理和监控部署在 YARN 集群上的各种应用。

（3）NodeManager

主要负责启动 ResourceManager 分配给 ApplicationMaster 的 Container，并且会监视 Container 的运行情况。在启动 Container 的时候，NodeManager 会设置一些必要的环境变量以及相关文件；当所有准备工作做好后，才会启动该 Container。启动后，NodeManager 会周期性地监视该 Container 运行占用的资源情况，若是超过了该 Container 所声明的资源量，则会 kill 掉该 Container 所代表的进程。

如图 1-11 所示，该集群上有两个任务（对应 Node2、Node6 上面的 AM），并且 Node2 上面的任务运行有 4 个 Container 来执行任务；而 Node6 上面的任务则有 2 个 Container 来执行任务。

1.2.4 Hadoop 生态系统

Hadoop 的生态圈其实就是一群动物在狂欢。我们来看看一些主要的框架。

（1）HBase

HBase（Hadoop Database）是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用 HBase 技术可在廉价 PC Server 上搭建起大规模结构化存储集群。

（2）Hive

Hive 是建立在 Hadoop 上的数据仓库基础构架。它提供了一系列的工具，可以用来进行数据提取转化加载（ETL），这是一种可以存储、查询和分析存储在 Hadoop 中的大规模数据的机制。

（3）Pig

Pig 是一个基于 Hadoop 的大规模数据分析平台，它提供的 SQL-LIKE 语言叫作 Pig Latin。该语言的编译器会把类 SQL 的数据分析请求转换为一系列经过优化处理的 Map-Reduce 运算。

（4）Sqoop

Sqoop 是一款开源的工具，主要用于在 Hadoop（Hive）与传统的数据库（MySQL、post-gresql等）间进行数据的传递，可以将一个关系型数据库中的数据导入 Hadoop 的 HDFS 中，也可以将 HDFS 的数据导入关系型数据库中，如图 1-13 所示。

（5）Flume

Flume 是 Cloudera 提供的一个高可用、高可靠、分布式的海量日志采集、聚合和传输的系统，Flume 支持在日志系统中定制各类数据发送方，用于收集数据。同时，Flume 提供对数据进行简单处理并写到各种数据接受方（可定制）的能力，如图 1-14 所示。

（6）Oozie

Oozie 是基于 Hadoop 的调度器，以 XML 的形式写调度流程，可以调度 Mr、Pig、Hive、shell、jar 任务等。

主要的功能如下。

1. Workflow：顺序执行流程节点，支持 fork（分支多个节点）、join（将多个节点合并为一个）。
2. Coordinator：定时触发 Workflow。
3. Bundle Job：绑定多个 Coordinator。

（7）Chukwa

Chukwa 是一个开源的、用于监控大型分布式系统的数据收集系统。它构建在 Hadoop 的 HDFS 和 MapReduce 框架上，继承了 Hadoop 的可伸缩性和鲁棒性。Chukwa 还包含了一个强大和灵活的工具集，可用于展示、监控和分析已收集的数据。

（8）ZooKeeper

ZooKeeper 是一个开放源码的分布式应用程序协调服务，是 Google 的 Chubby 一个开源的实现，是 Hadoop 和 Hbase 的重要组件，如图 1-15 所示。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

（9）Avro

Avro 是一个数据序列化的系统。它可以提供：丰富的数据结构类型、快速可压缩的二进制数据形式、存储持久数据的文件容器、远程过程调用 RPC。

（10）Mahout

Mahout 是 Apache Software Foundation（ASF）旗下的一个开源项目，提供一些可扩展的机器学习领域经典算法的实现，旨在帮助开发人员更加方便快捷地创建智能应用程序。Mahout 包含许多实现，包括聚类、分类、推荐过滤、频繁子项挖掘。此外，通过使用 Apache Hadoop 库，可以有效地将 Mahout 扩展到云中。

1.3 应用场景

Hadoop适用于海量数据、离线数据和负责数据，应用场景如下，

场景1：数据分析，如海量日志分析，商品推荐，用户行为分析

场景2：离线计算，(异构计算+分布式计算)

场景3：海量数据存储

2 Storm介绍

from https://www.cnblogs.com/zhaojiankai/p/757617.html

2.1 Storm简介

Apache Storm是自由开源的分布式实时计算系统，擅长处理海量数据，适用于数据实时处理而非批处理。Storm中核心概念：

Nimbus：Storm集群主节点，负责资源分配和任务调度。我们提交任务和截止任务都是在Nimbus上操作的。一个Storm集群只有一个Nimbus节点。

Supervisor：Storm集群工作节点，接受Nimbus分配任务，管理所有Worker。

Worker：工作进程，每个工作进程中都有多个Task。

Task：任务，每个Spout和Bolt都是一个任务，每个任务都是一个线程。

Topology：计算拓扑，包含了应用程序的逻辑。

Stream：消息流，关键抽象，是没有边界的Tuple序列。

Spout：消息流的源头，Topology的消息生产者。

Bolt：消息处理单元，可以过滤、聚合、查询数据库。

Stream grouping：消息分发策略，一共6种，定义每个Bolt接受何种输入。

Reliability：可靠性，Storm保证每个Tuple都会被处理。

2.2 Strom架构

Zookeeper集群在Storm集群中的作用：

Zookeeper集群负责Nimbus节点和Supervior节点之间的通信，监控各个节点之间的状态。比如通常我们提交任务的时候是在Nimbus节点上执行的，Nimbus节点通过zk集群将任务分发下去，而Supervisor是真正执行任务的地方。Nimbus节点通过zk集群监控各个Supervisor节点的状态，当某个Supervisor节点出现故障的时候，Nimbus节点就会通过zk集群将那个Supervisor节点上的任务重新分发，在其他Supervisor节点上执行。这就意味着Storm集群也是高可用集群，如果Nimbus节点出现故障的时候，整个任务并不会停止，但是任务的管理会出现影响，通常这种情况下我们只需要将Nimbus节点恢复就可以了。Nimbus节点不支持高可用，这也是Storm目前面临的问题之一。不过一般情况下，Nimbus节点的压力不大，通常不会出现问题。

一般情况下，Zookeeper集群的压力并不大，一般只需要部署3台就够了。Zookeeper集群在Storm集群中逻辑上是独立的，但在实际部署的时候，一般会将zk节点部署在Nimbus节点或Supervisor节点上。

storm处理数据的特点：数据源源不断，不断处理。

storm中是没有数据存储结构的，我们需要自己设计数据落地接口，指明数据存储到哪一部分中。Storm本身是不存储数据的。

3 Spark介绍

3.1 Spark简介

Apache Spark是一个围绕速度、易用性和复杂分析构建的大数据处理框架，最初在2009年由加州大学伯克利分校的AMPLab开发，并于2010年成为Apache的开源项目之一，与Hadoop和Storm等其他大数据和MapReduce技术相比，Spark有如下优势：

Spark提供了一个全面、统一的框架用于管理各种有着不同性质（文本数据、图表数据等）的数据集和数据源（批量数据或实时的流数据）的大数据处理的需求。官方资料介绍Spark可以将Hadoop集群中的应用在内存中的运行速度提升100倍，甚至能够将应用在磁盘上的运行速度提升10倍

3.2 Spark架构

通常当需要处理的数据量超过了单机尺度(比如我们的计算机有4GB的内存，而我们需要处理100GB以上的数据)这时我们可以选择spark集群进行计算，有时我们可能需要处理的数据量并不大，但是计算很复杂，需要大量的时间，这时我们也可以选择利用spark集群强大的计算资源，并行化地计算，其架构示意图如下：

• Spark Core：包含Spark的基本功能；尤其是定义RDD的API、操作以及这两者上的动作。其他Spark的库都是构建在RDD和Spark Core之上的
• Spark SQL：提供通过Apache Hive的SQL变体Hive查询语言（HiveQL）与Spark进行交互的API。每个数据库表被当做一个RDD，Spark SQL查询被转换为Spark操作。
• Spark Streaming：对实时数据流进行处理和控制。Spark Streaming允许程序能够像普通RDD一样处理实时数据
• MLlib：一个常用机器学习算法库，算法被实现为对RDD的Spark操作。这个库包含可扩展的学习算法，比如分类、回归等需要对大量数据集进行迭代的操作。
• GraphX：控制图、并行图操作和计算的一组算法和工具的集合。GraphX扩展了RDD API，包含控制图、创建子图、访问路径上所有顶点的操作
• Spark架构的组成图如下：

• Cluster Manager：在standalone模式中即为Master主节点，控制整个集群，监控worker。在YARN模式中为资源管理器
• Worker节点：从节点，负责控制计算节点，启动Executor或者Driver。
• Driver： 运行Application 的main()函数
• Executor：执行器，是为某个Application运行在worker node上的一个进程

Spark与hadoop:

• Hadoop有两个核心模块，分布式存储模块HDFS和分布式计算模块Mapreduce
• spark本身并没有提供分布式文件系统，因此spark的分析大多依赖于Hadoop的分布式文件系统HDFS
• Hadoop的Mapreduce与spark都可以进行数据计算，而相比于Mapreduce，spark的速度更快并且提供的功能更加丰富

关系图如下：

 运行流程及特点：

spark运行流程图如下：

1. 构建Spark Application的运行环境，启动SparkContext
2. SparkContext向资源管理器（可以是Standalone，Mesos，Yarn）申请运行Executor资源，并启动StandaloneExecutorbackend，
3. Executor向SparkContext申请Task
4. SparkContext将应用程序分发给Executor
5. SparkContext构建成DAG图，将DAG图分解成Stage、将Taskset发送给Task Scheduler，最后由Task Scheduler将Task发送给Executor运行
6. Task在Executor上运行，运行完释放所有资源

     Spark运行特点：

1. 每个Application获取专属的executor进程，该进程在Application期间一直驻留，并以多线程方式运行Task。这种Application隔离机制是有优势的，无论是从调度角度看（每个Driver调度他自己的任务），还是从运行角度看（来自不同Application的Task运行在不同JVM中），当然这样意味着Spark Application不能跨应用程序共享数据，除非将数据写入外部存储系统
2. Spark与资源管理器无关，只要能够获取executor进程，并能保持相互通信就可以了
3. 提交SparkContext的Client应该靠近Worker节点（运行Executor的节点），最好是在同一个Rack里，因为Spark Application运行过程中SparkContext和Executor之间有大量的信息交换
4. Task采用了数据本地性和推测执行的优化机制

常用术语:

Application: Appliction都是指用户编写的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， 这个每一个oarseGrainedExecutor Backend能并行运行Task的数量取决与分配给它的cpu个数

Cluter Manager：指的是在集群上获取资源的外部服务。目前有三种类型

1. 1. Standalon : spark原生的资源管理，由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之间的依赖的关系找出开销最小的调度方法，如下图

TASKSedulter: 将TaskSET提交给worker运行，每个Executor运行什么Task就是在此处分配的. TaskScheduler维护所有TaskSet，当Executor向Driver发生心跳时，TaskScheduler会根据资源剩余情况分配相应的Task。另外TaskScheduler还维护着所有Task的运行标签，重试失败的Task。下图展示了TaskScheduler的作用

4 Flink介绍

4.1 Flink简介

Flink核心是一个流式的数据流执行引擎，其针对数据流的分布式计算提供了数据分布、数据通信以及容错机制等功能。基于流执行引擎，Flink提供了诸多更高抽象层的API以便用户编写分布式任务：

DataSet API， 对静态数据进行批处理操作，将静态数据抽象成分布式的数据集，用户可以方便地使用Flink提供的各种操作符对分布式数据集进行处理，支持Java、Scala和Python。

DataStream API，对数据流进行流处理操作，将流式的数据抽象成分布式的数据流，用户可以方便地对分布式数据流进行各种操作，支持Java和Scala。

Table API，对结构化数据进行查询操作，将结构化数据抽象成关系表，并通过类SQL的DSL对关系表进行各种查询操作，支持Java和Scala。

此外，Flink还针对特定的应用领域提供了领域库，例如：

Flink ML，Flink的机器学习库，提供了机器学习Pipelines API并实现了多种机器学习算法。

Gelly，Flink的图计算库，提供了图计算的相关API及多种图计算算法实现。

为什么我会接触到 Flink 呢？因为我目前在负责的是监控平台的告警部分，负责采集到的监控数据会直接往 kafka 里塞，然后告警这边需要从 kafka topic 里面实时读取到监控数据，并将读取到的监控数据做一些 聚合/转换/计算 等操作，然后将计算后的结果与告警规则的阈值进行比较，然后做出相应的告警措施（钉钉群、邮件、短信、电话等）。画了个简单的图如下：

4.2 Flink架构

Flink 是一个开源的分布式流式处理框架：

①提供准确的结果，甚至在出现无序或者延迟加载的数据的情况下。

②它是状态化的容错的，同时在维护一次完整的的应用状态时，能无缝修复错误。

③大规模运行，在上千个节点运行时有很好的吞吐量和低延迟。

更早的时候，我们讨论了数据集类型（有界 vs 无穷）和运算模型（批处理 vs 流式）的匹配。Flink 的流式计算模型启用了很多功能特性，如状态管理，处理无序数据，灵活的视窗，这些功能对于得出无穷数据集的精确结果是很重要的。

除了提供数据驱动的视窗外，Flink还支持基于时间，计数，session等的灵活视窗。视窗能够灵活的触发条件定制化从而达到对复杂的流传输模式的支持。Flink的视窗使得模拟真实的创建数据的环境成为可能。

Flink的容错能力事轻量级的，允许系统提供高并发，同时在同一时间提供强一致性保证。Flink以零数据丢失的方式从故障中恢复，但没有考虑可靠性和延迟之间的折中。

Flink可以满足高并发和低延迟（计算大量数据很快）。下图显示了Apache Flink与Apache Storm在完成流数据清晰的分布式的性能对比

Flink保存点提供了一个状态化的版本机制，使得能以无丢失状态和最短时间的停机方式更新应用和回退历史数据。

Flink被设计成用上千个点在大规模集群上运行。除了支持独立集群部署外，Flink还支持YARN和Me'sos方式部署。

Flink的程序内在事并行和分布式的，数据流可以被分区成stram partitions，operators被划分为operator subtasks；这些subtasks在不同的机器火容器中分不同的西城独立运行；operator subtasks的数量在具体的operator就是并行计算数，程序不同的operator 阶段可能有不同的并行数；如下图所示，source operator 的并行书为2，但是最后的sink operator 为1；

flink 作业提交架构流程可见下图：

1、Program Code：我们编写的 Flink 应用程序代码

2、Job Client：Job Client 不是 Flink 程序执行的内部部分，但它是任务执行的起点。 Job Client 负责接受用户的程序代码，然后创建数据流，将数据流提交给 Job Manager 以便进一步执行。 执行完成后，Job Client 将结果返回给用户

、Job Manager：主进程（也称为作业管理器）协调和管理程序的执行。 它的主要职责包括安排任务，管理checkpoint ，故障恢复等。机器集群中至少要有一个 master，master 负责调度 task，协调 checkpoints 和容灾，高可用设置的话可以有多个 master，但要保证一个是 leader, 其他是 standby; Job Manager 包含 Actor system、Scheduler、Check pointing 三个重要的组件

4、Task Manager：从 Job Manager 处接收需要部署的 Task。Task Manager 是在 JVM 中的一个或多个线程中执行任务的工作节点。 任务执行的并行性由每个 Task Manager 上可用的任务槽决定。 每个任务代表分配给任务槽的一组资源。 例如，如果 Task Manager 有四个插槽，那么它将为每个插槽分配 25％ 的内存。 可以在任务槽中运行一个或多个线程。 同一插槽中的线程共享相同的 JVM。 同一 JVM 中的任务共享 TCP 连接和心跳消息。Task Manager 的一个 Slot 代表一个可用线程，该线程具有固定的内存，注意 Slot 只对内存隔离，没有对 CPU 隔离。默认情况下，Flink 允许子任务共享 Slot，即使它们是不同 task 的 subtask，只要它们来自相同的 job。这种共享可以有更好的资源利用率。

5 各处理方式对比

请参考 https://www.jianshu.com/p/5cc07eae1a0c

谢谢