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

来源:华体会全站官网登录入口 发布时间:2024-01-29 23:13:31 阅读: 1

  简介: 本文介绍大数据开发治理平台DataWorks在数据治理领域的最新产品进展,包括基于事前、事中、事后的全链路理念构建的核心产品功能和数据治理量化评估机制解读,以及围绕降本增效的成本治理最佳实践。

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

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

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

  开展数据治理工作,通常会参考DAMA或者DCMM理论体系,不难发现数据治理涵盖内容极为广泛。从哪里优先入手,以什么样的路径来推进,这是公司进行数据治理工作首先要回答的问题。数据治理的目标和执行路径不清晰,是第一个典型痛点。

  无论是企业内部自发地开展、还是请专业的咨询机构,构建出数据治理咨询方案、产出一些列的规范和管理办法后,往往只能停留于纸面,没有恰当的治理平台工具来支撑落地,这是会面临的第二个典型挑战。

  如何客观地评估治理、将治理成效量化、可视化。当这个工作没做好时,治理的推进难度会显著加大。

  数据治理的工作容易陷入“运动式治理”,通过集中的突击、在一段时间内看到一定的效果。但如果不融入到日常的数据开发生产链路中去,这项工作就不持续,不能长久地、从根本性地解决治理的问题。

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

  首先,明确治理的核心对象是与ETL作业中相关的任务和表。数据治理是治理客观的对象,不是治理人。但治理实施的一个关键前提,是对任务和表这些基本对象的确定归属,梳理并定义清楚对象的具体负责人,来确保治理问题有着落、有跟进。通过具体到人,进而汇聚到部门、到全集团整体,

  其次,数据治理采取的实施路径是 “现状分析 - 问题定位 - 优化治理 - 效果评估”,构建一个闭环流程;

  最后,数据治理的核心,要落在量化上:将问题量化、将成效量化。并基于局部的明细给出全局的决策建议,比如为全集团的资源调配、各部门的预算制定、成本优化目标的设定等,提供参考。并且,这些量化的评估和治理问题的发现、修复,都会通过一个统一的平台工具来承接。

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

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

  数据治理中心通过检查项的功能,能做到在任务的提交、发布等关键环节,对于SQL代码的质量、性能消耗等进行自动扫描和检查卡点,来预防新问题的引入。这个有点类似于编译和优化的提示。

  当前面临的一个现实问题是数仓、数据中台的建设可能已进行了较长时间,会存在许多存量的问题是需要优化治理。数据治理中心的治理项功能,就是为此而设计,不难发现系统中存量的需要优化的问题,并给出对应的处理方法。与检查项一样,这也是一种全自动的方式。

  数据治理中心最具特色的,或是说阿里巴巴内部数据治理实践的特色,是这套量化评估机制。基于治理“健康分”的概念,从“计算”、“存储”、“质量”、“安全”和“研发”五个基础维度进行量化评估,进而给出整体的治理健康度评估。便于治理实施前了解现状、同时也会数据治理实施后的成效提供客观评估。

  此外,数据治理中心在成本优化治理方面,也提供了资源使用分析等一系列的产品能力,可以清晰了解单个任务、单张表粒度的的资源消耗、费用预估以及资源异动情况,帮助公司有明确的目的性地进行计算和存储的优化治理,来达成降本增效的目标。

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

  数据层:是整个产品模块的关键基础,数据治理中心汇聚了任务、表、模型、数据服务API等一系列的对象的元数据信息,并构建用以分析洞察的元数仓,来支撑上层的治理应用。

  治理应用层:数据治理中心的主体功能所在。基于内置的方案模板,提供用于事前问题自动预防、事后存量问题的自动发现,以及对应的优化处理指南等系列的功能。资源使用分析是面向成本治理构建的产品能力,包含资源的明细和异动分析等,以及规划中的资源智能优化建议。对象360用于汇聚展示对象的全景信息,尤其是需要治理优化的问题,并全生命周期追踪对象的事件变化情况等。标签体系作为额外的支撑体系,便于有效的对任务进行类型打标区分,然后进行集中式的治理。场景化治理是基于PDCA理念构建,来帮助按照业务需要,灵活圈选需要治理的对象、评估现状、设定治理目标,并有效监督治理实施进度,最终来达成治理落地。

  管理运营层:数据治理中心核心服务于数据治理管理员以及数据治理具体参与的一线同学两类用户群体。在管理运营层,提供了治理评估报告、治理健康分、治理排行榜和治理运营推送等一系列功能。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  基于阿里内部和Dataworks客户最佳实践,持续丰富内置的治理项和检查项,让治理问题得以更全面地发现和预防

  为任务下线、表删除等治理操作提供优雅处理方案,解决治理风险顾虑,提升问题优化治理效率和处置完成率

  拓展支持的引擎类型,从只支持MaxCompute,到支持EMRHive、Hologres等更多引擎类型