网易互娱数据成本优化治理实践

针对业务场景中数据应用价值的落地，网易数帆形成了以 DataOps、DataFusion、DataProduct 为内核，数据技术、数据资产、数据应用和数据运营为四要素的数据生产力模型，其中网易公司数据运营的一个重要手段是网易数据治理大赛。本文是第二届网易数据治理大赛获奖作品分享，来自于网易互娱用户体验中心数据团队。

1 项目背景

我们团队为网易互娱大量游戏产品提供了常规概况、经济分析、留存分析、回流分析、付费分析、服务器分析、渠道分析、定制专题、社交分析、全球分析、问卷分析、全球设备等多种游戏分析专题服务，也支持自定义指标展示的 BI 看板分析。

目前为止，已累计服务互娱 300+款产品，离线数仓 SQL 月执行次数便最高可达近 400 万次。

2 项目挑战

随着业务发展，目前离线数仓执行作业数已达到每月三百万+个，各个环节的问题也凸显出来：

• 日志管理混乱，多产品多程序规范不统一，日志打印随意，解析与维护困难；

• 产品持续运营，作业与数据累积，作业常需长期执行，数据生命周期不明确；

• 日志重复存储，原始日志与经格式化解析后的原始表并存两份，成本负担大；

• 海外市场开拓，海外数据存储成本远高于国内，导致产品数据存储成本飙升。

为此，对项目进行数据成本优化迫在眉睫。

3 项目实现

我们总体的优化方向分为存储和计算两大部分，基于日志的处理流向分不同阶段进行优化。

对于存储部分，对互娱数仓总体存储进行占比分析，我们发现 ODS 层数据占据了全项目的 75%的存储空间。因此，我们的首要目标便是优化 ODS 层的数据存储，分为存储前、存储时、存储后三个子目标进行优化。

对于计算部分，由于计算任务众多，我们优先针对耗时较长、逻辑通用性较高的 P1 指标的计算任务进行优化，分为计算前、计算时两个子目标进行优化。

（1）存储前：日志格式规范管理

程序日志作为互娱 ODS 层数据的直接来源，合理的日志格式规范可以直接从源头上降低人力和存储成本。这里我们提出了日志打印的三大原则：

• 标准：日志打印遵守统一标准格式，保证下游可正常解析，异常日志的存储或特化解析会带来存储空间的浪费、人力维护跟进的投入开销与下游解析作业的性能开销；

• 按需：仅打印下游业务所需的日志，非必要的日志可不打印或不采集到下游链路中；在满足业务分析的前提下，日志打印可遵守最小原则，最大限度减少下游日志传输量；

• 精简：对于频繁在多条日志反复打印的字段，可仅在会话中的第一条日志打印完整信息，后续日志通过会话 ID 进行关联查询；可通过维表查询替换的字段，在日志打印时可进一步压缩字段的大小。

当然，基于人工遵守原则来保证日志规范总会有遗漏的地方，因此互娱数据治理平台的日志上报模块便应运而生。就以日志精简打印为例，用户可在日志上报模块上报和配置日志的映射关系，首先程序按约定打印日志时仅打印日志列名的缩写，其次业务同学按约定的映射字段登记表或字段的英文全名以及业务描述，理论上可以减少 10%-20%的日志存储空间。

（2）存储时：共享数仓方案

互娱旧版原始日志存储架构中多个部门都有各自 ETL 后的 ODS 层，形成了多份原始日志重复存储的局面。为此，UX+SDC+GDC 等多个部门联合推进了共享数仓的方案，实现一个多部门共享实时 ODS 层：读取实时流数据，实时 ETL 后按日志名入库为不同表，分钟级时效，业务部门直接基于共享 ODS 层进行上层指标计算，实现一份 ODS 层的最优存储。该方案的推进，也带来了诸多好处：

• 解决原先原始日志不可「查询」的问题：提供给用户最基础的 ODS 表查询，而原始日志本身将不再存储；

• 解决原先文件存储无法细粒度管理问题：调整为表存储模块,   给产品提供项目日志数据管理入口；

• 优化上层业务线按单日志重跑执行效率：底层日志按表分别存储，上层数据重跑无需扫描全部日志。

（3）存储后：动态生命周期管理

早期我们对于 ODS 层数据存储优化的手段便是由业务同学人工配置 ODS 表生命周期，但该方式存在诸多问题：

• 错误冲突：人工配置可能会误消亡正在读取的表分区数据，业务 A 配置的规则不一定符合业务 B 的要求；

• 维护麻烦：生命周期额外配置，与业务同学计算指标作业隔离，业务逻辑更新时需兼顾两处；

• 历史遗留：人工配置容易可能会造成历史遗留问题，出于稳定考虑，业务无法有绝对把握缩短生命周期。

因此，针对上述痛点，互娱数据团队提出了一个自动化方案：基于 SQL 审计记录，动态消亡长期未读分区数据，再次读取时自动重切数据。

2022 年 6~9 月份，某海外大型项目，回收过期数据 2229.5T，截止 2022 年 09 月 27 日，项目现存数据仅 386.3T，减少了 85%的存储空间。

（4）存储后：数据分级与压缩存储

当数据必须存储时，我们可以通过分级存储与压缩存储来进一步降低存储成本。

通过 SQL 审计信息发现，按时间从近到远，数据的读取频率也从高到低递减，因此我们提出了分级存储的模式：按数据生产日期从近到远，权衡读写性能，选择存储介质。

• 第一级：存储在常规 Hadoop 集群，保证读写性能；

• 第二级：存储在冷备 Hadoop 集群，可读写，但性能稍差；

• 第三级：存储在冷备 S3 集群，只读不可写，性能最差。

同时，在存储时，我们可以基于数据的读写特性，比如是否要支持追加写等约束，为数据选择合适的压缩格式，这里我们也分为两级进行实现：

• 第一级：格式压缩，基于不同表，压缩为 orc/textfile+snappy 格式，压缩率在 30~48%左右；

• 第二级：使用纠删码技术，从 3 副本减少到 1.5 副本，压缩率在 50%左右。

（5）计算前：计算效率优化

由于互娱数仓作业任务数众多，因此我们选择优先针对耗时较长、逻辑通用性较高的计算任务进行优化。具体思路是从数据仓库建模角度重新梳理数据链路，减少跨层引用，复用数据中间层降低重复计算和 IO 等。经过测验，项目里满足条件的作业所需计算资源会降低 70%-90%，整体常规运营指标任务所需计算资源能降低 30%-50%。

（6）计算时：任务错峰调度

在早期，由于缺乏有效规范，过往的计算任务分配调度时间相对随意。从项目调度图可以观测到，很多项目下的任务运行时间集中在了忙时阶段，造成计算成本相对较高。而不同的时段的内存、CPU 等计算资源成本是不一致，一般可以分为忙时(凌晨 2 点-8 点)和闲时两个阶段，忙时和闲时计算费用单价比为 4:1。

因此我们通过对项目任务优先级和预期产出时间进行梳理，使用迁移非关键分析指标至闲时等手段，重新合理分配了任务的调度运行时间，从而降低了总体项目的计算成本。

4 项目成果

（1）2021 年的计算存储优化效果

2021 年 9 月份对公司部分游戏业务进行存储和计算优化之后，如右图所示，在保障不影响业务运转的前提下，成本方面环比 8 月各业务都有了较为明显的下降。存储部分最高优化 65%，计算部分最高优化 71%，总计预估年节约成本约合 960 万元。

（2）2022 年的计算存储优化效果

2022 年 6 月份起对公司海外项目为主进行存储和计算优化后，优化占最终优化总体各为 45%、55%，总计预估年节约成本约合 1500 万+元。

本次的分享就到这里，谢谢大家。