存储与计算资源是数仓建设的基础，也是数仓建设中的重要成本支出。而随着数仓建设规模逐渐扩大、时间跨度逐渐拉长，将不可避免的出现数据表、任务、字段的冗余。
技术路线针对数仓建设成本治理的粒度从大到小可以分为：数据表、数据任务、数据表字段。从粗到细的治理优化思路如下：
(资料图片)
根据以上的优化思路，首先要解决如何定位低频使用数据表、高资源浪费率任务、低频使用字段的问题，在此基础上，针对不同的场景通过不同的手段进行优化。
"数仓建设成本分析"看板总览
技术方案低频使用数据表优化方案定位低频使用数据表火山引擎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对数仓建设过程中的数据表、数据任务、埋点字段的成本的进行了由粗到细的梳理与优化，提升了现有资源的承载能力，降低了建设成本。