1. 为什么Hive查询值得单独拿出来讲大数据这个领域很多人是从“装个环境跑个WordCount”开始的但真正进入日常干活阶段打交道最多的其实是Hive。原因很简单业务方的需求大部分是“帮我统计一下昨天各渠道的订单量”“把用户按活跃度分个层”“这两张表关联一下看看转化”这些活儿用MapReduce手写一遍纯属跟自己过不去而Hive一句SQL就能搞定。我见过不少刚入行的同学Hadoop生态里别的组件说不清楚没关系但Hive的查询必须得熟练因为这是数据开发岗面试和实际工作中出现频率最高的技能点。你可以不会调优但你不能不会写查询。这篇文章就围绕Hive基本查询操作展开把SELECT、WHERE、GROUP BY、JOIN、排序、函数这些基础但容易踩坑的东西掰开揉碎讲一遍。适合刚接触Hive的数据开发新人也适合从传统关系型数据库转过来的同学——因为Hive SQL看着像SQL但底层跑的是MapReduce或Tez/Spark很多在MySQL里理所当然的写法到了Hive里就是另一回事。我个人的经验是Hive查询的坑主要集中在三个地方一是对执行引擎的理解不到位写出全表扫描的慢查询二是对NULL、类型隐式转换这些细节不敏感结果对不上还找不到原因三是不清楚分区和分桶对查询的影响白白浪费了优化机会。下面我会按“设计思路—核心细节—实操过程—问题排查”的顺序把这些问题一个个拆开。2. Hive查询的整体设计与执行逻辑2.1 从SQL到分布式任务Hive到底做了什么很多人写Hive SQL的时候脑子里想的是MySQL觉得写完回车就出结果。实际上Hive收到一条SQL之后做的事情比你想的复杂得多。它先通过解析器把SQL变成抽象语法树再经过语义分析、逻辑计划、逻辑优化、物理计划、物理优化最后生成一批可执行的分布式任务交给底层引擎去跑。这个过程里你写的每一个JOIN、每一个GROUP BY都会被翻译成若干个Map和Reduce阶段。理解这一点非常关键因为它直接决定了你该怎么写查询。举个最典型的例子在MySQL里SELECT * FROM t LIMIT 10几乎是瞬间返回但在Hive里如果这张表没有分区限制它可能启动一堆Map任务去扫描全部数据然后每个Map各取一部分最后合并出10条。数据量大的时候这个“取10条”可能要跑好几分钟。所以Hive查询的第一原则就是永远想办法减少扫描的数据量能加分区过滤就加能提前过滤就提前过滤。2.2 为什么Hive SQL和标准SQL“长得像但脾气不同”Hive SQL在设计上大量借鉴了SQL-92标准所以SELECT、FROM、WHERE、GROUP BY、ORDER BY这些关键字你都会用。但它的“脾气”有几个明显不同第一Hive默认不支持行级更新和删除它是为批量读写设计的所以你的思维要从“操作一行行记录”切换到“操作一批批数据”。第二Hive的JOIN默认是等值JOIN非等值连接在早期版本里支持很差虽然现在好一些了但性能依然不理想。第三Hive对数据类型的要求相对宽松但有陷阱比如字符串和数字比较时会发生隐式转换转换规则和MySQL不完全一样很容易出现“明明该匹配上的却没匹配上”。第四Hive的排序行为分好几种ORDER BY是全局排序只有一个Reduce数据量大时极慢SORT BY是局部排序DISTRIBUTE BY控制分发CLUSTER BY是前两者的结合。这个区别在MySQL里根本不存在但Hive里必须搞清楚。我刚开始用Hive的时候就吃过亏写了个ORDER BY想看看数据结果几千万条数据全塞到一个Reduce里跑了半小时还没出来最后只能杀掉重写。这个教训让我记住了——在Hive里ORDER BY要慎用除非你明确知道数据量很小。2.3 查询设计的核心思路先想数据怎么流动写Hive查询之前我习惯先在纸上画一下数据流向从哪张表读经过哪些过滤和聚合最后输出成什么。这个习惯是从踩坑里养出来的。因为Hive查询一旦提交你很难像MySQL那样中途看执行计划调整只能等它跑完或者杀掉重来。提前想清楚数据怎么流动能避免大量无效计算。具体来说设计一条Hive查询时我会问自己几个问题这张表有没有分区我能不能用分区字段过滤掉大部分数据我需要的字段是不是全部能不能只SELECT必要的列这个JOIN能不能改成MapJoin小表能不能先过滤再关联这个GROUP BY会不会产生数据倾斜有没有热点key排序是不是必须的能不能用SORT BY代替ORDER BY这些问题看起来琐碎但每一个都对应着实实在在的性能差异。下面进入具体操作层面我会把每个基础查询操作讲透同时把对应的坑标出来。3. 基础查询操作的核心细节与实操要点3.1 SELECT与FROM看似最简单坑却不少SELECT是Hive查询的入口语法上就是SELECT 列名 FROM 表名。但这里有几个细节值得单独说。列的选择SELECT *在Hive里是要尽量避免的。原因有两个一是列式存储格式比如ORC、Parquet下只读需要的列能大幅减少IO二是当表字段很多时SELECT *会让后续的查询计划变得臃肿。我一般建议明确写出需要的列名哪怕多打几个字。列别名Hive支持SELECT col1 AS alias1但要注意别名不能和已有列名冲突否则会出现难以排查的错误。另外在WHERE子句里不能使用SELECT中定义的别名因为WHERE的执行顺序在SELECT之前。这个和MySQL的行为一致但很多人会忘。LIMITSELECT * FROM t LIMIT 10在Hive里并不是“只读10行”而是“每个Map任务读一部分最后合并出10行”。所以如果表很大且没有分区过滤这个LIMIT依然会触发全表扫描。正确的做法是加上分区条件比如WHERE dt2024-01-01 LIMIT 10。表名和库名跨库查询时要写db_name.table_name这个在Hive里很常见。如果经常查某个库的表可以先USE db_name切换过去。提示在Hive里执行SELECT * FROM t LIMIT 1来“看一眼数据结构”是很多人的习惯但如果这张表有几十亿行且没有分区这个操作可能跑很久。更安全的做法是先用DESC t看表结构或者用DESC FORMATTED t看详细信息和分区字段。3.2 WHERE过滤分区过滤是性能的生命线WHERE子句用来过滤行语法和标准SQL基本一致支持、!、、、、、BETWEEN、IN、LIKE、IS NULL等操作符。但在Hive里WHERE最重要的作用是分区裁剪。假设有一张按天分区的订单表orders分区字段是dt。如果你写SELECT * FROM orders WHERE dt2024-01-01Hive只会扫描这一个分区的数据速度很快。但如果你写SELECT * FROM orders WHERE order_id 1000Hive就得扫描所有分区因为order_id不是分区字段。这个差别在数据量大时可能是几分钟和几小时的差距。分区字段的使用有几个注意点分区字段在表定义里是独立的不是普通列但在查询时可以像普通列一样用。分区字段的值是字符串类型即使你看起来像数字比较时要注意类型。多级分区要按顺序过滤比如dt2024-01-01 AND hour10不能跳过dt直接过滤hour虽然语法上可以但性能会差。NULL的处理Hive里NULL的判断用IS NULL和IS NOT NULL不能用 NULL。另外要注意NULL在聚合函数里的行为COUNT(col)不统计NULL值COUNT(*)统计所有行SUM/AVG会忽略NULL。这些和标准SQL一致但很多人写的时候不留意。LIKE和RLIKEHive支持LIKE做简单通配也支持RLIKE做正则匹配。RLIKE功能更强但性能更差能用LIKE就别用RLIKE。另外LIKE的%在前缀匹配时无法利用索引Hive本身也没有传统索引所以LIKE %abc这种写法要尽量避免。3.3 GROUP BY与聚合函数数据倾斜的重灾区GROUP BY是Hive查询里最常用的操作之一也是性能问题最集中的地方。它的作用是把数据按指定列分组然后对每组做聚合计算。常用聚合函数函数作用注意事项COUNT计数COUNT(*)统计所有行COUNT(col)忽略NULLSUM求和忽略NULL返回NULL如果所有值都是NULLAVG平均值忽略NULLMAX/MIN最大/最小值忽略NULLCOLLECT_SET收集去重后的值返回数组数据量大时慎用COLLECT_LIST收集所有值返回数组不去重GROUP BY的执行过程Hive会把GROUP BY的列作为Reduce的key相同key的数据分发到同一个Reduce任务。如果某个key的数据量特别大比如某个渠道的订单占了总量的80%就会出现数据倾斜——一个Reduce忙死其他Reduce闲着。这是Hive查询里最经典的性能问题。解决数据倾斜的常见方法两阶段聚合先给key加随机前缀做局部聚合再去掉前缀做全局聚合。这个在SQL里写起来比较绕但效果很好。开启负载均衡设置hive.groupby.skewindatatrueHive会自动做两阶段聚合。过滤热点key如果热点key是异常数据直接WHERE过滤掉。MapJoin如果GROUP BY之前有小表JOIN用MapJoin避免Reduce阶段。HAVING和WHERE的区别WHERE在GROUP BY之前过滤HAVING在GROUP BY之后过滤。所以能用WHERE过滤的不要放到HAVING里因为WHERE能减少进入GROUP BY的数据量。这个规则在Hive里比MySQL里更重要因为Hive的GROUP BY代价更高。注意Hive的GROUP BY结果不保证有序如果需要有序输出必须显式加ORDER BY或SORT BY。另外GROUP BY的列可以是表达式比如GROUP BY substr(dt,1,7)按月分组但这样会让分区裁剪失效要权衡使用。3.4 JOIN操作小表在前大表在后JOIN是Hive查询里另一个高频操作也是容易出问题的地方。Hive支持INNER JOIN、LEFT JOIN、RIGHT JOIN、FULL JOIN语法和标准SQL一致但执行逻辑有区别。JOIN的执行过程Hive默认会把JOIN翻译成ReduceJoin也就是两个表的数据都按JOIN key分发到Reduce然后在Reduce里做关联。这个过程涉及大量的网络传输和磁盘IO所以性能通常不如MapJoin。MapJoin如果其中一个表足够小默认25MB以下Hive可以把它加载到内存里在Map阶段就完成关联避免Reduce阶段。这个优化对性能提升非常明显。开启方式有两种一是设置hive.auto.convert.jointrue让Hive自动判断二是用/* MAPJOIN(small_table) */提示手动指定。JOIN的写法建议小表放在JOIN的右边虽然新版本Hive会自动优化但养成习惯没坏处。JOIN之前先过滤减少参与JOIN的数据量。多表JOIN时如果JOIN key相同可以合并成一次JOIN。避免笛卡尔积除非你明确知道自己在做什么。LEFT JOIN的NULL问题LEFT JOIN时如果右表没有匹配的行右表的列会返回NULL。这个在后续计算里要特别小心比如SUM(right_table.amount)会把NULL当0处理但COUNT(right_table.id)不会统计NULL。我见过有人用LEFT JOIN之后COUNT右表字段结果发现数量对不上排查半天才发现是NULL的问题。JOIN key的类型Hive在JOIN时会做隐式类型转换如果两边的key类型不一致比如一边是string一边是int转换规则可能导致意外的结果。最稳妥的做法是显式转换比如CAST(a.id AS STRING) b.id。3.5 排序操作ORDER BY、SORT BY、DISTRIBUTE BY、CLUSTER BYHive的排序是初学者最容易混淆的地方因为标准SQL里只有ORDER BY而Hive有四种排序相关操作。ORDER BY全局排序保证输出结果完全有序。但代价是只有一个Reduce任务数据量大时极慢甚至跑不出来。我一般只在数据量小几万行以内或者必须全局有序的场景下用。SORT BY局部排序每个Reduce内部有序但全局不保证有序。优点是可以用多个Reduce并行排序速度快。适合“每个分组内有序”的场景。DISTRIBUTE BY控制数据如何分发到Reduce和GROUP BY类似但不做聚合。通常和SORT BY配合使用实现“按某列分发再按另一列排序”。CLUSTER BY当DISTRIBUTE BY和SORT BY的列相同时可以用CLUSTER BY简写。它等价于DISTRIBUTE BY col SORT BY col。排序方式全局有序Reduce数量适用场景ORDER BY是1小数据量全局排序SORT BY否多个每组内排序DISTRIBUTE BY SORT BY否多个按列分发后组内排序CLUSTER BY否多个分发和排序同列提示如果你写了ORDER BY但数据量很大Hive可能会报错或者跑很久。这时候可以考虑用SORT BY加LIMIT或者先过滤数据再排序。另外hive.mapred.modestrict时会禁止没有LIMIT的ORDER BY这个配置在生产环境很常见。4. 完整实操流程与关键环节实现4.1 环境准备与测试数据构建在开始实操之前先确认你的Hive环境可用。我假设你已经有一个能跑Hive的环境不管是单机还是集群下面直接进入查询操作。先建一张测试表模拟订单数据CREATE TABLE IF NOT EXISTS orders ( order_id BIGINT, user_id BIGINT, product_id BIGINT, amount DOUBLE, channel STRING, order_time STRING ) PARTITIONED BY (dt STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY \t STORED AS TEXTFILE;这张表按天分区字段包括订单ID、用户ID、商品ID、金额、渠道、下单时间。分区字段是dt。然后往几个分区里插入一些测试数据。实际生产中数据是通过ETL流程写入的这里为了演示直接用INSERT语句造几条INSERT INTO TABLE orders PARTITION (dt2024-01-01) VALUES (1001, 2001, 3001, 99.5, app, 2024-01-01 10:23:45), (1002, 2002, 3002, 150.0, web, 2024-01-01 11:15:30), (1003, 2001, 3003, 200.0, app, 2024-01-01 14:20:10), (1004, 2003, 3001, 99.5, mini, 2024-01-01 16:45:00), (1005, 2002, 3004, 320.0, web, 2024-01-01 18:30:22); INSERT INTO TABLE orders PARTITION (dt2024-01-02) VALUES (1006, 2001, 3002, 150.0, app, 2024-01-02 09:10:00), (1007, 2004, 3003, 200.0, web, 2024-01-02 12:25:40), (1008, 2002, 3001, 99.5, mini, 2024-01-02 15:50:15), (1009, 2003, 3004, 320.0, app, 2024-01-02 19:05:30), (1010, 2005, 3002, 150.0, web, 2024-01-02 21:40:00);再建一张用户表CREATE TABLE IF NOT EXISTS users ( user_id BIGINT, user_name STRING, city STRING, register_date STRING ) ROW FORMAT DELIMITED FIELDS TERMINATED BY \t STORED AS TEXTFILE; INSERT INTO TABLE users VALUES (2001, user_a, beijing, 2023-01-15), (2002, user_b, shanghai, 2023-03-20), (2003, user_c, guangzhou, 2023-05-10), (2004, user_d, shenzhen, 2023-07-08), (2005, user_e, hangzhou, 2023-09-12);数据准备好了下面开始各种查询操作。4.2 基础查询与过滤实操先看最简单的查询——查2024-01-01的订单SELECT order_id, user_id, amount, channel FROM orders WHERE dt 2024-01-01;这条查询会只扫描dt2024-01-01这个分区速度很快。如果你用EXPLAIN看执行计划会看到分区裁剪生效了。再看一个带多个过滤条件的SELECT order_id, user_id, amount FROM orders WHERE dt 2024-01-01 AND channel app AND amount 100;这里channel和amount的过滤是在Map阶段完成的能减少进入后续阶段的数据量。实操心得在写WHERE条件时把分区字段放在最前面虽然Hive不要求顺序但这样写便于自己和别人阅读也能提醒自己分区裁剪是否生效。另外如果过滤条件里有函数比如WHERE substr(dt,1,7)2024-01分区裁剪会失效因为Hive无法从函数表达式推断出分区范围。正确写法是WHERE dt BETWEEN 2024-01-01 AND 2024-01-31。4.3 聚合统计实操统计每天的订单总数和总金额SELECT dt, COUNT(*) AS order_cnt, SUM(amount) AS total_amount, AVG(amount) AS avg_amount FROM orders GROUP BY dt;结果会按dt分组输出每天的订单数、总金额和平均金额。再统计每个渠道的订单情况SELECT channel, COUNT(*) AS order_cnt, SUM(amount) AS total_amount, COUNT(DISTINCT user_id) AS user_cnt FROM orders WHERE dt BETWEEN 2024-01-01 AND 2024-01-02 GROUP BY channel;这里用了COUNT(DISTINCT user_id)统计去重用户数。注意DISTINCT在数据量大时性能较差因为它需要把所有user_id收集起来去重。如果只是估算可以用近似函数或者先GROUP BY再去重。参数计算示例假设orders表有10亿行channel有5个值那么GROUP BY channel会产生5个Reduce key。如果数据均匀分布每个Reduce处理2亿行。但如果app渠道占了80%那app对应的Reduce要处理8亿行其他4个Reduce各处理5000万行这就是典型的数据倾斜。解决办法是开启hive.groupby.skewindatatrue或者给channel加随机前缀做两阶段聚合。4.4 JOIN关联实操把订单表和用户表关联看看每个城市的订单情况SELECT u.city, COUNT(*) AS order_cnt, SUM(o.amount) AS total_amount FROM orders o JOIN users u ON o.user_id u.user_id WHERE o.dt BETWEEN 2024-01-01 AND 2024-01-02 GROUP BY u.city;这条查询先按分区过滤orders然后和users做JOIN最后按城市分组聚合。users表很小5行Hive会自动把它转成MapJoin在Map阶段完成关联避免Reduce阶段。如果想手动指定MapJoinSELECT /* MAPJOIN(u) */ u.city, COUNT(*) AS order_cnt, SUM(o.amount) AS total_amount FROM orders o JOIN users u ON o.user_id u.user_id WHERE o.dt BETWEEN 2024-01-01 AND 2024-01-02 GROUP BY u.city;LEFT JOIN示例统计每个用户的订单数包括没有下单的用户SELECT u.user_id, u.user_name, COUNT(o.order_id) AS order_cnt, COALESCE(SUM(o.amount), 0) AS total_amount FROM users u LEFT JOIN orders o ON u.user_id o.user_id AND o.dt BETWEEN 2024-01-01 AND 2024-01-02 GROUP BY u.user_id, u.user_name;这里注意两点一是JOIN条件里带了分区过滤避免扫描所有分区二是用COALESCE把NULL转成0因为LEFT JOIN时没有订单的用户SUM会返回NULL。4.5 排序与窗口实操按订单金额降序排列取前3名SELECT order_id, user_id, amount FROM orders WHERE dt 2024-01-01 ORDER BY amount DESC LIMIT 3;数据量小的时候这样写没问题。但如果数据量大ORDER BY会强制一个Reduce可能跑很久。替代方案是用SORT BY加LIMITSELECT order_id, user_id, amount FROM orders WHERE dt 2024-01-01 SORT BY amount DESC LIMIT 3;注意SORT BY是局部排序每个Reduce内部有序但全局不保证有序。所以这个写法取到的“前3名”可能不是真正的全局前3而是某个Reduce里的前3。如果数据只有一个Reduce那结果和ORDER BY一样。实际使用时要想清楚是否需要全局有序。窗口函数示例计算每个渠道内按金额排序的排名SELECT order_id, channel, amount, ROW_NUMBER() OVER (PARTITION BY channel ORDER BY amount DESC) AS rn FROM orders WHERE dt 2024-01-01;窗口函数在Hive里支持得很好PARTITION BY控制分组ORDER BY控制组内排序。这个在数据分析里非常常用比如计算每个用户的首次下单时间、每个品类的销量排名等。5. 常见问题与排查技巧实录5.1 查询跑得慢怎么定位问题Hive查询慢的原因很多我一般按以下顺序排查第一步看执行计划。用EXPLAIN命令查看查询计划重点关注有没有全表扫描、有没有分区裁剪、JOIN是MapJoin还是ReduceJoin。EXPLAIN SELECT order_id, amount FROM orders WHERE dt 2024-01-01 AND channel app;执行计划里如果看到TableScan后面有Partition过滤说明分区裁剪生效了。如果看到Filter在TableScan之后说明过滤是在扫描之后做的可能扫描了多余数据。第二步看数据量。用DESC FORMATTED orders看表的统计信息或者直接SELECT COUNT(*) FROM orders WHERE dt2024-01-01看分区大小。数据量大是慢的根本原因其他优化都是在这个基础上做文章。第三步看数据倾斜。如果查询卡在某个Reduce上不动大概率是数据倾斜。可以在查询里加DISTRIBUTE BY看数据分布或者看YARN的任务监控页面看各个Reduce处理的数据量是否均匀。第四步看资源。如果集群资源紧张查询会排队等资源。这个不是SQL能解决的需要和运维协调。5.2 结果对不上常见原因有哪些结果对不上是比查询慢更让人头疼的问题因为慢至少知道在跑对不上是根本不知道哪里错了。我整理了几种常见情况现象可能原因排查方法COUNT结果比预期少NULL值被忽略用COUNT(*)对比COUNT(col)JOIN后数据变多右表有重复key先对右表做去重或聚合JOIN后数据变少key类型不一致导致匹配失败显式CAST统一类型SUM结果偏小NULL被当0处理用COALESCE或检查NULL分区数据缺失分区过滤条件写错用SHOW PARTITIONS查看分区字符串比较不匹配隐式类型转换显式CAST或统一类型一个真实的排查案例有次我写了个JOIN查询发现结果比预期少了很多。检查后发现左表的user_id是BIGINT右表的user_id是STRINGHive在JOIN时把STRING转成了BIGINT但右表里有些user_id带有空格转换后变成了NULL导致这些行匹配不上。解决办法是在JOIN前用TRIM()去掉空格或者统一用STRING类型关联。5.3 新手最容易踩的五个坑坑一用ORDER BY排大数据。前面说过ORDER BY只有一个Reduce数据量大时极慢。我见过有人对几亿行数据ORDER BY跑了一小时还没出来。记住大数据排序用SORT BY全局有序用ORDER BY但必须加LIMIT。坑二SELECT * 不加分区。这个坑太常见了尤其是从MySQL转过来的同学。Hive里SELECT * FROM big_table会扫描全表如果表有几百个分区每个分区几GB这个查询可能直接把集群跑挂。养成习惯查Hive表先想分区条件。坑三GROUP BY后直接用非聚合列。标准SQL里GROUP BY后只能SELECT分组列和聚合函数但Hive在某些配置下允许SELECT非分组列结果是不确定的。比如SELECT channel, order_id, COUNT(*) FROM orders GROUP BY channelorder_id的值是随机的。这个错误很隐蔽因为Hive不报错但结果没有意义。坑四JOIN时小表放左边。虽然新版本Hive会自动优化但在一些老版本或者特定配置下小表放右边更容易触发MapJoin。我一般习惯把小表写在JOIN的右边。坑五忽略NULL的影响。NULL在Hive里是个特殊值和任何值比较都返回NULL包括NULLNULL返回NULL不是true。所以WHERE col NULL永远查不到数据必须用IS NULL。另外在JOIN时NULL key不会匹配任何行包括另一个NULL。这个在关联用户维度表时经常出问题。5.4 性能优化的几个实用技巧除了前面提到的分区裁剪、MapJoin、避免数据倾斜还有几个技巧在实际工作中很管用用ORC或Parquet格式。这两种列式存储格式在Hive里查询性能比TextFile好很多因为只读需要的列而且压缩率高。建表时用STORED AS ORC查询速度能提升几倍。合理设置Reduce数量。Reduce太多会产生大量小文件Reduce太少会导致单个任务处理数据过多。一般建议每个Reduce处理128MB~256MB数据。可以通过hive.exec.reducers.bytes.per.reducer参数控制。用EXPLAIN分析执行计划。这个习惯能帮你提前发现性能问题而不是等查询跑起来才后悔。开启向量化查询。设置hive.vectorized.execution.enabledtrueHive会按批处理数据减少CPU开销。这个在ORC格式下效果尤其明显。用TEZ或Spark引擎。Hive默认用MapReduce但TEZ和Spark引擎通常快很多。如果集群支持建议切换引擎。提示优化不是一蹴而就的每次优化后都要对比执行时间和资源消耗确认优化有效。我见过有人加了一堆参数结果查询更慢了就是因为没有验证。6. 从基础查询到实战的进阶思路基础查询操作掌握之后下一步就是把这些操作组合起来解决实际业务问题。比如“统计每个渠道每天的GMV和环比增长率”这个需求涉及多天数据、分组聚合、窗口函数、自关联是基础查询的综合应用。再比如“找出连续三天都有下单的用户”这个需要用到窗口函数和日期计算是进阶查询的典型场景。我个人的学习路径是先把单表查询练熟再把JOIN练熟然后把窗口函数练熟最后把这些组合起来做复杂的业务分析。每一步都要动手写、动手跑、动手排查问题。光看文档是学不会Hive的因为Hive的很多行为只有在实际跑数据的时候才会暴露出来。另外Hive的版本差异比较大不同版本对SQL的支持程度不同。比如窗口函数在Hive 0.11之后才支持MapJoin的自动转换在Hive 0.11之后才默认开启。写查询之前最好确认一下集群的Hive版本避免用了不支持的语法。最后分享一个我自己的习惯每次写完一条复杂的Hive查询先用小数据量比如一个分区跑一遍验证逻辑确认结果正确后再放到全量数据上跑。这个习惯帮我省了很多时间因为逻辑错误在小数据上很容易发现在全量数据上可能要跑很久才暴露。