在银行的大数据平台，Hive 元数据和 HiveQL 语法是事实标准的数仓语言层，但底层执行引擎经历了从 MapReduce 到 Tez、再到 Spark 的持续迭代。当前主流选择集中在 Hive on Spark 和原生 Spark SQL 两条路线。
银行场景下的计算特征
银行大数据平台处理的典型负载包括：
- 批处理报表：每日凌晨跑批生成T+1监管报表，涉及数十张亿级表的多层Join和聚合
- 客户画像标签计算：基于交易流水、资产变动、信用卡消费等数据生成数万维度客户标签
- 反洗钱与风控模型：特征工程阶段需要回溯全量历史交易做时间窗口聚合
- 数据治理与稽核：全表扫描检测异常值、空值率、重复率
Hive on Spark：平滑迁移的保守方案
Hive on Spark 的设计思路是在保持 HiveQL 语法和 Hive Metastore 不变的前提下，将计算引擎从 MapReduce 切换成 Spark。
优势： 1. 语法100%兼容：对业务分析师和ETL工程师而言，写法和原来完全一致 2. 元数据无缝复用：Hive Metastore 中管理的几万张表分区信息无需迁移 3. 降低迁移风险：对已有 Hive UDF、自定义 SerDe 友好
性能陷阱： - Shuffle 策略差异：涉及倾斜Join时，Hive on Spark 不会自动触发 Spark AQE 自动倾斜处理 - 广播Join阈值：默认10MB，银行里的维表通常几十MB到上百MB，不会广播
-- Hive on Spark手动指定Broadcast Hint
SELECT /*+ BROADCAST(a) */ *
FROM big_txn_table t
JOIN dim_cust_info a ON t.cust_id = a.cust_id;
原生 Spark SQL：追求极致性能的新路线
原生 Spark SQL 绕过了 Hive 的执行层，由 Catalyst 优化器直接从 SQL/ DataFrame 生成物理计划。
核心优势： 1. AQE自适应查询执行：动态调整 Join 策略、减少 Shuffle 分区数、自动处理数据倾斜 2. 向量化执行：对于 ORC/Parquet 格式，按 batch 处理数据，性能提升3-5倍 3. DataFrame API 的灵活性：复杂风控特征工程比纯 SQL 更优雅
挑战： - HiveQL 语法差异：原生 Spark SQL 解析器不完全兼容 Hive 方言 - 权限集成：Ranger/Sentry 对 Hive Server2 的审计和行级列级权限管理更完善
推荐架构：双轨并行，逐步迁移
| 层级 | 推荐引擎 | 原因 |
|---|---|---|
| ODS层数据摄入 | Hive on Spark | 兼容原有 Flume/Kafka 到 Hive 链路 |
| DWD数据清洗 | Spark SQL | DataFrame API更可控，AQE处理数据波动 |
| DWS汇总聚合 | Spark SQL | 大表 Join + Group By，AQE收益最大 |
| 即席查询层 | Hive on Spark/Impala | 分析师熟悉HiveQL，BI工具原生对接 |
| 监管报送SQL | Hive on Spark | 存量脚本不动，风险最低 |
动态分区裁剪
原生 Spark SQL 在 3.0 之后支持 Dynamic Partition Pruning（DPP）：当大表 Join 小表时，会自动将小表的过滤条件下推到大表的分区扫描阶段。在 PB 级交易流水表上，实测速度提升10倍以上。
不要盲目追求性能而放弃生态。在金融行业，稳定压倒一切。