前几天同事跑基准测试手里一份日志数据集超过 2GB按测试规范要求压缩到 250MB 以内才能提交。他问我这种缩减到底是怎么做的采样策略算法上有没有标准答案其实这个问题把 benchmarks 里一个很容易被忽视的环节摊开了——数据集datasets的规模控制。很多人都以为缩减就是随机抽几行但真到了具体场景里怎么抽、按什么维度抽、比例怎么定、抽完怎么验证每一步都有讲究。这篇文章我就把实际项目中用过的做法、踩过的坑、以及各类采样策略sampling strategy的适用边界一次性讲清楚。1. 250MB 数据集红线是怎么来的缩减背后的四个现实约束先说一个基本判断250MB 这个数字本身不是一个物理定律而是工程权衡的结果。不同项目里这个阈值可以是 100MB、512MB、1GB但作用都一样——把测试数据约束在一个够用但不失控的规模。这个约束主要来自四个现实因素。1.1 内存和测试时长最直接的两座大山基准测试通常要跑很多轮配合不同参数、不同版本、不同硬件配置横向对比。假设一份 2GB 的数据某项查询跑一次要 3 分钟改成 250MB 后可能只需要 20 秒。如果一轮 benchmark 要跑 20 种查询、5 组配置全量数据要跑 5 小时缩减后 30 分钟就能收工。这中间的差距决定了你一天能迭代几轮。对于做性能回归的人来说这个差距就是效率的分水岭。内存就更现实了。很多测试环境是容器化的内存配额就 4GB 或者 8GB。2GB 的原始数据在加载阶段就可能触发内存压力导致 GC 抖动明显最后测出来的数字混入了资源争抢的噪声反而不如一份小但可控的数据集靠谱。1.2 可复现性和版本控制基准测试的生命线基准测试最重要的属性是可复现。你不可能在文档里写拿那份 2GB 的数据去测数据文件放在共享盘上哪天被人清理了结论就永远无法重新验证。所以很多团队会把基准测试数据集纳入版本控制随代码一起发布。像 Git 这类工具对单文件大小有严格限制超过 100MB 就开始告警250MB 的数据集即使通过 LFS 管理拉取和存储成本也明显更高。这里要提醒一句如果你发现自己的 benchmark 数据是躺在某个临时目录里手工下载的那数据缩减就不只是优化而是刚需。把数据压到可入库、可分发、可追溯的规模才是这套做法真正解决的问题。1.3 测试环境的多样性小数据集是兼容性保障我还遇到过一类场景基准测试需要在多个环境上跑有些环境是标准的云主机有些是开发同学的本地机器。本地机器通常没有几 GB 内存和大量磁盘空间给测试数据用。如果数据集可以压到 250MB那么任何一台笔记本电脑都能复现测试这大大降低了参与 benchmark 的门槛。换句话说缩减数据不只是为了快还是为了让更多环境能跑得起同一套测试。1.4 直接给结论什么时候真要缩减什么时候别硬减先想清楚你缩减数据的目的再决定怎么做。一般来说下面三种情况是真需要缩减的CI/CD 里的性能回归测试每一轮提交都要跑时间窗口有限要对外发布可复现基准测试包数据需要入库管理开发调试阶段需要快速验证 query 的正确性和执行计划变化。对应的如果你是做最终性能报告、上线前的容量评估那千万不要减。这种场景用全量数据跑跑得再久也要忍。缩减数据集只能用于趋势验证和质量筛选不能替代最终的全量压测。把这个定位想清楚后面所有采样策略的选择才不会跑偏。2. 缩减不只是抽几行场景裁剪和行级采样是两条完全不同的路很多人提到数据集缩减第一反应就是抽样。但实际工程里缩减数据有两个维度一个是砍掉不关心的部分另一个是保留结构但缩小规模。这两个维度我分别叫它场景裁剪和行级采样。搞清楚它们的区别能帮你省不少功夫。2.1 场景裁剪只留核心 workload只留关键字段场景裁剪是从业务维度砍掉对整个测试没有价值的数据。具体做法有两种。第一种是裁剪字段原始数据表里有 50 个字段但你的 benchmark 只涉及其中 8 个字段那其余 42 个字段完全可以删除。别看这招简单实际压测中它带来的体积缩减非常可观。比如日志类数据原始行里可能包含完整的请求头、埋点参数、堆栈信息这些内容占到行大小的一大半但测试链路根本用不到。去掉之后2GB 的 CSV 可能直接变成 400MB。第二种是裁剪查询场景一个数据集对应 100 类查询请求但你的基准测试只关心其中 20 类核心查询。那么就可以把其他查询对应的数据模式从数据集中移除。这种方法要注意的是不能只删除那条查询涉及的记录因为不同查询之间可能隐式共享某些数据特征。实际中更稳妥的做法是先确定核心 workload 的数据访问模式再只保留这些模式触及的数据表和相关分区。2.2 行级采样保留整体结构缩小数据规模行级采样是标题里问的重点。它的思路是文件还是那个文件表还是那张表字段还是那些字段但行数按比例减少。这样数据的形状不变体积变小workload 的运算逻辑也不变测出来的执行计划才具有可比性。这一条是整个基准测试缩减方法里性价比最高、应用最广的路线。但它有一个容易被低估的问题采样怎么做直接决定了缩减后的数据能不能代表全量。如果只是简单地每隔 10 行取 1 行遇到数据在磁盘上按时间排序的场景你的样本可能只覆盖了前几天的数据某些周期性的特征全丢了。这个问题我们下一章展开讲。2.3 我通常怎么选看 workload 类型不拍脑袋我的选择逻辑是这样的如果瓶颈主要在字段宽、记录多但查询模式非常固定优先做场景裁剪因为它最直接还能顺带减少测试脚本的复杂度如果瓶颈在于数据行数大、分布特征复杂、需要保留数据的统计特性就用行级采样。在大多数实操里两种方法会组合使用。比如先裁剪字段把 2GB 降到 800MB再用采样把 800MB 降到 250MB 以下。只靠单一手段硬压往往会把样本质量压得很差。记住一个原则先做无损或低损裁剪再做有损采样。顺序反了的话采样的偏差会被后续裁剪再次放大。3. 采样策略全景图六种方法各自保住了什么又丢掉了什么这是本章最核心的内容。从实践角度我把基准测试里常用的采样策略整理成六种简单随机采样、分层采样、哈希确定性采样、系统采样、偏斜采样、残差采样。它们在不同场景下各有不可替代的价值但也有很多细节坑。3.1 简单随机采样最省事也最容易翻车简单随机采样的意思是每一行数据以相同的概率 p 被保留。说起来最简单实现也最简单import random def simple_random_select(p: float, row_index: int) - bool: random.seed(row_index) return random.random() p这里有一个隐蔽的坑random.seed(row_index)这种方式虽然可复现但如果是在分布式环境下多个 worker 同时生成随机数序列很难保证跨进程的一致性。另外简单随机采样对行内聚性完全无感——如果数据是一张订单表和一张订单明细表的 join 结果按行随机采样后某个订单只保留了部分明细join 基数就会失真后续查询性能根本没法还原全量行为。所以在真实 benchmark 中简单随机采样只适合两类场景一类是每条记录之间完全独立、关联性不强的数据比如独立事件日志另一类是快速验证流程是否跑通的冒烟测试对精度要求不高。其他情况直接用容易翻车。3.2 分层采样保住类别比例的小心思如果数据中有明显的类别字段比如 90% 的搜索点击行为和 10% 的购买行为简单随机采样很容易让小类别在样本里消失。假设保留比例 p12.5%在极端情况下购买行为可能只剩 1.25%计算链路里的聚合函数、连接操作都没法测出像样的延迟。分层采样就是为这个场景设计的先按类别把数据分成多个层再在每一层内独立做随机采样。这样每一层都能保留自己 12.5% 的数据整体上类别比例和全量数据保持一致。实现上有两种做法。一种是先按类别分组再对每组装桶计数另一种更高效的做法是用一个类别编码拼接上原始记录的唯一 ID 来作为采样键。分层采样的问题在于它对层的定义很敏感。层分得越细每层内能抽到的样本就越少小层的数据量可能不足以支撑有统计意义的基准测试。所以分层不是越细越好一般情况下分到业务上最重要的 1-2 个维度就够用了。3.3 哈希确定性采样基准测试场景下的默认答案哈希确定性采样是我在实际项目里用得最多的方案。它的原理是对每条记录的某个关键字段比如 user_id、order_id做哈希然后看哈希值是否落在保留区间内。同一个 key 的哈希值永远一样所以同一个 user 的所有记录要么全部保留要么全部丢弃不会出现随机采样那种用户被拆散的问题。关键代码长这样import hashlib def hash_select(key: str, keep_ratio: float, seed: int 42) - bool: # 使用 md5 而不是内置 hash()原因见下文 digest hashlib.md5(f{seed}:{key}.encode(utf-8)).hexdigest() # 取前 4 个十六进制字符映射到 0~65535 bucket int(digest[:4], 16) # 65535 是 0xFFFF这里做了一个归一化 return bucket / 0xFFFF keep_ratio这里有一个必须踩过的坑不要用 Python 内置的hash()做确定性采样。Python 字符串的哈希默认带有随机种子PYTHONHASHSEED同一字符串在不同进程里哈希结果不一样样本集就没法复现。用 hashlib.md5 或 sha1 这类明确指定算法的哈希函数才能保证结果跨进程、跨机器完全一致。哈希确定性采样的第二个优势是天然支持并行。你可以把整个数据集按 hash 值分桶多台机器各自处理一部分桶最后合并需要按比例缩减时直接调整 keep_ratio不需要重新扫描全量数据。第三个优势是对后续增量扩展友好。如果先按 12.5% 采样出了 250MB后来发现还得再压到 100MB你只需要把 keep_ratio 从 0.125 改到 0.05同一个哈希函数和种子就能再次稳定地抽样而且第二次的样本恰好是第一次样本的子集。这在反复调优 benchmark 数据集的时候非常有用。3.4 系统采样、偏斜采样与残差采样系统采样是每隔 N 行取一行的策略。它实现简单也没有随机性因此在某些传统数据库测试里很常见。但它有一个致命问题如果数据在物理存储上存在周期性规律比如每天固定时间段的请求量高峰固定间隔采样会和这个周期产生共振导致样本严重失去代表性。我的建议是除非你对数据分布非常有信心否则不要在基准测试里用系统采样。偏斜采样是专门制造热点场景的采样策略。比如你想测试缓存热点、商品秒杀这类压力场景可以在采样时故意放大高频率 key 的保留比例缩小低频 key 的保留比例。它不是为了代表全量而是为了放大极端。这类采样适合做专项压力测试不适合做通用基准测试。残差采样严格来说不是一种采样策略而是一种补充手段先用主策略采样然后把那些采样中被丢掉但业务上至关重要的记录比如 VIP 用户、核心商户重新加回来。比如按 event_id 哈希采样后你发现某些核心用户的记录几乎全被丢掉了那就手动把这些人保留。这个做法不精确但非常实用能在保持基准公平性的同时确保关键场景不被采样抹掉。3.5 选型对照表策略核心逻辑保留了什么丢掉了什么推荐场景简单随机采样每行等概率独立保留总体大致分布行间关联、长尾小类独立事件日志、冒烟测试分层采样按类别分组再抽样类别比例层内细节、层间关联类别不平衡的数据哈希确定性采样按 key 哈希分桶key 级完整性低基数字段特征需要可复现的常规基准系统采样每隔 N 行取一行实现简单周期共振风险仅对均匀数据可用偏斜采样放大热点 key热点行为总体代表性热点压测专项残差采样主采样后补回关键记录关键业务实体无严格统计保证核心用户不可丢时另外补充一个容易混淆的点LIMIT 不是采样。有些测试脚本为了省事直接在查询 SQL 的末尾加LIMIT 200000这取的是物理存储顺序里最前面的 20 万行不是随机样本也不是分层样本它会强烈偏向数据写入初期的特征。做数据缩减一定要在数据预处理阶段做而不是在查询阶段用 LIMIT 糊弄。4. 从 2GB 压到 250MB 的一次完整实操以哈希确定性采样为例理论讲再多不如完整走一遍流程。下面我用一个实际场景演示怎么做假设你有一份 2GB 的用户行为日志目标是压到 250MB 以下同时尽量保留原数据的统计特性和查询行为。4.1 第一步先做一次数据分布体检动手采样之前必须先弄清楚这 2GB 数据长什么样。至少要回答下面几个问题数据总量多少行每行平均大小多少主键或核心关联键是什么业务上按哪个维度做关联数据的时间跨度多大是否有明显的周期特征有没有分布严重不均的类别字段未来基准测试要用到哪些查询这些查询 join 的键是什么这一步决定了你不是在盲人摸象。我一般先用一个轻量脚本扫一遍# 快速统计行数 wc -l user_logs.csv # 看前几行结构 head -5 user_logs.csv # 看总体文件大小 du -h user_logs.csv不要跳过这一步。我见过有人直接在 2GB 数据上按 user_id 哈希采样采完后才发现 user_id 是空的或者大量为空等于拿一个无效 key 做分桶样本完全失真。先体检再动手这是原则。4.2 第二步定采样键、采样比例和种子采样键的选择是整件事最关键的一环。原则是选那个在后续查询里被 join 或被 group by 的高基数字段。在行为日志里通常是 user_id 或者 device_id在订单场景里通常是 order_id 和 customer_id 的组合在 IoT 场景里可能是 sensor_id。采样比例的计算方式很简单期望目标大小 250MB 当前大小 2GB 2048MB 采样比例 250 / 2048 ≈ 0.122为了保险我会把目标比例再留 10% 的余量所以取 0.11 而不是 0.122。因为采样后的数据在文件序列化时还会有些额外开销压缩格式也影响实际大小。宁可多采一点然后验证后再调整也不要一开始采得太大导致后续反复重跑。种子seed是很多人忽略的点。seed 的作用是让哈希结果固定只要 seed 不变每次生成的样本就完全一样。这个 seed 相当于你这次采样版本的标识建议用日期加版本号比如 42 或者 20250101并且写进采样脚本的注释里。以后别人想复现你的数据集只要知道 seed、哈希算法和采样比例就能重新生成。4.3 第三步单遍流式采样代码数据有 2GB不能一次性读进内存用单遍流式扫描就可以了。下面这段代码是我项目里简化出来的版本足够处理几 GB 的 CSV 文件import hashlib import csv import sys def hash_select(key: str, keep_ratio: float, seed: int) - bool: digest hashlib.md5(f{seed}:{key}.encode(utf-8)).hexdigest() bucket int(digest[:4], 16) return bucket / 0xFFFF keep_ratio def sample_csv(input_path: str, output_path: str, key_col: int, keep_ratio: float, seed: int 42): with open(input_path, r, newline, encodingutf-8) as fin, \ open(output_path, w, newline, encodingutf-8) as fout: reader csv.reader(fin) writer csv.writer(fout) header next(reader) writer.writerow(header) for row in reader: key row[key_col] if hash_select(key, keep_ratio, seed): writer.writerow(row) if __name__ __main__: # 参数输入文件 输出文件 key列索引 采样比例 种子 sample_csv(sys.argv[1], sys.argv[2], int(sys.argv[3]), float(sys.argv[4]), int(sys.argv[5]))注意看这行bucket int(digest[:4], 16)它取前四个十六进制字符映射到一个 0~65535 的整数。整个哈希过程只需要计算一次 md5不需要随机状态不需要跨进程通信所以跑几十 GB 的文件也不会太慢。采样完成后建议顺手统计一下输出文件的行数和大小这一步能帮你尽早发现比例是否算错。4.4 第四步采样质量的三项体检样本生成完不等于大功告成。我每次都会做三项检查它们能在十几分钟内帮你看穿这次采样是否合格。第一项是规模检查样本文件大小是否在目标范围内。如果明显超过 250MB可能是字段里包含大量长文本需要裁字段如果明显偏小说明采样键或比例可能不对。第二项是分布检查抽样比较全量数据与样本数据在关键维度上的分布。比如对比用户活跃等级的占比-- 全量统计 SELECT user_level, COUNT(*) / (SELECT COUNT(*) FROM full_table) AS ratio FROM full_table GROUP BY user_level; -- 样本统计 SELECT user_level, COUNT(*) / (SELECT COUNT(*) FROM sample_table) AS ratio FROM sample_table GROUP BY user_level;如果两个 ratio 差得太多就说明当前策略没有保住关键分布需要换成按 user_level 做分层哈希采样。这里我强调一下分层哈希的组合技巧先用md5(seed:user_level)把数据分成几层层内再用哈希确定性采样既保住了类别比例又保住了 key 的完整性。第三项是关联完整性检查如果测试 workload 涉及多表 join你需要验证样本里的外键关系没有断。例如全量数据中 user_id 和 order_id 的对应关系是 1 对 5在样本里也应该接近 1 对 5。最简单的方法是先跑一条小聚合查询对比全量和样本的 JOIN 基数偏差超过 10% 就要考虑换采样键。5. 样本数据跑出来的数字到底能不能信很多人在数据缩减完成后直接拿着样本上的 benchmark 结果跟全量历史数据对比发现数字对不上就开始怀疑采样策略。其实这里还有一道坎样本上的性能结论不能简单乘除回全量。这也是整个话题里最容易被误解的部分。5.1 样本性能数据不能你乘我除地外推假设样本是全量的 12.5%样本上某个查询跑了 100ms你是不是想说全量要跑 800ms不对。真实情况可能差很多原因有三个数据量变小后整个工作集可能放进内存甚至 CPU 缓存执行路径彻底变化并行度不变时数据量小时网络和磁盘 I/O 的调度模式与全量完全不一样某些查询优化器会根据统计信息切换执行计划样本的行数和基数会让优化器选择一条完全不同的 join 策略。所以样本上的结果只能用来对比不同版本之间的相对趋势。比如 A 版本在样本上比 B 版本快 20%这个结论大概率在全量下也成立但如果你把样本上的绝对耗时当成全量的预期值那十有八九会翻车。正确做法是双轨制日常迭代用样本集跑回归发布前用全量集跑最终 benchmark两条轨道并存各管一段。5.2 可复现的校验手段卡方检验、双重跑批和回归基线为了让样本集可信可以引入一些统计学手段。我常用的是卡方检验比较全量和样本在关键类别字段上的频数分布是否有显著差异。直接调 scipy 就行from scipy.stats import chi2_contingency # 构造全量和样本的计数表 table [[full_count_a, sample_count_a], [full_count_b, sample_count_b]] chi2, p_value, dof, expected chi2_contingency(table) if p_value 0.05: print(分布无显著差异) else: print(分布有显著差异需要调整采样策略)除了分布校验另一个非常有效的做法是双重跑批同一份样本数据在两个不同版本的系统上跑同样的查询记录两边的结果和耗时。如果版本之间没有预期差异而样本上测出的差异波动很大说明样本里某些关键特征没有覆盖到。这个方法的优点是它直接和你的 benchmark 目标绑定比纯统计检验更贴近实际。还有一个工程上的细节样本集一旦确定就把它固定下来不要每次跑测试都重新采样。固定样本集 固定 seed 固定的哈希函数三件套齐全后你才能说这次变慢是因为代码改动而不是因为数据变了。5.3 红牌警告这些场景千万别采样最后说几个我交过学费后总结出来的红牌场景。在这些场景里采样会直接毁掉基准测试的价值宁可多等几个小时跑全量也不要走采样这条捷径。低频高价值事务比如支付、订单确认这类只占总数据 0.1% 的操作在 12.5% 的样本里可能只剩下几百条记录压力完全不够基数极端的 join全量数据里某张表有 1 亿个唯一 key采样后可能只剩 1200 万个join 的哈希表大小和内存占用完全不是一回事尾延迟敏感型的测试你要测的是 P99 甚至 P999 延迟样本数据很难触发到真正的长尾路径数据规模本身是变量因素的测试如果你测的就是数据量变大时系统性能怎么线性/非线性变化那更不能采样因为样本把规模这个变量给消除了。这些场景下更合理的做法是调整测试策略而不是缩减数据。比如低频高价值事务可以单独构造一份专项数据集把这类记录完整保留再对高频低价值的记录做采样。这就是前面说的残差采样思路的工程化变体。6. 我在反复折腾数据缩减后的一些体会从我自己的实操经验看数据缩减的功夫不在采样这一步而在事前分析和事后验证。很多人问 sampling strategy 怎么选其实答案在问题之外你首先要清楚这份数据要服务哪些查询、哪些维度不能丢、结果要用来做什么决策。这些想清楚了策略几乎是自然涌现的。哈希确定性采样之所以成为我的默认选项不是因为它统计上最优雅而是因为它工程上最稳——可复现、可并行、可增量扩展而且和业务 key 对齐副作用最小。但我现在也学会了不把它当成万能钥匙遇到类别极不平衡的数据我会换成分层哈希遇到低频高价值场景我会单独做残差采样。另外还有一点想分享数据缩减做完之后别忘了把采样参数写进文档包括 seed、哈希函数、采样比例、样本文件大小、验证结果。这些信息在几个月后你回看 benchmark 结论时会比代码本身更值钱。如果哪天同事拿着你生成的样本数据集跑出了一组异常数字你能快速定位是采样造成的还是代码造成的这个能力就是这套方法给你最大的回报。 基准测试数据集缩减指南：从2GB到250MB的采样策略
前几天同事跑基准测试手里一份日志数据集超过 2GB按测试规范要求压缩到 250MB 以内才能提交。他问我这种缩减到底是怎么做的采样策略算法上有没有标准答案其实这个问题把 benchmarks 里一个很容易被忽视的环节摊开了——数据集datasets的规模控制。很多人都以为缩减就是随机抽几行但真到了具体场景里怎么抽、按什么维度抽、比例怎么定、抽完怎么验证每一步都有讲究。这篇文章我就把实际项目中用过的做法、踩过的坑、以及各类采样策略sampling strategy的适用边界一次性讲清楚。1. 250MB 数据集红线是怎么来的缩减背后的四个现实约束先说一个基本判断250MB 这个数字本身不是一个物理定律而是工程权衡的结果。不同项目里这个阈值可以是 100MB、512MB、1GB但作用都一样——把测试数据约束在一个够用但不失控的规模。这个约束主要来自四个现实因素。1.1 内存和测试时长最直接的两座大山基准测试通常要跑很多轮配合不同参数、不同版本、不同硬件配置横向对比。假设一份 2GB 的数据某项查询跑一次要 3 分钟改成 250MB 后可能只需要 20 秒。如果一轮 benchmark 要跑 20 种查询、5 组配置全量数据要跑 5 小时缩减后 30 分钟就能收工。这中间的差距决定了你一天能迭代几轮。对于做性能回归的人来说这个差距就是效率的分水岭。内存就更现实了。很多测试环境是容器化的内存配额就 4GB 或者 8GB。2GB 的原始数据在加载阶段就可能触发内存压力导致 GC 抖动明显最后测出来的数字混入了资源争抢的噪声反而不如一份小但可控的数据集靠谱。1.2 可复现性和版本控制基准测试的生命线基准测试最重要的属性是可复现。你不可能在文档里写拿那份 2GB 的数据去测数据文件放在共享盘上哪天被人清理了结论就永远无法重新验证。所以很多团队会把基准测试数据集纳入版本控制随代码一起发布。像 Git 这类工具对单文件大小有严格限制超过 100MB 就开始告警250MB 的数据集即使通过 LFS 管理拉取和存储成本也明显更高。这里要提醒一句如果你发现自己的 benchmark 数据是躺在某个临时目录里手工下载的那数据缩减就不只是优化而是刚需。把数据压到可入库、可分发、可追溯的规模才是这套做法真正解决的问题。1.3 测试环境的多样性小数据集是兼容性保障我还遇到过一类场景基准测试需要在多个环境上跑有些环境是标准的云主机有些是开发同学的本地机器。本地机器通常没有几 GB 内存和大量磁盘空间给测试数据用。如果数据集可以压到 250MB那么任何一台笔记本电脑都能复现测试这大大降低了参与 benchmark 的门槛。换句话说缩减数据不只是为了快还是为了让更多环境能跑得起同一套测试。1.4 直接给结论什么时候真要缩减什么时候别硬减先想清楚你缩减数据的目的再决定怎么做。一般来说下面三种情况是真需要缩减的CI/CD 里的性能回归测试每一轮提交都要跑时间窗口有限要对外发布可复现基准测试包数据需要入库管理开发调试阶段需要快速验证 query 的正确性和执行计划变化。对应的如果你是做最终性能报告、上线前的容量评估那千万不要减。这种场景用全量数据跑跑得再久也要忍。缩减数据集只能用于趋势验证和质量筛选不能替代最终的全量压测。把这个定位想清楚后面所有采样策略的选择才不会跑偏。2. 缩减不只是抽几行场景裁剪和行级采样是两条完全不同的路很多人提到数据集缩减第一反应就是抽样。但实际工程里缩减数据有两个维度一个是砍掉不关心的部分另一个是保留结构但缩小规模。这两个维度我分别叫它场景裁剪和行级采样。搞清楚它们的区别能帮你省不少功夫。2.1 场景裁剪只留核心 workload只留关键字段场景裁剪是从业务维度砍掉对整个测试没有价值的数据。具体做法有两种。第一种是裁剪字段原始数据表里有 50 个字段但你的 benchmark 只涉及其中 8 个字段那其余 42 个字段完全可以删除。别看这招简单实际压测中它带来的体积缩减非常可观。比如日志类数据原始行里可能包含完整的请求头、埋点参数、堆栈信息这些内容占到行大小的一大半但测试链路根本用不到。去掉之后2GB 的 CSV 可能直接变成 400MB。第二种是裁剪查询场景一个数据集对应 100 类查询请求但你的基准测试只关心其中 20 类核心查询。那么就可以把其他查询对应的数据模式从数据集中移除。这种方法要注意的是不能只删除那条查询涉及的记录因为不同查询之间可能隐式共享某些数据特征。实际中更稳妥的做法是先确定核心 workload 的数据访问模式再只保留这些模式触及的数据表和相关分区。2.2 行级采样保留整体结构缩小数据规模行级采样是标题里问的重点。它的思路是文件还是那个文件表还是那张表字段还是那些字段但行数按比例减少。这样数据的形状不变体积变小workload 的运算逻辑也不变测出来的执行计划才具有可比性。这一条是整个基准测试缩减方法里性价比最高、应用最广的路线。但它有一个容易被低估的问题采样怎么做直接决定了缩减后的数据能不能代表全量。如果只是简单地每隔 10 行取 1 行遇到数据在磁盘上按时间排序的场景你的样本可能只覆盖了前几天的数据某些周期性的特征全丢了。这个问题我们下一章展开讲。2.3 我通常怎么选看 workload 类型不拍脑袋我的选择逻辑是这样的如果瓶颈主要在字段宽、记录多但查询模式非常固定优先做场景裁剪因为它最直接还能顺带减少测试脚本的复杂度如果瓶颈在于数据行数大、分布特征复杂、需要保留数据的统计特性就用行级采样。在大多数实操里两种方法会组合使用。比如先裁剪字段把 2GB 降到 800MB再用采样把 800MB 降到 250MB 以下。只靠单一手段硬压往往会把样本质量压得很差。记住一个原则先做无损或低损裁剪再做有损采样。顺序反了的话采样的偏差会被后续裁剪再次放大。3. 采样策略全景图六种方法各自保住了什么又丢掉了什么这是本章最核心的内容。从实践角度我把基准测试里常用的采样策略整理成六种简单随机采样、分层采样、哈希确定性采样、系统采样、偏斜采样、残差采样。它们在不同场景下各有不可替代的价值但也有很多细节坑。3.1 简单随机采样最省事也最容易翻车简单随机采样的意思是每一行数据以相同的概率 p 被保留。说起来最简单实现也最简单import random def simple_random_select(p: float, row_index: int) - bool: random.seed(row_index) return random.random() p这里有一个隐蔽的坑random.seed(row_index)这种方式虽然可复现但如果是在分布式环境下多个 worker 同时生成随机数序列很难保证跨进程的一致性。另外简单随机采样对行内聚性完全无感——如果数据是一张订单表和一张订单明细表的 join 结果按行随机采样后某个订单只保留了部分明细join 基数就会失真后续查询性能根本没法还原全量行为。所以在真实 benchmark 中简单随机采样只适合两类场景一类是每条记录之间完全独立、关联性不强的数据比如独立事件日志另一类是快速验证流程是否跑通的冒烟测试对精度要求不高。其他情况直接用容易翻车。3.2 分层采样保住类别比例的小心思如果数据中有明显的类别字段比如 90% 的搜索点击行为和 10% 的购买行为简单随机采样很容易让小类别在样本里消失。假设保留比例 p12.5%在极端情况下购买行为可能只剩 1.25%计算链路里的聚合函数、连接操作都没法测出像样的延迟。分层采样就是为这个场景设计的先按类别把数据分成多个层再在每一层内独立做随机采样。这样每一层都能保留自己 12.5% 的数据整体上类别比例和全量数据保持一致。实现上有两种做法。一种是先按类别分组再对每组装桶计数另一种更高效的做法是用一个类别编码拼接上原始记录的唯一 ID 来作为采样键。分层采样的问题在于它对层的定义很敏感。层分得越细每层内能抽到的样本就越少小层的数据量可能不足以支撑有统计意义的基准测试。所以分层不是越细越好一般情况下分到业务上最重要的 1-2 个维度就够用了。3.3 哈希确定性采样基准测试场景下的默认答案哈希确定性采样是我在实际项目里用得最多的方案。它的原理是对每条记录的某个关键字段比如 user_id、order_id做哈希然后看哈希值是否落在保留区间内。同一个 key 的哈希值永远一样所以同一个 user 的所有记录要么全部保留要么全部丢弃不会出现随机采样那种用户被拆散的问题。关键代码长这样import hashlib def hash_select(key: str, keep_ratio: float, seed: int 42) - bool: # 使用 md5 而不是内置 hash()原因见下文 digest hashlib.md5(f{seed}:{key}.encode(utf-8)).hexdigest() # 取前 4 个十六进制字符映射到 0~65535 bucket int(digest[:4], 16) # 65535 是 0xFFFF这里做了一个归一化 return bucket / 0xFFFF keep_ratio这里有一个必须踩过的坑不要用 Python 内置的hash()做确定性采样。Python 字符串的哈希默认带有随机种子PYTHONHASHSEED同一字符串在不同进程里哈希结果不一样样本集就没法复现。用 hashlib.md5 或 sha1 这类明确指定算法的哈希函数才能保证结果跨进程、跨机器完全一致。哈希确定性采样的第二个优势是天然支持并行。你可以把整个数据集按 hash 值分桶多台机器各自处理一部分桶最后合并需要按比例缩减时直接调整 keep_ratio不需要重新扫描全量数据。第三个优势是对后续增量扩展友好。如果先按 12.5% 采样出了 250MB后来发现还得再压到 100MB你只需要把 keep_ratio 从 0.125 改到 0.05同一个哈希函数和种子就能再次稳定地抽样而且第二次的样本恰好是第一次样本的子集。这在反复调优 benchmark 数据集的时候非常有用。3.4 系统采样、偏斜采样与残差采样系统采样是每隔 N 行取一行的策略。它实现简单也没有随机性因此在某些传统数据库测试里很常见。但它有一个致命问题如果数据在物理存储上存在周期性规律比如每天固定时间段的请求量高峰固定间隔采样会和这个周期产生共振导致样本严重失去代表性。我的建议是除非你对数据分布非常有信心否则不要在基准测试里用系统采样。偏斜采样是专门制造热点场景的采样策略。比如你想测试缓存热点、商品秒杀这类压力场景可以在采样时故意放大高频率 key 的保留比例缩小低频 key 的保留比例。它不是为了代表全量而是为了放大极端。这类采样适合做专项压力测试不适合做通用基准测试。残差采样严格来说不是一种采样策略而是一种补充手段先用主策略采样然后把那些采样中被丢掉但业务上至关重要的记录比如 VIP 用户、核心商户重新加回来。比如按 event_id 哈希采样后你发现某些核心用户的记录几乎全被丢掉了那就手动把这些人保留。这个做法不精确但非常实用能在保持基准公平性的同时确保关键场景不被采样抹掉。3.5 选型对照表策略核心逻辑保留了什么丢掉了什么推荐场景简单随机采样每行等概率独立保留总体大致分布行间关联、长尾小类独立事件日志、冒烟测试分层采样按类别分组再抽样类别比例层内细节、层间关联类别不平衡的数据哈希确定性采样按 key 哈希分桶key 级完整性低基数字段特征需要可复现的常规基准系统采样每隔 N 行取一行实现简单周期共振风险仅对均匀数据可用偏斜采样放大热点 key热点行为总体代表性热点压测专项残差采样主采样后补回关键记录关键业务实体无严格统计保证核心用户不可丢时另外补充一个容易混淆的点LIMIT 不是采样。有些测试脚本为了省事直接在查询 SQL 的末尾加LIMIT 200000这取的是物理存储顺序里最前面的 20 万行不是随机样本也不是分层样本它会强烈偏向数据写入初期的特征。做数据缩减一定要在数据预处理阶段做而不是在查询阶段用 LIMIT 糊弄。4. 从 2GB 压到 250MB 的一次完整实操以哈希确定性采样为例理论讲再多不如完整走一遍流程。下面我用一个实际场景演示怎么做假设你有一份 2GB 的用户行为日志目标是压到 250MB 以下同时尽量保留原数据的统计特性和查询行为。4.1 第一步先做一次数据分布体检动手采样之前必须先弄清楚这 2GB 数据长什么样。至少要回答下面几个问题数据总量多少行每行平均大小多少主键或核心关联键是什么业务上按哪个维度做关联数据的时间跨度多大是否有明显的周期特征有没有分布严重不均的类别字段未来基准测试要用到哪些查询这些查询 join 的键是什么这一步决定了你不是在盲人摸象。我一般先用一个轻量脚本扫一遍# 快速统计行数 wc -l user_logs.csv # 看前几行结构 head -5 user_logs.csv # 看总体文件大小 du -h user_logs.csv不要跳过这一步。我见过有人直接在 2GB 数据上按 user_id 哈希采样采完后才发现 user_id 是空的或者大量为空等于拿一个无效 key 做分桶样本完全失真。先体检再动手这是原则。4.2 第二步定采样键、采样比例和种子采样键的选择是整件事最关键的一环。原则是选那个在后续查询里被 join 或被 group by 的高基数字段。在行为日志里通常是 user_id 或者 device_id在订单场景里通常是 order_id 和 customer_id 的组合在 IoT 场景里可能是 sensor_id。采样比例的计算方式很简单期望目标大小 250MB 当前大小 2GB 2048MB 采样比例 250 / 2048 ≈ 0.122为了保险我会把目标比例再留 10% 的余量所以取 0.11 而不是 0.122。因为采样后的数据在文件序列化时还会有些额外开销压缩格式也影响实际大小。宁可多采一点然后验证后再调整也不要一开始采得太大导致后续反复重跑。种子seed是很多人忽略的点。seed 的作用是让哈希结果固定只要 seed 不变每次生成的样本就完全一样。这个 seed 相当于你这次采样版本的标识建议用日期加版本号比如 42 或者 20250101并且写进采样脚本的注释里。以后别人想复现你的数据集只要知道 seed、哈希算法和采样比例就能重新生成。4.3 第三步单遍流式采样代码数据有 2GB不能一次性读进内存用单遍流式扫描就可以了。下面这段代码是我项目里简化出来的版本足够处理几 GB 的 CSV 文件import hashlib import csv import sys def hash_select(key: str, keep_ratio: float, seed: int) - bool: digest hashlib.md5(f{seed}:{key}.encode(utf-8)).hexdigest() bucket int(digest[:4], 16) return bucket / 0xFFFF keep_ratio def sample_csv(input_path: str, output_path: str, key_col: int, keep_ratio: float, seed: int 42): with open(input_path, r, newline, encodingutf-8) as fin, \ open(output_path, w, newline, encodingutf-8) as fout: reader csv.reader(fin) writer csv.writer(fout) header next(reader) writer.writerow(header) for row in reader: key row[key_col] if hash_select(key, keep_ratio, seed): writer.writerow(row) if __name__ __main__: # 参数输入文件 输出文件 key列索引 采样比例 种子 sample_csv(sys.argv[1], sys.argv[2], int(sys.argv[3]), float(sys.argv[4]), int(sys.argv[5]))注意看这行bucket int(digest[:4], 16)它取前四个十六进制字符映射到一个 0~65535 的整数。整个哈希过程只需要计算一次 md5不需要随机状态不需要跨进程通信所以跑几十 GB 的文件也不会太慢。采样完成后建议顺手统计一下输出文件的行数和大小这一步能帮你尽早发现比例是否算错。4.4 第四步采样质量的三项体检样本生成完不等于大功告成。我每次都会做三项检查它们能在十几分钟内帮你看穿这次采样是否合格。第一项是规模检查样本文件大小是否在目标范围内。如果明显超过 250MB可能是字段里包含大量长文本需要裁字段如果明显偏小说明采样键或比例可能不对。第二项是分布检查抽样比较全量数据与样本数据在关键维度上的分布。比如对比用户活跃等级的占比-- 全量统计 SELECT user_level, COUNT(*) / (SELECT COUNT(*) FROM full_table) AS ratio FROM full_table GROUP BY user_level; -- 样本统计 SELECT user_level, COUNT(*) / (SELECT COUNT(*) FROM sample_table) AS ratio FROM sample_table GROUP BY user_level;如果两个 ratio 差得太多就说明当前策略没有保住关键分布需要换成按 user_level 做分层哈希采样。这里我强调一下分层哈希的组合技巧先用md5(seed:user_level)把数据分成几层层内再用哈希确定性采样既保住了类别比例又保住了 key 的完整性。第三项是关联完整性检查如果测试 workload 涉及多表 join你需要验证样本里的外键关系没有断。例如全量数据中 user_id 和 order_id 的对应关系是 1 对 5在样本里也应该接近 1 对 5。最简单的方法是先跑一条小聚合查询对比全量和样本的 JOIN 基数偏差超过 10% 就要考虑换采样键。5. 样本数据跑出来的数字到底能不能信很多人在数据缩减完成后直接拿着样本上的 benchmark 结果跟全量历史数据对比发现数字对不上就开始怀疑采样策略。其实这里还有一道坎样本上的性能结论不能简单乘除回全量。这也是整个话题里最容易被误解的部分。5.1 样本性能数据不能你乘我除地外推假设样本是全量的 12.5%样本上某个查询跑了 100ms你是不是想说全量要跑 800ms不对。真实情况可能差很多原因有三个数据量变小后整个工作集可能放进内存甚至 CPU 缓存执行路径彻底变化并行度不变时数据量小时网络和磁盘 I/O 的调度模式与全量完全不一样某些查询优化器会根据统计信息切换执行计划样本的行数和基数会让优化器选择一条完全不同的 join 策略。所以样本上的结果只能用来对比不同版本之间的相对趋势。比如 A 版本在样本上比 B 版本快 20%这个结论大概率在全量下也成立但如果你把样本上的绝对耗时当成全量的预期值那十有八九会翻车。正确做法是双轨制日常迭代用样本集跑回归发布前用全量集跑最终 benchmark两条轨道并存各管一段。5.2 可复现的校验手段卡方检验、双重跑批和回归基线为了让样本集可信可以引入一些统计学手段。我常用的是卡方检验比较全量和样本在关键类别字段上的频数分布是否有显著差异。直接调 scipy 就行from scipy.stats import chi2_contingency # 构造全量和样本的计数表 table [[full_count_a, sample_count_a], [full_count_b, sample_count_b]] chi2, p_value, dof, expected chi2_contingency(table) if p_value 0.05: print(分布无显著差异) else: print(分布有显著差异需要调整采样策略)除了分布校验另一个非常有效的做法是双重跑批同一份样本数据在两个不同版本的系统上跑同样的查询记录两边的结果和耗时。如果版本之间没有预期差异而样本上测出的差异波动很大说明样本里某些关键特征没有覆盖到。这个方法的优点是它直接和你的 benchmark 目标绑定比纯统计检验更贴近实际。还有一个工程上的细节样本集一旦确定就把它固定下来不要每次跑测试都重新采样。固定样本集 固定 seed 固定的哈希函数三件套齐全后你才能说这次变慢是因为代码改动而不是因为数据变了。5.3 红牌警告这些场景千万别采样最后说几个我交过学费后总结出来的红牌场景。在这些场景里采样会直接毁掉基准测试的价值宁可多等几个小时跑全量也不要走采样这条捷径。低频高价值事务比如支付、订单确认这类只占总数据 0.1% 的操作在 12.5% 的样本里可能只剩下几百条记录压力完全不够基数极端的 join全量数据里某张表有 1 亿个唯一 key采样后可能只剩 1200 万个join 的哈希表大小和内存占用完全不是一回事尾延迟敏感型的测试你要测的是 P99 甚至 P999 延迟样本数据很难触发到真正的长尾路径数据规模本身是变量因素的测试如果你测的就是数据量变大时系统性能怎么线性/非线性变化那更不能采样因为样本把规模这个变量给消除了。这些场景下更合理的做法是调整测试策略而不是缩减数据。比如低频高价值事务可以单独构造一份专项数据集把这类记录完整保留再对高频低价值的记录做采样。这就是前面说的残差采样思路的工程化变体。6. 我在反复折腾数据缩减后的一些体会从我自己的实操经验看数据缩减的功夫不在采样这一步而在事前分析和事后验证。很多人问 sampling strategy 怎么选其实答案在问题之外你首先要清楚这份数据要服务哪些查询、哪些维度不能丢、结果要用来做什么决策。这些想清楚了策略几乎是自然涌现的。哈希确定性采样之所以成为我的默认选项不是因为它统计上最优雅而是因为它工程上最稳——可复现、可并行、可增量扩展而且和业务 key 对齐副作用最小。但我现在也学会了不把它当成万能钥匙遇到类别极不平衡的数据我会换成分层哈希遇到低频高价值场景我会单独做残差采样。另外还有一点想分享数据缩减做完之后别忘了把采样参数写进文档包括 seed、哈希函数、采样比例、样本文件大小、验证结果。这些信息在几个月后你回看 benchmark 结论时会比代码本身更值钱。如果哪天同事拿着你生成的样本数据集跑出了一组异常数字你能快速定位是采样造成的还是代码造成的这个能力就是这套方法给你最大的回报。