企业官网建设流程全解析

做大数据的人，几乎没有人能绕过Hive和HQL。哪怕现在Spark、Flink已经成了流批处理的主力，绝大多数离线数仓的底层表结构、数据加工、指标计算，仍然跑在成千上万条HQL上。我最早接触Hive时，以为HQL就是SQL，拿着MySQL那套习惯去写，结果在分区认知、文件存储、执行计划这些地方踩了不少坑。这篇东西就是把我对HQL语言特性的理解从头捋了一遍，适合刚入行的大数据开发、分析师，以及做数据仓库想系统了解HQL能力边界的人。

1. HQL不是SQL：先弄清它的定位和使用边界

1.1 从Hive说起：HQL到底解决什么问题

Hive最初的设计目标很朴素：让不熟悉Java、不熟悉MapReduce的人，也能用类似SQL的语法操作HDFS上的大规模数据。HQL的全称是Hive Query Language，它在语法层面大量借鉴了SQL标准，所以如果你会标准SQL，上手几乎不需要额外的学习成本。但它的本质不是一套数据库查询语言，而是一种翻译语言——把类SQL语句翻译成分布式计算任务，真正干活的是背后的计算引擎（早期是MapReduce，后来可以切换成Tez、Spark）。

这一点决定了HQL的定位：它不是为了替代MySQL或者Oracle，而是为了解决“单机数据库装不下、算不动”的问题。一张表几十亿行、几百个字段，存在几十台机器上，用HQL写一条聚合语句，几秒钟到几分钟出结果，这是传统关系型数据库做不到的。我见过很多新人拿SELECT和JOIN在Hive里跑单表几百万行的数据，其实用MySQL更合适——HQL适合的是GB到PB级别的数据规模，数据量不够大时，它的调度开销反而会拖慢速度。

1.2 HQL与标准SQL的执行路径差异

标准SQL在执行时，优化器会基于索引、统计信息生成执行计划，数据存在本机的表结构里，所有操作都在数据库引擎内部完成。HQL不一样，它的完整执行路径是：SQL语句 → 解析器（Parser） → 语法分析（Analyzer）→ 逻辑计划（Logical Plan）→ 物理计划（Physical Plan）→ 执行引擎 → 最终任务。每一步都可能涉及HDFS文件扫描、网络传输、数据序列化和反序列化。

这意味着几个重要的实际结论：

• HQL的查询延迟远高于传统SQL。没有索引概念，它是全表扫描优先，绝大多数查询都是“读就完了”，所以查询速度和文件大小、存储格式高度相关。
• HQL对底层引擎的适配决定了写法偏好。很多在MySQL里没问题的写法，在HQL里会遇到性能坑。比如笛卡尔积关联，MySQL可能还勉强能跑，HQL里直接会导致数据膨胀到内存溢出。
• HQL有自己独特的操作语义。比如它不依赖索引做关联，而是通过Map端和Reduce端的数据分发来实现JOIN；它没有真正的事务能力，ACID支持从Hive 0.14才开始引入且一直不完整。

1.3 哪些场景适合HQL，哪些不适合

适合的场景：离线批处理、数据仓库分层建设（ODS/DWD/DWS/ADS）、全量或大批量数据清洗、统计分析（PV/UV、TopN、漏斗）、报表指标加工等。对实时性要求不高的场景，HQL几乎是标准答案。

不适合的场景：高并发在线查询、需要毫秒级响应、需要频繁UPDATE和DELETE单行数据、需要跨行事务。如果遇到这些需求，应该考虑HBase、Doris、ClickHouse、关系型数据库，或者直接用Flink做实时计算。这个边界必须明确，很多项目的失败不是Hive不行，而是用错了地方。

2. HQL的数据组织核心：库、表、分区与分桶

2.1 建表DDL：内部表与外部表怎么选

HQL的表结构和实际数据是分离的：元数据存在Hive的Metastore里（通常是一个MySQL库），真实数据存在HDFS目录下。建表语法很接近标准SQL，但多了很多分布式生态的关键字。

CREATE EXTERNAL TABLE dwd_order_detail ( order_id STRING COMMENT '订单编号', user_id STRING COMMENT '用户ID', order_amount DECIMAL(10,2) COMMENT '订单金额', create_time TIMESTAMP COMMENT '下单时间' ) PARTITIONED BY (dt STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' STORED AS ORC LOCATION '/data/warehouse/dwd_order_detail';

内部表和外部表最核心的区别在于：DROP TABLE时，内部表连数据文件一起删掉，外部表只删元数据，HDFS上的数据文件还在。我个人的习惯是：ODS层和DWD层用外部表，因为原始数据往往要从文件系统迁移或共享；ADS层和结果表用内部表，因为数据是加工出来的，生命周期跟着表走。

建表时还有一个容易忽略的参数：ROW FORMAT和STORED AS。文本格式（TEXTFILE）虽然可读性好，但查询性能是最差的；生产环境建议用ORC或者Parquet这种列式存储，配合压缩（如Snappy、ZSTD），查询时只读需要的列，文件大小和扫描IO能减少一半以上。

2.2 分区语法：静态分区与动态分区

分区是Hive目前最重要、也最常用的数据组织方式，本质上就是把一个大表按某些字段（比如日期、省份、渠道）拆成多个目录。例如PARTITIONED BY (dt STRING)会把数据放到/data/warehouse/dwd_order_detail/dt=2024-01-01/这样的目录下，查询时通过分区字段做裁剪，只扫描对应目录，避免全表扫描。

静态分区是最直观的写法：

INSERT OVERWRITE TABLE dwd_order_detail PARTITION (dt='2024-01-01') SELECT order_id, user_id, order_amount, create_time FROM ods_order_raw WHERE day = '2024-01-01';

动态分区则是按SELECT出来的字段值自动创建分区，适合一次写入多个分区：

INSERT OVERWRITE TABLE dwd_order_detail PARTITION (dt) SELECT order_id, user_id, order_amount, create_time, day AS dt FROM ods_order_raw WHERE day BETWEEN '2024-01-01' AND '2024-01-31';

动态分区有底层的数量和性能限制，Hive默认hive.exec.max.dynamic.partitions=1000，如果一次性产生几千个分区，任务会直接报错。实际开发里我通常先确认目标分区数，再考虑是否开启动态分区；如果分区数量太大（比如按天+按小时生成上万个分区），宁可先汇总统计好分区，再用静态分区逐天写入。

2.3 分桶与排序：优化JOIN和抽样的进阶手段

分桶（BUCKETING）是HQL里比分区更细粒度的文件组织方式。它通过CLUSTERED BY (字段) INTO N BUCKETS把数据按哈希值分散到N个文件中，这对随机抽样、以及桶键与关联键一致的桶表JOIN有显著效果，因为系统知道两个表桶的对应关系，不需要全量扫描，只读取匹配的桶。

CREATE TABLE user_log_bucketed ( user_id STRING, log_time TIMESTAMP, action STRING ) CLUSTERED BY (user_id) INTO 32 BUCKETS STORED AS ORC;

但我要提醒一点：分桶不是默认选项，它只在你明确知道某个高频JOIN是以这个桶键为关联键时才有价值。否则，多一层分桶只会增加写数据的复杂度，还会影响小文件治理。我这几年用分桶的场景，绝大多数都和“按用户ID抽样分析”有关，其他时候老老实实用分区表就够了。

排序在HQL里的作用是配合分桶：SORT BY保证桶内有序，ORDER BY保证全局有序但代价极高。生产中常做的方案是DISTRIBUTE BY user_id SORT BY create_time DESC，让同一个用户的数据落在同一个Reducer里，再在桶内按时间排序，这样既能控制排序代价，又能满足“每个用户最后几条”这类需求。

3. 写查询HQL：从简单查询到复杂关联的实操要点

3.1 先记住一条执行顺序

HQL的SELECT语句执行顺序和标准SQL一致，实际执行和书写顺序差别很大。完整顺序是：FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY → LIMIT。这意味着WHERE里不能用SELECT中定义的别名，GROUP BY之后才执行HAVING，ORDER BY是最后才执行的全局排序。

这条顺序的重要性在于排查问题时非常有用。我遇到过不少同事把WHERE当成最后过滤，结果在GROUP BY之前就把大量行过滤掉了，导致统计结果和预期差得很远。举个简单的坑：想过滤掉订单金额为空的用户，正确写法是在WHERE里写order_amount IS NOT NULL，但有人会在HAVING里过滤，这会导致所有分组先算完、再过滤，白白浪费了计算资源。

3.2 JOIN与关联优化：大小表怎么关联不倾斜

HQL支持inner join、left join、right join、full join，语法和SQL几乎一致。但执行层面有个关键机制：Hive会把JOIN操作转换成Map端或Reduce端任务，并根据表的大小自动判断执行策略。

小表的处理尤其要注意。如果一个大表和一个小表关联，Hive可以把小表加载到内存里，在Map端完成关联，避免Reduce阶段的数据倾斜和网络开销。但小表的大小有上限，通常是由hive.auto.convert.join.noconditionaltask.size控制（默认10MB）。如果你能确定某张维表很小，可以手动开启MapJoin：

SELECT /*+ MAPJOIN(dim_user) */ o.order_id, u.user_name, o.order_amount FROM dwd_order_detail o LEFT JOIN dim_user u ON o.user_id = u.user_id;

这种写法在生产里很常见。反过来，如果两个表都很大，JOIN时最容易遇到的就是数据倾斜：某个关联键的数据量特别大，大量数据都分到一个分区/Reducer上，其他节点空转，整个任务卡在那里。排查时先用分组统计看看关联键的分布：

SELECT user_id, COUNT(*) AS cnt FROM dwd_order_detail WHERE dt = '2024-01-01' GROUP BY user_id ORDER BY cnt DESC LIMIT 20;

如果发现个别键的count特别离谱，就需要考虑过滤掉这些异常键、拆分处理后再合并，或者把倾斜键加盐分散（把一个键拆成多个带后缀的键）。

3.3 给每一行标号：最常用的几种写法

很多业务场景需要对查询结果“给每一行标号”，比如给每个用户的订单从新到旧排一个序号、取每个分组前几名。HQL里最核心的就是窗口函数ROW_NUMBER()，配合OVER (PARTITION BY ... ORDER BY ...)使用：

SELECT user_id, order_id, order_amount, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC) AS rn FROM dwd_order_detail WHERE dt = '2024-01-01';

这个结果里，每个用户的最新一单rn=1，第二新rn=2。如果只想保留每个用户最近一单，在外面套一层：

SELECT user_id, order_id, order_amount FROM ( SELECT user_id, order_id, order_amount, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY create_time DESC) AS rn FROM dwd_order_detail WHERE dt = '2024-01-01' ) t WHERE t.rn = 1;

注意HQL里对子查询要求必须起别名（上面的t），而且子查询里面默认不能直接引用外层字段。实际操作中，这个“分组取Top1”的写法是离线开发里使用频率最高的模式之一，常用于取用户最新状态、取每个类目销量最高的商品等。

3.4 lateral view与explode：处理数组和Map的专用语法

HQL里有一类场景是字段是复杂类型——比如一个用户有多个标签存在数组里，或者直接存JSON字符串。这时用普通查询无法展开，需要LATERAL VIEW配合UDTF函数。典型用法是把数组字段炸开成多行：

SELECT user_id, tag FROM dwd_user_tags LATERAL VIEW EXPLODE(tags) t AS tag;

如果字段是JSON结构，可以先通过get_json_object取出需要的字段，再炸开内嵌数组。这套组合在数据清洗阶段非常常用，尤其是面对埋点日志、用户标签数据时，几乎每一条HQL都绕不开。

4. HQL窗口函数：容易被低估的一类语言特性

4.1 窗口函数解决什么问题，和GROUP BY哪里有本质差异

传统聚合函数（SUM、COUNT）配GROUP BY会把多行压成一行，行细节全丢。窗口函数则不同，它在不开裂行明细的前提下对一组行做聚合，聚合结果附加到每一行后面。用生活类比的话，GROUP BY像把一堆散钱换成整钞，窗口函数更像给每张钞票盖一个“这堆钱总额是多少”的章——金额总数在，每张钞票也还在。

窗口函数的语法结构是：函数() OVER (PARTITION BY 分组字段 ORDER BY 排序字段 窗口子句)。PARTITION BY用于分组，ORDER BY决定窗口内排序，窗口子句可以进一步限制参与计算的行范围。如果什么都不写，默认是整个分组参与计算。

4.2 三类常用窗口函数详解

第一类是排名函数：ROW_NUMBER()生成连续且不重复的序号；RANK()相同值排名相同，但下一个排名会跳号（比如1、1、3）；DENSE_RANK()相同值排名相同，下一个排名不跳号（比如1、1、2）。具体选哪个，取决于你要1、2、3顺序还是并列排名。做排行榜、打标场景会经常遇到，值得花时间区分清楚。

第二类是聚合窗口函数：SUM、AVG、MIN、MAX加OVER，可以计算累计值、移动平均。比如计算每个用户的历史累计消费金额：

SELECT user_id, create_time, order_amount, SUM(order_amount) OVER (PARTITION BY user_id ORDER BY create_time) AS cum_amount FROM dwd_order_detail WHERE dt >= '2024-01-01';

这里没有加窗口子句，默认的窗口从分组第一行到当前行，所以cum_amount是累计值。这个写法在计算用户生命周期价值、消费频次分布时非常有用。

第三类是分析函数：LAG、LEAD可以取前一行/后一行的值，适合算环比增长、会话间隔；FIRST_VALUE、LAST_VALUE取窗口首尾值。比如计算连续两天订单金额的环比变化：

SELECT dt, order_amount, LAG(order_amount, 1) OVER (ORDER BY dt) AS prev_amount, ROUND((order_amount - LAG(order_amount, 1) OVER (ORDER BY dt)) / LAG(order_amount, 1) OVER (ORDER BY dt), 4) AS growth_rate FROM dwd_daily_amount WHERE dt BETWEEN '2024-01-01' AND '2024-01-31';

4.3 窗口子句：ROWS BETWEEN与RANGE

窗口子句可以精确定义聚合范围，常用写法是ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW（从分组首行到当前行）或者ROWS BETWEEN 3 PRECEDING AND CURRENT ROW（最近4行）。这对计算移动平均特别有用，比如给每日订单金额算7日滚动均值：

SELECT dt, order_amount, AVG(order_amount) OVER (ORDER BY dt ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS avg_7d FROM dwd_daily_amount WHERE dt BETWEEN '2024-01-01' AND '2024-03-31';

RANGE和ROWS的差异在于，RANGE按ORDER BY字段的值范围界定窗口，而ROWS按物理行数。实际开发中90%的场景用ROWS就够了，但遇到时间字段不连续、只想按时间值取范围的场景时，要能想到RANGE。

4.4 实战场景：TopN、同比环比计算

窗口函数最经典的应用就是取每个分组TopN。比如每个用户消费金额最高的3个订单：

SELECT * FROM ( SELECT user_id, order_id, order_amount, ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY order_amount DESC) AS rn FROM dwd_order_detail WHERE dt = '2024-01-01' ) t WHERE t.rn <= 3;

这个模式就是“子查询打序号+外层过滤”，和3.3节讲的“给每一行标号”一脉相承。另一个常见需求是同比环比：用LAG取上一周期的值，再做除法；或者用SUM(amount) OVER (PARTITION BY year ORDER BY month)做年度累计。窗口函数在日报、周报、月报的指标计算中几乎是标配，用好它，能减少大量重复的子查询和JOIN。

5. HQL写数据与文件治理：从INSERT到小文件优化

5.1 INSERT OVERWRITE与INSERT INTO的核心区别

HQL里写数据的核心语法是INSERT OVERWRITE和INSERT INTO。INSERT INTO是追加数据，INSERT OVERWRITE是清空原有数据再写入。从语言特性角度理解：OVERWRITE不是标准的SQL语义，它是Hive为了适配HDFS“写不可变文件”机制设计的——直接覆盖目标表或分区的目录。

实际开发中，如果想要每天跑数重刷当天的数据，用INSERT OVERWRITE更常见。但OVERWRITE有坑：如果目标分区不存在，它会自动创建；如果有人不小心把分区写成了整表，可能导致整个表的数据被清掉。所以写这种语句前，我习惯先跑一遍SELECT确认目标表名和分区字符串正确，再执行INSERT。

5.2 动态分区写入的正确姿势

动态分区写数据是很多刚入门的人踩坑的重灾区。它很方便，但要注意三个问题：分区列必须放在SELECT的最后；一次写入的分区数不能超过上限；产生的文件数和分区、Reducer数量直接相关。

合理做法是先明确目标分区的范围。比如按天刷一个月的数据，可以先在WHERE里过滤日期，让SELECT出来的分区键只有30个值，再用动态分区写入。不要一次性写一整年，否则365个分区、每个分区又分成一堆小文件，后续查询性能会急转直下。

5.3 小文件是怎么来的，HQL层怎么治

小文件问题在整个Hive运维里都是高频话题。小文件太多了，NameNode内存会被占满，查询任务在分布式文件系统层面就慢得不行。说得直白点，一个只有几KB的文件，在HDFS里的元数据开销可能比数据本身还大，就像把十斤大米分装成几千个牙签盒，光找盒子就累死人。

小文件主要来源有几个：动态分区过多，导致每个分区都有独立文件；INSERT次数过多，每次都有新的Reducer输出；Reduce数量设置过大；用Spark/Flink写入Hive表时并行度太高。

HQL层面的治理思路有几条：

1. 合并小文件：对ORC表可以用ALTER TABLE table_name PARTITION (dt='...') CONCATENATE;直接合并，对文本表通常要重写一遍。
2. 控制Reducer数量：通过SET mapreduce.job.reduces=N;设置合理数字，或者用DISTRIBUTE BY配合随机数让数据均匀分布。
3. 用INSERT OVERWRITE重写表：把旧数据读出来再写一遍，让文件落在新的、更少的文件中。这种方式虽然耗时，但对已存在的大量小文件最直接。

5.4 数据导出与迁移时的HQL注意事项

把Hive表数据导出到文件系统或关系型库，也是HQL高频使用场景。最常用的是INSERT OVERWRITE DIRECTORY：

INSERT OVERWRITE DIRECTORY '/tmp/export/order' ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' SELECT order_id, user_id, order_amount FROM dwd_order_detail WHERE dt = '2024-01-01';

可以配LOCATION 'hdfs://...'指定HDFS路径，也可以用hive -e "SELECT ..." > local_file导出到本地。导出时要特别注意格式：如果字段里有换行符或逗号，用这种方式导出CSV会在下游解析时炸裂，建议导出前先用regexp_replace把特殊字符替换掉，或者用ORC/Parquet这种二进制格式传递。

6. HQL扩展：UDF/UDTF/UDAF实战经验

6.1 先判断要不要自己写函数

Hive内置了非常多的函数——字符串、日期、数学、JSON处理、集合操作等等。大多数情况下不需要自己写，但总有内置函数不够用的时候，比如某种特殊格式的解析、需要调用外部算法、做复杂的加密解密。这时就需要写自定义函数。

HQL里的自定义函数分成三类：UDF（一行进、一行出，比如把字符串转大写）、UDTF（一行进、多行出，比如EXPLODE）、UDAF（多行进、一行出，比如自定义聚合）。难易程度完全不在一个量级，UDF最简单，UDAF最复杂。

6.2 一个最简单的UDF是怎么写出来的

写UDF在Java里实现其实很简单。继承org.apache.hadoop.hive.ql.exec.UDF，实现evaluate方法，一行结果对应一行输出。比如实现一个把字符串转成大写并去掉首尾空格的函数：

import org.apache.hadoop.hive.ql.exec.UDF; public class TrimUpper extends UDF { public String evaluate(String input) { if (input == null) return null; return input.trim().toUpperCase(); } }

打包成Jar后，在Hive里注册：

ADD JAR hdfs:///path/to/trimupper.jar; CREATE TEMPORARY FUNCTION trim_upper AS 'com.example.TrimUpper'; SELECT trim_upper(user_name) FROM dwd_user LIMIT 10;

实战中的坑主要是：类名必须写完整包名路径；Jar包的依赖要和Hive版本兼容；临时函数只在当前会话里有效，永久函数需要放到Hive的辅助Jar目录或通过CREATE FUNCTION语句注册；函数性能不能太差，因为它会在每个Map/Reduce任务里被调用成千上万次。

6.3 UDTF的妙用与限制

UDTF常用于自定义的“一行变多行”逻辑，典型场景是解析日志里的嵌套列表。实现UDTF通常需要继承GenericUDTF，实现initialize、process、close三个方法。比UDF要复杂一些，但核心思想不复杂：initialize里声明输出列名和类型，process里按逻辑向前端返回多行结果。

用的时候必须配合LATERAL VIEW：

SELECT user_id, extracted_value FROM dwd_log LATERAL VIEW my_udtf(log_content) t AS extracted_value;

UDTF有个历史限制：select列表里不能同时出现其他列，某些版本会报错；后来虽然通过LATERAL VIEW支持了多列，但依然要注意UDTF造成的行膨胀——如果每条日志炸出几十行，整体数据量会成倍增长。

6.4 UDAF的复杂度与替代方案

UDAF（自定义聚合函数）是最复杂的，它涉及部分聚合、合并、序列化、反序列化等一整套机制，通常要继承AbstractGenericUDAFResolver和GenericUDAFEvaluator，要在不同阶段（PARTIAL1、PARTIAL2、FINAL等）分别实现逻辑。

我的实际建议是：如果不是非常核心且无法绕过的需求，尽量别自己写UDAF。可以用UDF+窗口函数组合替代，或者把逻辑拆成多个UDF处理。真有绕不过去的需求，先在网上找现成实现，参考Hive源码的示例（比如GenericUDAFSum），再改造成自己的逻辑。写完一定要在本地小数据集上验证边界情况，比如NULL值、空字符串、全NULL列，这些在UDAF里最容易出bug。

7. 常见问题与排查技巧实录

7.1 一张问题速查表

7.2 乱码分区怎么处理

乱码分区这个问题我遇到的不多，但每次遇到都很头疼。比如某个分区的值里带了一些控制字符或者用了错误的分隔符，导致SHOW PARTITIONS正常，但WHERE条件怎么都匹配不上。

处理办法是自己构造精确条件删除。先查看当前所有分区：

SHOW PARTITIONS dwd_order_detail;

然后根据异常分区字符串，用DROP PARTITION删除：

ALTER TABLE dwd_order_detail DROP PARTITION (dt='2024-01-01');

如果是无法直接识别的乱码值，可以尝试把异常值先SELECT出来确认，再用字符串截取或HEX()函数比对。实在不行，最后的手段是直接从HDFS上删除对应目录，然后执行MSCK REPAIR TABLE让元数据重新同步。这个方法虽然粗暴，但实测下来通常能止血。

7.3 用EXPLAIN看懂一条HQL的执行计划

HQL提供了EXPLAIN命令，能输出一条SQL被翻译成什么样的执行步骤：

EXPLAIN SELECT user_id, COUNT(*) FROM dwd_order_detail WHERE dt = '2024-01-01' GROUP BY user_id;

输出里能看到TableScan、Filter、Group By Operator、Reduce Output Operator等节点。耐心看一遍，能认清一条HQL实际是“哪些数据在Map端做完、哪些在Reduce端做完”。比如关联键分布不均，从Reduce Output Operator的分发条件就能判断是不是按关联键做Shuffle；如果发现Map端已经做了聚合，那Reduce端压力就会小很多。

我第一次用EXPLAIN时完全看不懂，后来养成了一个习惯：每条慢查询都先跑一下EXPLAIN，再看哪些步骤的Input输出特别大，逐步调整WHERE下推、JOIN顺序、Reducer数量。这个习惯帮我解决了不少“看起来没毛病但就是跑不动”的问题。

7.4 数据倾斜问题的排查思路

数据倾斜是HQL最顽固的性能问题。典型表现：任务进度走到99%卡很久，或者某个Reducer处理的数据量是其他Reducer的几十倍。排查思路是分三步走：

1. 先定位倾斜键。用GROUP BY+COUNT(*)+ORDER BY DESC找出数据量最大的几个键值。如果是正常的头部用户（比如超级大V），需要业务层面处理；如果是NULL值导致的倾斜，通常在WHERE里先过滤掉。
2. 针对普通键倾斜。给倾斜键加盐，比如把大键拆成user_id + '_0'到user_id + '_9'，让数据分散到不同Reducer；最后在结果层去掉盐。这种方式能解决大部分由个别热点键导致的倾斜。
3. 开启HQL内置优化。SET hive.groupby.skewindata=true;可以让GROUP BY分成两个Job，第一轮打散分组，第二轮合并结果；SET hive.optimize.skewjoin=true;可以处理JOIN的倾斜。

倾斜问题的核心是理解数据分布，不只看SQL本身。我处理过最诡异的倾斜是字段类型不一致——两个表JOIN时一边是STRING一边是INT，导致隐式转换后哈希值分布异常。解决办法是把关联字段统一成同类型再JOIN。

7.5 三个容易被忽略的HQL开发习惯

最后分享三个我个人形成的习惯：第一，写HQL前先确认数据量级和分区键，能用分区裁剪的绝不扫全表；第二，所有复杂查询先加LIMIT 10跑通语法，再放开数据范围，避免语法错误消耗大量集群资源；第三，定期收集并复用自己沉淀的HQL片段，比如TopN模板、累计求和模板、分桶join模板，开发效率能提高不少。HQL这个语言本身不算难，难的是在一个真实的、庞大的数据环境里始终写出又快又稳的查询——这个过程没有捷径，只能靠多踩坑、多总结。