数据库 频道

数据治理的兴与衰,如何进行数据治理?

数据治理在炒作周期中迎来翻转。90年代末,元数据管理作为使数据可操作和可信赖的银弹,突然乍现。

十几年后,这个行业充斥着失败的、由高层领导推动的计划,他们曾试图编目每一项数据资产。如此多的数据团队被淹没,以至于无法想象还有人敢再次踏上这凶险的征程。

然而,许多数据团队相信,今天的潮水已经转向了!

数据治理仍然是至关重要的,也许随着数据量的增加和GDPR等数据监管的颠覆性浪潮席卷整个行业,数据治理变得更加重要了。

在这些外部力量的推动下,数据团队已经开始说服自己,也许,只是也许,机器学习自动化可以驯服风暴,使这次的数据资产编目成为可能。

不幸的是,许多新的数据治理计划因为专注于技术而忽略了文化和流程,注定会沉沦。

实际上,对于团队来说,要改善数据治理状况,他们不仅需要对数据有可见性,还需要像对待产品一样对待数据治理,以领域为先,并将数据质量作为先决条件。

像对待产品一样对待数据治理 - 不要像对待数据治理一样对待产品

数据治理是一个巨大的挑战,因此,试图用一个大的解决方案来解决它是很诱人的。

通常情况下,数据治理计划将从一个数据领导者开始,该领导者宣布了一个似乎可以接受的目标:“我们将对所有的东西进行编目,并为我们所有的数据资产端到端分配所有者,这样它就可以被访问,有意义,合规并可靠。”

该举措的首要问题是它是如何产生的。就像成功的公司以客户为中心一样,数据团队也必须关注他们的数据消费者和内部客户。

我保证市场部没有人要求你提供一个数据目录。他们要求的是有用的报告和更可靠的仪表盘。

合规部门也没有人要求你提供数据目录。他们要求了解受管制和个人可识别信息的位置以及谁有访问权。

但是,一些数据团队并没有为这些可实现的目标设定路线,而是在没有看到业务需求的情况下,将目光投向了地平线以外。没有最小可行的产品,没有客户反馈和迭代只有伟大的想法和破碎的承诺。

不要误会我的意思:编目仍然有重要的作用。但是,即使是最好的技术也不能替代良好的流程。

人们过多地强调战术(对数据资产进行编目),而对目标(可访问的、有意义的、合规的、可靠的数据)重视不够。一旦团队意识到他们需要更具体的坐标,就难怪数据治理的船帆开始瘪下去了。

让我们重新审视一下领导层先前的命令。“我们将对所有的东西进行编目,并为我们所有的数据资产指定所有者,使其能够被访问、有意义、合规和可靠。”

· “编目”是什么意思?数据将如何被组织?它将为谁而建?它将包括什么级别的细节?是否需要实时?在哪个层面上?

·究竟什么是“所有的东西”?什么是“数据资产”?它仅仅是表,还是指SQL查询和下游报告?

·“所有者”是什么意思?谁拥有目录?他们将如何被分配?以及他们负责什么?我们是否在谈论过去的集中式数据管理人?

·什么是“端到端”?目录的范围是什么?它是否包括结构化和非结构化的数据?如果是的话,在非结构化数据被处理成具有意图、意义和目的的形式之前,如何对其进行编目?

如果没有这些问题的答案,对数据进行编目就像对水进行编目一样,其不断移动和变化的状态,使其几乎无法记录。

以领域为先

这些要点之所以如此难以确定,是因为团队没有指南针导航:企业的需求。具体来说,就是实际使用这些数据的不同业务领域的需求。

没有业务背景,就没有一个正确的答案,更不用说确定优先次序了。缓解治理漏洞是一项艰巨的任务,如果没有充分了解哪些数据资产被你的公司实际访问,以及出于什么目的,就不可能对这些数据进行优先排序。

正如我们已经转向云优先和移动优先的方法,数据团队开始采用领域优先的方法,通常被称为数据网络(data mesh)。这种分散的方法将数据所有权分配给开发和维护数据产品的不同部门的数据团队。而在这个过程中,让数据团队更贴近业务。

数据网络由三个独立的组件组成:数据源、数据基础设施和面向领域的数据管道,由功能所有者管理。数据网络架构的基础是一个通用的互操作层,反映了域未知(domain-agnostic)标准,以及可观测性和治理。(图片来源:Monte Carlo)。

现代数据治理方法需要结合数据在领域中的意义。了解这些数据域之间的关系以及聚合视图的哪些方面是重要的,这一点很重要。

这种类型的数据发现可以根据一组特定消费者对数据的摄取、存储、聚合和使用情况,提供一个特定领域的动态理解。

数据治理还必须超越对数据的描述,了解其目的。数据生产者对资产的描述与数据消费者对其功能的理解大相径庭,甚至在一个数据消费者与另一个消费者之间,在理解赋予数据的意义方面也可能存在巨大差异。

领域优先的方法可以在企业业务工作流程中共享数据的含义和要求。

数据质量是数据治理的先决条件

没有技术可以解决马虎的数据流程或组织文化。即使更多的数据资产被自动记录和编目,更多的问题也会暗自滋生。如果你吸收的水多于你要排出的水,你就会沉没。

软件工程和网站可靠性工程的学科的SLA已经发展到了5个9可用性标准(如99.999%)。不幸的是,大多数数据团队没有任何内部的SLA,详细说明他们的数据产品的预期性能,并且可能难以设置和记录数据质量指标(如数据停机时间)。

当数据的速度太快,混乱的数据产生的后果太小,数据工程师太少时,很难责怪数据团队有一些马虎的习惯。然而,实行任何数据治理计划,数据可靠性工程必须被优先考虑,如此数据治理才可能成功。

它(数据可靠性)也必须是治理计划走向成功的第一步。简单地说,如果你对一个坏掉的系统进行编目、记录和组织,那么一旦它被修复,你就不得不再做一次。

贯彻良好的数据质量实践也可以让团队在实现数据治理目标方面取得先机,将数据可观测性从一个想法变成现实,变成当前(实时)状态。

例如,如果没有实时血统,就不可能知道PII或其他受监管的数据是如何蔓延的。想一想:即使你使用的是市场上最先进的数据目录,你的治理也只能达到和你对数据去向的了解一样好。如果你的管道不可靠,你的数据目录也不可靠。

有目的的数据治理

我对数据团队的建议是,将数据治理的任务打散。启动多个较小的计划,每个计划都集中在一个特定的目标上,即让数据更容易访问、更有意义、更合规、更可靠。

把你的数据治理计划当作一个产品,倾听你的消费者的意见,以了解优先事项、工作流程和目标。航行和迭代。

数据治理已经使许多数据团队陷入困境,但通过使业务驱动的流程成为你的北极星,你可以找到平静的水域。

关于作者:Barr Moses是数据可靠性公司Monte Carlo的首席执行官和联合创始人。

0
相关文章