Spark SQL 和 Shark 在架构上有哪些区别?将来会合并吗

如题所述

  Shark为了实现Hive兼容,在HQL方面重用了Hive中HQL的解析、逻辑执行计划翻译、执行计划优化等逻辑,可以近似认为仅将物理执行计划从MR作业替换成了Spark作业(辅以内存列式存储等各种和Hive关系不大的优化);同时还依赖Hive Metastore和Hive SerDe(用于兼容现有的各种Hive存储格式)。这一策略导致了两个问题,第一是执行计划优化完全依赖于Hive,不方便添加新的优化策略;二是因为MR是进程级并行,写代码的时候不是很注意线程安全问题,导致Shark不得不使用另外一套独立维护的打了补丁的Hive源码分支(至于为何相关修改没有合并到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作为引擎,不仅仅是查询优化方面。

  此外,除了兼容HQL、加速现有Hive数据的查询分析以外,Spark SQL还支持直接对原生RDD对象进行关系查询。同时,除了HQL以外,Spark SQL还内建了一个精简的SQL parser,以及一套Scala DSL。也就是说,如果只是使用Spark SQL内建的SQL方言或Scala DSL对原生RDD对象进行关系查询,用户在开发Spark应用时完全不需要依赖Hive的任何东西。

  能够对原生RDD对象进行关系查询,个人认为大大降低了用户门槛。一方面当然是因为熟悉SQL的人比熟悉Spark API的人多,另一方面是因为Spark SQL之下有Catalyst驱动的查询计划优化引擎。虽然在很多方面Spark的性能完爆Hadoop MapReduce好几条街,但Spark的运行时模型也比MapReduce复杂不少,使得Spark应用的性能调优比较tricky。虽然从代码量上来看,Spark应用往往是对等的MR应用的好几分之一,但裸用Spark API开发高效Spark应用还是需要花些心思的。这就体现出Spark SQL的优势了:即便用户写出的查询不那么高效,Catalyst也可以自动应用一系列常见优化策略。
温馨提示:答案为网友推荐,仅供参考
相似回答