简介本资源为基于 hortonworks/hive-testbench 编译的 Hive 性能测试程序面向大数据开发工程师、数据仓库从业者及需要评估 Hive 性能的测试人员。它提供了一套完整的测试用例与脚本用于模拟数据加载、查询执行等操作帮助定位 Hive 在稳定性、资源消耗与查询效率上的瓶颈为调优提供量化依据。压缩包共约 2000 个文件整体 64.25MB以 class 编译产物、log 运行日志、sql 测试脚本、ans 预期结果、tpl 模板及 jar 依赖为主另含少量 sh 启动脚本、properties 配置与 xml 描述文件覆盖从构建到执行的完整链路。目前已有 395 人学习下载。通过该资源读者可获取可直接运行的测试程序与配套脚本结合日志与结果文件对比不同配置下的性能差异理解 HiveQL、Metastore 与执行引擎的协作机制为实际集群调优积累可复用的测试数据与排错思路。1. 从一次压测翻车说起Hive 性能测试程序到底测什么很多人第一次接触 Hive 性能测试都是被一个很朴素的问题逼出来的集群刚扩容完老板问“现在到底能扛多少并发”或者调参之后想验证“这次改动是不是真的有效”。没有一套标准化的压测程序你只能靠拍脑袋或者拿几条自己写的 SQL 跑一跑结果既不可复现也没法横向对比。Hive 性能测试程序hive-testbench就是为解决这个问题而生的——它提供了一套从数据生成到查询执行的完整基准测试框架核心是 TPC-DS 和 TPC-H 两套标准查询集配合可配置的数据规模让你能在自己的集群上跑出可对比、可复现的性能数据。这套东西适合谁一是负责集群调优的运维或平台工程师需要量化验证参数改动的效果二是做数仓选型或迁移的团队想对比不同版本、不同引擎比如 Hive on Tez 和 Hive on Spark的实际表现三是准备面试或学习 Hive 执行计划的开发者想拿真实的大查询练手。它不解决业务问题但能帮你把“性能”这件事从玄学变成可测量的工程指标。2. 编译前的环境准备从源码到可执行包的完整链路hive-testbench 本质上是一组 Shell 脚本加 Hive SQL 模板外加一个用于生成 TPC-DS/TPC-H 数据的工具链。它不依赖复杂的构建系统但对环境有比较明确的要求。很多人卡在第一步不是因为难而是因为没搞清楚它到底需要什么。2.1 依赖组件与版本匹配这套程序的核心依赖是 Hadoop 和 Hive 的客户端环境因为它最终是通过hive或beeline命令提交查询的。你需要确保集群的 Hive 版本与 testbench 脚本中引用的 SQL 语法兼容。常见做法是先确认集群 Hive 版本然后选择对应分支的 testbench 源码。比如 Hive 2.x 和 Hive 3.x 在 Tez 引擎配置上有差异如果混用查询可能直接报错。另外数据生成阶段依赖dsdgen和dbgen这两个工具它们来自 TPC 官方工具包testbench 的脚本里已经包含了编译逻辑。你需要的是 GCC 编译环境、make 工具以及足够的本地磁盘空间来存放生成的数据文件。我一般会预留至少 100GB 的临时空间因为 1TB 规模的数据生成过程中中间文件会占用大量空间。提示不要试图在 Hive 服务端节点上直接跑数据生成最好找一台有客户端环境、磁盘充足的边缘节点生成后再上传到 HDFS。2.2 获取源码与目录结构说明从 GitHub 获取源码后你会看到几个关键目录tpcds、tpch、bin、sbin。tpcds和tpch下分别有gen_data、run_query等脚本bin里是通用的工具脚本。整个项目的设计思路是先生成数据到本地或 HDFS再创建 Hive 表并加载数据最后执行查询集并记录耗时。# 克隆源码到本地 git clone https://github.com/hortonworks/hive-testbench.git cd hive-testbench # 查看目录结构确认脚本存在 ls -l tpcds/ tpch/ bin/ sbin/这段命令只是把代码拉下来但要注意不要直接在生产集群的 Hive 服务节点上执行克隆和编译避免污染环境。我习惯在独立的客户端机器上操作编译完成后再把生成的 jar 包和脚本分发到需要执行查询的节点。2.3 编译数据生成工具testbench 的数据生成工具需要现场编译因为不同平台的二进制不通用。编译入口在tpcds/gen_data和tpch/gen_data目录下脚本会自动调用make。但这里有个坑默认的 Makefile 可能针对特定平台做了优化如果你的 GCC 版本较新可能会报一些警告甚至错误。# 进入 tpcds 数据生成目录 cd tpcds/gen_data # 执行编译生成 dsdgen 可执行文件 make clean make # 检查是否生成成功 ls -l dsdgen编译逻辑说明make clean先清理旧对象文件避免残留导致链接错误make会根据 Makefile 中的规则编译 C 源码。参数方面如果你需要调整生成数据的并行度可以修改 Makefile 中的CFLAGS加上-O2优化编译速度。编译成功后当前目录会出现dsdgen可执行文件这就是后续生成 TPC-DS 数据的核心工具。对于 TPC-H操作类似只是工具名变成dbgen。两个工具的参数体系不同TPC-DS 的dsdgen支持按比例因子scale factor生成比如-SCALE 1000表示生成 1TB 数据TPC-H 的dbgen用-s参数指定规模-s 100表示 100GB。3. 数据生成与建表把 TPC-DS 数据集灌进 Hive编译只是热身真正耗时间的是数据生成和加载。这一步的细节决定了你后续查询测试的成败因为数据分布不对查询性能就失去参考意义。3.1 用 dsdgen 生成指定规模的数据TPC-DS 的数据模型包含 24 张表其中事实表有store_sales、catalog_sales、web_sales等维度表有date_dim、customer、item等。生成数据时dsdgen会按照比例因子自动计算各表行数。比如比例因子 1000 对应约 1TB 原始数据其中store_sales表会有数十亿行。# 在 tpcds/gen_data 目录下执行生成 100GB 规模的数据 ./dsdgen -SCALE 100 -DIR /data/tpcds_100g -TERMINATE N -FORCE # 参数解释 # -SCALE 100比例因子100 约等于 100GB # -DIR指定输出目录必须存在且可写 # -TERMINATE N不在每行末尾加分隔符保持默认格式 # -FORCE覆盖已存在的文件生成过程可能持续几十分钟到数小时取决于磁盘 IO 和 CPU。我一般会开多个终端并行生成不同的表但要注意dsdgen默认是单线程的并行需要手动拆分表名。一个取巧的做法是用-CHILD和-PARALLEL参数让多个进程分别生成数据分片最后合并。但合并时要注意文件顺序否则加载到 Hive 后数据会错乱。注意生成过程中如果中断重新执行时一定要加-FORCE否则会提示文件已存在而跳过导致数据不完整。3.2 创建 Hive 表并加载数据数据生成到本地后需要上传到 HDFS然后创建对应的 Hive 外部表。testbench 提供了create_table.sql模板但直接执行往往会因为路径、分隔符不匹配而失败。我一般会先检查模板中的LOCATION和ROW FORMAT设置。-- 以 store_sales 表为例创建外部表并指定分隔符 CREATE EXTERNAL TABLE IF NOT EXISTS store_sales ( ss_sold_date_sk INT, ss_sold_time_sk INT, ss_item_sk INT, ss_customer_sk INT, ss_cdemo_sk INT, -- 省略其余字段 ss_ext_sales_price DECIMAL(7,2) ) ROW FORMAT DELIMITED FIELDS TERMINATED BY | STORED AS TEXTFILE LOCATION /tpcds/store_sales;这段 SQL 的关键在于FIELDS TERMINATED BY |因为dsdgen默认用竖线分隔字段。如果你生成时改了分隔符这里必须同步修改。另外LOCATION指向 HDFS 上的目录需要提前把本地数据文件上传上去。# 上传数据到 HDFS hdfs dfs -mkdir -p /tpcds/store_sales hdfs dfs -put /data/tpcds_100g/store_sales.dat /tpcds/store_sales/ # 刷新表分区如果是分区表 hive -e MSCK REPAIR TABLE store_sales;加载完成后建议先跑一个COUNT(*)验证行数是否与预期一致。如果行数偏差很大通常是分隔符或换行符问题。TPC-DS 生成的数据中某些字段可能包含换行符导致 Hive 读取时行数膨胀。解决办法是在建表时加上ESCAPED BY \\并在生成数据时用-TERMINATE N避免多余分隔符。3.3 查询集执行与耗时采集testbench 的查询集在tpcds/run_query目录下每个查询是一个独立的.sql文件。执行方式很简单但采集耗时需要自己封装。# 执行单个查询并记录耗时 start_time$(date %s) hive -f tpcds/run_query/query1.sql /dev/null 21 end_time$(date %s) echo Query1 耗时: $((end_time - start_time)) 秒如果要批量执行所有查询可以写一个循环脚本把每个查询的耗时输出到 CSV 文件。这里有个细节Hive 的查询编译时间也计入总耗时如果你只想测执行时间可以用EXPLAIN先预热或者用beeline的--outputformatcsv参数只取结果。我一般会跑三轮取平均值第一轮预热后两轮取稳定值。4. 避坑与排查那些让你白跑一整天的细节这套程序看起来只是脚本加 SQL但实际跑起来坑一个接一个。下面这几条是我和同行踩过的血泪经验按现象、原因、解决三段式整理。4.1 数据生成报错“Cannot open file”现象执行dsdgen时提示无法打开输出文件进程直接退出。 原因-DIR指定的目录不存在或者当前用户没有写权限。dsdgen不会自动创建目录。 解决提前用mkdir -p创建目录并确认chmod 755权限。如果目录在 NFS 上还要检查挂载参数是否支持大文件写入。4.2 查询执行报“Vertex failed”或内存溢出现象跑 TPC-DS 的复杂查询时Tez 任务失败日志显示容器内存超限。 原因TPC-DS 的某些查询如 query 72、query 88会产生巨大的中间结果默认的容器内存配置不够。 解决调整hive.tez.container.size和hive.tez.java.opts一般建议容器内存不低于 4GBJava 堆设为容器大小的 80%。同时检查tez.runtime.io.sort.mb是否过小导致频繁溢写。4.3 表行数与预期严重不符现象COUNT(*)结果比 TPC-DS 官方文档给出的行数少很多或多很多。 原因数据文件中的换行符与 Hive 默认行分隔符冲突或者字段分隔符设置错误。 解决用head查看原始数据文件确认分隔符和换行符。建表时显式指定LINES TERMINATED BY \n并加上ESCAPED BY \\。如果已经建表可以重建外部表并重新加载。4.4 查询耗时波动极大现象同一个查询两次执行耗时相差数倍。 原因Hive 的查询结果缓存、Tez 会话复用、集群其他任务干扰都会影响耗时。 解决每次测试前清理缓存hive -e CLEAR CACHE关闭 Tez 会话复用set hive.tez.container.reusefalse并确保集群没有其他大任务在跑。最好在固定时间段测试记录多次结果取中位数。4.5 编译 dsdgen 时链接失败现象make报错“undefined reference topthread_create”。 原因Makefile 中缺少-lpthread链接选项或者 GCC 版本对 POSIX 线程库的默认链接行为有变化。 解决手动修改 Makefile在LDFLAGS中加上-lpthread然后重新make clean make。如果还不行检查系统是否安装了glibc-static和libstdc-static。5. 进阶技巧让压测结果真正可对比跑通一遍不算本事能让结果在不同时间、不同集群之间横向对比才算把这套工具用到位。下面这几个习惯是我从多次翻车中总结出来的。5.1 固定测试基线与环境快照每次压测前记录集群的节点数、内存、磁盘类型、Hive 版本、Tez 版本、关键参数如hive.exec.dynamic.partition.mode、tez.am.resource.memory.mb。这些信息不记录后面看到耗时差异你根本不知道是参数改了还是机器换了。我一般会写一个env_snapshot.sh在测试前自动采集这些信息并输出到日志。#!/bin/bash # 采集环境快照 echo 集群节点 env_snapshot.log yarn node -list 2/dev/null | grep -c RUNNING env_snapshot.log echo Hive 版本 env_snapshot.log hive --version 21 | head -1 env_snapshot.log echo 关键参数 env_snapshot.log hive -e set hive.tez.container.size; set tez.am.resource.memory.mb; env_snapshot.log 21这个脚本输出的信息虽然简单但在对比两次测试结果时能帮你快速排除环境差异。比如某次耗时突然增加 30%一看快照发现节点数从 10 变成了 8那就不用纠结参数了。5.2 用查询子集做快速回归TPC-DS 完整跑一遍 99 个查询在 1TB 规模下可能要几个小时。日常调参不需要每次都全跑可以挑 10 个代表性查询组成子集覆盖不同的执行计划特征有的走 MapJoin有的走 Common Join有的产生大量 shuffle。我常用的子集是 query 3、query 7、query 26、query 42、query 55、query 68、query 72、query 88、query 96、query 99。这 10 个查询跑下来大约 20 分钟足够判断参数改动是否有效。# 快速回归脚本只跑选定的查询 for q in 3 7 26 42 55 68 72 88 96 99; do start$(date %s) hive -f tpcds/run_query/query${q}.sql /dev/null 21 end$(date %s) echo query${q},$((end - start)) quick_regression.csv done跑完后把 CSV 导入表格对比上次结果。如果某个查询耗时变化超过 15%就重点排查该查询的执行计划。这种快速回归能让你在半小时内验证一个参数猜想而不是等一整天。5.3 结果验证别只看耗时耗时短不代表结果对。有一次我调了一个参数查询快了 40%后来发现是因为结果集被截断了。所以每次压测后必须验证关键查询的结果行数和校验和。TPC-DS 官方提供了结果校验工具但用起来麻烦。我的做法是对每个查询记录COUNT(*)和SUM()某个数值字段和基线对比。如果数值不一致说明查询逻辑或数据加载有问题耗时再短也没有意义。-- 以 query 3 为例验证结果 SELECT COUNT(*) AS cnt, SUM(ss_ext_sales_price) AS total FROM store_sales WHERE ss_sold_date_sk BETWEEN 2451149 AND 2451179;把这条 SQL 的结果和上次对比如果cnt和total完全一致才认为查询执行正确。这个习惯让我避免了好几次“假优化”的尴尬。从那以后我每次跑压测都强制走一遍环境快照、快速回归、结果校验这三步哪怕再急也不跳过。希望这些经验能帮到你少走点弯路。本文还有配套的精品资源点击获取