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

本文涉及的产品
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 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、汇总、分布

后记

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

相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
目录
相关文章
|
1月前
|
数据采集 监控 数据管理
数据治理之道:大数据平台的搭建与数据质量管理
【10月更文挑战第26天】随着信息技术的发展,数据成为企业核心资源。本文探讨大数据平台的搭建与数据质量管理,包括选择合适架构、数据处理与分析能力、数据质量标准与监控机制、数据清洗与校验及元数据管理,为企业数据治理提供参考。
86 1
|
8天前
|
机器学习/深度学习 存储 数据采集
解锁DataWorks:一站式大数据治理神器
解锁DataWorks:一站式大数据治理神器
30 1
|
1月前
|
数据采集 分布式计算 大数据
数据治理之道:大数据平台的搭建与数据质量管理
【10月更文挑战第27天】在数字化时代,数据治理对于确保数据资产的保值增值至关重要。本文探讨了大数据平台的搭建和数据质量管理的重要性及实践方法。大数据平台应包括数据存储、处理、分析和展示等功能,常用工具如Hadoop、Apache Spark和Flink。数据质量管理则涉及数据的准确性、一致性和完整性,通过建立数据质量评估和监控体系,确保数据分析结果的可靠性。企业应设立数据治理委员会,投资相关工具和技术,提升数据治理的效率和效果。
105 2
|
2月前
|
分布式计算 大数据 Serverless
云栖实录 | 开源大数据全面升级:Native 核心引擎、Serverless 化、湖仓架构引领云上大数据发展
在2024云栖大会开源大数据专场上,阿里云宣布推出实时计算Flink产品的新一代向量化流计算引擎Flash,该引擎100%兼容Apache Flink标准,性能提升5-10倍,助力企业降本增效。此外,EMR Serverless Spark产品启动商业化,提供全托管Serverless服务,性能提升300%,并支持弹性伸缩与按量付费。七猫免费小说也分享了其在云上数据仓库治理的成功实践。其次 Flink Forward Asia 2024 将于11月在上海举行,欢迎报名参加。
236 6
云栖实录 | 开源大数据全面升级:Native 核心引擎、Serverless 化、湖仓架构引领云上大数据发展
|
1月前
|
分布式计算 大数据 OLAP
AnalyticDB与大数据生态集成:Spark & Flink
【10月更文挑战第25天】在大数据时代,实时数据处理和分析变得越来越重要。AnalyticDB(ADB)是阿里云推出的一款完全托管的实时数据仓库服务,支持PB级数据的实时分析。为了充分发挥AnalyticDB的潜力,将其与大数据处理工具如Apache Spark和Apache Flink集成是非常必要的。本文将从我个人的角度出发,分享如何将AnalyticDB与Spark和Flink集成,构建端到端的大数据处理流水线,实现数据的实时分析和处理。
67 1
|
6月前
|
数据采集 监控 大数据
大数据时代的数据质量与数据治理策略
在大数据时代,高质量数据对驱动企业决策和创新至关重要。然而,数据量的爆炸式增长带来了数据质量挑战,如准确性、完整性和时效性问题。本文探讨了数据质量的定义、重要性及评估方法,并提出数据治理策略,包括建立治理体系、数据质量管理流程和生命周期管理。通过使用Apache Nifi等工具进行数据质量监控和问题修复,结合元数据管理和数据集成工具,企业可以提升数据质量,释放数据价值。数据治理需要全员参与和持续优化,以应对数据质量挑战并推动企业发展。
1676 3
|
1月前
|
数据采集 分布式计算 OLAP
最佳实践:AnalyticDB在企业级大数据分析中的应用案例
【10月更文挑战第22天】在数字化转型的大潮中,企业对数据的依赖程度越来越高。如何高效地处理和分析海量数据,从中提取有价值的洞察,成为企业竞争力的关键。作为阿里云推出的一款实时OLAP数据库服务,AnalyticDB(ADB)凭借其强大的数据处理能力和亚秒级的查询响应时间,已经在多个行业和业务场景中得到了广泛应用。本文将从个人的角度出发,分享多个成功案例,展示AnalyticDB如何助力企业在广告投放效果分析、用户行为追踪、财务报表生成等领域实现高效的数据处理与洞察发现。
55 0
|
6月前
|
数据采集 大数据
大数据实战项目之电商数仓(二)
大数据实战项目之电商数仓(二)
153 0
|
5月前
|
数据采集 运维 Cloud Native
Flink+Paimon在阿里云大数据云原生运维数仓的实践
构建实时云原生运维数仓以提升大数据集群的运维能力,采用 Flink+Paimon 方案,解决资源审计、拓扑及趋势分析需求。
18529 54
Flink+Paimon在阿里云大数据云原生运维数仓的实践
|
5月前
|
存储 机器学习/深度学习 大数据
参与开源大数据Workshop·杭州站,共探企业湖仓演进实践
Apache Flink 诚邀您参加 7 月 27 日在杭州举办的阿里云开源大数据 Workshop,了解流式湖仓、湖仓一体架构的最近演进方向,共探企业云上湖仓实践案例。
181 12
参与开源大数据Workshop·杭州站,共探企业湖仓演进实践
下一篇
DataWorks