cdh spark
- 作者: 沈温柔阿
- 来源: 51数据库
- 2020-09-25
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要简洁得多。
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要简洁得多。
shark为了实现hive兼容，在hql方面重用了hive中hql的解析、逻辑执行计划翻译、执行计划优化等逻辑，可以近似认为仅将物理执行计划从mr作业替换成了spark作业（辅以内存列式存储等各种和hive关系不大的优化）
推荐阅读
