Hive
用 SQL 查 HDFS 上的文件，把目录当成表
Hive 本身不算数据库，它是一层“翻译”：把 SQL 翻译成 MapReduce / Tez / Spark 作业，真正的数据还是躺在 HDFS 的文件里。表结构、分区这些信息存在 Metastore，所以 Spark、Flink、Trino 都能共用同一套表定义。
它解决什么问题
HDFS 上是一堆文件，业务同学只会写 SQL。要查“上个月每个城市的订单额”，总不能让大家去写 MapReduce 吧。
真实场景：典型场景：ODS 层原始日志按天分区存在 HDFS，分析师写一条 Hive SQL 就能算出各渠道的转化率，不用关心文件怎么切块。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
HiveQL
长得像 SQL，但语法和执行模型更接近批处理
类比：方言，和普通话（标准 SQL）八九不离十
看概念详情Metastore
存表名、字段、分区、文件位置，是整个数据湖的“户口本”
类比：图书馆的目录卡片，书在哪一排全靠它
看概念详情分区
按目录切分数据（如 dt=2026-10-31），查询时只扫需要的目录
类比：文件柜按年份分抽屉，找 2026 年的只开一个抽屉
看概念详情外部表
只登记元数据，删表不删数据，多个引擎共享同一份文件
类比：借阅登记，注销借书证不会烧掉书
看概念详情执行引擎
Hive 只负责解析和优化，真正跑的是 MR / Tez / Spark
类比：设计师出图纸，施工队负责盖楼
看概念详情数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
一条 Hive SQL 从提交到出结果
← 左右滑动查看完整流程图 →
客户端把一条 HiveQL 发给 HiveServer2，此时还没有任何计算发生。
提示：Hive 自己不算数据，它做的事是：查元数据 → 生成计划 → 交给执行引擎。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- SQL 门槛低，分析师不用学编程就能查 PB 级数据
- 元数据与计算分离，Spark / Trino / Flink 都能共用一套表
- 存储便宜，直接跑在 HDFS 上，数据不搬家
- 生态成熟，分区、分桶、UDF 该有的都有
- 延迟分钟级起步，做不了交互式分析
- 不适合频繁小批量写入（每次写入都会产生小文件）
- 不支持事务和行级更新（ACID 表有限支持，性能一般）
- 默认引擎调优复杂，SQL 写不好就是全表扫
常见使用场景
每个场景都配一句「为什么用它」。
离线数仓分层建模
ODS → DWD → DWS → ADS 四层建模，全部用 Hive 表承载。
为什么用它：同一份元数据能被多个引擎复用，是数仓的事实标准。
T+1 报表
每天凌晨跑批，把结果写进 ADS 层供 BI 工具查询。
为什么用它：数据量大、容忍分钟级延迟，正好匹配批处理模型。
数据湖的元数据层
Spark、Trino、Flink 通过 Hive Metastore 访问同一批表。
为什么用它：不用为每个引擎复制一份表定义，治理成本低。
同类对比
和同赛道的组件并排看，差异一目了然。
三者常常同时存在：Hive 存原始与明细、Doris 做实时报表、ClickHouse 扛大屏聚合。选型先问「查询长什么样、并发多少、要不要更新」，再比性能。
常见问题
上手第一个月最容易卡住的地方。
Q1Hive 和 MySQL 有什么本质区别？
MySQL 是数据库，负责存储 + 计算 + 事务；Hive 只是计算入口，数据在 HDFS，元数据在 Metastore。所以 Hive 没有事务、没有行级更新、延迟分钟级，它的定位是“数据仓库工具”，不是“在线业务库”。
Q2内部表和外部表怎么选？
默认建外部表。内部表删表会连数据一起删，风险太大；外部表只删元数据，数据还在 HDFS，多个引擎还能继续用。只有临时中间表才用内部表。
Q3为什么我的 Hive 查询特别慢？
九成是没走分区裁剪：where 里没有分区字段，或者用了函数包住分区字段（如 where date_format(dt)=...）导致无法下推。其次看文件格式（Text 比 Parquet 慢几倍）、小文件数量、join 是否发生数据倾斜。
Q4Hive 会被淘汰吗？
Hive 作为“计算引擎”确实被 Spark / Trino 取代得差不多了，但 Hive Metastore 反而越来越重要——Iceberg、Hudi、Paimon 都在用它做元数据。所以现在的 Hive 更多是“表定义中心”。