SQL on Haoop/Spark

SQL on Haoop/Spark

            在批处理时代，Hive一枝独秀；在实时交互式查询时代，呈现出的则是百花齐放的局面。Hive on Tez、Hive on Spark、Spark SQL等等，目前来看也没有谁干掉谁的趋势。 所以大家在实际项目中就会遇到疑惑，我的项目该使用哪种SQL on Hadoop的解决方案。先说说“后Hive时代”主要的几种SQL on Hadoop 产品

主要有1，Hive系的Hive on Tez，也就是我们经常说的Stinger。2，Spark系的Spark SQL/DataFrame。3，Hive on Spark。4, Impala/Drill。5, Presto
Hive/Tez/Stinger目前的主要推动者是hortonworks和Yahoo!。
        刚刚结束的2015 Hadoop Summit(San Jose)上，Yahoo分享了他们目前生产环境中Hive on Tez的一些情况。显示和Hive 0.10(RCFile)相比，目前的Hive on Tez在1TB的数据量查询的加速比平均为6.2倍。目前的Hive on Tez已经是production-ready。Tez这个执行引擎和Spark比较类似，原来的MR只能执行Map和Reduce两种操作，现在的Tez可以把Job解析成DAG来执行。除此之外还有一些进一步优化Hive执行效率的工作，例如Vectorized Execution和ORCFile等。Dropbox也透露他们的Hive集群下一步的升级目标就是Hive on Tez。Yahoo！内部的很多集群已经升级为默认的Tez作为Hive的执行引擎了。

另外一个和Hive on Tez类似的是Hive on Spark， Hive on Spark目前的主要推动者是Cloudera，可以认为是Hive社区这边搞的”Hive on Spark”。刚刚release了第一个使用版本，目前不能用于生产环境。Hive on Spark既能利用到现在广泛使用的Hive的前端，又能利用到广泛使用的Spark作为后端执行引擎。对于现在既部署了Hive，又部署了Spark的公司来说，节省了运维成本。现在看起来Spark很火，大家都往Spark上靠。但是我们在实际项目应用中还得考虑这个东西是不是适合。

 对于上面提到的Hive on Tez和Hive on Spark两种系统都具备的优点是：

1，现存的Hive jobs可以透明、无缝迁移到Hive on ***平台，可以利用Hive现有的ODBC/JDBC，metastore, hiveserver2, UDF，auditing, authorization, monitoring系统，不需要做任何更改和测试，迁移成本低。

2，无论后端执行引擎是MapReduce也好，Tez也好，Spark也好，整个Hive SQL解析、生成执行计划、执行计划优化的过程都是非常类似的。而且大部分公司都积累了一定的Hive运维和使用经验，那么对于bug调试、性能调优等环节会比较熟悉，降低了运维成本。

 因为目前大多数跟大数据有关的公司和team都部署了Hadoop和Hive，而且都有一定的这方面的运维和使用经验。所以说Hive on Tez和Hive on Spark在这方面优势明显，使得我们的项目风险降低不少。

       下面说说现在比较火的Spark SQL

        Spark SQL主要的推动者是Databricks。提到Spark SQL不得不提的就是Shark。Shark可以理解为Spark社区这边搞的一个”Hive on Spark”，把Hive的物理执行计划使用Spark计算引擎去执行。这里面会有一些问题，Hive社区那边没有把物理执行计划到执行引擎这个步骤抽象出公共API，所以Spark社区这边要自己维护一个Hive的分支，而且Hive的设计和发展不太会考虑到如何优化Spark的Job。但是前面提到的Hive on Spark却是和Hive一起发布的，是由Hive社区控制的。所以后来Spark社区就停止了Shark的开发转向Spark SQL（“坑了”一部分当时信任Shark的人）。Spark SQL是把SQL解析成RDD的transformation和action，而且通过catalyst可以自由、灵活的选择最优执行方案。对数据库有深入研究的人就会知道，SQL执行计划的优化是一个非常重要的环节，Spark SQL在这方面的优势非常明显，提供了一个非常灵活、可扩展的架构。但是Spark SQL是基于内存的，元数据放在内存里面，不适合作为数据仓库的一部分来使用。所以有了Spark SQL的HiveContext，就是兼容Hive的Spark SQL。它支持HiveQL, Hive Metastore, Hive SerDes and Hive UDFs以及JDBC driver。这样看起来很完美，但是实际上也有一些缺点：Spark SQL依赖于Hive的一个snapshot，所以它总是比Hive的发布晚一个版本，很多Hive新的feature和bug fix它就无法包括。而且目前看Spark社区在Spark的thriftserver方面的投入不是很大，所以感觉它不是特别想朝着这个方向发展。还有一个重要的缺点就是Spark SQL目前还不能通过分析SQL来预测这个查询需要多少资源从而申请对应的资源，所以在共享集群上无法高效地分配资源和调度任务。这里面提到的Spark SQL目前还不能通过分析SQL来预测这个查询需要多少资源从而申请对应的资源的问题，我想很多运维Hadoop和Hive集群的同学都有感触。这里面提到的Spark SQL目前还不能通过分析SQL来预测这个查询需要多少资源从而申请对应的资源的问题，我想很多运维Hadoop和Hive集群的同学都有感触， 因为大多数ETL都是晚上跑，如果资源估计不合理，第二天早晨老板晨会的时候看不到数。那么大家的KPI就。。。所以这个也是Hive的优势，目前Spark SQL的成熟度也不如Hive高。所以如果大家现有的ETL等服务，在Hive上跑的还不错，那就先跑着，先别折腾新东西，而且是Hive社区也在不断发展进步。性能各方面也在提升。

       特别是目前Spark社区把Spark SQL朝向DataFrame发展，目标是提供一个类似R或者Pandas的接口，把这个作为主要的发展方向。DataFrame这个功能使得Spark成为机器学习和数据科学领域不可或缺的一个组件，但是在数据仓库（ETL，交互式分析，BI查询）领域感觉已经不打算作为他们主要的发展目标了。Spark SQL和DataFrame特别适合数据挖掘和机器学习前面的数据准备的工作。

        大家做过机器学习的同学都知道，算法只是其中的一小部分工作。而且大部分人是不会自己写新的算法的，更多的是用别人的算法。所以主要的工作量就集中在数据预处理上。现在Spark里面的MLlib提供了一个新的机器学习pipeline 叫ML。ML是完全基于DataFrame来实现的了，完全看不到RDD的影子了。

        下面说说一直很低调的Impala。

         Impala在国外还是有一定的市场空间的，位于New York的大数据广告公司Collective内部的一个reporting service使用Impala，Spark，Parquet技术，运行在一个165的节点的YARN+Impala的集群上，有13 billion行的数据。这个是今年9月份在美国纽约举办的Impala meetup上即将的一个分享，在国内，明略数据可以算是在这方面最优发言权的了。因为我们面对的客户大多是金融、政府、公安等，这些行业的特点是数据查询的实时性要求非常高，特别是查询性能，而且对SQL的支持也要比较标准，例如SQL99标准等。我们在Impala上自己动手改了一个新的引擎，让Impala可以查询RDBMS的数据。这对于很多企业内部有多重数据源的整合查询，而且要求很快查询性能，而且要求SQL标准的场景，Impala还是非常适合的。

        Impala主要的推动者是Cloudera，自从推出以来一直不温不火。Impala是一种MPP架构的执行引擎，查询速度非常快，是交互式BI查询最好的选择，即使是在并发性非常高的情况下也能保证查询延迟，所以在multi-tenant, shared clusters上表现比较好。Impala的另外一个重要的优点就是支持的SQL是在以上这些系统中是最标准的，也就是跟SQL99是最像的，所以对于传统企业来说可能是个不错的选择。Impala的主要缺点是社区不活跃，由C++开发，可维护性差，目前系统稳定性还有待提高。

        说完了上面这四种，基本上算是最主流的了~像Presto，Tajo，Drill也有很多公司用。Presto是Facebook开发的，目前也得到了Teradata的支持。目前Presto的主要使用者还是互联网公司，像Facebook，Netflix等。

        目前来看Hive依然是批处理/ETL 类应用的首选。Hive on Spark能够降低Hive的延迟，但是还是达不到交互式BI查询的需求。目前交互式BI查询最好的选择是Impala。Spark SQL/DataFrame是Spark用户使用SQL或者DataFrame API构建Spark pipeline的一种选择，并不是一个通用的支持交互式查询的引擎，更多的会用在基于Spark的机器学习任务的数据处理和准备的环节。

        最后，大家选择SQL on Hadoop产品，主要的目的可以说是构建大数据时代的数据仓库。

        我推荐大家看一本书，当然这本书现在还没有发表，大家可以等到他发表的时候再看。http://www.manning.com/ramachandran/。

【问题1：明略目前impala最大的规模多少？性能如何？谢谢】因为我们的客户都是政府、金融方面的，所以我们最大的Impala集群今天我不能透露有多大，但是性能上我们可以透露就是比原生的要快1-2倍。当然这个主要的性能优化点是我们接了RDBMS集群。

【问题2」@百事可乐 刚你说到Spark做ETL的痛点，可否详细说说，除下资源预测，还有哪些？】Spark做ETL的痛点，除了资源预测以外，还有SQL支持。Spark的SQL支持没有Hive更全面，bug也相对较多，毕竟是比较新的项目，而且主要是从Spark社区的角度，他们也不是很重视这一方面。毕竟是比较新的项目，而且主要是从Spark社区的角度，他们也不是很重视这一方面。

 【问题2」@百事可乐 刚你说到Spark做ETL的痛点，可否详细说说，除下资源预测，还有哪些？】Spark SQL的thriftserver的发展也比较慢，因为社区可能更多资源在DataFrame那边。

【问题3我最近在做金融数据，要求达到近实时处理（interactive query）的，吞吐量1G/s，选哪种比较合适？数据量比较大，目前是在MYSQL上，读写性能达不到要求，时间序列数据】那这个你可以尝试下Parquet列式存储。原来的MySQL是单机的，拿到分布式上之后，IO自然就并发了，这个是显而易见的。但是更多的提升来自像Parquet列式存储，SQL引擎的predictive pushdown，这个在目前主流的SQL on Hadoop上面都支持。这个在目前主流的SQL on Hadoop上面都支持。【原来想在HBase上做尝试，但还没实施，股票交易类数据，并发性要求较高】并发查询多的时候，Impala优势明显。

【[问题4] via qq群 ：可以这样理解吗，根据应用场景不同，sql on hadoop架构还是混合模型的，就是多重组件同时存在？】是的。至少我认为是这样的。其实还是用最合适的工具解决对应的问题是最好的。例如Spark最大的优势是迭代式机器学习，例如Logistic Regression，性能提升非常大。但是像NaiveBayes这样的，提升就没那么明显。SQL on Hadoop也是这样的，如果你的业务用Hive跑的好好的，没啥问题，千万别瞎折腾。数据也是分层了，底层的ETL和上层的interactive query或者OLAP，所查询的数据量是不一样的，性能要求也不一样，所以选择不同的工具也是正常的。

【[问题5] apache phoenix进入cloudera lab能说明什么吗？】这个其实cloudera的人回答更好，我说下我的观点：说明phoenix是个备选，还是要看具体的业务类型。Phoenix适合那种对HBase有很多技术积累的公司。而且phoenix一个重要的特点就是数据不是immutable的了，所以对于很多数据治理的场景是有很大帮助的。

【[问题6]对于交互式BI查询场景，把一些中间层数据用phoenix存起来，再提供查询，@百事可乐 怎么看这种用法？】交互式BI查询，很多数据可以通过预先计算，然后存起来。这个前提就是你的很多维度 、 组合可以预先计算，而且存储空间够用。其实这种场景你不用phoenix，直接用HBase也行。当然phoenix更方便。因为这种类似OLAP的查询，基本上不会有太多的JOIN。大部分是select from where group by这样的查询【Cube?】对，就是CUBE。但是这个的特点就是，他只是OALP，不能做interactive query。

【问题7：请问下之前您提到的spark sql的不足（基于代价的优化？），sparksql 的解析引擎可扩展性好，那么社区或者公司有没有在研究？】我先告诉你答案，就是这个基于代价的预估据我了解目前还没有研究。【嗯 确实join不多 用phoenix方便一些 感谢】因为Spark SQL的特点导致的。为什么呢？你可以想一想，如果我要预估Spark SQL这个SQL查询需要多少数据，那么就需要元数据，就需要对应的统计数据。这些在Hive里面是存储在metastore里面的。Spark SQL的SQLContext的元数据是放到内存里面的。HiveContext的元数据是放到metastore里面的，但是跟Hive要兼容。所以HiveContext这边要一直追着Hive社区走。这也是我前面提到的一点，为啥Hive on Spark比Spark SQL的HiveContext更容易发展和维护的原因。这个feature很难搞，除非他自己搞一套。【看来不是技术问题 而是一个协作的问题嘛】对，当然因为协作的问题，导致做这件事的技术成本增加很多。
【[问题8 ]Tez稳定吗】我前面已经提到了，Tez已经是production ready的东西了，所以稳定性还不错。当然，在超大数据量下，肯定不如MR引擎。超大数据量的稳定性Hive是最好的。