前言

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

分析框架

开局一张图

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

成本模型指标化

数仓的成本模型其实分为两大块，一块就是我们的存储，另一块就是计算了，我们关注的就是存储到底有没有问题，或者说计算是不是有问题，怎样去衡量这两块健康与否呢，一般是三部曲——技术参数量化+资源消耗成本化+成本指标化，下面我们分别进行说明。

大数据平台的成本主要是存储成本和计算成本来衡量。下面从这两块进行剖析。

存储成本化

衡量存储的技术参数

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

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

存储的目标

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

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

存储成本化

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

存储成本指标

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

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

资源成本化

衡量资源的技术参数

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

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

计算目标

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

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

资源成本指标

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

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

数仓规范

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

数仓层次化规范

数据的划分

数据的划分其实也就是我们所谓的顶层设计，划分的方式本身随着业务的规模，组织结构以及经济体的要求不同而不一样，但是不管出于什么考虑，我们总是希望我们的数据在整个划分层次上是可以找到对应关系的，不管是传统的3层也好，5层也好，甚至7层模型也好，我个人观点可以参考我们的linux对目录的划分，不管世界怎么复杂，都需要有自己的归属。

需要了解的是，即使是数据的架构，是紧密跟上时代的变化的，传统的ODS->DWD->DWS->ADM的场景在企业发展的过程中不断的经受着新挑战，首要的其实就是软件系统的改变，下一步就是数据体系的改变了，所以数仓规范的过程其实是有参考现代容器化部署的思想，引入租户隔离、单元板块架构，加上原有的项目划分和数仓分层便是现代的架构模式了。

层次化规范的考量

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

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

层次划分下的指标

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

模型规范

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

模型定义的规范

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

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

模型定义规范性指标

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

后记

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

我也是爱分享的，扫波码支持一下吧^^