企业官网建设流程全解析

1. 从一条SQL说起：为什么Hive值得单独拎出来讲

很多人第一次接触大数据技术栈，都是从Hive开始的。原因很简单——它把分布式计算包装成了SQL。你不需要写MapReduce，不需要理解DAG调度，只要会写SELECT ... FROM ... WHERE ...，就能对存储在HDFS上的海量数据做查询分析。这个门槛低到几乎为零，但真正用好Hive的人并不多。

我在实际工作中见过太多这样的情况：一条Hive SQL跑几个小时不出结果，或者跑出来了但数据对不上，又或者同样的逻辑别人跑10分钟你跑2小时。这些问题往往不是Hive本身的问题，而是对Hive的底层机制、执行原理、优化手段理解不够深入导致的。

这篇文章面向的是已经接触过Hive、或者正准备在生产环境中使用Hive的开发和数据分析人员。我会从Hive的核心架构讲起，拆解它的执行流程，然后重点讲分区、分桶、文件格式、SQL优化、数据倾斜处理这些实战中绕不开的话题。每一部分都会解释“为什么这样做”，而不是只给结论。文章内容基于Hive 2.x/3.x的常见实践，部分细节在不同版本间可能有差异，我会尽量标注。

2. Hive到底是怎么把SQL变成分布式任务的

2.1 核心组件拆解：从客户端到执行引擎

Hive的架构看起来不复杂，但每个组件都有明确的职责。理解这些组件之间的关系，是排查问题的第一步。

HiveServer2（HS2）是你最常打交道的服务。它对外提供JDBC/ODBC接口，接收客户端发来的SQL，然后负责整个执行流程的编排。你通过Beeline、JDBC或者任何BI工具连上Hive，实际连的就是HS2。HS2内部会为每个连接创建一个Session，管理会话级别的配置和资源。

Driver是HS2内部的核心模块，负责SQL的解析、编译、优化和执行。当你提交一条SQL，Driver会依次做这几件事：先用Antlr做词法和语法分析，生成抽象语法树（AST）；然后做语义分析，校验表是否存在、字段是否匹配、类型是否兼容；接着生成逻辑执行计划，再经过一系列优化规则（比如谓词下推、列裁剪、Join重排序）转成物理执行计划；最后把物理计划提交给执行引擎。

MetaStore是Hive的元数据服务，存储了所有表的结构信息、分区信息、列类型、存储格式等。MetaStore通常背后是MySQL或PostgreSQL这样的关系型数据库。这里有一个很常见的坑：MetaStore的性能直接影响Hive的编译速度。如果你的表有几十万个分区，每次查询编译时MetaStore都要去拉分区列表，这个开销可能比实际计算还大。

执行引擎是真正干活的部分。Hive本身不负责计算，它把物理计划翻译成MapReduce、Tez或者Spark任务提交到YARN上执行。MapReduce是最经典的引擎，但性能最差，因为每个阶段都要落盘。Tez用DAG代替了多轮MapReduce，减少了中间落盘。Spark引擎则利用内存计算进一步加速。选择哪个引擎，直接决定了你的SQL跑得快不快。

2.2 一条SQL的完整旅程：从提交到出结果

我拿一条最简单的SQL来走一遍完整流程：

SELECT dept_id, COUNT(*) AS cnt FROM employee WHERE dt = '2024-01-01' GROUP BY dept_id;

这条SQL提交到HS2之后，Driver首先做语法解析，确认employee表存在、dept_id和dt字段存在。然后做逻辑计划优化：因为dt是分区字段，优化器会把WHERE dt = '2024-01-01'下推到表扫描阶段，只读取对应分区目录下的文件，而不是全表扫描。这就是分区裁剪，是最基本也是最重要的优化之一。

接下来是物理计划生成。如果是MapReduce引擎，这条SQL会被拆成至少两个Stage：一个MapReduce做局部聚合（Combiner），另一个做全局聚合。Map阶段读取分区文件，按dept_id做局部COUNT，输出到Reduce阶段做最终COUNT。如果是Tez引擎，这两个阶段可以在一个DAG里完成，省掉了中间写HDFS的开销。

任务提交到YARN之后，ApplicationMaster负责协调各个Container的执行。每个Map任务读取一个InputSplit（通常对应一个HDFS Block），解析数据，执行聚合逻辑。Reduce任务拉取Map的输出，做最终聚合，把结果写到HDFS的临时目录，最后由HS2读取并返回给客户端。

整个过程中，有几个地方最容易出问题：小文件太多导致Map任务数量爆炸；数据倾斜导致某个Reduce任务跑得特别慢；内存不够导致Container被Kill。这些问题后面会逐一展开。

2.3 MetaStore为什么是性能瓶颈的隐形杀手

很多人优化Hive SQL时只盯着SQL本身，忽略了MetaStore的影响。我踩过最典型的一个坑是：一张按天分区的表，积累了三年数据，分区数量超过1000个。每次查询编译时，MetaStore都要去MySQL里查分区信息，而MySQL那边没有做好索引，单次查询编译就要等十几秒。SQL本身跑起来只要几秒，编译却花了十几秒。

解决思路有两个方向。一是控制分区数量，不要无限制地按天分区，可以考虑按月分区或者使用更粗的粒度。二是优化MetaStore的数据库，确保PARTITIONS、TBLS、SDS这些核心表有合适的索引，定期做统计信息更新。如果用的是MySQL，还要注意连接池配置，MetaStore的并发连接数不够也会导致编译排队。

还有一个容易被忽略的点：Hive的统计信息。ANALYZE TABLE ... COMPUTE STATISTICS这个操作会把表的行数、文件数、大小等信息写入MetaStore。CBO（基于代价的优化器）依赖这些统计信息来做Join顺序决策。如果统计信息缺失或者过时，优化器可能选出一个很差的执行计划。我建议对核心表定期跑统计信息，尤其是那些参与Join的大表。

3. 分区和分桶：物理存储设计决定查询上限

3.1 分区表的本质：目录结构就是索引

Hive的分区不是什么高深的技术，它的本质就是在HDFS上按分区字段建立子目录。比如一张按天分区的表employee，dt='2024-01-01'的数据就存在/warehouse/employee/dt=2024-01-01/目录下。当你写WHERE dt = '2024-01-01'时，Hive只需要读取这个目录下的文件，其他目录直接跳过。

这个设计的好处是分区裁剪非常高效，不需要任何额外的索引结构。但代价是分区字段的选择很关键。分区字段应该满足两个条件：一是查询中经常作为过滤条件，二是每个分区的数据量相对均匀。如果按一个高基数的字段分区（比如用户ID），会产生大量小目录和小文件，NameNode压力巨大，查询性能反而下降。

动态分区是实际生产中用得最多的方式。你可以在INSERT语句中根据查询结果自动创建分区：

SET hive.exec.dynamic.partition = true; SET hive.exec.dynamic.partition.mode = nonstrict; INSERT OVERWRITE TABLE employee_partitioned PARTITION(dt) SELECT emp_id, name, dept_id, salary, dt FROM employee_staging;

这里有个坑：动态分区默认是strict模式，要求至少有一个静态分区字段。如果你全用动态分区，必须设成nonstrict。另外，动态分区会为每个不同的分区值创建一个文件，如果分区值太多（比如几千个），会生成大量小文件。可以通过hive.exec.max.dynamic.partitions和hive.exec.max.dynamic.partitions.pernode来控制上限。

实操心得：动态分区写入时，建议在SQL最后加一个DISTRIBUTE BY dt，这样相同分区值的数据会落到同一个Reduce任务里，减少最终生成的文件数量。这个技巧在处理分区数较多的场景下特别管用。

3.2 分桶表的适用场景：Join和采样加速

分桶是比分区更细粒度的数据组织方式。它根据某个字段的哈希值把数据分成固定数量的文件。比如CLUSTERED BY (emp_id) INTO 16 BUCKETS，就是按emp_id的哈希值对16取模，把数据分到16个文件里。

分桶最大的价值在于Map端Join。如果两张表都按Join Key分了相同数量的桶，那么Hive可以做一个桶对一个桶的Join，不需要把整张表 shuffle 一遍。这在处理大表Join大表的场景下，能省掉大量的网络传输和磁盘IO。

-- 建两张分桶表 CREATE TABLE orders_bucketed (order_id INT, user_id INT, amount DOUBLE) CLUSTERED BY (user_id) INTO 32 BUCKETS; CREATE TABLE users_bucketed (user_id INT, user_name STRING) CLUSTERED BY (user_id) INTO 32 BUCKETS; -- 开启分桶Join优化 SET hive.optimize.bucketmapjoin = true; SET hive.optimize.bucketmapjoin.sortedmerge = true; -- 分桶Join SELECT o.order_id, u.user_name, o.amount FROM orders_bucketed o JOIN users_bucketed u ON o.user_id = u.user_id;

分桶的另一个用途是数据采样。TABLESAMPLE(BUCKET 1 OUT OF 16 ON emp_id)可以快速抽取1/16的数据做探索性分析，不需要全表扫描。这在数据量很大的时候非常实用。

但分桶不是银弹。它的维护成本比分区高，插入数据时需要确保分桶数量一致，否则Join优化不生效。而且分桶数量一旦确定，后期调整需要重建表。我的经验是：如果两张表经常按同一个Key做Join，且数据量都很大，值得考虑分桶；否则优先用分区。

3.3 分区和分桶的常见误用与纠正

我见过最常见的误用是过度分区。有人按小时分区，一天24个分区，一年就是8760个分区。如果每个分区只有几MB数据，NameNode要维护大量小文件，查询编译时MetaStore也要拉取大量分区元数据，整体性能反而下降。

另一个误用是分区字段选错。有人用性别、状态这种低基数字段做分区，结果只有两三个分区，每个分区数据量巨大，分区裁剪几乎没效果。分区字段应该选那些在查询中频繁过滤、且基数适中的字段，比如日期、地区、业务线。

分桶的误用主要是分桶数量不合理。分桶数量太少，每个桶数据量还是很大，Join优化效果有限；分桶数量太多，小文件问题又来了。一般来说，分桶数量应该是集群可用Reduce槽位的整数倍，常见的选择是32、64、128。具体多少合适，要看数据量和集群规模，没有万能公式。

4. 文件格式与压缩：存储层的性能杠杆

4.1 行存 vs 列存：为什么列存更适合分析场景

Hive支持多种文件格式，最常用的是TextFile、SequenceFile、ORC和Parquet。TextFile是默认格式，可读性好但性能最差。SequenceFile是二进制格式，比TextFile好一些，但仍然是行存。ORC和Parquet是列存格式，在分析场景下性能优势明显。

列存的核心优势在于列裁剪和更高的压缩比。当你写SELECT name FROM employee时，列存只需要读取name这一列的数据，其他列完全不碰。而行存必须把整行数据都读出来，再丢弃不需要的列。在宽表场景下，这个差距可能是几倍甚至几十倍。

压缩比方面，同一列的数据类型相同、分布相似，压缩算法能获得更好的效果。ORC默认使用ZLIB压缩，Parquet默认使用Snappy。ZLIB压缩比更高但CPU开销大，Snappy压缩比稍低但速度更快。选择哪种，取决于你的场景是CPU密集型还是IO密集型。

4.2 ORC和Parquet的选型逻辑

ORC和Parquet都是优秀的列存格式，选哪个主要看你的技术栈。如果整个链路都是Hive和Tez，ORC是更好的选择，因为它是Hive社区原生开发的，对Hive的优化支持更充分。比如ORC支持谓词下推（Predicate Pushdown）和布隆过滤器（Bloom Filter），可以在读取数据时跳过不满足条件的Stripe。

Parquet的优势在于生态兼容性更好。Spark、Impala、Presto这些引擎对Parquet的支持都很成熟。如果你的数据需要在多个引擎之间共享，Parquet是更安全的选择。

ORC的Stripe大小默认是64MB，这个值可以调整。Stripe越大，压缩效果越好，但读取时的内存开销也越大。Parquet的Row Group默认是128MB，类似的概念。实际调优时，可以根据数据特征和集群内存情况适当调整。

-- 建ORC表 CREATE TABLE employee_orc ( emp_id INT, name STRING, dept_id INT, salary DOUBLE ) STORED AS ORC TBLPROPERTIES ("orc.compress"="ZLIB", "orc.stripe.size"="67108864"); -- 建Parquet表 CREATE TABLE employee_parquet ( emp_id INT, name STRING, dept_id INT, salary DOUBLE ) STORED AS PARQUET TBLPROPERTIES ("parquet.compression"="SNAPPY");

4.3 压缩算法的取舍：Snappy、ZLIB还是LZO

压缩算法的选择需要在压缩比和CPU开销之间做权衡。Snappy的压缩速度最快，但压缩比一般，适合对查询延迟敏感的场景。ZLIB压缩比高，但压缩和解压都需要更多CPU，适合存储成本敏感、查询频率不高的场景。LZO介于两者之间，但需要额外安装，现在用得越来越少。

还有一个容易被忽略的点：压缩算法要配合文件格式使用。ORC和Parquet内部已经做了列级压缩，你不需要再对整个文件做压缩。如果对ORC文件再用GZIP压缩，反而会导致Hive无法利用ORC的谓词下推特性，因为整个文件被压缩后，Hive必须先解压才能读取元数据。

注意：TextFile格式的表可以配合GZIP或BZIP2压缩，但GZIP不支持切分，一个大GZIP文件只能由一个Map任务处理，会影响并行度。BZIP2支持切分，但压缩解压速度慢。如果一定要用TextFile，建议用Snappy或LZO。

5. SQL写法的性能分水岭：从能跑到跑得快

5.1 Join策略的选择：Map Join、Bucket Join还是Reduce Join

Hive的Join策略直接决定了SQL的性能。默认情况下，Hive使用Reduce Join（也叫Common Join），也就是把两张表的数据都按Join Key shuffle到Reduce端再做匹配。这个方式通用性强，但网络传输和磁盘IO开销大。

如果其中一张表足够小，可以放进内存，就应该用Map Join。Map Join把小表加载到每个Map任务的内存中，在Map阶段直接完成Join，省掉了Reduce阶段。Hive会自动判断是否可以用Map Join，判断依据是hive.auto.convert.join和hive.mapjoin.smalltable.filesize（默认25MB）。如果你的小表超过这个阈值，可以手动调大，或者用Hint强制指定：

SELECT /*+ MAPJOIN(small_table) */ big_table.id, small_table.name FROM big_table JOIN small_table ON big_table.id = small_table.id;

Bucket Join适用于两张表都按Join Key分了相同数量的桶的场景。前面已经讲过，这里不重复。它的优势是省掉了shuffle，但前提是分桶结构一致。

还有一种SMB Join（Sort-Merge-Bucket Join），要求两张表不仅分桶数量一致，而且桶内数据按Join Key排序。这样Join时可以做归并排序，效率更高。建表时用SORTED BY指定排序字段即可。

选择哪种Join策略，核心判断依据是：小表能不能放进内存？两张表的分桶结构是否一致？数据量差距大不大？没有万能方案，要根据具体情况选。

5.2 数据倾斜的识别与破解

数据倾斜是Hive性能问题中最常见也最头疼的一类。表现是：大部分Reduce任务很快就跑完了，但有一两个Reduce任务跑了很久，甚至OOM。根本原因是某个Join Key或Group By Key的数据量远大于其他Key。

识别数据倾斜的方法很简单：看YARN的Job日志，如果某个Reduce任务的输入记录数或耗时远高于其他任务，基本就是倾斜了。也可以用EXPLAIN看执行计划，确认Join和Group By的Key分布。

解决数据倾斜有几种常用手段。第一种是Map Join，如果小表足够小，直接广播到Map端，完全避开Reduce阶段的倾斜。第二种是加盐打散，给倾斜的Key加上随机前缀，让数据分散到多个Reduce任务，最后再去掉前缀做二次聚合：

-- 加盐打散 SELECT key, SUM(cnt) FROM ( SELECT CONCAT(key, '_', CAST(RAND() * 10 AS INT)) AS salted_key, COUNT(*) AS cnt FROM skewed_table GROUP BY CONCAT(key, '_', CAST(RAND() * 10 AS INT)) ) t GROUP BY key;

第三种是单独处理倾斜Key。先把倾斜的Key单独拎出来处理，剩下的数据正常Join，最后Union在一起。这种方式比较繁琐，但效果最彻底。

实操心得：加盐打散时，盐的个数不要太多，一般10到100之间就够了。太多会导致小文件问题，太少又起不到打散效果。另外，加盐后做二次聚合时，要注意聚合函数是否支持分步计算，COUNT和SUM可以，AVG需要拆成SUM/COUNT。

5.3 小文件问题的产生与治理

小文件是Hive的另一个顽疾。HDFS的设计初衷是存储大文件，每个文件、每个Block在NameNode里都有一条元数据记录。小文件太多，NameNode内存压力大，查询时Map任务数量也会爆炸，每个Map任务启动和销毁都有开销。

小文件的产生有几个常见原因：动态分区写入时每个分区生成一个文件；Reduce任务数量过多，每个Reduce输出一个文件；频繁的INSERT操作每次生成新文件。

治理小文件有几个层面。写入时控制：在SQL最后加DISTRIBUTE BY或CLUSTER BY，减少Reduce输出文件数；设置hive.merge.mapfiles和hive.merge.mapredfiles为true，让Hive在任务结束后自动合并小文件。定期治理：用ALTER TABLE ... CONCATENATE合并ORC文件，或者用INSERT OVERWRITE重写表。建表时预防：合理设置分区粒度，避免过度分区。

-- 开启自动合并 SET hive.merge.mapfiles = true; SET hive.merge.mapredfiles = true; SET hive.merge.size.per.task = 256000000; SET hive.merge.smallfiles.avgsize = 16000000; -- 手动合并ORC文件 ALTER TABLE employee_orc PARTITION(dt='2024-01-01') CONCATENATE;

5.4 谓词下推与列裁剪：让优化器替你干活

谓词下推和列裁剪是Hive优化器自动做的两件事，但前提是你的SQL写法要让优化器有机会做。

谓词下推是指把过滤条件下推到尽可能靠近数据源的地方。比如WHERE dt = '2024-01-01'会被下推到表扫描阶段，只读取对应分区。但如果过滤条件写在子查询里，或者用了不支持下推的函数，优化器就无能为力了。

列裁剪是指只读取SQL中用到的列。如果你写SELECT *，优化器就无法做列裁剪，必须读取所有列。所以生产环境中应该尽量避免SELECT *，明确写出需要的字段。

还有一个容易忽略的点：分区过滤要写在WHERE里，不要写在ON里。对于Join查询，写在ON里的分区条件可能不会触发分区裁剪，写在WHERE里才会。这个细节在写复杂SQL时很容易搞错。

6. 执行引擎与资源调优：让集群为你所用

6.1 MapReduce、Tez、Spark引擎的实测差异

同一个SQL在不同引擎上的表现可能差好几倍。MapReduce是最稳定的引擎，但性能最差，因为每个Stage都要落盘。Tez用DAG把多个Stage串起来，减少了中间落盘，通常比MapReduce快2到5倍。Spark引擎利用内存缓存和更高效的执行模型，在迭代计算和复杂查询上优势明显。

选择引擎要考虑几个因素：集群资源、数据量、查询复杂度、团队熟悉程度。如果集群内存充足，Spark是首选；如果追求稳定性和兼容性，Tez是不错的选择；MapReduce现在主要用于兜底和兼容老任务。

切换引擎很简单：

-- 使用Tez SET hive.execution.engine = tez; -- 使用Spark SET hive.execution.engine = spark; -- 使用MapReduce SET hive.execution.engine = mr;

但切换引擎不是没有代价的。Tez和Spark对内存的要求更高，如果Container内存配置不合理，容易出现OOM。另外，不同引擎对某些SQL特性的支持程度不同，切换前最好做充分测试。

6.2 Container内存与并行度的平衡术

Hive任务的资源分配通过YARN Container来管理。每个Map任务和Reduce任务都运行在一个Container里。Container的内存大小由mapreduce.map.memory.mb和mapreduce.reduce.memory.mb控制，默认是1024MB和1024MB。

内存给少了会OOM，给多了浪费资源。我的经验是：Map任务通常处理的是读取和过滤，内存需求相对小，1到2GB够用；Reduce任务要做聚合和Join，内存需求大，通常需要2到4GB，复杂的Join可能需要更多。

并行度由mapreduce.job.maps和mapreduce.job.reduces控制。Map任务数量通常由InputSplit数量决定，也就是文件数量和大小。Reduce任务数量默认是1，这在大数据量下是灾难性的。我一般会根据数据量设置Reduce数量，经验公式是：Reduce数量 = 数据量 / 每个Reduce处理的目标数据量，目标数据量通常设为256MB到1GB。

-- 设置Reduce数量 SET mapreduce.job.reduces = 50; -- 或者让Hive自动计算 SET hive.exec.reducers.bytes.per.reducer = 256000000; SET hive.exec.reducers.max = 1009;

注意：Reduce数量不是越多越好。每个Reduce任务都有启动开销，如果数据量不大，Reduce太多反而慢。另外，Reduce数量直接影响输出文件数，太多会导致小文件问题。

6.3 动态资源分配与队列选择

YARN的动态资源分配允许任务在运行时根据负载动态申请和释放Container。开启后，Hive任务可以先申请少量Container，随着任务推进逐步增加，避免了一次性申请大量资源导致的排队。

SET yarn.scheduler.capacity.resource-calculator = org.apache.hadoop.yarn.util.resource.DominantResourceCalculator; SET hive.server2.tez.dynamic.resource.allocation = true;

队列选择也很关键。生产集群通常有多个队列，不同队列的资源配额和优先级不同。提交任务时要根据任务的重要程度和资源需求选择合适的队列。重要任务提交到高优先级队列，探索性分析提交到低优先级队列，避免互相影响。

7. 那些只有踩过才知道的坑

7.1 数据类型的隐式转换陷阱

Hive在比较不同数据类型的字段时会做隐式转换，但这个转换规则有时候很反直觉。比如STRING和INT比较时，Hive会把STRING转成INT。如果STRING字段里有非数字字符，转换结果是NULL，比较就永远不成立。

我踩过最典型的一个坑是：用户ID在A表里是STRING，在B表里是INT，Join的时候Hive把STRING转成INT，结果所有以0开头的用户ID都匹配不上。排查了半天才发现是类型不一致导致的。

避免这类问题的办法很简单：建表时确保关联字段类型一致。如果无法统一，就在SQL里显式转换，不要依赖隐式转换。

7.2 NULL值在Join和Group By中的行为

NULL值在Hive的Join和Group By中有特殊行为。Join时，NULL不等于任何值，包括另一个NULL。所以如果Join Key里有NULL，这些记录会被丢弃。Group By时，所有NULL会被分到同一组。

这个行为在统计场景下可能导致数据偏差。比如统计订单金额时，如果用户ID为NULL的订单被Join丢弃了，总金额就会少算。解决办法是用COALESCE或NVL把NULL转成默认值，或者在Join条件里显式处理NULL。

7.3 排序的代价：ORDER BY、SORT BY、DISTRIBUTE BY、CLUSTER BY

这四个排序相关的关键字经常让人混淆。ORDER BY是全局排序，只用一个Reduce，数据量大时极慢。SORT BY是局部排序，每个Reduce内部有序，但全局无序。DISTRIBUTE BY控制数据分发到哪个Reduce，CLUSTER BY等于DISTRIBUTE BY加SORT BY。

实际使用中，如果需要全局有序且数据量不大，用ORDER BY；如果只需要每个分区内有序，用SORT BY；如果需要控制数据分发，用DISTRIBUTE BY。千万不要在大数据量下用ORDER BY，除非你确定数据量很小。

7.4 事务表的限制与适用场景

Hive从0.14版本开始支持ACID事务，但限制很多。事务表必须是ORC格式，必须分桶，不支持LOAD DATA，只支持INSERT、UPDATE、DELETE。而且事务表的性能比普通表差，因为要维护增量文件和基线文件的合并。

事务表适合的场景是：需要行级更新、数据量不大、对延迟要求不高的场景。如果只是追加数据，用普通表加分区就够了，没必要上事务表。

8. 从能用到好用：我的Hive调优清单

调优Hive SQL不是一蹴而就的事，需要结合具体场景反复试验。我把自己常用的调优手段整理成一个清单，每次遇到性能问题就按这个清单过一遍。

第一层：SQL写法层面。避免SELECT *，明确写出需要的列；分区过滤写在WHERE里；小表Join大表时用Map Join；数据倾斜时加盐打散；避免在WHERE里对字段做函数操作，否则无法触发分区裁剪。

第二层：存储格式层面。核心表用ORC或Parquet；根据场景选择压缩算法；控制分区粒度，避免过度分区；定期合并小文件；对核心表跑统计信息。

第三层：执行引擎层面。根据集群情况选择Tez或Spark；合理设置Map和Reduce的内存；根据数据量调整Reduce数量；开启动态资源分配。

第四层：集群配置层面。优化MetaStore的数据库性能；确保YARN队列配置合理；监控NameNode的内存使用，及时清理无用的小文件。

这个清单不是万能的，但覆盖了大部分常见问题。实际调优时，先用EXPLAIN看执行计划，找到瓶颈在哪，再针对性地优化。不要盲目调参数，每个参数都有适用场景，用错了反而适得其反。

我在实际使用中发现，很多性能问题其实在SQL写出来的时候就已经注定了。与其花几个小时调参数，不如在写SQL的时候多花几分钟想想：这个Join能不能用Map Join？这个分区过滤能不能下推？这个聚合会不会倾斜？好的SQL写法，比任何参数调优都管用。