1、Spark SQL 概述：Spark SQL 的发展历史、核心优势、与 Hive 的对比
1.1 从 Shark 到 Spark SQL：一段不得不说的历史
说起 Spark SQL，得先聊聊它的前身——Shark。2012 年左右，Hive 还是大数据 SQL 查询的事实标准。但 Hive 有个硬伤：慢。它基于 MapReduce，每次查询都要落盘，延迟高得让人抓狂。
我记得当时有个项目，每天跑 Hive 做报表，一个简单的聚合查询要等十几分钟。业务方催得急，我们只能干瞪眼。后来 Spark 出现了，内存计算让性能有了质的飞跃。于是 UC Berkeley 的 AMPLab 搞出了 Shark——说白了就是把 Hive 的 SQL 翻译成 Spark 的 RDD 操作。
但 Shark 有个问题：它深度依赖 Hive 的解析器和优化器，改起来非常痛苦。我参与过几个 Shark 的调优项目，每次加个新功能都要动 Hive 的源码，维护成本极高。所以 2014 年，Spark 团队决定推倒重来，开发了 Spark SQL。
Spark SQL 不再依赖 Hive 的解析器，而是自己实现了 Catalyst 优化器和 Tungsten 执行引擎。嗯，这才是真正的「自研」路线。从 Spark 1.0 到现在的 3.x 版本，Spark SQL 已经成了 Spark 生态里最核心的模块之一。
- 2012 年：Shark 诞生，基于 Hive + Spark
- 2014 年：Spark SQL 1.0 发布，引入 DataFrame
- 2015 年：Spark SQL 1.3 引入 Dataset API
- 2016 年：Spark 2.0 统一了 DataFrame 和 Dataset
- 2020 年至今：持续优化，支持 ANSI SQL、动态分区裁剪等
1.2 Spark SQL 的核心优势：凭什么选它？
你可能会问：市面上 SQL-on-Hadoop 的引擎那么多，为什么偏偏选 Spark SQL？我个人的经验是，它有几个别人学不来的优势。
1.2.1 统一的数据处理平台
Spark SQL 不只是个 SQL 引擎。它把批处理、流处理、机器学习、图计算全部统一在一个框架里。我在做实时数仓项目时，用 Spark Structured Streaming 做实时 ETL，然后用 Spark SQL 做 Ad-hoc 查询，一套代码搞定。这种「一个平台打天下」的感觉，真的很爽。
1.2.2 极致的性能优化
Catalyst 优化器和 Tungsten 执行引擎是 Spark SQL 的两大杀器。Catalyst 会做逻辑优化（比如谓词下推、列裁剪）和物理优化（比如选择 Broadcast Hash Join 还是 Sort Merge Join）。Tungsten 则通过代码生成和内存管理，把执行效率拉到极致。
我曾经对比过同样的查询，Spark SQL 比 Hive 快了 5-10 倍。当然，这不是绝对的，但大部分场景下 Spark SQL 确实更胜一筹。
1.2.3 丰富的 API 支持
Spark SQL 提供了三种 API：SQL、DataFrame、Dataset。你可以用 SQL 写查询，也可以用 Scala/Java/Python 写 DataFrame 操作。我个人习惯用 SQL 做快速探索，用 DataFrame 做复杂 ETL。灵活度非常高。
1.3 Spark SQL vs Hive：一场没有硝烟的战争
很多人问我：有了 Spark SQL，Hive 是不是该淘汰了？我的回答是：看场景。下面这张表是我在实际项目中总结的对比。
| 对比维度 | Spark SQL | Hive |
|---|---|---|
| 执行引擎 | Spark（内存计算） | MapReduce / Tez（磁盘计算） |
| 查询速度 | 快（内存迭代） | 慢（磁盘落盘） |
| SQL 兼容性 | ANSI SQL 大部分支持 | HiveQL（类 SQL） |
| ACID 事务 | 有限支持（Delta Lake 等） | 原生支持（Hive ACID） |
| 数据规模 | 适合 TB-PB 级 | 适合 PB 级以上（更稳定） |
| 资源消耗 | 高（内存需求大） | 低（磁盘为主） |
| 生态集成 | Spark 全家桶 | Hadoop 生态 |
1.3.1 什么时候选 Spark SQL？
- 需要快速交互式查询，比如 BI 报表、Ad-hoc 分析
- 要做复杂的多阶段计算，比如迭代算法、图计算
- 团队已经用了 Spark 做 ETL，不想引入新引擎
1.3.2 什么时候选 Hive？
- 数据量极大（PB 级以上），且对延迟不敏感
- 需要强 ACID 事务支持，比如金融场景
- 现有 Hadoop 集群资源有限，内存不足
1.4 我的个人建议
如果你是新项目，我建议直接上 Spark SQL。原因很简单：生态好、性能强、社区活跃。但如果你维护的是老系统，别急着迁移。先把 Hive 和 Spark SQL 混用，慢慢过渡。
我记得有一次，一个客户非要我们一个月内把所有 Hive 任务改成 Spark SQL。结果呢？改到一半发现有些 UDF 不兼容，回滚都来不及。所以，渐进式迁移才是王道。
最后说一句：Spark SQL 和 Hive 不是非此即彼的关系。很多大厂的做法是：用 Hive 做离线批处理，用 Spark SQL 做实时或近实时查询。两者互补，效果更好。