本篇对 Hive on Spark、Spark on Hive 两个概念做个澄清。
1.1 什么是 Hive on Spark？
- 定义：Hive-on-Spark 是在 Hive 上新增一种计算引擎：Spark
- 目的：借助 Spark 内存计算引擎的优势，提升 Hive 查询性能（相较于默认执行引擎 MR）
- 地位：Spark 和 Hive 原有的执行引擎 MR，Tez 平级，可互相替换
- 益处：给已经部署了 Hive 或者 Spark 的用户提供了更加灵活的选择，从而进一步提高 Hive 和 Spark 的普及率
1.2 什么是 Spark on Hive？
- 定义：没有官方的 Spark on Hive 说法，属于大家习惯性称呼。结合网上资料，将其对应为 SparkSQL 读写 Hive 表特定场景
- 目的：使 SparkSQL 能够访问 Hive 表
- 地位：SparkSQL 对 Hive 为非必须依赖，SparkSQL 可以创建自己的metastore_db，但两者结合使用为目前常态
- 益处：可以使新版 SparkSQL 访问旧的数仓表，便于 SparkSQL 推广和应用
2.1 Hive on Spark 历史
- Hive 是基于 Hadoop 平台的数据仓库，最初由 Facebook 开发
- 在经过多年发展之后，已经成为 Hadoop 事实上的SQL引擎标准
- Hive 最初的计算引擎为 MapReduce
- 受限于其自身的 Map + Reduce 计算模式，以及不够充分的内存利用，MapReduce 的性能难以得到提升
- Hortonworks 于 2013 年提出将 Tez 作为另一个计算引擎以提高 Hive 的性能
- Hortonworks 有一个死对头 Cloudera
- 2014 年，Cloudera 主导启动了 Hive on Spark。这个项目得到了 IBM，Intel 和 MapR 的支持（注意：没有 Databricks，但 Databricks 在开发过程中积极配合）
- 2015 年 1 月初，Hive-on-Spark 合并回 trunk， 并在 Hive 后续版本中发布
2.2 SparkSQL 历史
- 定位： Spark 官方 Databricks 的项目，Spark 项目本身主推的 SQL 实现
- Spark 很早就已开始对接 Hive， 2013年，发布了 Shark 项目，用以提升 Hive 查询性能
- shark 底层使用 spark 的基于内存的计算模型，从而让性能比 Hive 提升了数倍到上百倍
- 底层很多东西还是依赖于 Hive，修改了内存管理、物理计划、执行三个模块
- Shark 对于 Hive 的修改/侵入性过于庞大，导致 Hive 社区都无法接受，无法合并回社区
- 2014 年 6 月 1 日的时候，Spark 宣布不再开发 Shark，全面转向 Spark SQL 的开发
3. Hive on Spark / Spark on Hive 异同
- 相同点：
- SQL 执行层都是 Spark 引擎
- 不同点：
- SQL 解析层不同， Hive on Spark （hive compiler）， Spark on Hive （SparkSQL compiler）
- 各自的长期规划不同：
- 其中 SparkSQL 作为 Spark 生态的一员继续发展，而不再受限于 Hive，只是兼容 Hive；而 Hive on Spark 是一个 Hive 的发展计划，该计划将 Spark 作为 Hive 的底层引擎之一，也就是说，Hive 将不再受限于一个引擎，可以采用 Map-Reduce、Tez、Spark 等引擎。
4. Hive on Spark 技术实现原理
- Hive on Spark 总体的设计思路是，尽可能重用 Hive 逻辑层面的功能；从生成物理计划开始，提供一整套针对 Spark 的实现
- 尽可能减少对 Hive 原有代码的修改
- 对于选择 Spark 的用户，应使其能够自动的获取 Hive 现有的和未来新增的功能
- 尽可能降低维护成本，保持对 Spark 依赖的松耦合
- 引入 SparkCompiler，与 MapReduceCompiler 和 TezCompiler 平行，将 Operator Tree 转换为 Task Tree
- SparkWork 对应 DAG 执行计划，SparkTask 对应 Job 任务
- 最后通过 foreachAsync 将 SparkTask 提交执行。