hadoop hive集群_技术干货之Hadoop 族谱

  Hadoop族谱(部分)

 大数据技术主要是要解决大规模数据的计算处理问题，但是我们要想对数据进行计算，首先要解决的其实是大规模数据的存储问题。 这里有一个直观又现实的问题想问你：如果一个文件的大小超过了一张磁盘的大小，你该如何存储？

我的答案是，单机时代，主要的解决方案是 RAID；分布式时代，主要解决方案是分布式 文件系统。

(为了便于理解和文章篇幅关系，这里只做最简单的介绍，具体会讲一下什么场景适合使用什么样的组件，如有兴趣可以自己深入研究)

HADOOP基础架构

HDFS也许不是最好的大数据存储技术，但依然最重要的大数据存储技术。

HDFS是在一个大规模分布式服务器集群上，对数据分片后进行并行读写及冗余存储。因为 HDFS 可以部署在一个比较大的服务器集群上，集群中所有服务器的磁盘都可供 HDFS 使用，所以整个 HDFS 的存储空间可以达到 PB 级容量。 这里我们迎来了了HADOOP家族的第一个成员HDFS

(图：HDFS架构图)

所以简单的来讲，你只要把HDFS理解成一个底层文件存储系统就可以了，其他类似Hive，

Hbase，KUDU之类的数据其实都是以文件形式存储在HDFS上面的。

为什么说MapReduce既是编程模型又是计算框架？

数据计算的核心思路是移动计算比移动数据更划算。既然计算方法跟传统计算方法不一 样，移动计算而不是移动数据，那么用传统的编程模型进行大数据计算就会遇到很多困难，因此 Hadoop 大数据计算使用了一种叫作 MapReduce的编程模型。

为什么说 MapReduce 是一种非常简单又非常强大的编程模型？简单在于其编程模型只包含 Map 和 Reduce 两个过程，map 的主要输入是一对 值，经过 map 计算后输出一对 值；然后将相同 Key 合并，形成；再将这个 输入 reduce，经过计算输出零个或 多个 对。同时，MapReduce又是非常强大的，不管是关系代数运算(SQL 计算)，还是矩阵运算(图计算)，大数据领域几乎所有的计算需求都可以通过 MapReduce 编程来实现。

 (图：MapReduce实现原理)

好了第二位成员MapReduce出现了，我们可以理解他是建立在HDFS上的一种批量计算方式，以及一种计算的框架。

为什么我们管Yarn叫作资源调度框架？

我们知道HADOOP上会运行很多计算任务，比如说SPARK,STORM，那我们怎么统一集中的管理资源呢？

 (图：yarn资源调度框架)

从图上看，Yarn 包括两个部分：一个是资源管理器(ResourceManager)，一个是节点 管理器(Node Manager)。这也是 Yarn的两种主要进程：ResourceManager进程负 责整个集群的资源调度管理，通常部署在独立的服务器上；NodeManager进程负责具体 服务器上的资源和任务管理，在集群的每一台计算服务器上都会启动，基本上跟 HDFS 的 DataNode进程一起出现。具体说来，资源管理器又包括两个主要组件：调度器和应用程 序管理器。所以第三位成员Yarn他的职责是用来管理调度资源的。

ZooKeeper是如何保证数据一致性的？

在分布式系统里的多台服务器要对数据状态达成一致，其实是一件很有难度和挑战的事情，因为服务器集群环境的软硬件故障随时会发生，多台服务器对一个数据的记录保持一 致，需要一些技巧和设计。

两个应用程序都需要对一个文件路径进行写操作，但是如果两个应用程序对于哪台服务器是主服务器的判断不同，就会分别连接到两个不同的 NameNode 上，并都得到了对同一 个文件路径的写操作权限，这样就会引起文件数据冲突，同一个文件指向了两份不同的数据。这种不同主服务器做出不同的响应，在分布式系统中被称作“脑裂”。光看这个词你也可以看出问题的严重性，这时候集群处于混乱状态，根本无法使用。那我们引入一个专 门进行判断的服务器当“裁判”，让“裁判”决定哪个服务器是主服务器不就完事了吗？

那么问题又来了，这几台做出判断决策的服务器又如何防止“脑裂”，自己不会出现混乱 状态呢？有时候真的很无奈，分布式系统设计就像是一个追着自己尾巴咬的喵喵，兜兜转转回到开头。

这就是用过Paxos 算法与 ZooKeeper架构来解决这个问题的

 (图：zookeeper运作方式)

这次的新成员名叫Zookeeper，我们只需要记住它是来决定谁是应该来当领导谁来当副领 导的，他们是一个基数人数的小组，通过投票决定。

基础架构小结

现在先来看下我们介绍了哪些成员：

HDFS-------------文件存储系统

MapReduce------计算模型和计算框架

Yarn----------------资源调度

Zookeeper---------协调服务

这四位成员组成了HADOOP生态圈最基本的架构，缺一不可，正是他们在HADOOP底层任劳任怨的支撑才有Spark，Storm，Kylin，Kudu等等明星产品的出现。让我们为他们四位鼓掌~

   将来和我们打交道最多的朋友们

之前我们说的四位成员虽然很重要，但是如果你不是资深的HADOOP开发工程师，可能你根本不会和他们打上交道，接下来我们要说的几位成员将会是我们日后遇到问题最多的几位朋友。

Hive是如何让MapReduce实现SQL操作的？

前面我们讲过，MapReduce 的出现大大简化了大数据编程的难度，使得大数据计算不再是高不可攀的技术圣殿，普通工程师也能使用 MapReduce 开发大数据程序。但是对于经 常需要进行大数据计算的人，比如从事研究商业智能(BI)的数据分析师来说，他们通常 使用 SQL 进行大数据分析和统计，MapReduce 编程还是有一定的门槛。而且如果每次统 计和分析都开发相应的MapReduce 程序，成本也确实太高了。那么有没有更简单的办 法，可以直接将 SQL 运行在大数据平台上呢？

对于常见的一条 SQL 分析语句，MapReduce 如何编程实现？

SELECT pageid, age, count(1) FROM pv_usersGROUP BY pageid,age;

(图：Map Reduce实现过程)

在数据仓库中，SQL 是最常用的分析工具，既然一条 SQL 可以通过MapReduce 程序实 现，那么有没有工具能够自动将 SQL 生成 MapReduce 代码呢？这样数据分析师只要输 入 SQL，就可以自动生成MapReduce 可执行的代码，然后提交 Hadoop执行，也就完 美解决了我们最开始提出的问题。问题的答案，也就是这个神奇的工具就是 Hadoop大数 据仓库 Hive。

Hive能够直接处理我们输入的 SQL 语句(Hive 的 SQL 语法和数据库标准 SQL 略有不 同)，调用 MapReduce 计算框架完成数据分析操作。下面是它的架构图，我们结合架构图来看看 Hive 是如何实现将SQL 生成 MapReduce 可执行代码的。

 (图：Hive 连接各个部件)

我们通过 Hive 的 Client(Hive 的命令行工具，JDBC 等)向 Hive 提交 SQL命令。如果 是创建数据表的 DDL(数据定义语言)，Hive 就会通过执行引擎 Driver 将数据表的信息 记录在 Metastore元数据组件中，这个组件通常用一个关系数据库实现，记录表名、字段 名、字段类型、关联 HDFS 文件路径等这些数据库的 Meta 信息(元信息)。如果我们提 交的是查询分析数据的 DQL(数据查询语句)，Driver 就会将该语句提交给自己的编译器 Compiler 进行语法分析、语法解析、语法优化等一系列操作，最后生成一个MapReduce 执行计划。然后根据执行计划生成一个 MapReduce 的作业，提交给HadoopMapReduce 计算框架处理。

我们对HIVE的误解： 

   误解1.   Hive是面向数仓的，不支持Update和delete

   结论：Hive是支持Update和delete的，只有古老版本的Hive才不支持

如果一个表要实现update和delete功能，该表就必须支持ACID，而支持ACID，就必须满足以下条件：

1-表的存储格式必须是ORC(STORED ASORC)；

2-表必须进行分桶(CLUSTERED BY(col_name, col_name, ...) INTO num_buckets BUCKETS)；

3-Tableproperty中参数transactional必须设定为True(tblproperties('transactional'='true'))；

举个例子：

(图：建表)

增删改

insert into t1 values(1,'aaa');

nsert into t1 values(2,'bbb');

update t1 set name='ccc' where id=1;

delete from t1 where id=2;

(图：增删改操作)

误解2. Hive 不支持子查询 Hive支持子查询，跟在FROM后面的子查询是肯定可以的，不过WHERE条件的子查询就要

    结论：看Hive的版本了，目前我们公司用的版本是都可以的

 (图：Hive查询)

使用HIVE需要注意的几个地方

1.External关键字可以让用户创建一个外部表，在建表的同时指定一个指向实际数据的路径(LOCATION)，Hive 创建内部表时，会将数据移动到数据仓库指向的路径；若创建外 部表，仅记录数据所在的路径，不对数据的位置做任何改变。在删除表的时候，内部表的元数据和数 据会被一起删除，而外部表只删除元数据，不删除数据。

2.LIKE允许用户复制现有的表结构，但是不复制数据。

3.用户在建表的时候可以自定义 SerDe 或者使用自带的SerDe。如果没有指定 ROWFORMAT 或者 ROW FORMATDELIMITED，将会使用自带的SerDe。在建表的时候，用 户还需要为表指定列，用户在指定表的列的同时也会指定自定义的SerDe，Hive 通过 SerDe 确定表的具体的列的数据。

4.如果文件数据是纯文本，可以使用 STORED ASTEXTFILE。如果数据需要压缩，使用 STORED AS SEQUENCE。

5.有分区的表可以在创建的时候使用 PARTITIONEDBY语句。一个表可以拥有一个或者多 个分区，每一个分区单独存在一个目录下。而且，表和分区都可以对某个列进行CLUSTERED BY 操作，将若干个列放入一个桶(bucket)中。也可以利用SORT BY对数 据进行排序。这样可以为特定应用提高性能。

6.表名和列名不区分大小写，SerDe 和属性名区分大小写。表和列的注释是字符串

注：SerDe是Serialize/Deserilize的简称，目的是用于序列化和反序列化STORED AS TEXTFILE：默认格式，数据不做压缩，磁盘开销大，数据解析开销大。可结 合Gzip、Bzip2使用(系统自动检查，执行查询时自动解压)，但使用这种方式，hive不会对 数据进行切分， 从而无法对数据进行并行操作STORED AS SEQUENCE：HadoopAPI提供的一种二进制文件支持，其具有使用方便、 可分割、可压缩的特点。SequenceFile支持三种压缩选择：NONE，RECORD，BLOCK。Record压缩率低，一般建议使用BLOCK压缩。

HIVE总结：

总的来说HIVE既是数据存储引擎，又是数据查询引擎既然我们之前说了HIVE支持增删改，那他是不是可以直接拿来作为我们的生产库使用呢？ 答案是否定的，原因就是HIVE是基于MAPREDUCE设计的，对数据的操作无论多还是少， 都要走MapReduce，所以带来的结果就是实时性能很差，虽然HIVE让我们可以使用SQL 来操作HDFS数据，但是无法满足实时的动态的交互应用。

HIVE非常适合跑批量任务以及对历史数据批量查询，比如每月月底统计这个月的交易额，统计前几年的某个商品的销售情况。

既然说到了实时交互式查询，那HADOOP是否可以做到呢？这就引来了我们第二位朋友Hbase。

BigTable的开源实现：HBase

我们知道，Google 发表 GFS、MapReduce、BigTable三篇论文，号称“三驾马车”， 开启了大数据的时代。那和这“三驾马车”对应的有哪些开源产品呢？ GFS 对应的 Hadoop 分布式文件系统 HDFS，以及 MapReduce 对应的Hadoop分布式计算框架 MapReduce，最后我们就来领略一下BigTable对应的 NoSQL 系统 HBase，看看它是如 何大规模处理海量数据的。

NoSQL，主要指非关系的、分布式的、支持海量数据存储的数据库设计模式。也有许多专家将 NoSQL 解读为 Not Only SQL，表示 NoSQL只是关系数据库的补充，而不是替代方案。其中，HBase 是这一类 NoSQL 系统的杰出代表。

HBase 可伸缩架构：

我们先来看看 HBase 的架构设计。HBase 为可伸缩海量数据储存而设计，实现面向在线 业务的实时数据访问延迟。HBase 的伸缩性主要依赖其可分裂的 HRegion 及可伸缩的分 布式文件系统 HDFS实现。

 (图：HBase架构设计)

HBase 的核心设计目标是解决海量数据的分布式存储，和Memcached 这类分布式缓存的 路由算法不同，HBase 的做法是按 Key 的区域进行分片，这个分片也就是 HRegion。应 用程序通过HMaster 查找分片，得到 HRegion 所在的服务器 HRegionServer，然后和 该服务器通信，就得到了需要访问的数据。

HBase 的高性能存储:

传统的机械式磁盘的访问特性是连续读写很快，随机读写很慢。这是因为机械磁盘靠电机驱动访问磁盘上的数据，电机要将磁头落到数据所在的磁道上，这个过程需要较长的寻址时间。如果数据不连续存储，磁头就要不停的移动，浪费了大量的时间。为了提高数据写 入速度，HBase 使用了一种叫作LSM 树的数据结构进行数据存储。LSM树的全名是 LogStructed Merge Tree，翻译过来就是Log 结构合并树。数据写入的时候以 Log 方式连续 写入，然后异步对磁盘上的多个 LSM 树进行合并。

(图：LSM储存方式)

LSM 树可以看作是一个 N 阶合并树。数据写操作(包括插入、修改、删除)都在内存中进行，并且都会创建一个新记录(修改会记录新的数据值，而删除会记录一个删除标志)。 这些数据在内存中仍然还是一棵排序树，当数据量超过设定的内存阈值后，会将这棵排序树和磁盘上最新的排序树合并。当这棵排序树的数据量也超过设定阈值后，会和磁盘上下 一级的排序树合并。合并过程中，会用最新更新的数据覆盖旧的数据(或者记录为不同版本)。

在需要进行读操作时，总是从内存中的排序树开始搜索，如果没有找到，就从磁盘上的排 序树顺序查找。在 LSM 树上进行一次数据更新不需要磁盘访问，在内存即可完成。当数据 访问以写操作为主，而读操作则集中在最近写入的数据上时，使用 LSM 树可以极大程度地 减少磁盘的访问次数，加快访问速度。

Hbase给我们带来的思考：

Hbase是列族结构的，在使用的时候有那些缺点呢？

1:列族不好查询，没有传统sql那样按照不同字段方便，只能根据rowkey查询，范围查询 scan性能低。

2:查询也没有mysql一样的走索引优化，因为列不固定

3:列族因为不固定，所以很难做一些业务约束，比如uk等等。

4:做不了事务控制

那根据这些问题是否有解决方案呢？

SQL化----phoneix

通过JDBCAPI实现了大部分的java.sql接口，包括元数据APIDDL支持：

通过CREATE TABLE、DROP TABLE及ALTERTABLE来添加/删除DML支持：

用于逐行插入的UPSERT VALUES,用于相同或不同表之间大量数据传输的UPSERTSELECT,用于删除行的DELETE事务支持：

通过客户端的批处理实现的有限的事务支持(beta测试中)二级索引支持：

遵循ANSISQL标准

    我们可以看到phonix解决的hbase的很多不方便的问题，那它有哪些问题呢？

Hbase版本必须符合phoneix，就是说如果phoneix的版本是1.5,那我Hbase页必须是1.5，如果我所用的Hbase版本没有对应的phoneix那我就必须更换我的Hbase版本。

Hbase适用的场景：适合需要实时交互的应用，不适用于做批次分析

对比Mongodb：同样是nosql数据库，同样是支持分布式，Mongodb原生支持事务，支持二级索引，scan表性能要高于Hbase，，Mongodb同样可以和HADOOP结合，有原生API供Spark直接调取Mongodb数据跑批量。

Hbase有点不上不下的感觉，如果为了实时交互系统，Mongodb性能更优秀，如果是跑批HIVE和SPARK更优秀，并且phoneix也有很多局限性。

Impala另一个SQL化工具

在实践中，工程师其实并不需要经常编写 MapReduce 程序，因为网站最主要的大数据处 理就是 SQL 分析，也因此 Hive 在大数据应用中的作用非常重要。

后面随着 Hive 的普及，我们对于在 Hadoop 上执行 SQL 的需求越加强烈，对大数据 SQL 的应用场景也多样化起来，于是又开发了各种大数据 SQL 引擎。

Cloudera 开发了 Impala，这是一种运行在 HDFS 上的 MPP 架构的 SQL引擎。和 MapReduce 启动 Map 和 Reduce 两种执行进程，将计算过程分成两个阶段进行计算不同，Impala 在所有 DataNode 服务器上部署相同的 Impalad 进程，多个 Impalad进程 相互协作，共同完成 SQL 计算。在一些统计场景中，Impala 可以做到毫秒级的计算速度。

 

(图：Impala调用方式)

它提供SQL语义，能查询存储在Hadoop的HDFS和HBase中的PB级大数据。已有的Hive系统虽然也提供了SQL语义，但由于Hive底层执行使用的是MapReduce引擎，仍然是一个批 处理过程，难以满足查询的交互性。相比之下，Impala的最大特点也是最大卖点就是它的快速。

Impala是基于Hive的大数据实时分析查询引擎，直接使用Hive的元数据库Metadata,意味着impala元数据都存储在Hive的metastore中。并且impala兼容Hive的sql解析，实现了Hive的SQL语义的子集。

Impala与Hive都是构建在Hadoop之上的数据查询工具各有不同的侧重适应面，但从客户端使用来看Impala与Hive有很多的共同之处，如数据表元数 据、ODBC/JDBC驱动、SQL 语法、灵活的文件格式、存储资源池等。Impala与Hive在Hadoop中的关系如下图所示。 Hive适合于长时间的批处理查询分析，而Impala适合于实时交互式SQL查询，Impala给数 据分析人员提供了快速实验、验证想法的大数 据分析工具。可以先使用hive进行数据转换 处理，之后使用Impala在Hive处理后的结果数据集上进行快速的数据分析。

(图：ImpalaSQL查询)

Impala的优点：

• 支持SQL查询，快速查询大数据。

• 可以对已有数据进行查询，减少数据的加载，转换。

• 多种存储格式可以选择(Parquet, Text, Avro,RCFile, SequeenceFile)。

• 可以与Hive配合使用。

• 可以配合Hbase使用。

• Impala+kudu最佳拍档。

Impala的缺点：

• 不支持用户定义函数UDF(新版已支持)。

• 不支持text域的全文搜索。

• 不支持Transforms。

• 不支持查询期的容错。

• 对内存要求高。

• 原生Impala建的表不支持修改，必须配合Hive或Kudu。

• Impala不适合进行长时间查询。

说到了Imapa就不得不说下Kudu了

Fast Analytics on FastData-----KUDU

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

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

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

从上面分析可知，这两种数据在存储方式上完全不同，进而导致使用场景完全不同，但在真实的场景中，边界可能没有那么清晰，面对既需要随机读写，又需要批量分析的大数据 场景，该如何选择呢？这个场景中，单种存储引擎无法满足业务需求，我们需要通过多种大数据工具组合来满足这一需求，一个常见的方案是：

 

(图：Impala on HDFS)

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

架构复杂。从架构上看，数据在HBase、消息队列、HDFS 间流转，涉及环节太多， 运维成本很高。并且每个环节需要保证高可用，都需要维护多个副本，存储空间也有一定的浪费。最后数据在多个系统上，对数据安全策略、监控等都提出了挑战。 

时效性低。数据从 HBase导出成静态文件是周期性的，一般这个周期是一天(或一小 时)，在时效性上不是很高。

难以应对后续的更新。真实场景中，总会有数据是「延迟」到达的。如果这些数据之 前已经从 HBase 导出到 HDFS，新到的变更数据就难以处理了，一个方案是把原有数 据应用上新的变更后重写一遍，但这代价又很高。

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

(图：Hadoop Kudu HBase 位置图)

KUDU定位

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

数据模型KUDU的数据模型与传统的关系型数据库类似，一个 KUDU集群由多个表组成，每个表由多个字段组成，一个表必须指定一个由若干个(>=1)字段组成的主键，如下图：

 (图：KUDU数据模型)

KUDU表中的每个字段是强类型的，而不是 HBase 那样所有字段都认为是bytes。这样做的好处是可以对不同类型数据进行不同的编码，节省空间。同时，因为 KUDU的使用场景 是 OLAP分析，有一个数据类型对下游的分析工具也更加友好。

列式存储毫无疑问，Kudu是一个纯粹的列式存储引擎，相比Hbase只是按列存放数据，Kudu的列式存储更接近于Parquet，在支持更高效Scan操作的同时，还占用更小的存储空间。列式存储有如此优势，主要因为两点：1.通常意义下的OLAP查询只访问部分列数据，列存储引擎在这种情况下支持按需访问，而行存储引擎则必须检索一行中的所有数据。2.数据按列放一起一般意义来讲会拥有更高的压缩比，这是因为列相同的数据往往拥有更高的相似性。

TableKudu中所有的数据均存储在Table之中，每张表有其对应的表结构和主键，数据按主键有序存储。因为Kudu设计为支持超大规模数据量，Table之中的数据会被分割成为片段，称之为Tablet。

Tablet一个Tablet把相邻的数据放在一起，跟其他分布式存储服务类似，一个Tablet会有多个副本放置在不同的服务器上面，在同一时刻，仅有一个Tablet作为leader存在，每个副本均可单独提供读操作，写操作则需要一致性同步写入。

数据存储引擎KUDU+数据查询引擎IMPALA的完美结合 Impala 配合Kudu实时查询性能高于配合Hive。

Impala原生建表不支持update和delete，但是配合kudu存储引擎，完美解决问题。Impala配合Kudu进行实时告诉查询分析(大数据量情况下Impala读取Kudu数据性能远远高于Impala读取Hbase数据)

(图：KUDU数据流)

我们并没有觉得MapReduce速度慢，直到Spark出现。

事实上，在 Spark 出现之前，我们并没有对MapReduce 的执行速度不满，我们觉得大数 据嘛、分布式计算嘛，这样的速度也还可以啦。至于编程复杂度也是一样，一方面 Hive、Mahout 这些工具将常用的MapReduce 编程封装起来了；另一方面，MapReduce已经将分布式编程极大地简化了，当时人们并没有太多不满。

真实的情况是，人们在 Spark 出现之后，才开始对MapReduce 不满。原来大数据计算速度可以快这么多，编程也可以更简单。而且 Spark 支持 Yarn 和HDFS，公司迁移到 Spark 上的成本很小，于是很快，越来越多的公司用 Spark 代替 MapReduce。也就是 说，因为有了 Spark，才对 MapReduce 不满；

Spark 和 MapReduce 相比，有更快的执行速度。下图是Spark 和 MapReduce 进行逻 辑回归机器学习的性能比较，Spark 比 MapReduce 快 100 多倍。(官方出品)

(图：Spark和 MapReduce 性能图)

除了速度更快，Spark 和 MapReduce相比，还有更简单易用的编程模型。SCALA RDD 是 Spark 的核心概念，是弹性数据集(ResilientDistributedDatasets)的缩写。RDD 既是 Spark 面向开发者的编程模型，又是 Spark自身架构的核心元素。我们先来看 看作为 Spark 编程模型的 RDD。我们知道，大数据计算就是在大规模的数据集上进行一系列的数据计算处理。MapReduce 针对输入数据，将计算过程分为两个阶段，一个 Map阶 段，一个 Reduce 阶段，可以理解成是面向过程的大数据计算。我们在用 MapReduce 编程的时候，思考的是，如何将计算逻辑用 Map 和 Reduce 两个阶段实现，map 和

reduce 函数的输入和输出是什么，这也是我们在学习 MapReduce 编程的时候一再强调 的。而 Spark 则直接针对数据进行编程，将大规模数据集合抽象成一个 RDD对象，然后 在这个 RDD 上进行各种计算处理，得到一个新的RDD，继续计算处理，直到得到最后的 结果数据。所以 Spark 可以理解成是面向对象的大数据计算。我们在进行 Spark 编程的时 候，思考的是一个 RDD 对象需要经过什么样的操作，转换成另一个 RDD对象，思考的重 心和落脚点都在 RDD上。

(中间略过一些内容，东西太多了)

Spark 应用程序代码中的 RDD 和 Spark 执行过程中生成的物理RDD不是一一对应的， RDD 在 Spark里面是一个非常灵活的概念，同时又非常重要，需要认真理解。

当然 Spark 也有自己的生态体系，以 Spark 为基础，有支持SQL 语句的 Spark SQL，有 支持流计算的 Spark Streaming，有支持机器学习的 MLlib，还有支持图计算的 GraphX。利用这些产品，Spark技术栈支撑起大数据分析、大数据机器学习等各种大数据应用场景。

(图： Apache生态体系)

Spark是目前最流行的批量工具，支持SQL化，支持流计算，可以直接去读HDFS,HIVE,IMPALA,Mongodb等数据，官方给出的性能是MapReduce(也就是Hive的 性能)的10倍，当然这个有点太看环境了，实际中估计是2，3到倍以上的速度公司环境，kylin运行cube的job(跑批)，使用Mapreduce耗时是Spark2倍。

 (图： SparkMapReduce耗时比较)

因为数据量只有10000条可能不是很明显，但是随着数据量的增大，耗时一定是成指数及变化的。

对于新朋友们的总结以及结合集成系统的一些看法

• Hive存储和查询引擎作为数仓存储历史数据，不适合作为实时交互的数据库，可以增删改。

• HbaseNosql数据库引擎(列式)，支持大数据量的实时交互，适合配合前端业务系统使用，支持增删改。

• MongoDBHbase的替代者，性能优于Hbase，周边组件产品丰富，可以直接和Spark配合使用。

• Kudu 列式存储引擎，位置基于Hive和Hbase之间，同时适合OLTP和OLAP2种情况Impala搜索引擎，适合实时秒级数据查询，在非大批量数据情况下，他敢排第三，很少有人敢排前二 。

• Spark新时代的星星，号称10倍与MapReduce的性能，支持SQL，机学习首选。

• sqoop(大致提下)HADOOP下的数据传输工具，支持MYSQL,POSTGRESQL,ORACLE等到HIVE,HBASE等的数据采集工作。

开发人员需要学习的内容：

HDFS数据读写/HIVE/Impala/Hbase/Kudu/Spark操作规范Spark如何调取Hive数据/如何调取kudu数据可能会需要：PhoneixSQL语句。