背景
存储与计算资源是数仓建设的基础，也是数仓建设中的重要成本支出。而随着数仓建设规模逐渐扩大、时间跨度逐渐拉长，将不可避免的出现数据表、任务、字段的冗余。
技术路线
针对数仓建设成本治理的粒度从大到小可以分为：数据表、数据任务、数据表字段。从粗到细的治理优化思路如下：
- 当发现低频使用的数据表时，下线对应数据表的同时也删除对应数据任务；
- 当数据任务资源浪费严重，针对任务进行对应的代码与资源优化；
- 当发现一张表中个别字段使用使用频率很低，停止相关字段的计算与存储。
根据以上的优化思路，首先要解决如何定位低频使用数据表、高资源浪费率任务、低频使用字段的问题，在此基础上，针对不同的场景通过不同的手段进行优化。
"数仓建设成本分析"看板总览
技术方案
低频使用数据表优化方案
定位低频使用数据表
火山引擎DataLeap提供了Hive表的资源治理功能，包括Hive表的存储与访问次数等基本信息查询，用户可以根据该功能直接定位低频使用数据表并进行优化。
- 但是以上的优化存在以下缺陷：
- 使用 Hive 表的直接查询次数无法准确衡量用户对于数据的实际使用次数：为了保障查询速度，数据一般会由Hive表导入到ClickHouse等查询速度较快的介质中，而不会直接查询Hive表。因此，一张Hive表的直接访问次数一般是由下游的日常数据任务产生，而不是真正的用户查询。
- 缺少了对数据表生产过程中计算资源的统计：数据表在生产的过程中，除了占用存储资源，计算资源是不可或缺的一部分：存在经过复杂计算过程后，产出很小数据量的数据表。因此，当希望对成本进行快速优化时需要瞄准高成本的数据表时，只着眼于数据表占用的存储资源是不够全面的。
Hive表成本分析看板
https://data.bytedance.net/aeolus/#/dashboard/437272?appId=555186&sheetId=440345
为了解决以上两个问题，火山引擎DataLeap研发人员进行了Hive表成本分析看板的开发建设：
- 首先，对数据表进行血缘关系的梳理，从上（Hive表）至下（ClickHouse）建立数据表血缘关系树
- 进一步将所有叶子节点的访问次数累加到相应根节点上，作为该根节点的使用次数（直接访问+间接访问）
- 再统计数据表计算资源，关联数据表存储资源，获得该数据表的总生产成本
- 最后关联数据表的总生产成本与总使用次数，评价该数据表实际的ROI
数据表的生产成本vs使用次数
优化手段与思路
- 优化手段
针对数据表的优化手段有：
① 下线 数据表及对应任务
在火山引擎DataLeap下线相关任务，并删除对应数据表。
② 缩减数据表 TTL
根据「表分区查询热度分布图」在火山引擎DataLeap修改对应数据表TTL对应数据表。
火山引擎DataLeap数据表生命周期配置
③ 对历史数据进行温存配置
在火山引擎DataLeap配置历史数据温存天数。
- 优化思路
基于「Hive表成本分析看板」，根据不同的使用成本与使用次数阈值（如数据表的生产成本1000元/月，使用次数100次/月）将看板分为四个象限，其中各个象限的数据表的含义及推荐的优化手段为：
根据优化收益进行治理的顺序为：第二象限>第三象限>第一象限>第四象限。
低资源利用率任务优化方案
定位低资源利用率任务数据任务
计算资源分为CPU资源和内存资源，可以利用火山引擎DataLeap进行高浪费任务的定位与探查。
任务资源使用监控
通过高浪费率任务监控看板定位到的高资源浪费率任务
优化手段与思路
- 对于新增任务
基于大数据研发治理套件火山引擎DataLeap，在新建数据任务与数据表时，要求需求方提供数据的服务时限，设置数据任务的寿命。当寿命到期，会提醒相关负责人确认是否可下线当前数据任务。
数据任务寿命控制
- 对于历史任务
目前离线数据任务的主要计算引擎为Apache Spark。
低频使用字段优化方案
相比于数据表与任务，针对数据表中的低频使用的字段进行优化是一种更加细粒度的方式。
定位低频使用字段
在离线数仓建设中，原始日志一般会从消息队列中直接不加处理的存储到原始数据层，再通过明细数据层对原始日志进行字段清洗与解析。在实践中，火山引擎DataLeap研发人员发现处于明细数据层中的原始埋点明细表由于数据量巨大(单表PB量级)：在某些数据库中，仅三张表格就占据了所在数据库75%的存储大小，个别数据表的字段平均存储大小约为150TB。因此，为了更加高效地完成数据表字段优化，研发人员从埋点明细表的埋点字段入手。
和Hive数据表类似，埋点字段也具有以下特点：
- 埋点字段一般也不会对外直接提供查询，而是以清洗后的维度和指标的形式对外使用。
- 衡量一个埋点字段的ROI具有也两个方面：使用次数与生产成本（存储+计算成本）。
因此，首先也需要构建埋点的血缘关系树来统计其使用次数，再以存储+计算资源消耗来衡量其生产成本，最终才能准确地评价埋点的价值。
为了解决以上两个问题，研发人员进行了埋点成本分析看板的开发建设：
- 首先，以原始埋点明细表的埋点字段为根节点，从上（埋点明细Hive表）至下（服务层提供维度、指标查询的ClickHouse表）建立埋点字段的血缘关系树
- 进一步将所有叶子节点的维度、指标字段的访问次数累加到相应根节点埋点字段上，作为该根节点埋点字段的使用次数
- 再统计埋点明细数据表的计算资源与存储资源，获得该埋点字段的的平均生产成本
- 最后关联埋点字段的总生产成本与总使用次数，评价该埋点字段的实际的ROI
埋点字段的生产成本vs使用次数
优化手段与思路
- 优化手段
① 停止解析和存储埋点字段
为了减少明细数据层字段的的计算与存储成本，可以直接对一些低频使用埋点停止解析与存储。
但是低频字段并不等于不使用字段，即如果要下线低频使用字段，需要保证用户在偶尔使用时仍然可以获取。虽然使用频次不同，但是同一张表中的埋点字段不能分别设置不同的存储方式或者TTL，只能选择存储或者不存储。
因此，对于低频使用埋点，结合用户的实际使用情况与开发维护成本，可以通过搭建采样链路、从原始数据层临时获取等方式满足偶尔的少量使用场景，从而可以减少明细数据层的字段解析与存储。
② 拆解埋点字段中常用的部分
还有一些被高频使用的埋点常常以复杂的url、json的格式上报存储。而实际在下游的使用过程中只会解析获取部分属性提供服务。因此，基于准确的获取下游的使用方式，将大字段拆解为小字段，不解析存储不使用的部分。
- 优化思路
配合「埋点成本分析看板」，根据不同的使用成本与使用次数阈值将看板分为四个象限，其中各个象限的数据表的含义及推荐的优化手段为：
根据优化收益进行治理的顺序为：第二象限>第三象限>第一象限>第四象限。
总结
基于数据成本分析看板，结合以上技术方案，如果是累计下线20+张数据表及对应任务，优化10+高成本任务，停止200+数据埋点解析，结合数据表温存与TTL缩减，初步测算能节省数仓总成本的36%费用。
在梳理了数据表、字段的血缘树的基础上，建立了Hive表成本分析看板、任务成本分析看板、埋点成本分析看板等看板，结合大数据研发治理套件火山引擎DataLeap对数仓建设过程中的数据表、数据任务、埋点字段的成本的进行了由粗到细的梳理与优化，提升了现有资源的承载能力，降低了建设成本。
