欢迎关注wx公众号：DLab数据实验室 关注更多知识干货～

​​​​

概述

大数据计算发展至今，已经形成了一个百花齐放的大数据生态，通用的、定制的，批量的、实时的，关系的、图的、非结构的，数据计算的、机器学习的，我们都可以找到各种对应的计算引擎。
本文拟以大数据平台从底到高的层次为主线，梳理整个大数据计算生态。
下面大数据计算生态的图最上层为应用层，也就是实际与开发人员交互的层，例如分析人员通过在Hive中写SQL就可以调用到中间层的MapReduce引擎来进行分析处理。Spark的GraphX、MLlib等组件可以用来进行图分析和机器学习等。中间层的Spark、Flink等作为核心计算引擎提供批计算和流计算支持。左边ZK和Oozie是任务配置协调，右边的是日志采集、迁移或者获取数据相关的组件，再往下是最重要的资源调度管理系统，最底层是数据存储，一个大数据平台就要提供能进行多模型数据存储的能力，比如除了最常见的关系数据，还有时序、文档、键值和图等数据。
当然，这个图有些组件所处的层次其实还值得继续讨论，例如ElasticSearch其实也是一个存储组件，Hbase在作为存储组件的时候其实也作为查询计算组件使用，Flink也可以放到最上层，作为开发人员直接交互的组件。Anyway，整体来讲，整个大数据生态差不多就是这样子的，下面来具体进行介绍一下。

 

分析

大数据平台按照整体架构从底向上可以分为：存储层、缓存层、计算层、组件层、工具层、调度协调层。大数据平台的各层之间是向上赋能的。例如计算层依赖存储层，组件应用层依赖于计算层。
下面针对每个不同的功能层中的每个组件进行介绍。这里将会从概览的角度来介绍每个引擎或者组件，后续会通过一系列的文章对每个引擎或者组件进行详细的分析。

1.存储层

存储层负责进行大数据平台的数据存储。过去的几十年，数据大部分以结构化的形式存储在关系数据库中，常见的如Oracle和MySQL两种。随着数据越来越多样，出现了各种类型的数据库，如图数据库、键值数据库、时序数据库、文档数据库等，以及除了传统的行存数据库外，也出现了列存数据库或者文件格式。

1.1 HDFS：HDFS 是 Hadoop Distribute File System，Hadoop分布式文件系统的简称。这个文件系统是一个适用于大的数据集的支持高吞吐和高容错的运行在通用（廉价）机上的分布式文件系统。

HDFS 是一个主从架构的服务。一个 HDFS 集群包括一个 NameNode 节点、一个 SecondaryNameNode 节点（非必须）和多个 DataNode 节点。

图中的几个要点：

• NameNode管理着Metadata（元数据）
• 客户端client对元数据的操作是指向NameNode，对用户数据的读写是通过DataNode
• NameNode向DataNode发送Block的操作命令
• 一块的副本被存储在不同的机架中

1.2 关系数据存储（行存储)

传统的数据库例如MySQL,Oracle等关系数据库，都采用的是行存储引擎，在基于行式存储的数据库中， 数据是按照行数据为基础逻辑存储单元进行存储的， 一行中的数据在存储介质中以连续存储形式存在。

1.3 列存储

列式存储(Column-based)是相对于行式存储来说的，新兴的 Hbase、HP Vertica、EMC Greenplum 等分布式数据库均采用列式存储。在基于列式存储的数据库中， 数据是按照列为基础的逻辑存储单元进行存储的，一列中的数据在存储介质中以连续存储形式存在。

1.4 多模型存储

随着数据多样性的发展，多种类型的数据大量涌出，相对应的NoSQL系统也出现了。例如Neo4j图存储，用来存储社交网络、知识图谱等图数据；再入近两年Iot智能制造的兴起，大量工业生产生活中的时序数据，也对应出现了InfluxDB这种存储时序数据的系统；还有生产中常用的键值数据库Redis等。

2. 缓存层

缓存其实已经不是什么新概念了，无论是在操作系统还是传统的数据管理系统，都有缓冲区或者缓存的概念，主要是为了平衡CPU和磁盘之间的速度的差异，提高效率。在大数据的应用场景中，由于数据量比较大，数据的处理逻辑也比较复杂，因此一些中间过程结果可以复用的数据就可以通过分布式缓存来进行临时存储，其他的任务就可以避免数据的二次加工从而提高效率。

2.1 Alluxio

Alluxio（之前名为Tachyon）是世界上第一个以内存为中心的虚拟的分布式存储系统。它统一了数据访问的方式，为上层计算框架和底层存储系统构建了桥梁。 应用只需要连接Alluxio即可访问存储在底层任意存储系统中的数据。此外，Alluxio的以内存为中心的架构使得数据的访问速度能比现有方案快几个数量级。

 

Alluxio的特点是数据存储与计算分离，两部分引擎可以进行独立的扩展。上层的计算引擎(如Hadoop, Spark)可以通过Alluxio访问不同数据源(Amazon S3, HDFS)中的数据，通过Alluxio屏蔽底层不同的数据源，做到数据的无感获取。

3. 计算层（计算引擎）

有了数据之后，各个应用就可以利用这些数据进行不同维度或角度的分析，从而形成不同的数据价值产品。支撑这一过程的最重要的就是计算引擎。计算引擎为各个数据任务提供算力支持。
目前可以把计算引擎分为三类，批处理、流处理和即席（Ad-Hoc）查询三类。
批处理指的是大规模复杂的数据处理过程，通常的时间跨度在几分钟到数小时甚至数日；流处理指的是实时的数据处理和查询，通常的时间跨度在数百毫秒到数秒之间；即席（Ad-Hoc）查询指的是介于实时和批处理之间的一种查询处理，如一些交互式的数据探查任务，需要秒级或分钟级的较快的响应时间。

3.1 批处理

3.1.1 MapReduce（Hadoop）

MapReduce就是指我们常说的Hadoop MapReduce，它是一个批处理计算引擎。每个MapReduce任务都包含两个过程：Map过程和Reduce过程。

 

• • MapReduce的计算模型：Map和Reduce两个计算过程(中间用Shuffle串联),MapReduce程序
  • Map阶段：多台机器同时读取一个文件的各个部分，分别统计词频，产生多个Map集合
  • Reduce阶段：接收所对应的Map集合结果，将相同键的集合汇总，进而得到整个文件的词频结果
  • Map+Reduce过于笨重
  • 第二代的Tez/Spark让Map/Reduce模型更通用，让Map和Reduce之间的界限更模糊，数据交换更灵活，更少的磁盘读写，以便更方便地描述复杂算法，取得更高的吞吐量

 

3.1.2 Spark

与Hadoop MapReduce不同的是，Spark是基于内存的批处理计算引擎。SparkSpark及其组件已经形成了一个大数据生态，Spark基于这个引擎，提供了很多的高级应用模块解决不同场景中的业务需求。Spark分为Spark Core、SparkSQL、SparkStreaming、GraphX以及MLLib等，SparkCore为Spark的核心和基础，提供基本的批处理功能，其他的每个组件专注于不同的处理任务。

 

Spark与Hadoop相比主要有且不限于以下几个优势：

减少磁盘I/O：Hadoop的的map和reduce过程每此处理都要涉及读写磁盘，map端的中间结果也要排序并写入磁盘，reduce从磁盘中进行读取；这样整个处理过程中磁盘I/O就成了处理瓶颈；Spark允许将map端的中间结果放入内存，reduce直接从内存中拉取数据，避免了大量的磁盘I/O。

提高并行度：MapReduce的并行度是进程级别，Spark是线程级别。MapReduce需要进行磁盘的map写入，reduce读取，属于串行执行；spark把不同环节抽象为stage，允许多个stage串行执行或并行执行。

避免重复计算：Spark中通过DAG（有向无环图）来串起数据处理的各个Stage阶段，如果某个阶段发生故障或者数据丢失，可以利用血缘机制来回溯某个RDD，从而减少数据的重新计算，提高效率。

3.2 流处理

3.2.1 Flink

Flink是一个面向数据流处理和批量数据处理的可分布式的开源计算框架，它基于同一个Flink流式执行模型（streaming execution model），能够支持流处理和批处理两种应用类型。

它将数据流抽象为无界流和有界流。无界流是有开始但是没有结束的数据流，有界流是有开始也有结束的数据流。

 

Flink组件栈

 

Deployment层： 该层主要涉及了Flink的部署模式，Flink支持多种部署模式：本地、集群（Standalone/YARN），（GCE/EC2）。

Runtime层：Runtime层提供了支持Flink计算的全部核心实现，比如：支持分布式Stream处理、JobGraph到ExecutionGraph的映射、调度等等，为上层API层提供基础服务。

API层： 主要实现了面向无界Stream的流处理和面向Batch的批处理API，其中面向流处理对应DataStream API，面向批处理对应DataSet API。

Libraries层：该层也可以称为Flink应用框架层，根据API层的划分，在API层之上构建的满足特定应用的实现计算框架，也分别对应于面向流处理和面向批处理两类。面向流处理支持：CEP（复杂事件处理）、基于SQL-like的操作（基于Table的关系操作）；面向批处理支持：FlinkML（机器学习库）、Gelly（图处理）

3.2.2 Storm

Storm是Twitter开源的分布式实时大数据处理框架，被业界称为实时版Hadoop。

Apache Storm从一端读取实时数据的原始流，并将其传递通过一系列小处理单元，并在另一端输出处理/有用的信息。

下图描述了Apache Storm的核心概念。

 

但是随着SparkStreaming混合Flink的兴起，目前Storm的使用已经越来越少。

 

3.2.3 Spark（Streaming/Structured）

除此之外，在流处理上，还有Spark生态中的Spark streaming和structured streaming。

Spark Streaming：Spark Streaming是Spark最早推出的流处理组件，它基于流式批处理引擎，基本原理是把输入数据以某一时间间隔批量的处理（微批次），当批处理时间间隔缩短到秒级时，便可以用于实时数据流。

编程模型：在sparkstreaming内部，将接收到数据流按照一定的时间间隔进行切分，然后交给spark引擎处理，最终得到一个个微批的处理结果。

 

数据抽象：离散数据流或者数据流是sparkStreaming提供的基本抽象。他可以是从数据源不断流入的，也可以是从一个数据流转换而来的。本质上就是一系列的RDD。每个流中的RDD包含了一个特定时间间隔内的数据集合，如下图所示。

Structured Streaming：毫秒级别的持续流式处理，Spark 2.0 引入了Structured Streaming， 将微批次处理从高级 API 中解耦出去。它简化了 API 的使用，API 不再负责进行微批次处理；开发者可以将流看成是一个没有边界的表，并基于这些“表”运行查询。Structured Streaming的默认引擎基于微批处理引擎，并且可以达到最低100ms的延迟和数据处理的exactly-once保证。
Spark 2.3 继续向更快、更易用、更智能的目标迈进，引入了低延迟的持续流处理模式，可以达到端到端最低1ms的延迟和数据处理的at-least-once的保证。
采用何种处理模式只需要进行简单的模式配置即可。

编程模型：无界表，每个流的数据源从逻辑上来说看做一个不断增长的动态表（无界表），从数据源不断流入的每个数据项可以看作为新的一行数据追加到动态表中。用户可以通过静态结构化数据的批处理查询方式（SQL查询），对数据进行实时查询。

 

3.3 即席查询（Ad-Hoc)

3.3.1 Impala

Impala是用于处理存储在Hadoop集群中的大量数据的MPP（大规模并行处理）SQL查询引擎。 它是一个用C ++和Java编写的开源软件。 与其他Hadoop的SQL引擎相比，它提供了高性能和低延迟。

换句话说，Impala是性能最高的SQL引擎（提供类似RDBMS的体验），它提供了访问存储在Hadoop分布式文件系统中的数据的最快方法。

与Hive依赖于MapReduce计算不同，Impala采用的是基于内存的计算，因此可以更快地完成计算任务。

 

3.3.2 Presto

Presto是一个facebook开源的分布式SQL查询引擎，适用于交互式分析查询，数据量支持GB到PB字节。presto的架构由关系型数据库的架构演化而来。presto之所以能在各个内存计算型数据库中脱颖而出，在于以下几点：

1. 清晰的架构，是一个能够独立运行的系统，不依赖于任何其他外部系统。例如调度，presto自身提供了对集群的监控，可以根据监控信息完成调度。
2. 简单的数据结构，列式存储，逻辑行，大部分数据都可以轻易的转化成presto所需要的这种数据结构。
3. 丰富的插件接口，完美对接外部存储系统，或者添加自定义的函数。

 

Presto采用典型的master-slave模型：

1. coordinator(master)负责meta管理,worker管理，query的解析和调度
2. worker则负责计算和读写。
3. discovery server， 通常内嵌于coordinator节点中，也可以单独部署，用于节点心跳。在下文中，默认discovery和coordinator共享一台机器。

3.3.3 ClickHouse

ClickHouse是一个面向联机分析处理(OLAP)的开源的面向列式存储的DBMS，简称CK, 与Hadoop, Spark相比，ClickHouse很轻量级,由俄罗斯第一大搜索引擎Yandex于2016年6月发布, 开发语言为C++

ClickHouse的特点:

开源的列存储数据库管理系统，支持线性扩展，简单方便，高可靠性，

容错跑分快：比Vertica快5倍，比Hive快279倍，比MySQL快800倍,其可处理的数据级别已达到10亿级别

功能多：支持数据统计分析各种场景，支持类SQL查询，异地复制部署

 

ClickHouse最近也是比较火，很多公司用它来进行即时查询任务，如字节、携程等。

3.4 图计算

Giraph和GraphLab都是用来进行图数据处理的计算引擎，其中Giraph属于同步计算模型，GraphLab为异步计算模型。图计算主要将客观世界中事物间关系完整地刻画、计算和分析的一门技术。它可以用于银行对于不良贷款的预测，也可以用于网站大数据分析推荐等功能。图算法有很多种，每一种算法都有其实际的应用场景。常见的图算法有PageRank、最短路径、社群发现等算法。

 

4. 组件层（交互组件）

上面介绍的主要是可以独立进行计算的计算引擎，但是这些计算引擎对于一般水平的开发人员来讲还是比较复杂的，例如你可能只是想进行一些简单的SQL数据探查，就需要编写一整套的MapReduce代码，这就造成了这些计算引擎的使用门槛过高。
为了提高对数据分析人员的友好，一系列的上层组件也应运而生。例如Hive、Pig等，提供了将SQL或者脚本转换成MapReduce任务的功能，这样数据分析人员只需要关注业务SQL或者脚本的开发即可，而不用关系MapReduce的任务该如何写。

4.1 批处理

4.1.1 Hive

HIVE是由facebook开源，最初用于解决海量结构化的日志数据统计问题。Hive更多的是与数据仓库的概念结合在一起。各个公司的数据仓库可能都离不开Hive。主要是因为Hive定义了一种类似SQL的查询语言(HQL),将SQL转化为MapReduce任务在Hadoop上执行。

HQL用于运行存储在Hadoop上的查询语句，Hive让不熟悉MapReduce开发人员也能编写数据查询语句，然后这些语句被翻译为Hadoop上面的MapReduce任务。

 

4.1.2 Pig

由yahoo!开源，设计动机是提供一种基于MapReduce的ad-hoc(计算在query时发生)数据分析工具。其实Pig跟Hive类似，它是定义了一种数据流脚本语言(Pig Latin)，其编译器将Pig Latin翻译成MapReduce程序序列将脚本转换为MapReduce任务在Hadoop上执行。通常用于进行离线分析。

 

4.1.3 Tez

MapReduce(下面简称MR)的缺点很明显，性能比较弱，效率不高。 原因在于它只能把Job抽象成为Map, Reduce，但是复杂的任务可以有几十个MR任务，中间可能会有很多重复的任务。 而且MR并不支持对于整个pipeline的任务进行优化。比如说若干个MR任务的组合可以合并成一个来计算，这样就减少了数据的读写，传输的开销。归根结底，是因为Hadoop不支持任务的DAG(有向无环图)描述。

Tez提供了一个可重用，灵活的框架来支持数据流模型。他的主要特点是：

1. 用户可以将自己的Job描述成一个DAG，这样可以进行更灵活的优化和配置。
2. 提供了灵活的Runtime API。Tez支持在Runtime对DAG的配置进行修改，比如对于partitition的调整。
3. 提供了data-locality感知， 资源重用和错误容忍。

 

 

 

上面这个图就很好诠释了Tez的功能。它其实与Spark有点类似，说白了就是减少不同作业之间的数据读写磁盘的次数。

举个栗子看优势，如图，Tez可以将多个有依赖的作业转换为一个作业（这样只需写一次HDFS，且中间节点较少），从而大大提升DAG作业的性能。Tez已被Hortonworks用于Hive引擎的优化，经测试，性能提升约100倍。

SparkSQL

由于SQL的易学易用的特点，为了扩大Spark的应用范围，增加了对SQL和Hive的支持。
SparkSQL的处理流程如下图所示。
SparkSQL在1.x版本是通过SQLContext、HiveContext来获取编程入口，在2.X版本通过SparkSession获取编程入口，通过SparkSession.sql()简单易用。

 

连接方式：Spark连接hive表的两种策略，JDBC的方式和Spark直连的方式

 

4.1.4 Kudu

在 KUDU 之前，大数据主要以两种方式存储：

• 静态数据：以 HDFS 引擎作为存储引擎，适用于高吞吐量的离线大数据分析场景。这类存储的局限性是数据无法进行随机的读写。
• 动态数据：以 HBase、Cassandra 作为存储引擎，适用于大数据随机读写场景。这类存储的局限性是批量读取吞吐量远不如 HDFS，不适用于批量数据分析的场景。

从上面分析可知，这两种数据在存储方式上完全不同，进而导致使用场景完全不同，但在真实的场景中，边界可能没有那么清晰，面对既需要随机读写，又需要批量分析的大数据场景。

通常的做法是，数据实时写入 HBase，实时的数据更新也在 HBase 完成，为了应对 OLAP 需求，定时（通常是 T+1 或者 T+H）将 HBase 数据写成静态的文件（如：Parquet）导入到 OLAP 引擎（如：HDFS）。这一架构能满足既需要随机读写，又可以支持 OLAP 分析的场景，但他有如下缺点：

• 架构复杂。从架构上看，数据在 HBase、消息队列、HDFS 间流转，涉及环节太多，运维成本很高。并且每个环节需要保证高可用，都需要维护多个副本，存储空间也有一定的浪费。最后数据在多个系统上，对数据安全策略、监控等都提出了挑战。
• 时效性低。数据从 HBase 导出成静态文件是周期性的，一般这个周期是一天（或一小时），在时效性上不是很高。
• 难以应对后续的更新。真实场景中，总会有数据是「延迟」到达的。如果这些数据之前已经从 HBase 导出到 HDFS，新到的变更数据就难以处理了，一个方案是把原有数据应用上新的变更后重写一遍，但这代价又很高。

为了解决上述架构的这些问题，KUDU 应运而生。KUDU 的定位是 「Fast Analytics on Fast Data」，是一个既支持随机读写、又支持 OLAP 分析的大数据存储引擎。

 

从上图可以看出，KUDU 是一个「折中」的产品，在 HDFS 和 HBase 这两个偏科生中平衡了随机读写和批量分析的性能。从 KUDU 的诞生可以说明一个观点：底层的技术发展很多时候都是上层的业务推动的，脱离业务的技术很可能是「空中楼阁」。

4.2 流处理

SparkStreaming、Structured Streaming以及Flink和Storm已经在上面介绍过。

4.3 即席查询

4.3.1 ElasticSearch

Elasticsearch是一个开源的分布式、RESTful 风格的搜索和数据分析引擎，它的底层是开源库Apache Lucene。Elasticsearch主要是为了解决Lucene使用时的繁复性。它使用 Java 编写，内部采用 Lucene 做索引与搜索，但是它的目标是使全文检索变得更简单，简单来说，就是对Lucene 做了一层封装，它提供了一套简单一致的 RESTful API 来帮助我们实现存储和检索。 当然，Elasticsearch 不仅仅是 Lucene，并且也不仅仅只是一个全文搜索引擎。 它可以包含下面的一些内容：

• 一个分布式的实时文档存储，每个字段可以被索引与搜索；
• 一个分布式实时分析搜索引擎；
• 能胜任上百个服务节点的扩展，并支持 PB 级别的结构化或者非结构化数据。

由于Elasticsearch的功能强大和使用简单，维基百科、卫报、Stack Overflow、GitHub等都纷纷采用它来做搜索。现在，Elasticsearch已成为全文搜索领域的主流软件之一。

 

4.4 人工智能

4.4.1 SparkMLlib

MLlib支持包括分类、回归、聚类和协同过滤在内的四种常见机器学习算法，MLlib基于RDD，与SparkSQL、Spark Streaming、GraphX无缝集成，共同组成了Spark大数据生态。

4.4.2 Mahout

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

4.4.3 TensorFlow

TensorFlow 是一个用于数值计算的Python 库， 可以描述一幅数据计算的数据流图（data flow graph）。TensorFlow 最初由Google大脑小组（隶属于Google机器智能研究机构）的研究员和工程师们开发出来，用于机器学习和深度神经网络方面的研究，但这个系统的通用性使其也可广泛用于其他计算领域。

会话 (Session)：TensorFlow描述的计算流程图需要在Session中启动；Session将其与C++后端连接，为其分配计算设备（CPU 或 GPU）和提供计算方法，反复训练模型。

节点（Nodes）：在图中表示数学操作，例如，数据输入（feed in）的起点或输出（push out）的终点；

线（edges）：线输送节点间相互联系和不断变化的多维数据数组(即张量, tensor）。

5.工具层

除了以上的核心组件，还有一些必要的工具类组件，例如日志采集工具，不同数据源之间的数据传输工具等，这些是我们进行数据输入或输出过程中必不可少的。

5.1 Sqoop

传统的应用程序管理系统，即应用程序与使用RDBMS的关系数据库的交互，是产生大数据的来源之一。由RDBMS生成的这种大数据存储在关系数据库结构中的关系数据库服务器中。

Sqoop是一个用于在Hadoop和关系数据库服务器之间传输数据的工具。它用于从关系数据库（如MySQL，Oracle）导入数据到Hadoop HDFS，并从Hadoop文件系统导出到关系数据库。它由Apache软件基金会提供。

下图描述了Sqoop的工作流程。

 

Sqoop导入:导入工具从RDBMS向HDFS导入单独的表。表中的每一行都被视为HDFS中的记录。所有记录都以文本文件的形式存储在文本文件中或作为Avro和Sequence文件中的二进制数据存储。

Sqoop导出:导出工具将一组文件从HDFS导出回RDBMS。给Sqoop输入的文件包含记录，这些记录在表中被称为行。这些被读取并解析成一组记录并用用户指定的分隔符分隔。

5.2 Flume

Flume是一个分布式的、高可靠的、高可用的将大批量的不同数据源的日志数据收集、聚合、移动到数据中心（HDFS）进行存储的系统。即是日志采集和汇总的工具

flume的优势：

1. 可以高速采集数据，采集的数据能够以想要的文件格式及压缩方式存储在hdfs上
2. 事务功能保证了数据在采集的过程中数据不丢失
3. 部分Source保证了Flume挂了以后重启依旧能够继续在上一次采集点采集数据，真正做到数据零丢失

flume有3大组件

1. source(源端数据采集)：Flume提供了各种各样的Source、同时还提供了自定义的Source
2. Channel(临时存储聚合数据)：主要用的是memory channel和File channel（生产最常用），生产中channel的数据一定是要监控的，防止sink挂了，撑爆channel
3. Sink（移动数据到目标端）：如HDFS、KAFKA、DB以及自定义的sink

5.3 Kafka

 

Kafka是Apache旗下的一款分布式流媒体平台，Kafka是一种高吞吐量、持久性、分布式的发布订阅的消息队列系统。 它最初由LinkedIn(领英)公司发布，使用Scala语言编写，与2010年12月份开源，成为Apache的顶级子项目。 它主要用于处理消费者规模网站中的所有动作流数据。动作指(网页浏览、搜索和其它用户行动所产生的数据)。

6. 协调调度层

一个大数据平台，它的组件是数量多、类型繁的，那如何协调不同计算引擎之间对资源的申请、使用和释放，就需要统一的资源管理器；同时，大数据平台的任务之间并不是独立存在的，很多任务存在上下游的关系，例如一个任务的输入可能依赖于前一个或者多个任务的输出，这就需要我们协调好各个任务之间的依赖关系，确定好任务启动的时间和顺序；再者，在分布式的架构中，不同节点之间的数据协调、节点间的角色划分、HA等也都需要一些协调器来协助。

6.1 Zookeeper

zookeeper功能非常强大，可以实现诸如分布式应用配置管理、统一命名服务、状态同步服务、集群管理等功能，我们这里拿比较简单的分布式应用配置管理为例来说明。

假设我们的程序是分布式部署在多台机器上，如果我们要改变程序的配置文件，需要逐台机器去修改，非常麻烦，现在把这些配置全部放到zookeeper上去，保存在 zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 zookeeper 的通知，然后从 zookeeper 获取新的配置信息应用到系统中。

 

6.2 Oozie

设想一下，当你的系统引入了spark或者hadoop以后，基于Spark和Hadoop已经做了一些任务，比如一连串的Map Reduce任务，但是他们之间彼此右前后依赖的顺序，因此你必须要等一个任务执行成功后，再手动执行第二个任务。 这个时候Oozie就可以把多个任务组成一个工作流，自动完成任务的调用。

总结来说

• Oozie是管理Hadoop作业的工作流调度系统
• Oozie的工作流是一系列的操作图
• Oozie协调作业是通过时间（频率）以及有效数据触发当前的Oozie工作流程
• Oozie是针对Hadoop开发的开源工作流引擎，专门针对大规模复杂工作流程和数据管道设计
• Oozie围绕两个核心：工作流和协调器，前者定义任务的拓扑和执行逻辑，后者负责工作流的依赖和触发。

 

6.3 Yarn

 

YARN 是一个资源管理、任务调度的框架，主要包含三大模块：ResourceManager（RM）、 NodeManager（NM）、ApplicationMaster（AM）。

ResourceManager 负责所有资源的监控、分配和管理；

ApplicationMaster 负责每一个具体应用程序的调度和协调；

NodeManager 负责每一个节点的维护。 对于所有的 applications，RM 拥有绝对的控制权和对资源的分配权。而每个 AM 则会和 RM 协商资源，同时和 NodeManager 通信来执行和监控 task。

 

总结

讲了这么多的大数据组件，其实，大数据计算生态中的组件远不止这些，这只是我们在各个领域常用的组件，随着数据多样性和场景多样性的增加，大数据生态中的组件也会继续增加，但是原理其实都是大同小异。我们需要不断的去学习。

本文主要从总体上来介绍了大数据生态中的各个组件及其功能，后面我会将每个组件用一整篇文章来进行详细介绍，也欢迎大家关注我的微信公众号【DLab数据实验室】来一起学习大数据的知识～