Spark on Databricks：Hive事实表缓存性能优化技术咨询

针对你遇到的Hive表缓存后性能未达预期的问题，结合30列Parquet事实表的场景，我整理了几个实用的优化方向，你可以根据实际情况尝试：

1. 先裁剪数据再缓存，减少无效内存占用 #

你的表有30列，但大部分计算可能只用到其中一部分列，甚至特定行数据。全表缓存会浪费大量内存存储用不到的数据，反而拖慢缓存加载和查询速度。建议只缓存查询需要的列和过滤后的行：

-- 示例：只缓存常用的10列+过滤近30天的数据
CACHE TABLE f_traffic_cached 
AS SELECT col1, col2, ..., col10 
FROM f_traffic 
WHERE dt >= date_sub(current_date(), 30);

如果用Spark API操作，也可以先做数据裁剪再缓存：

val filteredTraffic = spark.table("f_traffic")
  .select("col1", "col2", ..., "col10")
  .filter("dt >= date_sub(current_date(), 30)")
filteredTraffic.cache() // 或用persist指定更合适的存储级别
filteredTraffic.write.mode(SaveMode.Overwrite).saveAsTable("f_traffic_cached")

2. 调整缓存存储级别，适配内存情况 #

默认的CACHE TABLE使用MEMORY_ONLY级别，如果表数据量较大，内存不足以容纳全表，Spark会自动把部分数据溢写到磁盘，导致查询时频繁读写磁盘，速度骤降。建议换成序列化存储级别，减少内存占用同时避免频繁磁盘IO：

-- 使用MEMORY_AND_DISK_SER级别，序列化存储在内存，内存不足时存磁盘
CACHE TABLE f_traffic 
OPTIONS ('storageLevel' 'MEMORY_AND_DISK_SER');

如果集群内存充足，也可以尝试MEMORY_ONLY_SER，序列化后数据体积通常能减少30%-50%，进一步降低内存开销。

3. 结合分区/分桶优化，缓存热点数据 #

如果你的事实表没做分区，建议先按业务常用维度（比如时间dt）做分区——很多计算往往只涉及部分分区（比如最近几周的数据），只缓存这些热点分区就能覆盖大部分查询需求，避免全表缓存的资源浪费：

-- 先给表添加分区（如果还没做的话）
ALTER TABLE f_traffic ADD PARTITION (dt='2024-01-01') LOCATION 's3://path/to/partition';
-- 只缓存最近30天的分区
CACHE TABLE f_traffic_recent AS SELECT * FROM f_traffic WHERE dt >= date_sub(current_date(), 30);

针对需要频繁join/聚合的场景，可以把表改成分桶表，分桶后数据分布更均匀，缓存后查询时能减少shuffle开销，提升计算速度：

-- 创建分桶表示例（按user_id分100桶）
CREATE TABLE f_traffic_bucketed (
  col1 string,
  col2 int,
  ...
)
CLUSTERED BY (user_id) INTO 100 BUCKETS
STORED AS PARQUET;
-- 插入数据后缓存分桶表
INSERT OVERWRITE TABLE f_traffic_bucketed SELECT * FROM f_traffic;
CACHE TABLE f_traffic_bucketed;

4. 优化Parquet文件结构，降低缓存加载开销 #

S3上的Parquet如果存在大量小文件（比如<64MB），缓存时需要读取大量文件元数据，加载速度会很慢。建议先合并小文件，调整到合适的文件大小（通常128MB-256MB是最优的）：

// 合并小文件，重新写入表
spark.read.table("f_traffic")
  .repartition(100) // 根据数据量调整分区数，确保每个文件大小在128MB左右
  .write.mode(SaveMode.Overwrite)
  .option("mergeSchema", "true")
  .saveAsTable("f_traffic_optimized")
// 缓存优化后的表
%sql CACHE TABLE f_traffic_optimized;

5. 检查缓存命中率，确保查询命中缓存 #

有时候缓存后速度没提升，是因为查询没有命中缓存（比如查询的列/过滤条件和缓存的表不一致）。你可以通过以下方式排查：

• 用%sql SHOW CACHE查看缓存的表信息，确认缓存状态正常；
• 打开Spark UI的Storage标签，查看缓存的Hit Rate（命中率），如果命中率低于80%，说明缓存的内容和查询不匹配，需要调整缓存的表结构或查询语句。

6. 预计算聚合结果缓存，替代原始表缓存 #

如果你的大量计算都是基于聚合操作（比如sum、count、group by），直接缓存原始事实表不如缓存预聚合后的结果表高效。比如：

-- 缓存按天按用户的聚合结果
CACHE TABLE f_traffic_daily_agg 
AS SELECT dt, user_id, sum(traffic) as total_traffic, count(*) as visit_count 
FROM f_traffic 
GROUP BY dt, user_id;

后续查询直接使用这个聚合缓存表，能大幅减少计算量，速度提升会非常明显。

内容的提问来源于stack exchange，提问作者datahack