1.Hive底层原理：explain执行计划详解
2.Hive最终都会转化成什么程序来执行？
3.7.11、Hive 元数据表结构详解
4.Hive常用算子实现原理简述--MapReduce版

Hive底层原理：explain执行计划详解

       理解 Hive 中的 EXPLAIN 命令对于优化查询和理解底层逻辑至关重要。EXPLAIN 命令能展示一个查询的执行计划，对于调优、排查数据倾斜等任务很有帮助。

       使用语法为：`EXPLAIN [参数] 查询语句`。赞助源码常见参数有但不限于：

       查看一个 Hive 查询转换为的执行计划，包含由一个或多个 stage 组成的序列，这些 stage 可以是 MapReduce、元数据存储或文件系统操作。

       执行计划由两部分组成：stage dependencies 和 stage plan。stage dependencies 展示了查询中各个 stage 之间的依赖关系。stage plan 展示了每个 stage 的执行流程，如 MapReduce 的执行计划分为多个操作，包括：

       Select Operator：选取操作，例如：GROUP BY、JOIN、商城模式源码FILTER 等。

       Group By Operator：分组聚合操作。

       Reduce Output Operator：输出到 reduce 操作。

       Filter Operator：过滤操作。

       Map Join Operator：join 操作。

       File Output Operator：文件输出操作。

       Fetch Operator：客户端获取数据操作。

       了解这些操作有助于解析和优化查询。

       在生产实践中，EXPLAIN 命令能解决多种问题，如：

       1. **过滤 null 值**：确认 join 语句是否自动过滤 null 值，例如：

       `EXPLAIN SELECT * FROM table1 JOIN table2 ON table1.id = table2.id WHERE table1.id IS NOT NULL`。

       查询结果中如出现 `predicate: id is not null` 表示会过滤 null 值。

       2. **分组排序**：查看 group by 语句是否自动排序，例如：

       `EXPLAIN SELECT id FROM table GROUP BY id`。

       结果中 `keys: id (type: int)` 和 `sort order: +` 表示按 id 正序排序。ogre源码阅读

       3. **比较查询性能**：评估不同 SQL 语句的执行效率，例如：

       比较 `EXPLAIN SELECT * FROM table WHERE condition1;` 和 `EXPLAIN SELECT * FROM (SELECT * FROM table WHERE condition1) subquery;`。

       结果表明，底层会自动优化，两条语句执行效率相同。

       EXPLAIN 还能用于查看 stage 依赖情况、排查数据倾斜和调优等。通过实践和探索，用户能更深入地理解 Hive 查询执行流程和优化策略。

Hive最终都会转化成什么程序来执行？

       hive最终都会转化为mapreduce的job来运行。

       用户接口主要有三个：CLI，Client 和 WUI。其中最常用的是 Cli，Cli 启动的时候，会同时启动一个 hive 副本。Client 是社区源码授权 hive 的客户端，用户连接至 hive Server。

       在启动 Client 模式的时候，需要指出 hive Server 所在节点，并且在该节点启动 hive Server。 WUI 是通过浏览器访问 hive。

扩展资料：

       hive 并不适合那些需要高实时性的应用，例如，联机事务处理（OLTP）。hive 查询操作过程严格遵守Hadoop MapReduce 的作业执行模型，hive 将用户的hiveQL 语句通过解释器转换为MapReduce 作业提交到Hadoop 集群上。

       Hadoop 监控作业执行过程，然后返回作业执行结果给用户。hive 并非为联机事务处理而设计，hive 并不提供实时的查询和基于行级的数据更新操作。hive 的最佳使用场合是大数据集的批处理作业，例如，机架软件源码网络日志分析。

       百度百科-hive

7.、Hive 元数据表结构详解

       Hive维护一套元数据，支持通过HQL查询时将HQL翻译为MapReduce执行。本文详解Hive元数据中关键表结构及其用途，以Hive 0.为例。

       版本表（VERSION）

       该表记录Hive版本信息，包含版本ID、版本号和版本说明，确保系统正确初始化。

       版本ID：主键

       版本号：Hive版本

       版本说明：版本描述

       版本表存在问题时，Hive-Cli无法启动，若表不存在，启动Hive-Cli将报错“Table ‘hive.version’ doesn’t exist”。

       数据库元数据表（DBS、DATABASE_PARAMS）

       DBS

       存储数据库基本信息，如数据库ID、描述、HDFS路径、名称和所有者等。

       数据库ID：主键

       描述：数据库说明

       HDFS路径：数据库在HDFS的存储位置

       名称：数据库名

       所有者：数据库所有者用户名

       所有者角色：所有者角色

       DATABASE_PARAMS

       存储数据库参数，如创建用户等，关联数据库ID。

       数据库ID：主键

       参数名：指定参数

       参数值：参数值

       表和视图元数据表（TBLS、TABLE_PARAMS、TBL_PRIVS）

       TBLS

       存储表、视图、索引的基本信息，包括创建时间、数据库ID、上次访问时间、所有者、保留字段等。

       TABLE_PARAMS

       存储表/视图属性信息，关联表ID。

       TBL_PRIVS

       存储表/视图授权信息，关联表ID。

       Hive文件存储信息元数据表（SDS、SD_PARAMS、SERDES、SERDE_PARAMS）

       SDS

       保存文件存储信息，如输入格式、输出格式、是否压缩等，关联表ID。

       SD_PARAMS

       存储存储属性信息，关联存储配置ID。

       SERDES

       存储序列化类信息。

       SERDE_PARAMS

       存储序列化属性、格式信息，关联序列化类配置ID。

       表字段元数据表（COLUMNS_V2）

       存储表字段信息，如字段ID、注释、名称、类型、顺序等。

       表分区元数据表（PARTITIONS、PARTITION_KEYS、PARTITION_KEY_VALS、PARTITION_PARAMS）

       PARTITIONS

       存储表分区基本信息，如分区ID、创建时间、分区名、存储ID、表ID等。

       PARTITION_KEYS

       存储分区字段信息，如表ID、字段说明、字段名、类型、顺序等。

       PARTITION_KEY_VALS

       存储分区字段值，如分区ID、字段值、顺序等。

       PARTITION_PARAMS

       存储分区属性信息。

       其他元数据表

       包括数据库权限（DB_PRIVS）、索引（IDXS）、索引属性（INDEX_PARAMS）、表字段统计（TAB_COL_STATS）、表字段授权（TBL_COL_PRIVS）、分区统计（PART_COL_STATS）、分区字段权限（PART_COL_PRIVS）以及用户函数（FUNCS、FUNC_RU）等。

       实例操作：

       查询表ID：根据dbName和tableName查找s.CD_ID。

       查询表字段：根据CD_ID查询字段信息。

       表操作（增、改、删）：新增、修改、删除表字段。

       

参考资料：

Hive的元数据表结构详解

Hive常用算子实现原理简述--MapReduce版

       Hive中的常用算子包括distinct、join、group by、order by、distribute by、sort by、count等，这些操作符在SQL中使用起来很方便，能快速达到我们想要的效果，但是这些算子在底层是怎么实现的呢？

        order by很容易想到执行原理，在一个reduce中将所有记录按值排序即可。因此order by在数据量大的情况下执行时间非常长，容易out of memory，非特殊业务需求一般不使用。distribute by也比较明显，根据hash值将distribute的值分发到不同的reduce。sort by是小号的order by，只负责将本reducer中的值排序，达到局部有序的效果。sort by和distribute by配合使用风味更佳，二者可以合并简写为cluster by。count则更加明晰，在combiner或reducer处按相同键累加值就能得到。

        比较复杂的是distinct、join、group by，本文重点讨论这三个算子在MapReduce引擎中的大致实现原理。班门弄斧，抛砖引玉。

        map阶段，将group by后的字段组合作为key，如果group by单字段那么key就一个。将group by之后要进行的聚合操作字段作为值，如要进行count，则value是1；如要sum另一个字段，则value就是该字段。

        shuffle阶段，按照key的不同分发到不同的reducer。注意此时可能因为key分布不均匀而出现数据倾斜的问题。

        reduce阶段，将相同key的值累加或作其他需要的聚合操作，得到结果。

        对group by的过程讲解的比较清楚的是这篇文章 /info-detail-.html 图文并茂，很生动。

        实例如下图，对应语句是 select rank, isonline, count(*) from city group by rank, isonline;

        如果group by出现数据倾斜，除去替换key为随机数、提前挑出大数量级key值等通用调优方法，适用于group by的特殊方法有以下几种：

        （1）set hive.map.aggr=true，即开启map端的combiner，减少传到reducer的数据量，同时需设置参数hive.groupby.mapaggr.checkinterval 规定在 map 端进行聚合操作的条目数目。

        （2）设置mapred.reduce.tasks为较大数量，降低每个reducer处理的数据量。

        （3）set hive.groupby.skewindata=true，该参数可自动进行负载均衡。生成的查询计划会有两个 MR Job。第一个 MR Job 中，Map 的输出结果集合会随机分布到Reduce 中，每个 Reduce 做部分聚合操作，并输出结果，这样处理的结果是相同的 Group By Key有可能被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个 MR Job 再根据预处理的数据结果按照 Group ByKey 分布到 Reduce 中（这个过程可以保证相同的 Group By Key 被分布到同一个 Reduce中），最后完成最终的聚合操作。

        Hive中有两种join方式：map join和common join

        如果不显式指定map side join，或者没有达到触发自动map join的条件，那么会进行reduce端的join，即common join，这种join包含map、shuffle、reduce三个步骤。

        （1）Map阶段

        读取源表的数据，Map输出时候以Join on条件中的列为key，如果Join有多个关联键，则以这些关联键的组合作为key。Map输出的value为join之后所关心的(select或者where中需要用到的)列；同时在value中还会包含表的Tag信息，用于标明此value对应哪个表。然后按照key进行排序。

        （2）Shuffle阶段

        根据key的值进行hash,并将key/value按照hash值推送至不同的reduce中，这样确保两个表中相同的key位于同一个reduce中

        （3）Reduce阶段

        根据key的值完成join操作，期间通过Tag来识别不同表中的数据。

        以下面的SQL为例，可用下图所示过程大致表达其join原理。

        SELECT u.name, o.orderid FROM user u JOIN order o ON u.uid = o.uid;

        关联字段是uid，因此以uid为map阶段的输出key，value为选取的字段name和标记源表的tag。shuffle阶段将相同key的键值对发到一起，reduce阶段将不同源表、同一key值的记录拼接起来，可能存在一对多的情况。

        如果指定使用map join的方式，或者join的其中一张表小于某个体积（默认MB），则会使用map join来执行。具体小表有多小，由参数 hive.mapjoin.smalltable.filesize 来决定。

        Hive0.7之前，需要使用hint提示 /*+ mapjoin(table) */才会执行MapJoin,否则执行Common Join，但在0.7版本之后，默认自动会转换Map Join，由参数 hive.auto.convert.join 来控制，默认为true。

        以下图为例说明map join如何执行，该图来自 /archives///.htm ，博主是一个水平深厚又乐于分享的前辈，图片水印上也有其网址。

        yarn会启动一个Local Task（在客户端本地执行的Task）--Task A，负责扫描小表b的数据，将其转换成一个HashTable的数据结构，并写入本地的文件中，之后将该文件加载到DistributeCache中。

        接下来是Task B，该任务是一个没有Reduce的MR，启动MapTasks扫描大表a,在Map阶段，根据a的每一条记录去和DistributeCache中b表对应的HashTable关联，并直接输出结果。

        由于MapJoin没有Reduce，所以由Map直接输出结果文件，有多少个Map Task，就有多少个结果文件。

        distinct一般和group by同时出现。

        当distinct一个字段时，将group by的字段和distinct的字段组合在一起作为map输出的key，value设置为1，同时将group by的字段定为分区键，这可以确保相同group by字段的记录都分到同一个reducer，并且map的输入天然就是按照组合key排好序的。根据分区键将记录分发到reduce端后，按顺序取出组合键中的distinct字段，这时distinct字段也是排好序的。依次遍历distinct字段，每找到一个不同值，计数器就自增1，即可得到count distinct结果。例如下面的SQL语句，过程可以下图示意。

        我暂时没有理解这是怎么实现的，别人写的也没有看明白。有善良的学富五车的大佬指点一下吗？