在 “YARN还是Mesos讨论之后(圆桌讨论: YARN & Mesos,论集群资源管理所面临的挑战 ;深度分享: Mesos资源调度与管理的深入分享与交流 )” ,CSDN Spark用户群迎来了 大数据专家—— 明略数据 梁堰波 ,就当前主流的SQL on Hadoop框架进行了深入分析,在给出了选择建议后并与用户进行了40分钟的互动与交流。
梁堰波 ,现就职于 明略数据 ,开源爱好者,Apache Hadoop & Spark contributor。北京航空航天大学计算机硕士,曾就职于Yahoo!、美团网、法国电信,具备丰富的大数据、数据挖掘和机器学习领域的项目经验。
下为讨论实录
在批处理时代,Hive一枝独秀;在实时交互式查询时代,呈现出的则是百花齐放的局面。Hive on Tez、Hive on Spark、Spark SQL等等,目前来看也没有谁干掉谁的趋势。所以大家在实际项目中就会遇到疑惑,我的项目该使用哪种SQL on Hadoop的解决方案。因此,做选择之前,相关人员首先得充分了解“后Hive时代”主要的几种SQL on Hadoop 产品。
着眼当下的SQL on Hadoop产品,最吸引人的无疑是下面几个:Hive系的Hive on Tez,也就是我们经常说的Stinger;Spark系的Spark SQL/DataFrame;Hive on Spark;Impala/Drill;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 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主要的推动者是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集群的同学都有感触。因为大多数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的影子了。
位于New York的大数据广告公司Collective内部的一个reporting service使用Impala,Spark,Parquet技术,运行在一个165的节点的YARN+Impala的集群上,有13 billion行的数据。这个是今年9月份在美国纽约举办的Impala meetup上即将的一个分享。
在国内,我们明略数据可以算是在这方面最优发言权的了。因为我们面对的客户大多是金融、政府、公安等,这些行业的特点是数据查询的实时性要求非常高,特别是查询性能,而且对SQL的支持也要比较标准,例如SQL99标准等。我们在Impala上自己动手改了一个新的引擎,让Impala可以查询RDBMS的数据。这对于很多企业内部有多重数据源的整合查询,而且要求很快查询性能,而且要求SQL标准的场景,Impala还是非常适合的。我们自己的Impala改进版,后面有机会可以和大家分享。
Impala主要的推动者是Cloudera,自从推出以来一直不温不火。Impala是一种MPP架构的执行引擎,查询速度非常快,是交互式BI查询最好的选择,即使是在并发性非常高的情况下也能保证查询延迟,所以在multi-tenant, shared clusters上表现比较好。Impala的另外一个重要的优点就是支持的SQL是在以上这些系统中是最标准的,也就是跟SQL99是最像的,所以对于传统企业来说可能是个不错的选择。Impala的主要缺点是社区不活跃,由C++开发,可维护性差,目前系统稳定性还有待提高。
像Presto,Tajo,Drill也有很多公司用。Presto是Facebook开发的,目前也得到了Teradata的支持。目前Presto的主要使用者还是互联网公司,像Facebook,Netflix等。像Presto,Tajo,Drill也有很多公司用。
这些东西都列在这了,我说下我个人的选择依据(个人意见,欢迎讨论)。
目前来看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集群。
我们做这个事情的主要初衷并不是比原来的Impala快,因为原来的就很快了。我们做这件事的目的是支持异构的RDBMS作为Impala的数据源。因为RDBMS的扩展性不够,我们是结合了Impala和RDBMS各自的优点。
问题2:刚你说到Spark做ETL的痛点,可否详细说说,除下资源预测,还有哪些?
梁堰波: Spark做ETL的痛点,除了资源预测以外,还有SQL支持。Spark的SQL支持没有Hive更全面,bug也相对较多,毕竟是比较新的项目,而且主要是从Spark社区的角度,他们也不是很重视这一方面。Spark SQL的thriftserver的发展也比较慢,因为社区可能更多资源在DataFrame那边。
问题3:我最近在做金融数据,要求达到近实时处理(interactive query)的,吞吐量1G/s,选哪种比较合适?数据量比较大,目前是在MYSQL上,读写性能达不到要求,时间序列数据。原来想在HBase上做尝试,但还没实施,股票交易类数据,并发性要求较高。
梁堰波: 那这个你可以尝试下Parquet列式存储。原来的MySQL是单机的,拿到分布式上之后,IO自然就并发了,这个是显而易见的。但是更多的提升来自像Parquet列式存储,SQL引擎的predictive pushdown,这个在目前主流的SQL on Hadoop上面都支持。这个在目前主流的SQL on Hadoop上面都支持。并发查询多的时候,Impala优势明显。
问题4:可以这样理解吗,根据应用场景不同,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这样的查询。但是这个的特点就是,他只是OALP,不能做interactive query。
1.扫码加入Spark微信讨论组2。 (注:CSDN Spark用户微信群1已满500,正在清理,后续我们会邀请2群朋友进入)
2. 加入CSDN Spark技术交流QQ群,群号:213683328。
3. CSDN高端专家微信群,采取受邀加入方式,不惧高门槛的请加微信号“zhongyineng”或扫描下方二维码,PS:带上你的BIO。