❶ Hadoop、Hive、Spark三者的区别和关系
Hadoop分为两大部分：HDFS、Maprece。
HDFS为海量的数据提供了存储，而MapRece则为海量的数据提供了计算。
由于编写MapRece程序繁琐复杂，而sql语言比较简单，程序员就开发出了支持sql的hive。hive的出现方便了程序员和没有计算机背景的数据分析人员。我们只需要编写相对简单的sql命令，hive会帮我们翻译为maprece程序交给计算机去执行。
mapreceh这个计算框架每次执行都是从磁盘中读取的，而spark则是直接从内存中读取的。由于MapRece 的框架限制，一个 MapRece 任务只能包含一次 Map 和一次 Rece，计算完成之后，MapRece 会将运算结果写回到磁盘中（更准确地说是分布式存储系统）供下次计算使用。如果所做的运算涉及大量循环，比如估计模型参数的梯度下降或随机梯度下降算法就需要多次循环使用训练数据，那么整个计算过程会不断重复地往磁盘里读写中间结果。这样的读写数据会引起大量的网络传输以及磁盘读写，极其耗时，而且它们都是没什么实际价值的废操作。因为上一次循环的结果会立马被下一次使用，完全没必要将其写入磁盘。
所以spark可以理解为maprece的改进升级版
❷ Spark SQL（十）：Hive On Spark
Hive是目前大数据领域，事实上的SQL标准。其底层默认是基于MapRece实现的，但是由于MapRece速度实在比较慢，因此这几年，陆续出来了新的SQL查询引擎，包括Spark SQL，Hive On Tez，Hive On Spark等。
Spark SQL与Hive On Spark是不一样的。Spark SQL是Spark自己研发出来的针对各种数据源，包括Hive、JSON、Parquet、JDBC、RDD等都可以执行查询的，一套基于Spark计算引擎的查询引擎。因此它是Spark的一个项目，只不过提供了针对Hive执行查询的工功能而已，适合在一些使用Spark技术栈的大数据应用类系统中使用。
而Hive On Spark，是Hive的一个项目，它是将Spark作为底层的查询引擎（不通过MapRece作为唯一的查询引擎）。Hive On Spark，只适用于Hive，在可预见的未来，很有可能Hive默认的底层引擎就从MapRece切换为Spark了；适合于将原有的Hive数据仓库以及数据统计分析替换为Spark引擎，作为全公司通用的大数据统计分析引擎。
Hive On Spark做了一些优化：
1、Map Join
Spark SQL默认对join是支持使用broadcast机制将小表广播到各个节点上，以进行join的。但是问题是，这会给Driver和Worker带来很大的内存开销。因为广播的数据要一直保留在Driver内存中。所以目前采取的是，类似乎MapRece的Distributed Cache机制，即提高HDFS replica factor的复制因子，以让数据在每个计算节点上都有一个备份，从而可以在本地进行数据读取。
2、Cache Table
对于某些需要对一张表执行多次操作的场景，Hive On Spark内部做了优化，即将要多次操作的表cache到内存中，以便于提升性能。但是这里要注意，并不是对所有的情况都会自动进行cache。所以说，Hive On Spark还有很多不完善的地方。
Hive QL语句 =>
语法分析 => AST =>
生成逻辑执行计划 => Operator Tree =>
优化逻辑执行计划 => Optimized Operator Tree =>
生成物理执行计划 => Task Tree =>
优化物理执行计划 => Optimized Task Tree =>
执行优化后的Optimized Task Tree
❸ 【数仓】对比spark-hive的两种分布式计算模式
最近在学习过程中发现SparkSQL、Hive on Spark、Spark on Hive是非常容易混淆的的概念。了解三者的关系前，先要先明白几个概念。
相对于HIve on MapRece，本质上来说，Hive on Spark是Hive把自己的引擎从MapRece替换为更高效的SparkRDD。数据源是hive本身，当我们执行HQL时底层已经不再是将HQL转换为MapRece任务，而是跑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的模式对大数据周边组件的支持兼容性更好。
❹ sparkSQL用jdbc连接hive和用元数据连接hive的区别，各自优缺点
spark on hive : 是spark 通过spark-sql 使用hive 语句操作hive ,底层运行的还是 spark rdd.
*（1）就是通过sparksql，加载hive的配置文件，获取到hive的元数据信息
* （2）spark sql获取到hive的元数据信息之后就可以拿到hive的所有表的数据
* （3）接下来就可以通过spark sql来操作hive表中的数据
hive on spark: 是hive 等的执行引擎变成spark , 不再是maprece. 相对于上一项,这个要实现责麻烦很多, 必须重新编译你的spark. 和导入jar包,
❺ 基于spark SQL之上的检索与排序对比性能测试
之前做过一年的spark研发，之前在阿里与腾讯也做了很久的hive，所以对这方面比较了解。
第一：其实快多少除了跟spark与hive本身的技术实现外，也跟机器性能，底层操作系统的参数优化息息相关，不能一概而论。
第二：hive 目前应该还是业界的主流，毕竟快与慢很多时候并非是至关重要的，对于一个生产系统来说，更重要的应该是稳定性，spark毕竟还算是比较新兴的事务，快确实快，但是稳定性上距离hive相差甚远。关于spark我们也修复了很多关于内存泄露的BUG，因为您问的是性能，所以不过多介绍（可以跟我要YDB编程指南，里面有我对这些BUG的修正）
第三：关于性能，我测试的可能不够全面，只能在排序与检索过滤上提供我之前的基于YDB的BLOCK sort测试报告供您参考（网络上贴word太费劲，您可以跟我要 word文档）。
排序可以说是很多日志系统的硬指标（如按照时间逆序排序），如果一个大数据系统不能进行排序，基本上是这个系统属于不可用状态，排序算得上是大数据系统的一个“刚需”,无论大数据采用的是hadoop,还是spark，还是impala,hive，总之排序是必不可少的，排序的性能测试也是必不可少的。
有着计算奥运会之称的Sort Benchmark全球排序每年都会举行一次，每年巨头都会在排序上进行巨大的投入，可见排序速度的高低有多么重要！但是对于大多数企业来说，动辄上亿的硬件投入，实在划不来、甚至远远超出了企业的项目预算。相比大数据领域的暴力排序有没有一种更廉价的实现方式？
在这里，我们为大家介绍一种新的廉价排序方法，我们称为blockSort。
500G的数据300亿条数据，只使用4台 16核，32G内存，千兆网卡的虚拟机即可实现 2~15秒的 排序 （可以全表排序，也可以与任意筛选条件筛选后排序）。
一、基本的思想是这样的，如下图所示：
1.将数据按照大小预先划分好，如划分成 大、中、小三个块(block)。
2.如果想找最大的数据，那么只需要在最大的那个块里去找就可以了。
3.这个快还是有层级结构的，如果每个块内的数据量很多，可以到下面的子快内进行继续查找，可以分多个层进行排序。
4.采用这种方法，一个亿万亿级别的数据（如long类型），最坏最坏的极端情况也就进行2048次文件seek就可以筛选到结果。
五、哪些用户适合使用YDB？
1.传统关系型数据，已经无法容纳更多的数据，查询效率严重受到影响的用户。
2.目前在使用SOLR、ES做全文检索，觉得solr与ES提供的分析功能太少，无法完成复杂的业务逻辑，或者数据量变多后SOLR与ES变得不稳定，在掉片与均衡中不断恶性循环，不能自动恢复服务，运维人员需经常半夜起来重启集群的情况。
3.基于对海量数据的分析，但是苦于现有的离线计算平台的速度和响应时间无满足业务要求的用户。
4.需要对用户画像行为类数据做多维定向分析的用户。
5.需要对大量的UGC（User Generate Content）数据进行检索的用户。
6.当你需要在大数据集上面进行快速的，交互式的查询时。
7.当你需要进行数据分析，而不只是简单的键值对存储时。
8.当你想要分析实时产生的数据时。
ps:说了一大堆，说白了最适合的还是踪迹分析因为数据量大，数据还要求实时，查询还要求快。这才是关键。
❻ spark SQL和hive到底什么关系
Spark SQL解决了这两个问题。
第一，Spark SQL在Hive兼容层面仅依赖HQL parser、Hive Metastore和Hive SerDe。也就是说，从HQL被解析成抽象语法树（AST）起，就全部由Spark SQL接管了。执行计划生成和优化都由Catalyst负责。借助Scala的模式匹配等函数式语言特性，利用Catalyst开发执行计划优化策略比Hive要简洁得多。去年Spark summit上Catalyst的作者Michael Armbrust对Catalyst做了一个简要介绍：2013 | Spark Summit。
第二，相对于Shark，由于进一步削减了对Hive的依赖，Spark SQL不再需要自行维护打了patch的Hive分支。Shark后续将全面采用Spark SQL作为引擎，不仅仅是查询优化方面。
❼ spark sql能替代hive吗
Spark SQL解决了这两个问题。 第一，Spark SQL在Hive兼容层面仅依赖HQL parser、Hive Metastore和Hive SerDe。也就是说，从HQL被解析成抽象语法树（AST）起，就全部由Spark SQL接管了。执行计划生成和优化都由Catalyst负责。借助Scala的模式匹配...
❽ spark与hive查询得出的数据不同
在实际工作的情况中，经常有spark与hive查询出来的数据存在不一样的情况，基本的原因如下： 1、由于精度不一样导致的 2、更多的时候确实是由于元数据混乱导致的 （就是说hive中能读到这个字段的值，但是在spark中却无法读取到该字段的值。 很多时候可能还是由于大小写的混乱所导致的） 同一条sql,hive能生成表,而spark却生成的一张空表,或者数据缺少,存在null值,与hive结果不一致 设置 spark.sql.hive.convertMetastoreOrc=false convertMetastoreParquet=false 原因: spark用自己的格式读取hive文件后进行自动转换后进行操作 官方说明❾ 大数据如何入门
首先我们要了解Java语言和Linux操作系统，这两个是学习大数据的基础，学习的顺序不分前后。
大数据
Java ：只要了解一些基础即可，做大数据不需要很深的Java 技术，学java SE 就相当于有学习大数据基础。
Linux：因为大数据相关软件都是在Linux上运行的，所以Linux要学习的扎实一些，学好Linux对你快速掌握大数据相关技术会有很大的帮助，能让你更好的理解hadoop、hive、hbase、spark等大数据软件的运行环境和网络环境配置，能少踩很多坑，学会shell就能看懂脚本这样能更容易理解和配置大数据集群。还能让你对以后新出的大数据技术学习起来更快。
Hadoop：这是现在流行的大数据处理平台几乎已经成为大数据的代名词，所以这个是必学的。Hadoop里面包括几个组件HDFS、MapRece和YARN，HDFS是存储数据的地方就像我们电脑的硬盘一样文件都存储在这个上面，MapRece是对数据进行处理计算的，它有个特点就是不管多大的数据只要给它时间它就能把数据跑完，但是时间可能不是很快所以它叫数据的批处理。
Zookeeper：这是个万金油，安装Hadoop的HA的时候就会用到它，以后的Hbase也会用到它。它一般用来存放一些相互协作的信息，这些信息比较小一般不会超过1M，都是使用它的软件对它有依赖，对于我们个人来讲只需要把它安装正确，让它正常的run起来就可以了。
Mysql：我们学习完大数据的处理了，接下来学习学习小数据的处理工具mysql数据库，因为一会装hive的时候要用到，mysql需要掌握到什么层度那?你能在Linux上把它安装好，运行起来，会配置简单的权限，修改root的密码，创建数据库。这里主要的是学习SQL的语法，因为hive的语法和这个非常相似。
Sqoop：这个是用于把Mysql里的数据导入到Hadoop里的。当然你也可以不用这个，直接把Mysql数据表导出成文件再放到HDFS上也是一样的，当然生产环境中使用要注意Mysql的压力。
Hive：这个东西对于会SQL语法的来说就是神器，它能让你处理大数据变的很简单，不会再费劲的编写MapRece程序。有的人说Pig那?它和Pig差不多掌握一个就可以了。
Oozie：既然学会Hive了，我相信你一定需要这个东西，它可以帮你管理你的Hive或者MapRece、Spark脚本，还能检查你的程序是否执行正确，出错了给你发报警并能帮你重试程序，最重要的是还能帮你配置任务的依赖关系。我相信你一定会喜欢上它的，不然你看着那一大堆脚本，和密密麻麻的crond是不是有种想屎的感觉。
Hbase：这是Hadoop生态体系中的NOSQL数据库，他的数据是按照key和value的形式存储的并且key是唯一的，所以它能用来做数据的排重，它与MYSQL相比能存储的数据量大很多。所以他常被用于大数据处理完成之后的存储目的地。
Kafka：这是个比较好用的队列工具，队列是干吗的?排队买票你知道不?数据多了同样也需要排队处理，这样与你协作的其它同学不会叫起来，你干吗给我这么多的数据(比如好几百G的文件)我怎么处理得过来，你别怪他因为他不是搞大数据的，你可以跟他讲我把数据放在队列里你使用的时候一个个拿，这样他就不在抱怨了马上灰流流的去优化他的程序去了，因为处理不过来就是他的事情。而不是你给的问题。当然我们也可以利用这个工具来做线上实时数据的入库或入HDFS，这时你可以与一个叫Flume的工具配合使用，它是专门用来提供对数据进行简单处理，并写到各种数据接受方(比如Kafka)的。
Spark：它是用来弥补基于MapRece处理数据速度上的缺点，它的特点是把数据装载到内存中计算而不是去读慢的要死进化还特别慢的硬盘。特别适合做迭代运算，所以算法流们特别稀饭它。它是用scala编写的。Java语言或者Scala都可以操作它，因为它们都是用JVM的。
❿ spark SQL和hive到底什么关系
Hive是一种基于HDFS的数据仓库，并且提供了基于SQL模型的，针对存储了大数据的数据仓库，进行分布式交互查询的查询引擎。
SparkSQL并不能完全替代Hive，它替代的是Hive的查询引擎，SparkSQL由于其底层基于Spark自身的基于内存的特点，因此速度是Hive查询引擎的数倍以上，Spark本身是不提供存储的，所以不可能替代Hive作为数据仓库的这个功能。
SparkSQL相较于Hive的另外一个优点，是支持大量不同的数据源，包括hive、json、parquet、jdbc等等。SparkSQL由于身处Spark技术堆栈内，基于RDD来工作，因此可以与Spark的其他组件无缝整合使用，配合起来实现许多复杂的功能。比如SparkSQL支持可以直接针对hdfs文件执行sql语句。