做传媒行业的数据平台有个很直观的感受数据不是“涨”出来的是“堆”出来的。图片、视频、音轨、稿件、弹幕、用户行为日志各类内容资产和业务数据每天都在膨胀存储成本往往跑得比业务预算还快。今天想分享的是我在某传媒集团数据平台上做存储治理的一段实践主题就围绕四个字数据压缩。整篇文章会拆解压缩算法选型、列式存储优化、链路改造过程、参数调优以及我踩过的那些坑适合正在做大数据存储优化、或刚接手传媒行业数据平台的朋友参考。1. 传媒行业的数据特点与压缩需求拆解1.1 内容形态各异非结构化数据是绝对主力传媒行业的数据跟传统互联网业务有个很明显的区别非结构化数据的占比高得吓人。电商平台的核心数据大量是订单、用户、商品这种结构化记录而传媒平台的核心资产是内容本身——一张新闻原图可能几十 MB一条 4K 视频素材动辄几个 GB一期节目的音频工程文件也有几百 MB。这些内容素材加上配套的业务数据比如稿件正文、评论、播放日志、广告投放记录一起构成了数据平台的主要存储压力。这种多形态混存的局面决定了压缩方案不能“一把尺子量到底”。文本和业务日志重复度高、规律性强适合走通用压缩算法图片和视频本身已经是高度编码的数据再用 gzip 这类通用算法去压效果差得离谱而那些历史素材和冷数据压缩策略又要综合考虑读取频率和解压成本。所以在做方案之前先得把数据按形态和访问热度拆开看才能对症下药。1.2 两个绕不开的矛盾成本与链路传媒行业数据平台通常面临两个核心矛盾。第一个是存储成本。内容资产要合规留存历史节目不能随便删素材归档又是刚需这部分数据只增不减。第二个是数据链路的效率问题。内容生产和分发之间是实时联动的关系编辑上传素材、审核、转码、分发每一步都有数据写入和读取。压缩如果做得太重CPU 被打满写入链路就会出现明显延迟压缩如果太轻存储成本又压不下来。我在项目里发现90% 的团队讨论“数据压缩”时第一反应是选个压缩算法比如把 Snappy 换成 Gzip。但真正影响成本和效率的是压缩在整条链路中的位置在采集端压缩、在存储层压缩、在查询端解压三个环节的资源消耗完全不同。方案设计必须先想清楚这个问题否则后面调参再精细也是事倍功半。1.3 整体设计思路不是“一刀切压缩”我的整体思路可以总结成三句话结构化数据走列式存储加现代压缩算法内容素材按冷热分层区别处理日志类文本优先做归档级高压缩。这三句话听起来简单落地时要拆成一套组合拳先摸清数据构成再做抽样压测然后针对每条业务链路单独调整压缩策略最后通过监控验证收益。这不是一次性改造更像是一个持续优化的过程每类数据都要单独评估“压缩率换 CPU、压缩率换延迟”的性价比。2. 压缩算法与文件格式的选型逻辑2.1 通用压缩算法怎么选Snappy、Gzip 还是 Zstandard做大数据平台的朋友对这几个名字应该不陌生。Snappy 是 Hadoop 生态里用得最广的压缩算法优点是压缩和解压都极快对 CPU 的影响小缺点是压缩率一般文本类日志大概只能压到原来的三分之一左右。Gzip 压缩率明显更高但压缩速度慢对 CPU 的消耗很猛如果用在高频写入链路上会把任务的耗时拖上去。Zstandard 是这几年的新宠压缩率接近 Gzip压缩和解压速度又比 Gzip 快得多而且可以调节压缩级别很受数据平台欢迎。这里先说结论实时写入链路优先考虑 Snappy 或 Zstandard离线批量链路可以选 Zstandard跨机房传输或者归档场景再考虑 Gzip。Zstandard 的等级调整很灵活level 1 到 level 22 跨度很大日常推荐级别通常在 3 到 7 之间。我见过不少团队直接把 Gzip 换成 Zstandard压缩率不但没降写入耗时还降了百分之三四十这就是选型带来的直观收益。2.2 存储格式层的压缩机制列式存储才是大头如果数据是结构化或半结构化的那么真正决定压缩效果的不是算法而是存储格式。Parquet 和 ORC 这类列式存储格式天生就是为压缩设计的。列式存储把同一列的数据连续存放同一列里的枚举值、状态码、时间戳这些数据往往高度相似压缩算法可以发挥出比行式存储好得多的压缩率。这也是为什么同一个日志数据集存成文本文件再用 Gzip 压和存成 Parquet 再启用 Zstandard压缩率和查询性能差距会非常明显。列式存储里面还有几个“隐藏开关”。字典编码dictionary encoding专门处理低基数列比如“省份”“设备类型”“页面名称”这类就几十个取值的字段编码后压缩率非常高。行组大小row group size和页大小page size也直接影响压缩效果行组越大、页越大压缩率越好但随机查询时读取成本也会增加。这些参数在新手阶段容易被忽略但它们对最终压缩收益的影响常常比换算法还大。2.3 图片和视频的“二次压缩”别自作聪明图片和视频这类内容素材很多人会习惯性地继续套 gzip 或者 Zstandard这其实是典型的误操作。视频文件在编码时就已经做了极其复杂的压缩H.264、H.265 这些编码标准内部有帧内预测、帧间预测、变换、量化、熵编码一整套机制通用压缩算法能捞到的东西很少。JPEG 图片同理它本身已经是熵编码后的产物再压一遍压缩率通常只有 1.01 到 1.05纯属浪费 CPU。对内容素材的正确做法是在源头控制编码格式而不是在存储层做“二次压缩”。图片分发场景优先考虑 WebP 或 AVIF视频归档前统一转成合适规格的编码和码率原始素材则按合规要求做无损归档或者干脆不压缩。只有那些不能转码又要长期留存的源文件才值得评估专用的归档压缩方案比如针对 RAW 图片的高保真压缩格式。这个认知如果不建立后面做的所有存储优化都会走偏。3. 实操过程一套压缩落地方案从 0 到 13.1 摸底调查先搞清楚数据到底长什么样动手改配置之前我花了大概一周时间做数据摸底。先说结论这一步绝对不能省。我接手的平台存储构成大致是这样的内容素材图片、视频、音频占了总存储量的大头大概六成以上业务日志和埋点数据占了大概三成剩下的才是稿件文本、配置数据和结果表。不同数据类型的访问频率差异也很大近期内容和热播节目的素材被频繁读取三年前的老素材基本没人碰日志数据则主要是离线分析在访问。摸底的方式很简单通过存储系统的目录统计按业务线汇总数据量再抽取每条链路的读写频率和查询接口耗时。这一步的价值在于后面所有压缩策略都能对应到具体的数据集上而不是凭感觉拍脑袋。我见过有人上来就把全平台切成最高压缩级别结果实时链路的延迟飙了一倍最后只能紧急回滚根源就是没有做分层摸底。3.2 数据抽样与压缩率评测用数据说话摸底之后就是评测。我对每类数据集抽取了代表样本每份样本控制在 1GB 左右然后分别跑几种常见压缩算法记录压缩率、压缩耗时、解压耗时和 CPU 占用。这里要提醒一句样本太小没有参考意义压缩算法在大文件上的表现和小文件差异很大样本太杂又会掩盖真实结论最好按业务类型分开测。以日志数据为例我当时拿到的评测结果大致是这样数据经过换算不同集群会有差异算法压缩率压缩耗时 (MB/s)解压耗时 (MB/s)CPU 占用情况Snappy2.6450680低Gzip3.960180高Zstandard level 33.5380500中低Zstandard level 74.2200420中Zstandard level 194.730280高这个结果非常典型Snappy 压缩率明显吃亏但胜在快Gzip 压缩率不错压缩速度却是硬伤Zstandard 在中等级别拿到了压缩率和速度的双重优势level 19 虽然压缩率最高但压缩耗时直接掉了一个量级。对离线日志链路我们最终选了 Zstandard level 7对实时写入链路选了 Zstandard level 3 作为折中。3.3 链路改造与灰度发布小步快跑最稳评测做完进入改造阶段。我的习惯是每条链路独立灰度不要一次性全量切换。第一批选的是最不敏感的历史日志归档链路这类数据没有实时读取压力压缩策略可以放得很激进。改造点其实不复杂就是在写入存储之前把压缩配置从原来的格式默认值改成 Zstandard并调整存储格式的编码选项。第二批接入的是离线分析链路。这里额外处理了一个问题下游分析师跑 SQL 的查询引擎对 Zstandard 的支持必须提前验证。我排查了集群里各组件版本确认查询端已经支持才敢切换。第三批是实时写入链路这一批最小心压缩级别用得很保守上线后盯了三天指标确认写入延迟没有波动才放开。那套流程走下来整体平稳几乎没有出现需要回滚的情况。4. 核心参数调优与性能评估4.1 Zstandard 的 level 到底怎么选别迷信 19Zstandard 最干扰人的就是压缩级别选项。很多人以为 level 越高越好因为压缩率最高但实际工程里 level 19 很少适合线上链路。以我们的日志数据为例level 19 比 level 7 的压缩率只提高了大约 12%但压缩耗时从 200MB/s 掉到 30MB/s慢了接近 6 倍。如果数据量是每天几十 TB这个差距意味着大规模额外消耗计算资源排队和超时的问题接踵而至。我的经验是日批任务用 level 7 是稳妥起点数据重复度高的纯文本可以尝试 level 9实时或近实时链路用 level 3。如果后续想继续压榨存储空间优先考虑从存储格式的编码机制上找优化空间而不是一味提高压缩等级。Zstandard 还有一个特点解压速度受级别影响远小于压缩速度所以对于“写少读多”的数据集用高一点级别很划算对于“写多读少”的采集链路就要保守些。4.2 列式存储的“压缩敏感度”配置同样是 Parquet 格式两套参数配置得到的压缩效果可能差出 20% 到 30%。首先是行组大小这个参数决定了多少行数据聚合在一起做压缩和编码。行组设得太小压缩上下文太少压缩率上不去设得太大查询时扫描单元变大过滤效果会被削弱。我们在离线分析场景用 128MB 左右的行组如果查询基本都是全表扫描这个值还能继续上调。其次是字典编码的开关。对于这种情况我建议专门做一次数据分布统计确认是低基数列再启用字典编码基数很高的列开字典反而会浪费内存。还有一个容易踩坑的点Parquet 的 page size 会影响压缩块的大小直接影响读取 I/O。我们把 page size 从默认的 1MB 调大了一些压缩率确实提升了一点但随之而来的是单页读取延迟增加。这些参数一定要结合真实查询场景调拿一套配置套所有表一定翻车。4.3 监控指标与成本核算压缩做得好不好靠数据说话压缩方案上线后我做了两套指标来评估效果。第一套是存储侧指标总存储量变化、各类数据的压缩率趋势、冷热层级间的数据流动情况。第二套是计算侧指标写入链路的延迟、任务 CPU 消耗、查询接口 P99 耗时。这两套指标缺一不可因为压缩本质上是在用 CPU 和查询效率去换存储空间只看存储不看计算很容易掩盖真实代价。成本核算方面我提供一个简单的思路用“少占了多少存储”来评估收益用“多消耗了多少 CPU 和延迟”来评估代价。如果月度存储成本下降了 20%但 CPU 资源也涨了 10%那就要判断这 10% 的 CPU 开销换 20% 的存储是否划算。在传媒行业存储成本往往是内容资产的硬成本而计算资源在内容生产高峰期本来就弹性波动大多数情况下这个交换是值得的但要形成一个可以持续衡量和汇报的数据口径。5. 常见问题与排查技巧实录5.1 压缩后查询反而变慢先别急着骂压缩很多团队切到高压缩级别后发现查询耗时不降反升第一反应是把压缩关掉。其实问题往往出在“读取小数据量需要先解压一大块数据”这个矛盾上。Parquet 这类列式格式本来支持列裁剪和谓词下推只读取查询需要的列和行组。如果查询条件写得不合理或者行组设得过大就必须解压原本不需要的数据于是压缩级别越高、解压开销越大、查询越慢。排查思路是这样的先看查询执行计划里实际扫描了哪些列和行组再检查表统计信息是否过期最后看行组大小和 page size 是否跟查询模式匹配。我遇到过一次情况一个大查询每次都要全表扫描压缩率很高但解压成了瓶颈。后来发现是因为下游有位同事写了不带分区过滤的 SQL把整个表的行组都扫了一遍。所以先修查询习惯再调存储参数顺序不能反。5.2 小文件遇上压缩两个难题要一起解传媒行业的数据链路很容易产生小文件尤其是日志采集按分钟落盘的时候一个业务线一天能生成几万个小文件。压缩把小文件变得“更小”但并没有解决小文件本身带来的问题海量文件导致 NameNode 内存压力大、查询任务频繁切换文件句柄、任务调度开销大。压缩率再高也弥补不了小文件带来的性能黑洞。我的做法是先合并再压缩。日志链路从按分钟落盘改为按小时合并小文件在写入侧先攒批再以较大文件形式落盘。这一步做完之后查询性能的提升非常明显甚至比单独调整压缩算法带来的收益还大。如果你所在平台的小文件问题已经很严重建议把“合并 压缩”当作一个整体方案来做而不是只盯压缩率这个指标。5.3 Zstandard 字典压缩的漂移问题Zstandard 有个高级功能叫字典压缩对大量相似的小文本块效果奇好。比如说传媒行业里有大量按稿子维度存储的短文本每条就几 KB但结构高度相似字典训练好之后压缩率可以做到 10 比 1 以上。但我在实践里踩过一个大坑字典是根据历史数据训练的如果业务改版导致字段结构和用词习惯变了字典立刻失效压缩率可能从 10 比 1 掉到 2 比 1。解决这个问题有两个方向一是给字典加版本定期用最新数据重新训练部署后新写入数据用新字典旧数据继续用旧字典二是在压缩率指标上配置监控一旦发现某类数据的压缩率明显下降就触发字典重建流程。这两个方向我都在生产环境用了效果稳定。这里要特别强调任何依赖数据分布的压缩方案都要有对应的“数据分布变化检测”否则就像带着旧地图找新路迟早翻车。5.4 压缩格式版本升级的兼容性坑最后聊一个特别容易被忽略的问题组件版本升级。数据平台里涉及压缩的组件很多采集端、消息队列、计算引擎、存储格式、查询引擎每一层对压缩格式的支持范围都可能不一样。比如某个版本的查询引擎只认识了 Zstandard 的部分参数或者对新的压缩级别值不识别读数据的时候直接报错或产生异常结果这类问题排查起来非常痛苦因为它不像语法错误那样明显。我的建议是把压缩格式和组件版本纳入统一的依赖管理和变更流程。升级组件之前先在测试环境用真实数据样本跑一遍完整的读写链路确认新旧版本互通之后再上生产。另外一个实用技巧是在写数据时把压缩算法和版本信息写入文件元数据这样后续排查问题时能快速定位到底层格式是什么配置不需要去翻历史任务配置。6. 这套方案的适用边界与后续演进数据压缩并不是在所有场景里都适用这一点我在项目收尾阶段体会得很深。如果你的数据是高频更新的业务库如 OLTP 类型压缩会显著拖慢写入和更新得不偿失如果数据量本身不大压不压根本不影响成本那也没必要承担压缩带来的额外 CPU 开销。这套方案的真正价值区间是“数据量大、访问频率相对可控、重复度高”的批处理和数据湖场景传媒行业的内容素材归档和业务日志分析正好落在里面。后续可以继续演进的方向一是冷热分层自动化把热数据保持轻压缩甚至不压缩把温冷数据自动迁移到高压缩级别存储二是引入更强的编码优化比如 Zstandard 的长距匹配模式或者列式存储的定制编码策略三是把压缩策略做细到表级和分区级而不是一个大集群一套配置。我个人的体会是数据压缩不是一个“配置一次就完事”的工作它更像一个需要持续关注成本、资源、性能三者平衡的运营动作。如果你正准备在自己平台里推数据压缩我的建议就一句话先摸底再压测小范围试点最后用数据说话。这套流程走熟了你会对自家平台的数据特征有远超从前的理解。