大数据平台治理——运营的角度看数仓

前言

三分靠技术,七分靠管理,其实一直就是技术岗位的现状,事实上在一个完整的互联网产业结构中,除了本身的软件性能和软件设计的优雅追求,还有着业务的持续运营以及背后的商业模式的运作。分析师的工作更多的就是指导业务的运营以及商业上成本的考量,以便为进一步的决策提供数据参考,本文就从一个数据分析师的角度去聊一下数仓的治理。

分析框架

开局一张图
在这里插入图片描述
我们说一个数仓的好与坏不是单纯的某个地方的好与坏,而是通过从左看右看上看下看达到一个优化局部最优到整体最优的解决方案。我们需要的一个结果就是数仓的健康,当然,健康的定义又可以有很多诠释,比如说控制野蛮生长、高时效、资产覆盖度厚实、模型规范、高质量等考量。基于各个方面的考量,我对数仓需要关注的点做了一个梳理,从这些点出发,我们便可以去建立考核的运营指标。从大类的划分主要分到两块,一块就是资源成本模型,因为本身成本就是钱嘛,另一块的话就是数仓的规范性,因为数仓的规范性衡量的其实就是数仓好用的一个方向,毕竟这个才是本身数仓的价值所在。

成本模型指标化

数仓的成本模型其实分为两大块,一块就是我们的存储,另一块就是计算了,我们关注的就是存储到底有没有问题,或者说计算是不是有问题,怎样去衡量这两块健康与否呢,一般是三部曲——技术参数量化+资源消耗成本化+成本指标化,下面我们分别进行说明。
在这里插入图片描述
大数据平台的成本主要是存储成本和计算成本来衡量。下面从这两块进行剖析。

存储成本化

衡量存储的技术参数

衡量存储的参数项主要是空间+格式+压缩算法,如下表格:

项目技术描述
文件数据空间 、临时空间、资源空间
格式文本、ORC、SequenceFile
存储介质SSD、HDD、SMR
压缩算法gzip、bzip2、LZO、LZ4、Snappy

存储的目标

存储少+备份少+压缩比高+更省钱便是存储的目标了,为了达成目标我们其实是通过不同手段去实施的,可想到的办法可以一张表格:

项目办法
存储少模型优化、减少节点数、周期性清理、无用表删除、视图化或者物化视图
备份少回收站清理,中间表直接去掉回收站、EC编码归档(3份变成1.5份)
压缩比高Orc存储、数据重分布、Bucket分桶存储
省钱冷备份、便宜存储介质

存储成本化

根据存储的目标,存储成本化,我们一般是按照计算和存储总成本进行分摊,成本=(存储r1+计算r2),然后进行定价,比如1TB=1块钱,其中1块钱按照总成本进行换算分摊,因为还会分摊总的包括机柜,带宽的成本,所以成本计算并不代表实实在在的采购成本,但是会有对应的关系。

存储成本指标

指标的构建可以比较灵活去调整,目标是有效指导且可落地,可衡量成本的参考指标如下:

类别指标项粒度参考获取
存储容量、长生命周期数量部门、项目、OwnerTopN、汇总、分布
备份类回收站生命周期、容量部门、项目、OwnerTopN、汇总、分布
压缩格式压缩格式占比、容量部门、项目、OwnerTopN、汇总、分布
低成本表访问频率,存储格式,容量部门、项目、OwnerTopN、汇总、分布

资源成本化

衡量资源的技术参数

衡量计算的主要参数是资源占用+计算耗时因为资源的计算平台是比较难容忍高峰期的占用,且和调度频率都有关系,所以一般还会考虑调度成本、如下表格:

项目技术描述
CPU消耗Task占用CPU个数*时间
内存消耗Task内存占用*时间
作业时间XX分钟
调度频率分钟级、小时级、天级、每天调度次数
调度时间段高峰时期(00:00-9:00)、低峰时间段(9:00-22:00)
数据倾斜严重倾斜、轻度倾斜
大文件扫描长周期数据扫描
资源分布低并发、高并发

计算目标

对于资源的优化来说,其实目标就是达到计算性能的优化,但是计算的场景其实是相对复杂的,针对整个平台来说,实际的场景是保障高峰时段的资源使用就可以了,而且是关注高优先级的作业,低峰的话就没关系了,一般平台侧识别出一些问题场景,针对问题比较大的场景去进行优化,同时优化侧的办法其实是由平台和Owner一起出方案进行落地。

项目办法
高峰资源减少不紧急任务错峰、调度后延、任务定点性能优化
高频作业保障高频作业常驻内存、批作业流化
作业计算合理性大扫描、倾斜等任务治理
资源保障优先级划分、资源分配粒度合理、资源借调

资源成本指标

指标的构建可以比较灵活去调整,目标是更多的发现问题,可衡量成本的参考指标如下:

类别指标项粒度参考获取
资源资源使用分布队列、部门、项目、OwnerTopN、汇总、分布、高峰时段、低峰时段
作业问题类数据倾斜、大扫描、任务报错部门、项目、OwnerTopN、汇总、分布
作业频率作业天调度次数作业级TopN、汇总、分布
作业优先级高优先级作业数量、延迟情况部门、项目、OwnerTopN、汇总、分布
时效保障1小时以上作业数量、2小时以上作业数量部门、项目、OwnerTopN、汇总、分布

数仓规范

前面提到,数仓的规范其实是衡量数仓好用不好用的一项参考,要想衡量一个数仓好和不好,我们首要的就是给好和不好界定标准、然后根据这个标准去进行匹配,这样我们就可以对健康程度进行量化,从而产生我们的运营指标。所以对于数仓来说,也是三部曲:——定义标准+标准化度量+模型健康度指标。数仓的衡量主要是在模型规范和层次规范上进行衡量,下面逐一说明。
在这里插入图片描述

数仓层次化规范

数据的划分

数据的划分其实也就是我们所谓的顶层设计,划分的方式本身随着业务的规模,组织结构以及经济体的要求不同而不一样,但是不管出于什么考虑,我们总是希望我们的数据在整个划分层次上是可以找到对应关系的,不管是传统的3层也好,5层也好,甚至7层模型也好,我个人观点可以参考我们的linux对目录的划分,不管世界怎么复杂,都需要有自己的归属。
在这里插入图片描述
需要了解的是,即使是数据的架构,是紧密跟上时代的变化的,传统的ODS->DWD->DWS->ADM的场景在企业发展的过程中不断的经受着新挑战,首要的其实就是软件系统的改变,下一步就是数据体系的改变了,所以数仓规范的过程其实是有参考现代容器化部署的思想,引入租户隔离、单元板块架构,加上原有的项目划分和数仓分层便是现代的架构模式了。
在这里插入图片描述

层次化规范的考量

我们的考量标准,在划分的基础之上对资产都有挂靠,这在一片混乱的资产治理中便是迈向了第一步。

项目技术描述
单元板块划分有无定义
穿透率下游对上游访问是按层次还是直接跨层级访问
层级覆盖指的上一层次的访问对下游的覆盖情况,一般是观测中间层资产的覆盖程度

层次划分下的指标

类别指标项粒度参考获取
资产分布可挂靠的资产数量单元、板块、项目、OwnerTopN、汇总、分布
资产分布跨板块不可覆盖的资产数量项目、OwnerTopN、汇总、分布
穿透率dws、adm等下游应用层穿透到ods的数量、比率单元、板块、项目、OwnerTopN、汇总、分布
穿透率adm等下游应用直接访问上一层级dwd\dws的数量、比率单元、板块、项目、OwnerTopN、汇总、分布

模型规范

模型规范主要是从模型定义规范和数据质量上面来衡量,定义规范是保障使用方好用而质量保证是保证数据是对的,这个是对数据最base的要求。

模型定义的规范

表的定义一般是按照层级规范会做表名上的约束,不符合规范的就是异常情况了,规范命名的建议是单独对不同层次去做规范,因为在ods+dwd+dws+adm表达的信息其实不一样,我们的目标是期望在命名上就找到归类。剩下的便是基础的对表使用了。

项目技术描述
表命名规范是否按照规范定义
生命周期明确的生命周期和说明
描述信息常规的就是中文信息,其他国际化场景是详细英文注释
字段合理性字段的定义、取值是否是遵循存储内容合理定义
时效要求期望描述是高优先级还是常规,对资源分配要求不会一样
数据来源期望描述上下文数据的获取来源
数据质量准确性、完整性、一致性的要求,需要有对应的dqc规则覆盖

模型定义规范性指标

类别指标项粒度参考获取
表命名规范规范资产+不规范资产定义量单元、板块、项目、OwnerTopN、汇总、分布
生命周期长周期资产、历史无访问的数据情况、数量+明细项目、OwnerTopN、汇总、分布、明细清单
时效要求高基线上的高延迟作业单元、板块、项目、OwnerTopN、汇总、分布
描述信息描述信息、字段信息是空的情况单元、板块、项目、Owner、表清单TopN、汇总、分布
数据质量数据质量通过率单元、板块、项目、Owner、表清单TopN、汇总、分布

后记

从各种资产考量中定义问题,到指标化其实是整个一个数据运营分析的一个思路,此时的数仓其实是需要当作一个业务主体来看待——基于数仓的元数据去看数仓,从指标体系的角度去看到整个数仓的资产状态,找出优化数仓的最短路径,便是达到了我们的目标。

我也是爱分享的,扫波码支持一下吧^^
在这里插入图片描述

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值