【数仓】对比spark-hive的两种分布式计算模式

最近在学习过程中发现SparkSQL、Hive on Spark、Spark on Hive是非常容易混淆的的概念。了解三者的关系前，先要先明白几个概念。

相对于HIve on MapReduce，本质上来说，Hive on Spark是Hive把自己的引擎从MapReduce替换为更高效的SparkRDD。数据源是hive本身，当我们执行HQL时底层已经不再是将HQL转换为MapReduce任务，而是跑SparkRDD任务。

在hive-site-xml中把hive.execution.engine配置换成spark，在hive所在节点安装Spark并配置环境变量。外部远程登录或者hive命令行模式就会执行spark任务了。

即：Hive on Spark = HQL解析 + SparkRDD引擎

Spark on Hive是以Spark角度看Hive是数据源，在Spark中配置Hive，并获取Hive中的元数据，然后用SparkSQL操作hive表的数据并直接翻译成SparkRDD任务。Hive只是作为一个Spark的数据源。

bin/spark-sql、bin/spark-submit采用的是这种方式。提交任务的jar必须带着hive-site.xml的配置。

即：Spark on Hive = SparkSql解析 + SparkRDD引擎

Spark on Hive的模式更加丝滑，性能更好。

HIve on Spark的模式对大数据周边组件的支持兼容性更好。

5种让Hive查询变快的方法

在过去几年中，主要受到围绕Stinger计划的Hive社区创新的推动，Hive查询时间得到了显着改善，使Hive能够以速度和规模支持批量和交互式工作负载。

但是，许多使用者仍然不熟悉以最快速度运行Hive查询的基本技术和最佳实践。本文中，将重点介绍一些常使用的简单技术，以提高HIVE查询的性能。

Hive可以使用Apache Tez执行引擎而不是Map-reduce引擎。不会详细介绍这里提到的使用Tez的许多好处; 相反，提出一个简单的建议：如果在您的环境中默认情况下没有打开它，请在Hive查询的开头使用Tez设置为“true”

Hive支持ORCfile，这是一种新的表存储格式，通过谓词下推，压缩等技术实现极佳的速度提升。

对每个HIVE表使用ORCFile应该是一个明智的选择，对于获得HIVE查询的快速响应时间非常有益。

作为一个例子，考虑两个大表A和B（存储为文本文件，这里没有指定一些列），以及一个简单的查询 :

此查询可能需要很长时间才能执行，因为表A和B都存储为TEXT。将这些表转换为ORCFile格式通常会显着缩短查询时间：

ORC支持压缩存储（使用ZLIB或如上所示使用SNAPPY），但也支持未压缩存储。

将基表转换为ORC通常是取决于所在团队获取数据的职责，由于其他优先级，可能需要一些时间来更改完整的获取数据过程。ORCFile的好处是如此明显，以至于推荐如上所示的自助式方法 - 将A转换为A_ORC，将B转换为B_ORC并以此方式进行连接，以便立即从更快的查询中受益，而不依赖于其他团队。

矢量化查询执行通过一次批量执行1024行而不是每行一行来提高扫描，聚合，过滤器和连接等操作的性能。

这个功能在Hive 0.13中引入，显着缩短了查询执行时间，并且可以通过两个参数设置轻松启用：

在提交最终执行之前，Hive会优化每个查询的逻辑和物理执行计划。这些优化不是基于查询的成本 - 也就是说，直到运行时。

最近添加到Hive，基于成本的优化，基于查询成本执行进一步优化，从而导致可能不同的决策：如何订购联接，执行哪种类型的联接，并行度等。

要使用基于成本的优化（也称为CBO），请在查询开头设置以下参数

然后，通过运行Hive的“analyze”命令为CBO准备数据，以收集我们想要使用CBO的表的各种统计信息。

例如，在tweet数据表中，希望收集有关该表的统计信息以及大约2列：“sender”和“topic”：

使用HIVE 0.14（在HDP 2.2上），analyze命令的工作速度要快得多，而且您不需要指定每一列，因此只需如下：

现在使用此表执行查询应该会导致不同的执行计划由于成本计算和Hive创建的不同执行计划而更快。

SQL是一种强大的声明性语言。与其他声明性语言一样，编写SQL语句的方法不止一种。尽管每个语句的功能都相同，但它可能具有截然不同的性能特征

每条记录代表一次点击事件，希望找到每个sessionID的最新网址。

有人使用如下方式：

在上面的查询中，构建一个子查询来收集每个会话中最新事件的时间戳，然后使用内部联接来过滤掉其余的事件。

虽然查询是一个合理的解决方案 - 从功能的角度来看 - 事实证明，有一种更好的方法来重写这个查询，如下所示

在这里，使用Hive的OLAP功能（OVER和RANK）来实现相同的功能，但没有使用表连接。

显然，删除不必要的连接几乎总能带来更好的性能，而且当使用大数据时，这比以往任何时候都更重要。在很多情况下查询不是最优的 - 所以仔细查看每个查询并考虑重写是否可以使它更好更快。

更多内容信息

什么是Hive on Spark

hive默认计算引擎是mapreduce，hive on spark是搞hive的开发者将计算引擎换成spark

对应的有spark sql，这是spark的开发者写的访问hive数据的sql引擎。两者开发者不同。

如果你搞hive的话，建议可以再了解下hive on tez，又叫Stinger

hivetez引擎和mr引擎的区别

MapReduce： 是一种离线计算框架，将一个算法抽象成Map和Reduce两个阶段进行处理，每个阶段都是用键值对（key/value）作为输入和输出，非常适合数据密集型计算。Map/Reduce通过把对数据集的大规模操作分发给网络上的每个节点实现可靠性；每个节点会周期性地返回它所完成的工作和最新的状态。如果一个节点在设定的时间内没有进行心跳上报，主节点（可以理解为主服务器）就会认为这个节点down掉了，此时就会把分配给这个节点的数据发到别的节点上运算，这样可以保证系统的高可用性和稳定性。因此它是一个很好的计算框架。

TEZ：

是基于Hadoop YARN之上的DAG（有向无环图，Directed Acyclic Graph）计算框架。核心思想是将Map和Reduce两个操作进一步拆分，即Map被拆分成Input、Processor、Sort、Merge和Output， Reduce被拆分成Input、Shuffle、Sort、Merge、Processor和Output等。这样，这些分解后的元操作可以任意灵活组合，产生新的操作，这些操作经过一些控制程序组装后，可形成一个大的DAG作业，从而可以减少Map/Reduce之间的文件存储，同时合理组合其子过程，也可以减少任务的运行时间。

两者比较：

MR计算，会对磁盘进行多次的读写操作，这样启动多轮job的代价略有些大，不仅占用资源，更耗费大量的时间，

而采用TEZ计算框架，就会生成一个简洁的DAG作业，算子跑完不退出，下轮继续使用上一轮的算子，这样大大减少磁盘IO操作，从而计算速度更快。 TEZ比MR至少快5倍

相关资料链接：网页链接

标签：hive计算引擎采用什么