‘壹’ 为什么说Spark sql远远超越了MPP SQL
这里说的并不是性能，因为我没尝试对比过（下文会有简单的说明），而是尝试从某种更高一层次的的角度去看，为什么Spark SQL 是远远超越MPP SQL的。
Spark SQL 和 MPP SQL 其实不在一个维度上。简而言之，
MPP SQL 是 Spark SQL 的一个子集
Spark SQL 成为了一种跨越领域的交互形态
MPP SQL 是 Spark SQL 的一个子集
MPP SQL 要解决的技术问题是海量数据的查询问题。这里根据实际场景，你还可以加上一些修饰词汇，譬如秒级，Ad-hoc 之类。
在实际业务中
探索类业务，比如KPI多维分析，用户画像查询，数据科学家摸底数据等
运营类业务，比如报表（现在很多BI系统基本上完全基于SQL来构建），各种运营临时统计需求
分析类业务，不过这个会比较浅显。显然，真实的的分析应该主要依托一些统计类，机器学习等技术的支持
运维类业务，比如实时查询查看海量的系统日志等
MPP SQL 是有一定的性能优势的，从HAWQ,Impala 等都是基于MPP架构的。然而仅限于此。这些功能Spark SQL 目前都已经涵盖了，MPP SQL能做的事情，Spark SQL都完成的很漂亮。
依托于Spark 自身的全平台性(漂亮的DataSource API以及各个厂商的努力适配),Spark SQL 基本上可以对接任意多个异构数据源进行分析和查询。大家可参考我的一个简略实现 利用StreamingPro实现SQL-交互式查询。
关于性能可以再多说两句：
得益于一些具有复杂存储格式的文件的诞生，譬如CarbonData, Spark SQL 已经实现海量数据的秒级查询
Spark 自身通过Tungsten等项目的优化(尤其是代码自动生成)，速度越来越生猛，而JVM譬如GC带来的问题则可以进一步通过off-heap的方式减少。
所以 Spark SQL 和 MPP SQL在性能上的差距也会越来越小。
Spark SQL 成为了一种跨越领域的交互形态
Spark 通过使用DS（2.0统一了DF 和 DS，使用一套SQL引擎）极大的增强了交互语意，意味着你可以用SQL（DS）作为统一的交互语言完成流式，批处理，交互式查询，机器学习等大数据领域常见场景。这在任何一个系统都是不多见的，也可见Spark团队的抽象能力。
引言中的那篇文章其实是作者吐槽Spark 团队对Spark core（RDD）那层关注太少了，所以开始发牢骚。
现在我们再回过头来看我们常见的一些业务：
实时分析类业务
探索类业务
分析预测类业务
运营报表类业务
首先这些业务都可以使用Spark 来实现。其次统一的交互接口都是DS(DF/SQL),并且DS/SQL 是一套极度易用并且广泛普及和接受的。
当然Spark 也不是一步就做到这点的，原来流式计算和批量计算就是两套API, DF 和 DS 也是两套API,后面经过发展，Databricks 团队也在积极思考和慢慢成长，经过先前已经有的积累，才做到现在的这一步。
所以本质上DS/SQL 已经成为除了RDD API 以外，另外一套通用的，统一的交互式API，涵盖了流式，批处理，交互式查询，机器学习等大数据领域。这也是我们第一次达成这样的统一，目前来看也仅在Spark平台上得以实现，它是的大数据的使用和学习门槛进一步降低，功在千秋。
RDD VS DS/SQL
DS/SQL 是一套数据类型首先，操作种类受限的表达语言，意味着Spark 团队可以做更好的性能优化，也意味着门槛更低，在易用性和性能上都能取得良好的平衡
‘贰’ 基于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:说了一大堆，说白了最适合的还是踪迹分析因为数据量大，数据还要求实时，查询还要求快。这才是关键。
‘叁’ hive和sparksql的区别
历史上存在的原理，以前都是使用hive来构建数据仓库，所以存在大量对hive所管理的数据查询的需求。而hive、shark、sparlSQL都可以进行hive的数据查询。shark是使用了hive的sql语法解析器和优化器，修改了执行器，使之物理执行过程是跑在spark上；而sparkSQL是使用了自身的语法解析器、优化器和执行器，同时sparkSQL还扩展了接口，不单单支持hive数据的查询，可以进行多种数据源的数据查询。
‘肆’ spark写入impala中需要什么jar包
phoenix、impala、hive、shark、spark SQL等，本人目前在项目中使用的是phoenix工具，是一个访问hbase的JDBC驱动jar包，基本像访问JDBC一样，可以进行各种CRUD操作，还带有事务功能，性能据官网介绍还是非常快的
‘伍’ Spark SQL真的远远超越了MPP SQL吗
//读取数据文件。
ReadStudent(Application.dataPath + “/Wild boar.accdb”);
}
///
/// 读取表数值的函数
///
/// 数据文件的路径
internal void ReadStudent(string filetoread)
‘陆’ Spark-Hadoop，Hive，Spark 之间是什么关系
大数据本身是个很宽泛的概念，Hadoop生态圈(或者泛生态圈)基本上都是为了处理超过单机尺度的数据处理而诞生的。你可以把它比作一个厨房所以需要的各种工具。锅碗瓢盆，各有各的用处，互相之间又有重合。你可以用汤锅直接当碗吃饭喝汤，你可以用小刀或者刨子去皮。但是每个工具有自己的特性，虽然奇怪的组合也能工作，但是未必是最佳选择。
大数据，首先你要能存的下大数据
传统的文件系统是单机的，不能横跨不同的机器。HDFS(Hadoop Distributed FileSystem)的设计本质上是为了大量的数据能横跨成百上千台机器，但是你看到的是一个文件系统而不是很多文件系统。比如你说我要获取/hdfs/tmp/file1的数据，你引用的是一个文件路径，但是实际的数据存放在很多不同的机器上。你作为用户，不需要知道这些，就好比在单机上你不关心文件分散在什么磁道什么扇区一样。HDFS为你管理这些数据。
存的下数据之后，你就开始考虑怎么处理数据。虽然HDFS可以为你整体管理不同机器上的数据，但是这些数据太大了。一台机器读取成T上P的数据(很大的数据哦，比如整个东京热有史以来所有高清电影的大小甚至更大)，一台机器慢慢跑也许需要好几天甚至好几周。对于很多公司来说，单机处理是不可忍受的，比如微博要更新24小时热博，它必须在24小时之内跑完这些处理。那么我如果要用很多台机器处理，我就面临了如何分配工作，如果一台机器挂了如何重新启动相应的任务，机器之间如何互相通信交换数据以完成复杂的计算等等。这就是MapRece
/ Tez / Spark的功能。MapRece是第一代计算引擎，Tez和Spark是第二代。MapRece的设计，采用了很简化的计算模型，只有Map和Rece两个计算过程(中间用Shuffle串联)，用这个模型，已经可以处理大数据领域很大一部分问题了。
那什么是Map，什么是Rece?
考虑如果你要统计一个巨大的文本文件存储在类似HDFS上，你想要知道这个文本里各个词的出现频率。你启动了一个MapRece程序。Map阶段，几百台机器同时读取这个文件的各个部分，分别把各自读到的部分分别统计出词频，产生类似(hello, 12100次)，(world，15214次)等等这样的Pair(我这里把Map和Combine放在一起说以便简化);这几百台机器各自都产生了如上的集合，然后又有几百台机器启动Rece处理。Recer机器A将从Mapper机器收到所有以A开头的统计结果，机器B将收到B开头的词汇统计结果(当然实际上不会真的以字母开头做依据，而是用函数产生Hash值以避免数据串化。因为类似X开头的词肯定比其他要少得多，而你不希望数据处理各个机器的工作量相差悬殊)。然后这些Recer将再次汇总，(hello，12100)+(hello，12311)+(hello，345881)=
(hello，370292)。每个Recer都如上处理，你就得到了整个文件的词频结果。
这看似是个很简单的模型，但很多算法都可以用这个模型描述了。
Map+Rece的简单模型很黄很暴力，虽然好用，但是很笨重。第二代的Tez和Spark除了内存Cache之类的新feature，本质上来说，是让Map/Rece模型更通用，让Map和Rece之间的界限更模糊，数据交换更灵活，更少的磁盘读写，以便更方便地描述复杂算法，取得更高的吞吐量。
有了MapRece，Tez和Spark之后，程序员发现，MapRece的程序写起来真麻烦。他们希望简化这个过程。这就好比你有了汇编语言，虽然你几乎什么都能干了，但是你还是觉得繁琐。你希望有个更高层更抽象的语言层来描述算法和数据处理流程。于是就有了Pig和Hive。Pig是接近脚本方式去描述MapRece，Hive则用的是SQL。它们把脚本和SQL语言翻译成MapRece程序，丢给计算引擎去计算，而你就从繁琐的MapRece程序中解脱出来，用更简单更直观的语言去写程序了。
有了Hive之后，人们发现SQL对比Java有巨大的优势。一个是它太容易写了。刚才词频的东西，用SQL描述就只有一两行，MapRece写起来大约要几十上百行。而更重要的是，非计算机背景的用户终于感受到了爱：我也会写SQL!于是数据分析人员终于从乞求工程师帮忙的窘境解脱出来，工程师也从写奇怪的一次性的处理程序中解脱出来。大家都开心了。Hive逐渐成长成了大数据仓库的核心组件。甚至很多公司的流水线作业集完全是用SQL描述，因为易写易改，一看就懂，容易维护。
自从数据分析人员开始用Hive分析数据之后，它们发现，Hive在MapRece上跑，真鸡巴慢!流水线作业集也许没啥关系，比如24小时更新的推荐，反正24小时内跑完就算了。但是数据分析，人们总是希望能跑更快一些。比如我希望看过去一个小时内多少人在一些特定页面驻足，分别停留了多久，对于一个巨型网站海量数据下，这个处理过程也许要花几十分钟甚至很多小时。而这个分析也许只是你万里长征的第一步，你还有很多其他的要分析。你无法忍受等待的折磨，只能跟帅帅的工程师蝈蝈说，快，快，再快一点!
于是Impala，Presto，Drill诞生了(当然还有无数非着名的交互SQL引擎，就不一一列举了)。三个系统的核心理念是，MapRece引擎太慢，因为它太通用，太强壮，太保守，我们SQL需要更轻量，更激进地获取资源，更专门地对SQL做优化，而且不需要那么多容错性保证(因为系统出错了大不了重新启动任务，如果整个处理时间更短的话，比如几分钟之内)。这些系统让用户更快速地处理SQL任务，牺牲了通用性稳定性等特性。如果说MapRece是大砍刀，砍啥都不怕，那上面三个就是剔骨刀，灵巧锋利，但是不能搞太大太硬的东西。
这些系统，说实话，一直没有达到人们期望的流行度。因为这时候又两个异类被造出来了。他们是Hive on Tez / Spark和SparkSQL。它们的设计理念是，MapRece慢，但是如果我用新一代通用计算引擎Tez或者Spark来跑SQL，那我就能跑的更快。而且用户不需要维护两套系统。这就好比如果你厨房小，人又懒，对吃的精细程度要求有限，那你可以买个电饭煲，能蒸能煲能烧，省了好多厨具。
上面的介绍，基本就是一个数据仓库的构架了。底层HDFS，上面跑MapRece/Tez/Spark，在上面跑Hive，Pig。或者HDFS上直接跑Impala，Drill，Presto。这解决了中低速数据处理的要求。
那如果我要更高速的处理呢？
如果我是一个类似微博的公司，我希望显示不是24小时热博，我想看一个不断变化的热播榜，更新延迟在一分钟之内，上面的手段都将无法胜任。于是又一种计算模型被开发出来，这就是Streaming(流)计算。Storm是最流行的流计算平台。流计算的思路是，如果要达到更实时的更新，我何不在数据流进来的时候就处理了?比如还是词频统计的例子，我的数据流是一个一个的词，我就让他们一边流过我就一边开始统计了。流计算很牛逼，基本无延迟，但是它的短处是，不灵活，你想要统计的东西必须预先知道，毕竟数据流过就没了，你没算的东西就无法补算了。因此它是个很好的东西，但是无法替代上面数据仓库和批处理系统。
还有一个有些独立的模块是KV Store，比如Cassandra，HBase，MongoDB以及很多很多很多很多其他的(多到无法想象)。所以KV Store就是说，我有一堆键值，我能很快速滴获取与这个Key绑定的数据。比如我用身份证号，能取到你的身份数据。这个动作用MapRece也能完成，但是很可能要扫描整个数据集。而KV
Store专用来处理这个操作，所有存和取都专门为此优化了。从几个P的数据中查找一个身份证号，也许只要零点几秒。这让大数据公司的一些专门操作被大大优化了。比如我网页上有个根据订单号查找订单内容的页面，而整个网站的订单数量无法单机数据库存储，我就会考虑用KV Store来存。KV Store的理念是，基本无法处理复杂的计算，大多没法JOIN，也许没法聚合，没有强一致性保证(不同数据分布在不同机器上，你每次读取也许会读到不同的结果，也无法处理类似银行转账那样的强一致性要求的操作)。但是丫就是快。极快。
每个不同的KV Store设计都有不同取舍，有些更快，有些容量更高，有些可以支持更复杂的操作。必有一款适合你。
除此之外，还有一些更特制的系统/组件，比如Mahout是分布式机器学习库，Protobuf是数据交换的编码和库，ZooKeeper是高一致性的分布存取协同系统，等等。
有了这么多乱七八糟的工具，都在同一个集群上运转，大家需要互相尊重有序工作。所以另外一个重要组件是，调度系统。现在最流行的是Yarn。你可以把他看作中央管理，好比你妈在厨房监工，哎，你妹妹切菜切完了，你可以把刀拿去杀鸡了。只要大家都服从你妈分配，那大家都能愉快滴烧菜。
你可以认为，大数据生态圈就是一个厨房工具生态圈。为了做不同的菜，中国菜，日本菜，法国菜，你需要各种不同的工具。而且客人的需求正在复杂化，你的厨具不断被发明，也没有一个万用的厨具可以处理所有情况，因此它会变的越来越复杂。
‘柒’ Spark与Hadoop MapRece大比拼，谁实力更强
一提到大数据处理，相信很多人第一时间想到的是 Hadoop MapRece。没错，Hadoop MapRece 为大数据处理技术奠定了基础。近年来，随着 Spark 的发展，越来越多的声音提到了 Spark。而Spark相比Hadoop MapRece有哪些优势?
Spark与Hadoop MapRece在业界有两种说法 ：一是 Spark 将代替 Hadoop MapRece，成为未来大数据处理发展的方向 ;二是 Spark 将会和 Hadoop 结合，形成更大的生态圈。其实 Spark 和 Hadoop MapRece 的重点应用场合有所不同。相对于 Hadoop MapRece 来说，Spark 有点“青出于蓝”的感觉，Spark 是在Hadoop MapRece 模型上发展起来的，在它的身上我们能明显看到 MapRece的影子，所有的 Spark 并非从头创新，而是站在了巨人“MapRece”的肩膀上。千秋功罪，留于日后评说，我们暂且搁下争议，来看看相比 Hadoop MapRece，Spark 都有哪些优势。
1、计算速度快
大数据处理首先追求的是速度。Spark 到底有多快?用官方的话说，“Spark 允许 Hadoop 集群中的应用程序在内存中以 100 倍的速度运行，即使在磁盘上运行也能快 10 倍”。可能有的读者看到这里会大为感叹，的确如此，在有迭代计算的领域，Spark 的计算速度远远超过 MapRece，并且迭代次数越多，Spark 的优势越明显。这是因为 Spark 很好地利用了目前服务器内存越来越大这一优点，通过减少磁盘 I/O 来达到性能提升。它们将中间处理数据全部放到了内存中，仅在必要时才批量存入硬盘中。或许读者会问 ：如果应用程序特别大，内存能放下多少 GB ?答曰 ：什么? GB ?目前 IBM 服务器内存已经扩展至几 TB 了。
2、应用灵活，上手容易
知道 AMPLab 的 Lester 为什么放弃 MapRece 吗?因为他需要把很多精力放到Map和Rece的编程模型上，极为不便。 Spark在简单的Map及Rece操作之外，还支持 SQL 查询、流式查询及复杂查询，比如开箱即用的机器学习算法。同时，用户可以在同一个工作流中无缝地搭配这些能力，应用十分灵活。
Spark 核心部分的代码为 63 个 Scala 文件，非常的轻量级。并且允许 Java、Scala、Python 开发者在自己熟悉的语言环境下进行工作，通过建立在Java、Scala、Python、SQL(应对交互式查询)的标准 API 以方便各行各业使用，同时还包括大量开箱即用的机器学习库。它自带 80 多个高等级操作符，允许在 Shell中进行交互式查询。即使是新手，也能轻松上手应用。
3、兼容竞争对手
Spark 可以独立运行，除了可以运行在当下的 YARN 集群管理外，还可以读取已有的任何 Hadoop 数据。它可以运行在任何 Hadoop 数据源上，比如 HBase、HDFS 等。有了这个特性，让那些想从 Hadoop 应用迁移到 Spark 上的用户方便了很多。Spark 有兼容竞争对手的胸襟，何愁大事不成?
4、实时处理性能非凡
MapRece 更 加 适 合 处 理 离 线 数 据( 当 然， 在 YARN 之 后，Hadoop也可以借助其他工具进行流式计算)。Spark 很好地支持实时的流计算，依赖Spark Streaming 对数据进行实时处理。Spark Streaming 具备功能强大的 API，允许用户快速开发流应用程序。而且不像其他的流解决方案，比如Storm，Spark Streaming 无须额外的代码和配置，就可以做大量的恢复和交付工作。
5、社区贡献力量巨大
从 Spark 的版本演化来看，足以说明这个平台旺盛的生命力及社区的活跃度。尤其自 2013 年以来，Spark 一度进入高速发展期，代码库提交与社区活跃度都有显着增长。以活跃度论，Spark 在所有的 Apache 基金会开源项目中位列前三，相较于其他大数据平台或框架而言，Spark 的代码库最为活跃。
Spark 非常重视社区活动，组织也极为规范，会定期或不定期地举行与 Spark相关的会议。会议分为两种 ：一种是 Spark Summit，影响力极大，可谓全球 Spark顶尖技术人员的峰会，目前已于 2013—2015 年在 San Francisco 连续召开了三届Summit 大会 ;另一种是 Spark 社区不定期地在全球各地召开的小型 Meetup 活动。Spark Meetup 也会在我国的一些大城市定期召开，比如北京、深圳、西安等地，读者可以关注当地的微信公众号进行参与。
Spark 的适用场景
从大数据处理需求来看，大数据的业务大概可以分为以下三类 ：
(1)复杂的批量数据处理，通常的时间跨度在数十分钟到数小时之间。
(2)基于历史数据的交互式查询，通常的时间跨度在数十秒到数分钟之间。
(3)基于实时数据流的数据处理，通常的时间跨度在数百毫秒到数秒之间。
目前已有很多相对成熟的开源和商业软件来处理以上三种情景 ：第一种业务，可以利用 MapRece 来进行批量数据处理 ;第二种业务，可以用 Impala 来进行交互式查询 ;对于第三种流式数据处理，可以想到专业的流数据处理工具Storm。但是这里有一个很重要的问题 ：对于大多数互联网公司来说，一般会同时遇到以上三种情景，如果采用不同的处理技术来面对这三种情景，那么这三种情景的输入/ 输出数据无法无缝共享，它们之间可能需要进行格式转换，并且每个开源软件都需要一支开发和维护团队，从而提高了成本。另外一个不便之处就是，在同一个集群中对各个系统协调资源分配比较困难。
那么，有没有一种软件可以同时处理以上三种情景呢? Spark 就可以，或者说有这样的潜力。Spark 同时支持复杂的批处理、互操作和流计算，而且兼容支持HDFS 和 Amazon S3 等分布式文件系统，可以部署在 YARN 和 Mesos 等流行的集群资源管理器上。
从 Spark 的设计理念(基于内存的迭代计算框架)出发，其最适合有迭代运算的或者需要多次操作特定数据集的应用场合。并且迭代次数越多，读取的数据量越大，Spark 的应用效果就越明显。因此，对于机器学习之类的“迭代式”应用，Spark 可谓拿手好戏，要比 Hadoop MapRece 快数十倍。另外，Spark Streaming因为内存存储中间数据的特性，处理速度非常快，也可以应用于需要实时处理大数据的场合。
当然，Spark 也有不适用的场合。对于那种异步细粒度更新状态的应用，例如 Web 服务的存储或增量的 Web 爬虫和索引，也就是对于那种增量修改的应用模型不适合。Spark 也不适合做超级大的数据量的处理，这里所说的“超级大”是相对于这个集群的内存容量而言的，因为 Spark 要将数据存储在内存中。一般来说，10TB 以上(单次分析)的数据就可以算是“超级大”的数据了。
一般来说，对于中小企业的数据中心而言，在单次计算的数据量不大的情况下，Spark 都是很好的选择。另外，Spark 也不适合应用于混合的云计算平台，因为混合的云计算平台的网络传输是很大的问题，即便有专属的宽带在云端 Cluster和本地 Cluster 之间传输数据，相比内存读取速度来说，依然不抵。
‘捌’ impala为什么比spark快
应该不会，Impala是相当专注于传统企业客户和OLAP和数据仓库工作负载。Shark支持传统OLAP。
比较：
一、总体上
Shark扩展了Apache Hive，大大加快在内存和磁盘上的查询。而Impala是企业级数据仓库系统, 可以很好地使用Hive/ HDFS，从架构层来说，类似于传统的并行数据库。这两个系统有着很多共同的目标，但也有很大差异。
二、与现有系统的兼容性
Shark直接建立在Apache/Hive代码库上，所以它自然支持几乎所有Hive特点。它支持现有的Hive SQL语言，Hive数据格式（SerDes），用户自定义函数（UDF），调用外部脚本查询。因为Impala使用自定义的C++运行，它不支持Hive UDF。这两个系统将会与许多BI工具整合，这一直是Impala的主要目标。Shark正在被用于一些BI工具，如Tableau，不过这并没有被探索更多。
三、内存中的数据处理
Shark允许用户显式地加载在内存中的数据，以加快查询处理，其内存使用有效率的，压缩的面向列的格式。Impala还没有提供在内存中的存储。
四、容错
Shark被设计为支持短期和长时间运行的查询。它可以从查询故障恢复(感谢底层Spark引擎)。Impala目前是更侧重于短查询，不容错（如果节点发生故障，查询必须重新启动，对短查询来说这无疑是可以接受的）。
五、性能
做全面的比较太早了点。Shark和Impala都报告比Hive快10-100倍，但这都依赖具体情况和系统负载。两个项目也都在未来6个月内会做重要优化。以我们的经验来看，Sharkr当前版本，如果是内存的数据一般比Hive快100倍，如果是磁盘上的数据一般快5-10倍，这取决于查询（带关联连接的查询，能比Hive快很多）。