阿里云云原生一体化数仓 — 数据治理新能力解读

本文涉及的产品
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 本文介绍大数据开发治理平台DataWorks在数据治理领域的最新产品进展,包括基于事前、事中、事后的全链路理念构建的核心产品功能和数据治理量化评估机制解读,以及围绕降本增效的成本治理最佳实践。

分享人:阿里云智能 产品专家 唐晨


没来得及看直播的同学,可以观看直播回放。
直播回放:
https://developer.aliyun.com/live/249774


一、数据治理中心产品简介

阿里云DataWorks:一站式大数据开发与治理平台 架构大图

阿里云 DataWorks定位于一站式的大数据开发和治理平台,从下图可以看出,DataWorks 与 MaxCompute、Hologres 等大数据引擎紧密配合,在数据的 采、建、管、用 四个关键环节提供了丰富的产品功能,是阿里巴巴内部构建数据中台的核心平台型产品,支撑了电商新零售、广告营销、本地生活&出行、智慧物流、企业智能管理等几乎全部业务板块和企业运营管理的数字化建设工作需要。

21.png

随着数据建设的深入,我们愈发意识到数据治理是 数据资产化建设、加速数据价值释放 不可或缺的关键工作。在阿里集团内部,我们提出了构建 “质量可靠、安全稳定、生产经济、消费便捷” 的数据资产体系的目标,并围绕这个目标来开展数据治理工作。在DataWorks中也构建了相应的产品模块和能力进行支撑,比如上图所示的“数据质量管理”、“数据资产地图”、“数据安全管理”以及“数据治理中心”等。


企业数据治理实施的典型痛点

数据治理的工作在很多企业已经广泛开展或正准备开展,数据治理实施,有以下四个方面的典型痛点:

  • 数据治理入手难
  • 开展数据治理工作,通常会参考DAMA或者DCMM理论体系,可以发现数据治理涵盖内容极为广泛。从哪里优先入手,以什么样的路径来推进,这是企业进行数据治理工作首先要回答的问题。数据治理的目标和执行路径不清晰,是第一个典型痛点。
  • 数据治理落地难
  • 无论是企业内部自发地开展、还是请专业的咨询机构,构建出数据治理咨询方案、产出一些列的规范和管理办法后,往往只能停留于纸面,没有恰当的治理平台工具来支撑落地,这是会面临的第二个典型挑战。
  • 数据治理成效的可视化不足
  • 如何客观地评估治理、将治理成效量化、可视化。当这个工作没有做好时,治理的推进难度会显著加大。
  • 数据治理工作不可持续
  • 数据治理的工作容易陷入“运动式治理”,通过集中的突击、在一段时间内看到一定的效果。但如果不融入到日常的数据开发生产链路中去,这项工作就不持续,不能长久地、从根本性地解决治理的问题。

2.png

阿里巴巴实践的数据治理体系

在数据质量管理、元数据管理、数据安全管理等细分领域的工作完成之外,阿里巴巴集团创新地构建了如下一套全集团通用的数据治理体系,从 计算、存储、质量、安全、模型和成本等多个维度进行治理切入,采用统一的方法和策略,构建量化的评估模型,并使用统一的治理平台工具来承接落地,取得了显著的成效。

3.png

这套体系同,有几个关键要点:

  • 首先,明确治理的核心对象是与ETL作业中相关的任务和表。数据治理是治理客观的对象,不是治理人。但治理实施的一个关键前提,是对任务和表这些基本对象的确定归属,梳理并定义清楚对象的具体负责人,来确保治理问题有着落、有跟进。通过具体到人,进而汇聚到部门、到全集团整体,
  • 其次,数据治理采取的实施路径是 “现状分析 -> 问题定位 -> 优化治理 -> 效果评估”,构建一个闭环流程;
  • 最后,数据治理的核心,要落在量化上:将问题量化、将成效量化。并基于局部的明细给出全局的决策建议,比如为全集团的资源调配、各部门的预算制定、成本优化目标的设定等,提供参考。并且,这些量化的评估和治理问题的发现、修复,都会通过一个统一的平台工具来承接。

这套在阿里巴巴内部多年实践证明行之有效的方法和能力,现在以产品化的方式正式对云上客户提供服务,这就是 DataWorks数据治理中心 这一全新产品模块。

4.png

数据治理中心基于治理问题驱动,构建了一个 治理量化评估 - 问题发现/预防 -治理问题的优化处理 的闭环提升机制。基于事前预防、事后整治相结合的方式,提供了几大核心产品功能。这里要说明下,我们将这个“事前”、“事后”的“事”,定义为 数据平台中,ETL作业的正式数据生产 这一个环节。

  • 数据治理中心通过检查项的功能,可以做到在任务的提交、发布等关键环节,对于SQL代码的质量、性能消耗等进行自动扫描和检查卡点,来预防新问题的引入。这个有点类似于编译和优化的提示。
  • 当前面临的一个现实问题是数仓、数据中台的建设可能已经进行了较长时间,会存在许多存量的问题需要优化治理。数据治理中心的治理项功能,就是为此而设计,可以发现系统中存量的需要优化的问题,并给出对应的解决办法。与检查项一样,这也是一种全自动的方式。
  • 数据治理中心最具特色的,或者说是阿里巴巴内部数据治理实践的特色,是这套量化评估机制。基于治理“健康分”的概念,从“计算”、“存储”、“质量”、“安全”和“研发”五个基础维度进行量化评估,进而给出整体的治理健康度评估。便于治理实施前了解现状、同时也会数据治理实施后的成效提供客观评估。
  • 此外,数据治理中心在成本优化治理方面,也提供了资源使用分析等一系列的产品能力,可以清晰了解单个任务、单张表粒度的的资源消耗、费用预估以及资源异动情况,帮助公司有针对性地进行计算和存储的优化治理,来达成降本增效的目标。

DataWorks 数据治理中心 产品架构全图

5.png

数据治理中心本质上是一款由(元)数据驱动的数据应用产品,大致可以分为数据层、应用层和管理运营层。

  • 数据层:是整个产品模块的关键基础,数据治理中心汇聚了任务、表、模型、数据服务API等一系列的对象的元数据信息,并构建用以分析洞察的元数仓,来支撑上层的治理应用。
  • 治理应用层:数据治理中心的主体功能所在。基于内置的方案模板,提供用于事前问题自动预防、事后存量问题的自动发现,以及对应的优化处理指南等系列的功能。资源使用分析是面向成本治理构建的产品能力,包含资源的明细和异动分析等,以及规划中的资源智能优化建议。对象360用于汇聚展示对象的全景信息,尤其是需要治理优化的问题,并全生命周期追踪对象的事件变化情况等。标签体系作为额外的支撑体系,便于有效的对任务进行类型打标区分,然后进行集中式的治理。场景化治理是基于PDCA理念构建,来帮助按照业务需要,灵活圈选需要治理的对象、评估现状、设定治理目标,并有效监督治理实施进度,最终来达成治理落地。
  • 管理运营层:数据治理中心核心服务于数据治理管理员以及数据治理具体参与的一线同学两类用户群体。在管理运营层,提供了治理评估报告、治理健康分、治理排行榜和治理运营推送等一系列功能。


DataWorks 数据治理中心 概要使用路径

6.png

数据治理中心的使用,概要可以分为现状评估、治理实施和治理运营&成效查看三个环节:

数据治理现状评估

数据治理中心提供了内置的模板功能,将在阿里巴巴内部的实践和服务外部客户过程沉淀下来的最佳实践,以模板的方式封装,提供开箱即用的能力。选定模板、开启产品模块后,即可使用数十种丰富的治理项和检查项,并查看整体的治理评估报告,也就是治理的健康分评估。

开启产品模块之后,可以看到治理的评估报告。数据治理中心会提供 租户全局、单个工作空间以及具体个人 三个视角的报告,覆盖 研发、质量、安全、计算和存储 五个维度,给出量化的具体评估。最关键的一点,对于不同的工作空间、不同的个体,这个评估模型采用的是同一套标准,保证评估的客观一致性。这份报告,可以作为治理工作正式开始实施前的一个基础参照。

7.png

数据治理健康分评估模型

数据治理健康分基于治理项发现的问题、按照定义的模型计算得出。采用的扣分逻辑为满分100分,通过内置的算法模型,按需要治理问题减掉扣分后得到健康分。

数据治理中心 细分了 研发、质量、存储、安全、计算和存储 五个维度的单项健康分,并综合后计算得出整体健康分。这个逻辑可能看起来并不复杂,复杂的在于底层元数据获取、加工构建、治理问题洞察。

8.png

数据治理实施:问题预防、发现和优化

需要使用到检查项和治理项,检查项面向事前治理问题预防,它会侵入日常任务的提交、发布等环节,如果检测不通过会阻塞流程,这个功能是默认是不开启的,需要按需开启,并可以控制特定的工作空间启用特定的检查项。治理项面向事后治理问题发现,这个功能不需额外设置、启用模板后即可生效。

治理问题的处理优化-自动预防(检查项)

检查项开启后,可以作用在某一个具体空间,在任务提交或发布环节,能够自动触发扫描。

9.png

当前数据治理中心内置模板提供数十种检查项,开箱即用,其余检查项也在随着在阿里巴巴集团内部沉淀,以及依据客户的反馈,在逐步丰富中。

image.png

基于DataWorks开放平台自定义拓展检查项

如果系统内置的检查项不能完全满足您个性化的需要,我们还提供了基于DataWorks的开发平台来灵活的扩展的机制。检查项的扩展核心需要使用开放事件、扩展点和扩展程序的功能。基于这套机制,可以自定义开发个性化的检查器,然后注册到数据治理中心,和内置的检查器进行统一的纳管和使用。

10.png

治理问题的处理优化-自动发现(治理项)

事后治理使用到的是“治理项”的能力,治理项和检查项不同,治理项在模板启用后是自动开启的。系统会自动扫描出需要治理优化的问题,并提供相应的处理指南、指导对问题进行优化。

11.png

与检查项类似,数据治理中心,通过模板的方式,在存储、计算、安全、质量和研发五个维度,共内置了43个治理项,这些都是阿里巴巴内部实践和客户需求沉淀而来,开箱即用。

12.png

数据治理的长效运营机制

在阿里巴巴内部数据治理的演进中,能看到三个明显的方向,分别从组织、平台、业务三个方向来描述。首先,数据治理不单纯是大数据团队一直在搞技术、建平台,它更多的是一个组织协同的问题,会跨越过原先单技术团队,到影响到公司整体的架构设计,如下图左侧,有数据平台团队,有业务团队,还有财务、风控等协同团队。涉及到跨团队,对于整个组织来说,一个很头疼的问题就是如何来衡量效果?如何更好地发挥组织的主动性?在企业内部做治理,经常会发现,有一个很好的规范,但是没有平台来落地。在阿里巴巴内部,这是设计治理健康分的一个很大的出发点。对于某个BU来说,比如今年的目标之一,就是把健康分从70分提升到80分,可以从计算、存储、研发、治理、安全等各个方面入手,有什么需求可以提给数据平台团队,将这些能力都沉淀到平台上,目标大家一起来共背。通过这种方式,各个团队就会有一个统一的考核指标来指引进行数据治理的工作。在长效推进上,我们会启动各类的数据治理战役,各个业务团队之间的治理成效比武等等长效的运营工作,也可以通过健康分做不断地延展,达到组织数据的协同的目的,发挥数据治理组织的主动性。

13.png

就具体数据治理成效而言,作为承接,数据治理中心会将存储的节约、计算的节约,风险的预防、问题的修复等,清晰地量化统计展示,以及与之对应的健康分提升等,这些具体的治理效果,给清晰地展示出来。14.png

数据治理中心也着眼于将 数据治理 从 小部分人的工作 转变为 有良好群众基础和参与度的普遍性的工作。数据治理排行榜可以让治理参与同学清楚感知其所处的位置,让优秀的得到表扬,不足的得到鼓励;同时面向治理管理员和普通同学提供不同的视角,让其清晰了解治理健康度水平和需要优化的问题,有的放矢地进行优化治理。

15.png

二、成本优化治理最佳实践

16.png

我们来看一个成本优化治理的具体的案例。这个案例中,我们的客户使用DataWorks+MaxCompute产品组合来构建离线数仓,MaxComputes使用后付费模式,随着业务高速发展,费用出现一定程度的不可预估。客户提出的成本优化治理诉求是在支持业务发展的大前提下降低整体成本30%,并且对SLA有高保障要求,进行成本优化治理时不能降低对业务数据产出时间的承诺。我们采取了三大类的优化治理措施,达成了整体成本下降了35%+、数据生产的SLA依旧保持稳中有升的目标。

措施一:针对存量问题优化治理,下线任务和表,减少资源浪费

1、利用 资源使用概览 功能,查看计算/存储/调度/同步资源消耗异动,针对性优化。

image.png

2、利用 资源使用明细 功能,根据作业SLA容忍度以及消耗CU倒排进行调度错峰。

image.png

3、利用 任务360功能,查看特定任务可优化治理的具体问题并进行处理

image.png

4、利用 治理工作台功能,检查可优化治理的任务的全貌并参照处理指南进行优化

image.png

成本优化,可以重点关注数据治理中心提供的如下检查项和治理项:

  • 检查项:分区表查询必须带分区
  • 检查项:禁止简单加治工
  • 治理项:持续导入一致
  • 治理项:导入为空
  • 治理项:同源导入
  • 治理项:连续出错节点
  • 治理项:空跑节点
  • 治理项:无人访问叶子节点
  • 治理项:SELECT无效调度
  • 治理项:暴力扫描
  • 治理项:输入为空
  • 治理项:输出为空
  • 治理项:未设置生命周期
  • 治理项:长时间未访问表

措施二:MaxCompute项目后付费转预付费,使用二级Quota实现降本

17.png

MaxCompute的资源有“后付费”和“预付费”两种付费模式。其中“后付费”模式以其灵活的资源分配策略、能及时满足大任务对资源使用诉求的高保障、加速任务产出时间,被广泛使用;但是“后付费”模式存在一个问题就是无法从全局对费用进行提前规划和整体控制,容易出现预期之外大额账单。对照而言,“预付费”模式支持购买固定额度的资源,更便于整体控制预算。所以当前有较多的从“后付费”转“预付费”的诉求,来实现对整体预算的可控和成本的精细化优化。后付费转预付费,是一把双刃剑。毕竟预付费模式,购买的额度是有上限的,可能会影响任务的产出完成时间。转换前,需要事前了解项目的特性,比如是否有资源突发使用的情况,资源使用的高峰值和低峰值为多少,要进行全面的摸底。数据治理中心提供了后付费模式下,将资源使用折算成预付费模式的CU消耗趋势值,可以作为转换购买CU值的参照,经验值建议为趋势图峰值的 1.2倍 到 1.5倍。如果期望转换但又没有把握购买多少CU合适,也可以联系我们协助进行容量评估。

后付费转预付费后,充分使用MaxCompute二级Quota组的功能,能有效地帮助进行资源的优化调配,有三点实践经验分享:

  1. 强隔离:设置资源组的 最小保障量 = 最大保障量;确保资源的分配。比如下图中的“算法组”。这个适合在夜间作业高峰时段,对于需要强保障的项目进行设置。
  2. 资源倾斜:如果设置 min < max,则该Quota组空闲时,其它Quota组可以占用资源。这种方式可以提供较好的灵活弹性。
  3. 使用Quota组分时的功能,通过分时设置,可以有效平衡在夜间高峰生产作业的资源分配和白天分析查询项目的资源诉求,从而降低整体的CU购买峰值。

此外,有两点需要特别注意:

1、需要梳理作业的优先级、对高优作业配置DataWorks基线监控,来保障资源的优先分配;如果系统推测关键任务预计会出现产出延迟,可以提前发送告警通知,为处置留出足够的提前量。

2、转预付费后,MCQA查询加速资源需重新规划,如果有使用这个功能,需要特别留意。


措施三:面向补数据场景,灵活使用usequota特性,让资源消耗可控

18.png

补数据,也就是回刷数据的功能,在算法实验场景下使用非常多。通常如果一个模型验证效果很好,算法同学往往需要回刷一个礼拜、一个月、甚至半年的数据。算法作业有个典型特点的扫描数据量极大,但对于完成时间的SLA要求相对不高,比如一天之内可以完成即可,如果使用后付费模式,按照扫描数据量正比的方式收取费用,会带来非常高的成本开销。下图左侧示意了这种情况,周期调度任务的费用,拆分开来看是相对平稳可控的,但是补数据费用的不确定性,带来了整体成本的一定程度的不可控。针对这种场景,MaxCompute提供了 use quota 的新特性,将作业指向一个特定的预付费Quota组,限定一个较低的CU上线,既能保障任务的运行完成,又可以有效地控制费用。针对周期调度任务,原则上不建议使用 use quota ,这种方式对于SLA会带来较大的影响,需要仔细评估后再使用这种方式。至少配置上基线监控,以便能提前预知任务产出出现延迟的情况。


三、数据治理中心未来规划

数据治理立足降本增效的核心诉求,围绕治理问题的自动预防和治理演进,提升治理问题的处理效率。

功能建设

  • 基于阿里内部和Dataworks客户最佳实践,持续丰富内置的治理项和检查项,让治理问题得以更全面地发现和预防
  • 为任务下线、表删除等治理操作提供优雅处理方案,解决治理风险顾虑,提升问题优化治理效率和处置完成率
  • 持续夯实资源使用分析洞察功能,切实帮助控制不合理的资源使用花费
  • 拓展支持的引擎类型,从只支持MaxCompute,到支持EMRHive、Hologres等更多引擎类型
  • 提供面向不同行业的最佳实践和行业模板

产品商业化

  • 全面开放:  2022年7月,提供一个月限时免费体验(无版本限制)
  • 产品收费:  2022年8月(ETA),作为企业版的核心功能特性,不额外单独收费DataWorks增值版本计费与说明


更多 阿里云大数据产品>>

MaxCompute 二维码拼图.png

相关实践学习
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
目录
相关文章
|
19天前
|
存储 人工智能 OLAP
AI Agent越用越笨?阿里云AnalyticDB「AI上下文工程」一招破解!
AI 上下文工程是管理大模型输入信息的系统化框架,解决提示工程中的幻觉、上下文溢出与信息冲突等问题。通过上下文的采集、存储、加工与调度,提升AI推理准确性与交互体验。AnalyticDB PostgreSQL 版提供增强 RAG、长记忆、Supabase 等能力,助力企业构建高效、稳定的 AI 应用。
|
4月前
|
运维 算法 机器人
阿里云AnalyticDB具身智能方案:破解机器人仿真数据、算力与运维之困
本文将介绍阿里云瑶池旗下的云原生数据仓库AnalyticDB MySQL推出的全托管云上仿真解决方案,方案采用云原生架构,为开发者提供从开发环境、仿真计算到数据管理的全链路支持。
|
17天前
|
存储 人工智能 OLAP
AI Agent越用越笨?阿里云AnalyticDB「AI上下文工程」一招破解!
AI上下文工程是优化大模型交互的系统化框架,通过管理指令、记忆、知识库等上下文要素,解决信息缺失、长度溢出与上下文失效等问题。依托AnalyticDB等技术,实现上下文的采集、存储、组装与调度,提升AI Agent的准确性与协同效率,助力企业构建高效、稳定的智能应用。
|
2月前
|
存储 人工智能 关系型数据库
阿里云AnalyticDB for PostgreSQL 入选VLDB 2025:统一架构破局HTAP,Beam+Laser引擎赋能Data+AI融合新范式
在数据驱动与人工智能深度融合的时代,企业对数据仓库的需求早已超越“查得快”这一基础能力。面对传统数仓挑战,阿里云瑶池数据库AnalyticDB for PostgreSQL(简称ADB-PG)创新性地构建了统一架构下的Shared-Nothing与Shared-Storage双模融合体系,并自主研发Beam混合存储引擎与Laser向量化执行引擎,全面解决HTAP场景下性能、弹性、成本与实时性的矛盾。 近日,相关研究成果发表于在英国伦敦召开的数据库领域顶级会议 VLDB 2025,标志着中国自研云数仓技术再次登上国际舞台。
262 0
|
3月前
|
存储 人工智能 分布式计算
数据不用搬,AI直接炼!阿里云AnalyticDB AI数据湖仓一站式融合AI+BI
阿里云瑶池旗下的云原生数据仓库AnalyticDB MySQL版(以下简称ADB)诞生于高性能实时数仓时代,实现了PB级结构化数据的高效处理和分析。在前几年,为拥抱大数据的浪潮,ADB从传统数仓拓展到数据湖仓,支持Paimon/Iceberg/Delta Lake/Hudi湖格式,为开放的数据湖提供数据库级别的性能、可靠性和管理能力,从而更好地服务以SQL为核心的大规模数据处理和BI分析,奠定了坚实的湖仓一体基础。
|
6月前
|
存储 缓存 分布式计算
StarRocks x Iceberg:云原生湖仓分析技术揭秘与最佳实践
本文将深入探讨基于 StarRocks 和 Iceberg 构建的云原生湖仓分析技术,详细解析两者结合如何实现高效的查询性能优化。内容涵盖 StarRocks Lakehouse 架构、与 Iceberg 的性能协同、最佳实践应用以及未来的发展规划,为您提供全面的技术解读。 作者:杨关锁,北京镜舟科技研发工程师
StarRocks x Iceberg:云原生湖仓分析技术揭秘与最佳实践
|
4月前
|
存储 人工智能 关系型数据库
从“听指令”到“当参谋”,阿里云AnalyticDB GraphRAG如何让AI开窍
阿里云瑶池旗下的云原生数据仓库 AnalyticDB PostgreSQL 版 GraphRAG 技术,创新融合知识图谱动态推理+向量语义检索,通过实体关系映射与多跳路径优化,构建可应对复杂场景的决策引擎。本文将通过家电故障诊断和医疗预问诊两大高价值场景,解析其如何实现从“被动应答”到“主动决策”的跨越。
|
5月前
|
分布式计算 运维 监控
Fusion 引擎赋能:流利说如何用阿里云 Serverless Spark 实现数仓计算加速
本文介绍了流利说与阿里云合作,利用EMR Serverless Spark优化数据处理的全过程。流利说是科技驱动的教育公司,通过AI技术提升用户英语水平。原有架构存在资源管理、成本和性能等痛点,采用EMR Serverless Spark后,实现弹性资源管理、按需计费及性能优化。方案涵盖数据采集、存储、计算到查询的完整能力,支持多种接入方式与高效调度。迁移后任务耗时减少40%,失败率降低80%,成本下降30%。未来将深化合作,探索更多行业解决方案。
282 1
|
5月前
|
SQL 存储 缓存
海量数据分页查询效率低?一文解析阿里云AnalyticDB深分页优化方案
本文介绍了AnalyticDB(简称ADB)针对深分页问题的优化方案。深分页是指从海量数据中获取靠后页码的数据,常导致性能下降。ADB通过快照缓存技术解决此问题:首次查询生成结果集快照并缓存,后续分页请求直接读取缓存数据。该方案在数据导出、全量结果分页展示及业务报表并发控制等场景下表现出色。测试结果显示,相比普通分页查询,开启深分页优化后查询RT提升102倍,CPU使用率显著降低,峰值内存减少至原方案的几分之一。实际应用中,某互联网金融客户典型慢查询从30秒优化至0.5秒,性能提升60+倍。
355 1