为什么Hive的元数据需要存放在传统的关系型数据库内
一、Hive 在哪？为什么元数据放 MySQL？
1. Hive 安装在哪里（整体部署位置）
Hive只是一套客户端工具 + 服务程序，不需要集群每台机器都装，实验环境一般只装在主节点（hadoop1）一台虚拟机上。
- 它本身不存储业务数据，原始表数据全部存在 HDFS；
- 它本身不负责分布式计算，只是翻译工具，真正计算交给 YARN 调度 MapReduce；
- Hive 由几部分程序组成，都运行在 hadoop1 本地 JVM 进程：
- CLI/Beeline：你敲 HQL 命令的客户端；
- Driver（解析 / 编译 / 优化器）：把 SQL 翻译成 MR 计划；
- Metastore 元数据服务：专门管理表结构信息；
- HiveServer2：供 JDBC 远程连接的服务。
简单一句话： Hive 是单机翻译程序，跑在单台虚拟机；数据存 HDFS；元数据单独存在 MySQL；计算交给 YARN+MR。
2. 什么是 Hive 元数据（Metastore 里存什么）
元数据就是描述数据的数据，所有建表、查询必须依赖这些信息：
- 库、表、分区、分桶名称；
- 每张表字段名、字段类型、分隔符；
- 这张表真实数据在 HDFS 上的存储路径；
- 表类型（内部表 / 外部表）、存储格式（Text/ORC）、权限信息。
举例子： 执行select * from student;Hive 必须先查元数据：student 表有哪些列、数据在 HDFS 哪个文件夹，才能去 HDFS 读取文件解析内容。
3. 为什么元数据不能放 HDFS，必须放 MySQL（关系型数据库）
（1）HDFS 天生不适合元数据的读写场景
HDFS 设计目标：大批量、顺序读写大文件，高吞吐；短板是随机读写极慢、不支持实时修改、没有事务。 而元数据操作特点：
- 每次执行 HQL 都要频繁随机查询表结构；
- 建表、删分区、改字段需要实时更新、少量修改；
- 多个人同时操作 Hive，需要并发读写、数据一致。 如果元数据存在 HDFS 文件里：多人同时建表会冲突，查询表结构卡顿，修改元数据无法实时生效。
（2）MySQL（RDBMS 关系库）刚好匹配元数据需求
- 支持低延迟随机增删改查，查一张表结构毫秒级完成；
- 完整 ACID 事务：多人同时建表 / 删分区不会出现元数据错乱；
- 支持多会话并发，多个终端、Spark、Impala 可以同时读取同一套元数据；
- 结构化表格存储元信息，方便索引快速查找。
（3）补充：Hive 默认 Derby 的缺陷（为什么换成 MySQL）
Hive 自带 Derby 嵌入式数据库，只能单用户单会话，开两个 Hive 窗口直接报错锁冲突； 改用 MySQL，支持多人同时操作 Hive。
二、完整 HQL 执行流程（结合 “SQL 翻译 MR” 这条主线）
以select word,count(*) from doc group by word;举例，完整链路：
- 用户在 hadoop1 执行 HQL，交给 Hive 的 Driver 组件；
- Driver 调用 Metastore 服务，去 MySQL 查询 doc 表元数据（字段、HDFS 路径）；
- Compiler 编译器拿到元数据，做四步翻译：
- 语法解析 → 生成抽象语法树 AST；
- 语义校验（表、字段是否存在）；
- 生成逻辑执行计划，优化（分区裁剪、谓词下推）；
- 翻译成 MapReduce 物理任务计划；
- ExecutionEngine 把 MR 作业提交给 YARN ResourceManager；
- YARN 分配 Container，启动 Map/Reduce Task 读取 HDFS 上 doc 原始数据计算；
- MR 结果写入 HDFS 输出目录；
- Hive 读取 HDFS 结果，格式化打印到终端。
分层总结三者分工：
- MySQL：只存表结构元数据（小量结构化描述信息）；
- HDFS：存储业务原始数据、MR 输出结果（海量文件）；
- Hive 程序 (hadoop1)：翻译 SQL、查询元数据、提交 MR 任务；
- YARN+MapReduce：分布式实际计算。