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

本文涉及的产品
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务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,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
目录
相关文章
|
11天前
|
运维 Cloud Native 应用服务中间件
阿里云微服务引擎 MSE 及 云原生 API 网关 2024 年 10 月产品动态
阿里云微服务引擎 MSE 面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持 Nacos/ZooKeeper/Eureka )、云原生网关(原生支持Higress/Nginx/Envoy,遵循Ingress标准)、微服务治理(原生支持 Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。API 网关 (API Gateway),提供 APl 托管服务,覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等 API 生命周期阶段。帮助您快速构建以 API 为核心的系统架构.满足新技术引入、系统集成、业务中台等诸多场景需要
|
1月前
|
运维 Cloud Native 数据可视化
阿里云云原生应用组装平台BizWorks满分通过最新评估
阿里云BizWorks满分通过《基于云计算的业务组装平台能力成熟度模型》评测,获得优秀级(最高等级),广东移动联合阿里云BizWorks团队开展的组装式应用实践获得第三届“鼎新杯”数字化转型应用优秀案例一等奖。
191 3
|
1月前
|
运维 Cloud Native 应用服务中间件
阿里云微服务引擎 MSE 及 云原生 API 网关 2024 年 09 月产品动态
阿里云微服务引擎 MSE 面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持 Nacos/ZooKeeper/Eureka )、云原生网关(原生支持Higress/Nginx/Envoy,遵循Ingress标准)、微服务治理(原生支持 Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。API 网关 (API Gateway),提供 APl 托管服务,覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等 API 生命周期阶段。帮助您快速构建以 API 为核心的系统架构.满足新技术引入、系统集成、业务中台等诸多场景需要
|
1月前
|
人工智能 自然语言处理 关系型数据库
阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成
近日,阿里云云原生数据仓库 AnalyticDB PostgreSQL 版已完成和开源LLMOps平台Dify官方集成。
|
28天前
|
运维 Cloud Native 持续交付
云原生技术解析:从IO出发,以阿里云原生为例
【10月更文挑战第24天】随着互联网技术的不断发展,传统的单体应用架构逐渐暴露出扩展性差、迭代速度慢等问题。为了应对这些挑战,云原生技术应运而生。云原生是一种利用云计算的优势,以更灵活、可扩展和可靠的方式构建和部署应用程序的方法。它强调以容器、微服务、自动化和持续交付为核心,旨在提高开发效率、增强系统的灵活性和可维护性。阿里云作为国内领先的云服务商,在云原生领域有着深厚的积累和实践。
54 0
|
8天前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
10天前
|
运维 Kubernetes Cloud Native
云原生技术:容器化与微服务架构的完美结合
【10月更文挑战第37天】在数字化转型的浪潮中,云原生技术以其灵活性和高效性成为企业的新宠。本文将深入探讨云原生的核心概念,包括容器化技术和微服务架构,以及它们如何共同推动现代应用的发展。我们将通过实际代码示例,展示如何在Kubernetes集群上部署一个简单的微服务,揭示云原生技术的强大能力和未来潜力。
|
11天前
|
消息中间件 存储 Cloud Native
云原生架构下的数据一致性挑战与应对策略####
本文探讨了在云原生环境中,面对微服务架构的广泛应用,数据一致性问题成为系统设计的核心挑战之一。通过分析云原生环境的特点,阐述了数据不一致性的常见场景及其对业务的影响,并深入讨论了解决这些问题的策略,包括采用分布式事务、事件驱动架构、补偿机制以及利用云平台提供的托管服务等。文章旨在为开发者提供一套系统性的解决方案框架,以应对在动态、分布式的云原生应用中保持数据一致性的复杂性。 ####
|
5天前
|
Cloud Native 云计算 Docker
云原生技术的崛起:从容器化到微服务架构
云原生技术的崛起:从容器化到微服务架构
|
8天前
|
Cloud Native 安全 API
云原生架构下的微服务治理策略与实践####
—透过云原生的棱镜,探索微服务架构下的挑战与应对之道 本文旨在探讨云原生环境下,微服务架构所面临的关键挑战及有效的治理策略。随着云计算技术的深入发展,越来越多的企业选择采用云原生架构来构建和部署其应用程序,以期获得更高的灵活性、可扩展性和效率。然而,微服务架构的复杂性也带来了服务发现、负载均衡、故障恢复等一系列治理难题。本文将深入分析这些问题,并提出一套基于云原生技术栈的微服务治理框架,包括服务网格的应用、API网关的集成、以及动态配置管理等关键方面,旨在为企业实现高效、稳定的微服务架构提供参考路径。 ####
31 5
下一篇
无影云桌面