我先说我个人的结论。
我的结论必须基于2017年9月初这个时间节点。因为未来，是存在一切可能的变数的。
1.Hive 在短期2-3年内，仍然无法被取代。大部分中大型互联网公司的sql类大数据分析job，70%以上都仍旧会跑在hive上。
2.presto ／ impala / sparksql / hive on tez . 我认为presto目前是最有可能胜出的一个。
3.spark 的地位有些尴尬。在大热之后，我不太看好他的未来。
我当然会慢慢来说我为什么会下这些结论。
首先，我在说几个我在工作当中看到的事实：
1.spark在小数据集的优势明显。 spark更容易编写类mr家族的job，引擎也更容易的帮助开发者构造了合理的dag执行步骤。 但是，在大规模数据集工作的时候，尤其是reduce的key很多的时候，spark的默认hash shuffle就完蛋了(具体请自己看spark的hash-based-shuffle原理)。所以高版本的spark也回到了mr赖以生存的sort-based-shuffle。既然在大规模数据集上工作，那么内存显然也装不下（几～几十tb）大的表数据，所以spark在大数据上，几乎没发代替hive。hive是稳如狗，spark经常有莫名其妙的问题。
2.小数据集上spark 和 presto／impala类的对比。首先，我做个假设，即大部分公司85％+的数据分析工作，仍然是sql based的。那么在这个前提下，我来谈一谈spark和 presto/impala的不同。 既然是在小数据集，那么我们假设worker节点有足够的内存，能容纳整个sql查询背后的数据表。那么查询的［速度／稳定性］（这玩意类似篮球届的 [ 助攻／失误] 比）， 就成为了最关键的指标。 spark的硬伤，就在于在spark官方推荐的几种部署方式中，仍然需要每次动态的启动spark-submit制定数量&内存大小的executor。 而presto/impala是使用常驻进程的方式。在期望值为秒级别返回的小数据集查询中，这是spark的硬伤。
3.兼容hive，是另一个最重要的点。兼容hive的好处，我就不做过多的解释了。网上经常有很多公司发的《sparksql兼容hive在xx公司的各种挑战》，一堆一堆的技术blog，我想说这些是你们该干的事情么？ 你们的兼容率,在spark1.8上，从50%做到了70%，在spark2.1呢？ 你们有能力把你们做的这些事情推进到spark社区，并merge进去么？ 你们投入在这上面的人月，用presto是不是直接就work了？ 大多数人在搞这个的人，我想心中都有自己的小算盘把。 那么diss完了spark-sql，回到presto/impala。
presto: 目前没有明显的硬伤，算是中规中矩的产品，兼容hive最好，速度不慢，多租户，资源控制做的相对很好。没有不支持的主流存储类型。 我认为这背后的一切，都是因为facebook是游戏账号转让平台幕后的推手。facebook是一家自己有大数据的公司。自己家用的产品，自己先production-ready，才好意思拿出来。那么系统的设计者，就不是赵高在做纸上谈兵，而是实实际际的考虑到了 sql on hadoop的实际痛点。
impala: 最大的优势就是超级快。缓存metastore的数据，缓存hdfs block位置的数据，缓存一切能缓存的东西。 这很好，但是，这些信息的变更也是很频繁的。采用太多缓存的结果是很多查询因为缓存信息的失效而直接fail了。 而且impala是大数据发行商cloudera推出的sql on hadoop，他为了支持自家的parquet存储结构，官方竟然选择不支持orcfile这种在hive里很常用的存储结构 ［我们组的兄弟自己写了一个支持orcfile的patch，马上推给impala社区，司。 马昭之心，马上便知］。这就是cloudera的短视，和不接地气。在sql on hadoop的市场格局还没有彻底形成之前，在cloudera manager本身都没有上市，没有占据大多数大型公司的hadoop部署管理工具的前提下，居然就开始想护犊子，开始搞保护主义了， 真的是格局太小了。 同理hive on tez是hortonworks维护的sql on hadoop产品， 就你那点可怜的文档，你是想搞开源呢？还是遮遮掩掩怕大家看到你没有实力的代码？
所以，我个人比较看好presto. 希望presto可以吸收impala上一些设计好的点。 在2-3年内统一这个sql on hadoop的市场。 未来待内存的价格进一步走低后，我们的“小数据集”，就可以变的越来越大了，那时候，hive的sql，也才更有可能会越来越多的跑在sql on hadoop上了。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
spark的部分，我忘记提编程范式。在shuffle的处理啊，内存管理啊，我认为在当下21世纪的今天，不会存在多大的技术gap，即一个公司一拨人的实现，可以2x 3x的秒杀另一个公司的产品。因为技术的理论基础是差不多的。 那么其不同，更多的表现在其他的架构点上。
presto&impala是纯sql-based的，而spark最开始是rdd based，是要用scala编程的,要写lambda表达式。我是个程序员，我很尊重lambda表达式，我尊重函数式编程。但我认为工程上，函数式编程是会阻碍这项技术的发展的。 lambda不好打断点debug，也比过程式更难以理解一些。 一个公司真正创造价值的那几十个，几百个大数据job，是要更容易debug，更容易做长期维护来的好呢，还是在写的时候为了快一些编程更好呢？ 而且，写起来最快的，最容易不出逻辑错误，最容易懂的数据分析ddl语言，是sql啊。 所以到了今年，spark社区全面转向了dateframe ,dateset, sparksql. 这玩意很类似 javaEE时代的hibernate，是一个大数据时代的orm框架.这可以看出spark社区在为了code based big-data job在努力。 但正如前面所说，我不知道spark社区为何不在兼容hive这条路，把hivesql兼容性支持的更好些，反而是去把重心放在dateframe ,dataset 上。 这就好比hibernate 不去做好怎么兼容mysql的sql，而是把重心放在hibernate自己的hql和creteria的api设计上。 这真有点kind of funny，想一统天下做sql层的入口，想革了hive 的命，最后捡了芝麻，丢了西瓜。
