一、Hive 在哪？为什么元数据放 MySQL？

1. Hive 安装在哪里（整体部署位置）

Hive只是一套客户端工具 + 服务程序，不需要集群每台机器都装，实验环境一般只装在主节点（hadoop1）一台虚拟机上。

• 它本身不存储业务数据，原始表数据全部存在 HDFS；
• 它本身不负责分布式计算，只是翻译工具，真正计算交给 YARN 调度 MapReduce；
• Hive 由几部分程序组成，都运行在 hadoop1 本地 JVM 进程：
  1. CLI/Beeline：你敲 HQL 命令的客户端；
  2. Driver（解析 / 编译 / 优化器）：把 SQL 翻译成 MR 计划；
  3. Metastore 元数据服务：专门管理表结构信息；
  4. HiveServer2：供 JDBC 远程连接的服务。

简单一句话： Hive 是单机翻译程序，跑在单台虚拟机；数据存 HDFS；元数据单独存在 MySQL；计算交给 YARN+MR。

2. 什么是 Hive 元数据（Metastore 里存什么）

元数据就是描述数据的数据，所有建表、查询必须依赖这些信息：

1. 库、表、分区、分桶名称；
2. 每张表字段名、字段类型、分隔符；
3. 这张表真实数据在 HDFS 上的存储路径；
4. 表类型（内部表 / 外部表）、存储格式（Text/ORC）、权限信息。

举例子： 执行select * from student;Hive 必须先查元数据：student 表有哪些列、数据在 HDFS 哪个文件夹，才能去 HDFS 读取文件解析内容。

3. 为什么元数据不能放 HDFS，必须放 MySQL（关系型数据库）

（1）HDFS 天生不适合元数据的读写场景

HDFS 设计目标：大批量、顺序读写大文件，高吞吐；短板是随机读写极慢、不支持实时修改、没有事务。 而元数据操作特点：

• 每次执行 HQL 都要频繁随机查询表结构；
• 建表、删分区、改字段需要实时更新、少量修改；
• 多个人同时操作 Hive，需要并发读写、数据一致。 如果元数据存在 HDFS 文件里：多人同时建表会冲突，查询表结构卡顿，修改元数据无法实时生效。

（2）MySQL（RDBMS 关系库）刚好匹配元数据需求

1. 支持低延迟随机增删改查，查一张表结构毫秒级完成；
2. 完整 ACID 事务：多人同时建表 / 删分区不会出现元数据错乱；
3. 支持多会话并发，多个终端、Spark、Impala 可以同时读取同一套元数据；
4. 结构化表格存储元信息，方便索引快速查找。

（3）补充：Hive 默认 Derby 的缺陷（为什么换成 MySQL）

Hive 自带 Derby 嵌入式数据库，只能单用户单会话，开两个 Hive 窗口直接报错锁冲突； 改用 MySQL，支持多人同时操作 Hive。

二、完整 HQL 执行流程（结合 “SQL 翻译 MR” 这条主线）

以select word,count(*) from doc group by word;举例，完整链路：

1. 用户在 hadoop1 执行 HQL，交给 Hive 的 Driver 组件；
2. Driver 调用 Metastore 服务，去 MySQL 查询 doc 表元数据（字段、HDFS 路径）；
3. Compiler 编译器拿到元数据，做四步翻译：
   • 语法解析 → 生成抽象语法树 AST；
   • 语义校验（表、字段是否存在）；
   • 生成逻辑执行计划，优化（分区裁剪、谓词下推）；
   • 翻译成 MapReduce 物理任务计划；
4. ExecutionEngine 把 MR 作业提交给 YARN ResourceManager；
5. YARN 分配 Container，启动 Map/Reduce Task 读取 HDFS 上 doc 原始数据计算；
6. MR 结果写入 HDFS 输出目录；
7. Hive 读取 HDFS 结果，格式化打印到终端。

分层总结三者分工：

1. MySQL：只存表结构元数据（小量结构化描述信息）；
2. HDFS：存储业务原始数据、MR 输出结果（海量文件）；
3. Hive 程序 (hadoop1)：翻译 SQL、查询元数据、提交 MR 任务；
4. YARN+MapReduce：分布式实际计算。