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

本文涉及的产品
云原生数据仓库AnalyticDB MySQL版,8核32GB 100GB 1个月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 大数据平台治理——运营的角度看数仓

前言

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

分析框架

开局一张图

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

成本模型指标化

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

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

存储成本化

衡量存储的技术参数

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

项目 技术描述
文件 数据空间 、临时空间、资源空间
格式 文本、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、汇总、分布

后记

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

相关实践学习
数据库实验室挑战任务-初级任务
本场景介绍如何开通属于你的免费云数据库,在RDS-MySQL中完成对学生成绩的详情查询,执行指定类型SQL。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
目录
相关文章
|
16天前
|
数据采集 大数据
大数据实战项目之电商数仓(二)
大数据实战项目之电商数仓(二)
|
18天前
|
SQL 分布式计算 关系型数据库
实时数仓 Hologres产品使用合集之湖仓加速版查询maxcompute外部表,有什么优化途径吗
实时数仓Hologres的基本概念和特点:1.一站式实时数仓引擎:Hologres集成了数据仓库、在线分析处理(OLAP)和在线服务(Serving)能力于一体,适合实时数据分析和决策支持场景。2.兼容PostgreSQL协议:Hologres支持标准SQL(兼容PostgreSQL协议和语法),使得迁移和集成变得简单。3.海量数据处理能力:能够处理PB级数据的多维分析和即席查询,支持高并发低延迟查询。4.实时性:支持数据的实时写入、实时更新和实时分析,满足对数据新鲜度要求高的业务场景。5.与大数据生态集成:与MaxCompute、Flink、DataWorks等阿里云产品深度融合,提供离在线
|
29天前
|
存储 SQL 分布式计算
闲侃数仓优化-大数据治理和优化
闲侃数仓优化-大数据治理和优化
39 0
|
4天前
|
存储 分布式计算 DataWorks
MaxCompute产品使用问题之dataworks仅支持maxcompute上面的数据治理吗
MaxCompute作为一款全面的大数据处理平台,广泛应用于各类大数据分析、数据挖掘、BI及机器学习场景。掌握其核心功能、熟练操作流程、遵循最佳实践,可以帮助用户高效、安全地管理和利用海量数据。以下是一个关于MaxCompute产品使用的合集,涵盖了其核心功能、应用场景、操作流程以及最佳实践等内容。
|
1月前
|
存储 数据挖掘 大数据
大数据数仓建模基础理论【维度表、事实表、数仓分层及示例】
数据仓库建模是组织和设计数据以支持数据分析的过程,包括ER模型和维度建模。ER模型通过实体和关系描述数据结构,遵循三范式减少冗余。维度建模,特别是Kimball方法,用于数据仓库设计,便于分析和报告。事实表存储业务度量,如销售数据,分为累积、快照、事务和周期性快照类型。维度表提供描述性信息,如时间、产品、地点和客户详情。数仓通常分层为ODS(源数据)、DWD(明细数据)、DIM(公共维度)、DWS(数据汇总)和ADS(应用数据),以优化数据管理、质量、查询性能和适应性。
|
16天前
|
消息中间件 分布式计算 Hadoop
大数据实战项目之电商数仓(一)
大数据实战项目之电商数仓(一)
|
28天前
|
数据采集 存储 监控
大数据治理:确保数据质量和合规性
【5月更文挑战第30天】大数据治理涉及数据分类、访问控制和质量监控,以确保数据安全和合规性。企业需保护个人隐私,防止数据泄露,并遵守各地法规,如GDPR和CCPA。技术实践包括数据加密、匿名化和严格访问控制。管理策略则强调制定政策、员工培训和法律合作。全面的数据治理能保障数据质量,驱动组织的创新和价值增长。
44 0
|
29天前
|
存储 SQL 分布式计算
大数据平台治理资源成本化
大数据平台治理资源成本化
28 0
|
17天前
|
Cloud Native 数据管理 OLAP
云原生数据仓库AnalyticDB产品使用合集之是否可以创建表而不使用分区
阿里云AnalyticDB提供了全面的数据导入、查询分析、数据管理、运维监控等功能,并通过扩展功能支持与AI平台集成、跨地域复制与联邦查询等高级应用场景,为企业构建实时、高效、可扩展的数据仓库解决方案。以下是对AnalyticDB产品使用合集的概述,包括数据导入、查询分析、数据管理、运维监控、扩展功能等方面。
340 2
云原生数据仓库AnalyticDB产品使用合集之是否可以创建表而不使用分区
|
17天前
|
SQL Cloud Native 关系型数据库
云原生数据仓库AnalyticDB产品使用合集之如何进行一键诊断
阿里云AnalyticDB提供了全面的数据导入、查询分析、数据管理、运维监控等功能,并通过扩展功能支持与AI平台集成、跨地域复制与联邦查询等高级应用场景,为企业构建实时、高效、可扩展的数据仓库解决方案。以下是对AnalyticDB产品使用合集的概述,包括数据导入、查询分析、数据管理、运维监控、扩展功能等方面。
353 7