火山引擎Dataleap治理实践:如何降低数仓建设成本

背景

存储与计算资源是数仓建设的基础,也是数仓建设中的重要成本支出。而随着数仓建设规模逐渐扩大、时间跨度逐渐拉长,将不可避免的出现数据表、任务、字段的冗余。为了减轻资源负担,降低数仓维护成本,需要对数仓建设成本进行治理与优化。

技术路线

针对数仓建设成本治理的粒度从大到小可以分为:数据表、数据任务、数据表字段。从粗到细的治理优化思路如下:

  1. 当发现低频使用的数据表时,下线对应数据表的同时也删除对应数据任务;
  2. 当数据任务资源浪费严重,针对任务进行对应的代码与资源优化;
  3. 当发现一张表中个别字段使用使用频率很低,停止相关字段的计算与存储。

根据以上的优化思路,首先要解决如何定位低频使用数据表、高资源浪费率任务、低频使用字段的问题,在此基础上,针对不同的场景通过不同的手段进行优化。
火山引擎Dataleap治理实践:如何降低数仓建设成本_第1张图片

技术方案

低频使用数据表优化方案
定位低频使用数据表
火山引擎Dataleap提供了Hive表的资源治理功能,包括Hive表的存储与访问次数等基本信息查询,用户可以根据该功能直接定位低频使用数据表并进行优化。
火山引擎Dataleap治理实践:如何降低数仓建设成本_第2张图片
但是以上的优化存在以下缺陷:

  1. 使用Hive表的直接查询次数无法准确衡量用户对于数据的实际使用次数:为了保障查询速度,数据一般会由Hive表导入到ClickHouse等查询速度较快的介质中,而不会直接查询Hive表。因此,一张Hive表的直接访问次数一般是由下游的日常数据任务产生,而不是真正的用户查询。
  2. 缺少了对数据表生产过程中计算资源的统计:数据表在生产的过程中,除了占用存储资源,计算资源是不可或缺的一部分:存在经过复杂计算过程后,产出很小数据量的数据表。因此,当希望对成本进行快速优化时需要瞄准高成本的数据表时,只着眼于数据表占用的存储资源是不够全面的。
  • Hive表成本分析看板
    为了解决以上两个问题,火山引擎Dataleap研发人员进行了Hive表成本分析看板的开发建设:
  1. 首先,对数据表进行血缘关系的梳理,从上(Hive表)至下(ClickHouse)建立数据表血缘关系树
  2. 进一步将所有叶子节点的访问次数累加到相应根节点上,作为该根节点的使用次数(直接访问+间接访问)
  3. 再统计数据表计算资源,关联数据表存储资源,获得该数据表的总生产成本
  4. 最后关联数据表的总生产成本与总使用次数,评价该数据表实际的ROI
    火山引擎Dataleap治理实践:如何降低数仓建设成本_第3张图片
    优化手段与思路
  5. 优化手段
    针对数据表的优化手段有:
    ① 下线数据表及对应任务
    在火山引擎Dataleap下线相关任务,并删除对应数据表。
    ② 缩减数据表TTL
    根据「表分区查询热度分布图」在火山引擎Dataleap修改对应数据表TTL对应数据表。

火山引擎Dataleap治理实践:如何降低数仓建设成本_第4张图片
③ 对历史数据进行温存配置
在火山引擎Dataleap配置历史数据温存天数。

  1. 优化思路
    基于「Hive表成本分析看板」,根据不同的使用成本与使用次数阈值(如数据表的生产成本1000元/月,使用次数100次/月)将看板分为四个象限,其中各个象限的数据表的含义及推荐的优化手段为:
    火山引擎Dataleap治理实践:如何降低数仓建设成本_第5张图片
    根据优化收益进行治理的顺序为:第二象限>第三象限>第一象限>第四象限。

低资源利用率任务优化方案
定位低资源利用率任务数据任务
计算资源分为CPU资源和内存资源,可以利用火山引擎Dataleap进行高浪费任务的定位与探查。
火山引擎Dataleap治理实践:如何降低数仓建设成本_第6张图片
「任务资源使用监控」

优化手段与思路

  • 对于新增任务
    基于大数据研发治理套件火山引擎DataLeap,在新建数据任务与数据表时,要求需求方提供数据的服务时限,设置数据任务的寿命。当寿命到期,会提醒相关负责人确认是否可下线当前数据任务。

火山引擎Dataleap治理实践:如何降低数仓建设成本_第7张图片
火山引擎Dataleap治理实践:如何降低数仓建设成本_第8张图片

  • 对于历史任务
    目前离线数据任务的主要计算引擎为Apache Spark。

低频使用字段优化方案

相比于数据表与任务,针对数据表中的低频使用的字段进行优化是一种更加细粒度的方式。
定位低频使用字段
在离线数仓建设中,原始日志一般会从消息队列中直接不加处理的存储到原始数据层,再通过明细数据层对原始日志进行字段清洗与解析。在实践中,火山引擎DataLeap研发人员发现处于明细数据层中的原始埋点明细表由于数据量巨大(单表PB量级):在某些数据库中,仅三张表格就占据了所在数据库75%的存储大小,个别数据表的字段平均存储大小约为150TB。因此,为了更加高效地完成数据表字段优化,研发人员从埋点明细表的埋点字段入手。
和Hive数据表类似,埋点字段也具有以下特点:

  1. 埋点字段一般也不会对外直接提供查询,而是以清洗后的维度和指标的形式对外使用
  2. 衡量一个埋点字段的ROI具有也两个方面:使用次数与生产成本(存储+计算成本)。
    因此,首先也需要构建埋点的血缘关系树来统计其使用次数,再以存储+计算资源消耗来衡量其生产成本,最终才能准确地评价埋点的价值。
    为了解决以上两个问题,研发人员进行了埋点成本分析看板的开发建设:
  3. 首先,以原始埋点明细表的埋点字段为根节点,从上(埋点明细Hive表)至下(服务层提供维度、指标查询的ClickHouse表)建立埋点字段的血缘关系树
  4. 进一步将所有叶子节点的维度、指标字段的访问次数累加到相应根节点埋点字段上,作为该根节点埋点字段的使用次数
  5. 再统计埋点明细数据表的计算资源与存储资源,获得该埋点字段的的平均生产成本
  6. 最后关联埋点字段的总生产成本与总使用次数,评价该埋点字段的实际的ROI

火山引擎Dataleap治理实践:如何降低数仓建设成本_第9张图片
优化手段与思路

  1. 优化手段
    ① 停止解析和存储埋点字段
    为了减少明细数据层字段的的计算与存储成本,可以直接对一些低频使用埋点停止解析与存储。
    但是低频字段并不等于不使用字段,即如果要下线低频使用字段,需要保证用户在偶尔使用时仍然可以获取。虽然使用频次不同,但是同一张表中的埋点字段不能分别设置不同的存储方式或者TTL,只能选择存储或者不存储。
    因此,对于低频使用埋点,结合用户的实际使用情况与开发维护成本,可以通过搭建采样链路、从原始数据层临时获取等方式满足偶尔的少量使用场景,从而可以减少明细数据层的字段解析与存储。
    ② 拆解埋点字段中常用的部分
    还有一些被高频使用的埋点常常以复杂的url、json的格式上报存储。而实际在下游的使用过程中只会解析获取部分属性提供服务。因此,基于准确的获取下游的使用方式,将大字段拆解为小字段,不解析存储不使用的部分。
  2. 优化思路
    配合「埋点成本分析看板」,根据不同的使用成本与使用次数阈值将看板分为四个象限,其中各个象限的数据表的含义及推荐的优化手段为:
    火山引擎Dataleap治理实践:如何降低数仓建设成本_第10张图片
    根据优化收益进行治理的顺序为:第二象限>第三象限>第一象限>第四象限。
    总结
    基于数据成本分析看板,结合以上技术方案,如果是累计下线20+张数据表及对应任务,优化10+高成本任务,停止200+数据埋点解析,结合数据表温存与TTL缩减,初步测算能节省数仓总成本的36%费用。
    在梳理了数据表、字段的血缘树的基础上,建立了Hive表成本分析看板、任务成本分析看板、埋点成本分析看板等看板,结合大数据研发治理套件火山引擎DataLeap对数仓建设过程中的数据表、数据任务、埋点字段的成本的进行了由粗到细的梳理与优化,提升了现有资源的承载能力,降低了建设成本。

你可能感兴趣的:(火山引擎,大数据)