随着任何数据和分析程序的发展，数据领导者不可避免地必须首先深入数据治理。数据治理有许多方面，如数据质量、访问策略、数据安全、元数据管理、数据管理等。但什么时候是合适的时间？需要谁？你是怎么开始的？

从历史上看，数据治理是对数据和分析体系结构和用例的事后思考。这导致许多组织争先恐后地解决与数据质量、数据可访问性和数据安全等相关的问题。

在本文中，我们将探讨数据领导者如何更主动地识别您何时需要数据治理，为数据治理战略奠定坚实的基础，并获得您的主动权。

看看Atlan最近在Contentsquare上的大师班：数据治理如何加速Contentsquare的分析和BI。

认识到需求：何时购买数据目录

数据治理团队确保向每一位决策者提供数据的信任（验证数据源和保护PII）和清晰度（有据可查的数据产品）。要做到这一点，需要有一个集中的地方来实现这些数据治理原则。

在现代数据堆栈中，这是数据目录。与传统的数据目录不同，这些下一代目录必须能够激活元数据，以支持数据治理的所有方面。

那么，什么时候是购买数据目录的合适时机呢？

会有早期信号表明您的团队需要一个目录。检测这些信号将是倾听定性反馈和定量分析的混合。

需要倾听的一些早期定性信号：

• 分析师不确定他们可以使用什么数据集，也不确定他们是否可以信任这些数据集。
• 不同的团队正在以不同的方式计算相同的度量。
• 分析师和业务用户甚至不确定度量定义的含义。

从数量上讲，你需要一个数据目录的信号围绕着数据团队经常关注的时间到价值指标。创建一个基准时间到价值计算，并监控这个指标在几周到一个月内的变化。要计算实现价值的时间：

【项目交付日期】 — [项目承诺日期]=[价值实现时间]

这可以使用敏捷项目管理工具中的数据来完成。如果你目前没有使用，你可以很容易地在谷歌表格中手动记录这些日期，以计算差异。

随着团队的成长，价值实现时间的任何持续增长（例如，季度比季度）都表明您需要投资于数据目录。

The bottom of this curve is the ideal time to buy a data catalog.

随着公司和团队的发展，这些定性和定量信号的出现或增加是很常见的。对数据的需求自然会增加。在早期，分析师将兼任工程师（反之亦然）。

然而，当您的团队识别出上述信号时，您需要将其划分为分析师任务和工程任务并进行专门化。这是您开始需要数据治理的时候，也是您应该开始采购数据目录的时候，因为拆分数据分析师和工程师后的下一步可能是创建第一个数据治理团队。

如果没有用户友好的数据目录，数据治理团队将不得不大大增加，以满足数据需求。这在经济上效率低下且不可扩展。

认识到数据和分析角色增长的拐点以及对价值实现时间的影响，是时候正式化数据治理工作并获取现代数据目录了。如果没有这一点，组织将不得不在招聘上投入过多的资金来手动管理新的数据产品 — 这在2023年面临的经济形势下是不可能的。

相反，在数据治理之旅的早期投资于正确的技术最终可以节省时间和金钱。利用下一代目录集中管理治理规则，但使数据发现民主化，从而产生高效的数据治理程序。

准备好获取数据目录了吗？查看我们的现代数据目录和活动元数据的终极指南。

定义愿景

在启动第一个数据治理计划时，重要的是让关键利益相关者参与定义您的目标和愿景。要做到这一点，您需要深入了解什么对您的公司最重要，以及这些利益相关者在没有数据治理的情况下面临哪些挑战。

安排与高管、业务领导者、运营团队以及数据和分析从业者的关键领导者举行多次会议。使用价值流映射框架识别独特的痛点和当前流程。这项练习有助于每个人在有效的数据治理到位的情况下，就可以实现的价值达成一致。

正如Bill Schmarzo和Kirk Borne博士在《数据、分析和数字转型经济学》中提到的那样，“数据的价值不仅仅在于拥有它（数据驱动）。数据的价值取决于您如何使用它来创建新的价值来源（价值驱动）。所以，不要只是数据驱动，要有价值驱动！

你的愿景和目标应该清晰简洁。它将成为一个伟大的数据治理计划对您的组织来说会是什么样子的北极星。

数据治理涵盖了数据和分析的许多方面，如数据质量、数据安全、DataOps、主数据管理和元数据管理等。您的治理战略将详细说明如何实现每一个目标，但您的愿景应该传达在每一个领域取得的成功将为组织带来什么。

例如，愿景声明可能看起来像：

[您的公司名称]的数据治理实现了对数据资产的民主化访问，这些资产是可信的、有充分记录的，并且是各种利益相关者和用例的最高质量。

在内部始终如一地传达愿景。一旦愿景实现，让每个人都知道什么是数据治理，以及你的目标、愿景和好处是什么。（下文将对此进行详细介绍。）

制定战略

一旦你确定了自己的目标和愿景，你就会知道自己将要攀登的山有多大。没有小山脉，所以将你的挑战分为多个较小的阶段可以帮助你高效执行，让利益相关者参与进来，并最大限度地提高你的成功机会。

做到这一点的最佳方法是创建一个数据治理成熟度模型。考虑一下你目前处于1级，并称之为与你当前时刻产生共鸣的东西。如果数据治理计划成功，则根据您想要实现的目标设置级别5名称。在这里设定登月目标是完全可以的，因为5级将成为推动内部治理引擎前进的动力！

根据您在课程中需要实现的目标，定义中间步骤（即2、3和4级）。下面是一个示例，但一定要根据您的组织进行自定义。

Sample data governance maturity model.

你的程序应该在各个层面上考虑和预测一些基本部分。每个级别都应包含（请参阅下面的示例）：

1. 里程碑：在每个级别的推出过程中要实现的目标。
2. 行动计划：在指定时间内完成目标的任务清单。
3. 范围：您将覆盖各个级别的哪些部门。
4. 风险：尽可能地预测您在执行每个级别时会遇到的风险。
5. 预期结果：完成每一步后，您的组织将在哪里。预期结果是一种向下一个级别过渡的标准。

Think through the following elements for each level of your data governance maturity model.

 

 

确保买入

此时，您已经迈出了数据治理计划中最大的一步 — 开始！你的愿景和目标是明确的，你的执行策略是健全和明确的，成熟度目标是结构化和建模的。

为了使该项目栩栩如生，现在是时候从决策者那里获得支持，确保预算，并确定启动该项目的合适团队了。

花点时间与决策者会面，仔细展示你的成熟度模型，强调在完成模型的每个级别后的预期结果。您的目标是让这些利益相关者相信数据治理是让您的公司在数据方面突飞猛进的下一步。要做到这一点，请确保数据治理计划的预期结果与利益相关者的业务和/或运营目标一致。

当你的战略很明确，人们相信你会执行它时，解锁预算以获得必要的技术并雇佣合适的人将变得很简单。

启动

总有一天，您的第一个数据治理价值将交付。它可以是实现数据目录或新的KPI词汇表、监控核心数据、定义所有权等。

数据治理可交付成果，就像任何其他数据产品（数据集、表、仪表板等）一样，都是关于使用的。别忘了衡量你推出的所有产品的采用率，当然，还要使用周活跃用户、月活跃用户、产品粘性和功能使用等指标来衡量你的数据目录的采用率。

为这些采用指标设定目标是关键。它将帮助你确定你在哪里，你想去哪里，以及你到达那里还缺少什么。它还将帮助您更好地与利益相关者沟通您正在取得的进展。

总的来说，数据治理是任何数据和分析集团成功的关键支柱。要认识到需要专门的数据治理计划，您必须监控当前数据团队的发展、他们面临的挑战以及对数据消费者实现价值的时间的影响。

对特定组织中的数据治理有一个清晰的愿景是很重要的，它必须伴随着一个易于各种利益相关者理解的战略和路线图。随着成熟度水平的确定和与业务价值的联系的建立，决策者更容易获得必要技术（如数据目录和/或数据质量工具）和人员的支持和预算。

现在是时候开始启动您的数据治理计划了！

即将推出：第二部分是关于持续参与和发展您的计划！

要在收件箱中收到这篇文章，请订阅《元数据周刊》，这是Atlan的时事通讯，其中包含有关活动元数据、DataOps和数据文化的最新链接。

作为IT和商业新闻的狂热消费者，你肯定听说过“垃圾进垃圾出”这句格言。概念很简单：任何分析、分析或业务输出的质量和相关用途都是模型输入数据质量的直接函数。

这个经常被人背诵的短语已经存在了一段时间，但它在今天仍然是一个重要的真理。无论是追求数字化转型，还是利用人工智能（AI）、机器学习（ML）或物联网（IoT）等技术，组织都需要强大的可信数据基础来实现其业务目标。

在报道了数据治理和主数据管理（MDM）市场几年之后——作为帮助客户构建治理MDM业务案例的一部分——我退一步思考了为什么大多数组织的数据状态如此糟糕。

继续阅读，了解为什么在展示企业关键任务运营和分析中可用的可信数据的价值方面存在如此大的挑战，以及如何将自己的脏数据踢到路边。

目录

• 什么是垃圾进，垃圾出？
• 垃圾进垃圾出的历史
• 垃圾输入、垃圾输出示例
• 垃圾从哪里来？
• 主数据管理（MDM）如何解决垃圾输入、垃圾输出问题？

什么是垃圾进，垃圾出？

 

“垃圾进，垃圾出”（GIGO）的概念听起来就是这样：如果你给你的模型喂食垃圾，你就会得到垃圾。换言之，在数据、分析和生活中，“你吃什么就是什么。”

“垃圾”可能是不准确、不完整、不一致的数据，或者不符合数据管理协会（DAMA）定义的65个数据质量维度中的任何一个。

在数字化转型的背景下，GIGO成为了一个真正的问题，尤其是当生成人工智能等新技术提高了产出不佳时可能出现问题的风险时。思考：

• 由于低估或高估对产品或服务的需求而错过销售机会
• 将预算浪费在无效的营销活动上
• 与错误的人共享敏感信息而不遵守隐私法规
• 由于误报导致收入目标缺失
• 收到彻头彻尾的虚假信息

即使没有像人工智能模型这样复杂的东西，垃圾输出仍然会让那些依赖数据和分析来为有影响力的决策提供信息的有抱负的数据驱动组织感到头疼。当我们考虑一些真实世界的例子时，我们会对此进行更多的讨论。

垃圾进，垃圾出的历史

 

尽管“垃圾进，垃圾出”这个短语的第一次使用可以追溯到1957年，但它在计算的早期就被普及了，随着20世纪90年代数据仓库的兴起，它被背诵到了陈词滥调的地步。

垃圾：数据仓库和技术债务

这个故事的简洁版本始于这样一个事实，即无论我们当时是否意识到，在任何商业环境中，我们大多数人在历史上都曾获得过在筒仓中优化业务流程的补偿。

对于我们这些有幸在20世纪后半叶参与信息技术的人来说，我们被允许并鼓励自动化这些筒仓。

当所有这些流程被聚合在一起时，这带来了巨大的生产力提升，而当每个新的业务应用程序系统都携带自己的一组数据时，人们几乎没有注意到所产生的技术债务。

ERP和其他应用程序套件在至少在其数据库中共同定位逻辑上相似的数据方面取得了重大进展，但几乎没有内置任何功能来在支持的业务流程中加强广泛的数据质量和语义。

这导致在单个物理数据存储中出现一组不同的“逻辑”竖井。与此同时，诸如CRM之类的专业应用程序出现了，再次单独提高了生产力，但再次使可信数据和可重复使用数据的问题复杂化。

垃圾处理：数据仓库、数据分析师和数据质量

20世纪90年代，数据仓库和数据集市的出现，以及整合和协调来自这些不同数据仓库的源数据以用于基本报告和分析的首次尝试，首次广泛暴露了数据质量差的技术债务。

讨厌的数据分析师发现，这些系统中的数据不符合每个系统中表面上的规则。更糟糕的是，这些系统中看似相似的数据属性的含义几乎没有相似之处。

如今，随着企业现在追求数字化转型等战略举措，他们越来越发现，如果他们要实现未来的能力以及业务流程和分析的自动化，就不能再容忍基本上不受信任的数据的现状。

现在必须偿还质量差、关键任务数据的技术债务。事实上，根据哈佛商业评论分析服务公司的一项调查，60%的组织报告称，他们在企业范围内的数据战略投资不足，阻碍了有价值的数据被广泛使用，这并不奇怪。

垃圾输入示例

 

如上所述，垃圾输入实际上可以归结为无法满足DAMA 65个数据质量维度中任何一个维度的数据。Dataversity的一篇文章将这些划分为六个核心维度。

以下是每个维度的一些示例：

• 准确性：数据与实际相符吗？你能通过将数据与你知道的真实来源进行交叉引用来验证其准确性吗？例如，如果您的组织有一个垂直的电子商务业务，您可以使用服务来验证送货地址，如必应地图API位置。
• 完整性：所有信息都在那里吗？例如，一个完整的美国地址应该包括街道编号、城市、州和邮政编码。缺少任何一个数据点都将被视为不完整。
• 一致性：存储数据的每个位置的数据是否相同？例如，如果你将CRM中的客户发货地址数据与ERP中的同一客户发货地址进行比较，你应该会得到完美的匹配。这不仅适用于具有正确的地址，而且适用于一致格式化的地址。例如，如果一个地址在您的CRM中被格式化为“Louisiana”，在您的ERP中格式化为“LA”，在HRIS中格式为“LA”，则即使每个系统在地址数据中使用正确的状态，数据也不会一致。
• 及时性：数据接收是否及时？也就是说，什么时候需要、预测或预期？要继续使用地址示例，您需要在客户下新订单时收到发货地址，以便将其发送到您的订单履行系统。
• 有效性：数据是否符合预定义的业务规则？假设您的组织的订单履行系统需要九位数的邮政编码，而不是大多数人使用的标准五位数邮政编码。如果订单仅使用五位数的邮政编码，则数据将无效。
• 唯一性：数据是否只在一个位置存储一次？我们已经讨论过数据竖井的问题，但这里我指的是单个位置中的重复数据。例如，如果一个客户的文件中有两个发货地址，一个用于家庭，另一个用于工作，您会希望这两个地址都链接到数据库中的一个客户记录，而不是为同一个人创建两个地址不同的客户记录。

这绝不是一份详尽无遗的清单。这取决于数据管理员来决定哪些维度对他们来说最重要，以定义在他们的组织中什么是优质数据还是劣质数据。

垃圾从哪里来？

 

数据仓库是数据质量的一个问题，但如果将其确定为问题的根本原因，那将是一个错误。所谓的垃圾可以来自各种各样的来源。

以下是我多年来看到的一些例子：

• 合并和收购，或从不符合现有公司标准的外部来源导入数据的任何时间
• 数据输入错误（人为错误）
• 在一个系统内或跨多个系统进行数据验证或验证的规则存在冲突或不同
• 在复杂的业务流程中缺乏跨系统的集成
• 组织中缺乏数据治理组织或共享治理策略

主数据管理（MDM）如何解决垃圾输入、垃圾输出问题？

 

值得庆幸的是，GIGO的问题已经有了解决方案。主数据管理（MDM）就是通过修复进入业务或分析流程的低质量数据实例来创建您可以信任的数据，它非常善于打破数据孤岛。

以下是MDM可以帮助您将脏数据踢到路边的一些具体方法：

• 数据质量：再次回顾我们之前谈到的数据质量的六个核心维度。主数据管理解决方案可以帮助您清理数据，使其符合这些标准。
• 数据治理：MDM解决方案与数据治理解决方案不同，但两者是相辅相成的。如果数据治理是为了创建策略来定义什么是干净的或好的数据，那么MDM就是为了强制执行这些策略。MDM为您提供了一个单一的位置来配置数据质量规则，并确保它们在整个企业中一致且自动地应用。
• 数据丰富：数据丰富是指使用MDM解决方案清理数据并使用补充信息进行改进的过程。理论上，您可以在没有数据丰富的情况下解决GIGO问题，但如果您想充分利用输入数据，它仍然很有价值。
• 数据集成：这是MDM分解数据竖井的主要方式。MDM不是让垃圾数据分布在整个组织中，而是作为准确、可靠数据的单一真实来源。
• 数据管理：主数据管理为数据管理者提供了一个接口，以修正MDM解决方案识别为垃圾的数据。
• 层次管理：使用MDM，一个管家的垃圾就是另一个管家有价值的洞察力。层次结构管理是许多MDM解决方案中的一项功能，它使您能够管理数据中的复杂关系，从而更好地了解组织与客户、供应商、资产和材料关系的完整背景。
• 工作流自动化：手动审查潜在的垃圾数据可能会耗费大量时间。这就是工作流自动化的闪光点，它提供了一种在复杂的业务流程或工作流中协调对标记为潜在垃圾的数据的审查和批准的方法。

多域MDM平台通过提供所需的数据模型灵活性进一步实现了这一点，使业务能够开发一个准确反映业务当前和期望的未来状态的通用数据模型。

如果您想解决组织的技术债务并全面实现任何数字业务转型，实施MDM和数据治理对于清除脏数据的垃圾至关重要。

什么是数据质量？

数据质量定义为：

数据满足公司对准确性、有效性、完整性和一致性的期望的程度。

通过跟踪数据质量，企业可以查明损害质量的潜在问题，并确保共享数据适合用于特定目的。

当收集的数据不能满足公司对准确性、有效性、完整性和一致性的期望时，可能会对客户服务、员工生产力和关键战略产生巨大的负面影响。

为什么数据质量很重要？

高质量的数据是做出准确、知情决策的关键。虽然所有数据都有一定程度的“质量”，但各种特征和因素决定了数据质量的程度（高质量与低质量）。此外，不同的数据质量特征对整个组织的各个利益相关者来说可能更为重要。

流行的数据质量特征和维度列表包括：

• 精确
• 完整性
• 一致性
• Integrity(诚实正直)
• 合理性
• 及时性
• 唯一性/重复数据消除
• 有效性
• 可访问性

由于数据准确性是高质量数据的一个关键属性，因此单个不准确的数据点可能会对整个系统造成严重破坏。

如果没有数据质量的准确性和可靠性，高管就无法信任数据或做出明智的决策。这反过来会增加运营成本，并对下游用户造成严重破坏。分析人士最终依赖于不完美的报告，并根据这些发现得出错误的结论。最终用户的生产力将因存在缺陷的指导方针和做法而下降。

数据维护不善也会导致各种其他问题。例如，过时的客户信息可能会导致错过向上销售或交叉销售产品和服务的机会。

低质量的数据也可能导致公司将产品运送到错误的地址，导致客户满意度降低，重复销售减少，以及由于重新发货而导致的成本增加。

在监管更严格的行业，不良数据可能会导致公司因财务或监管合规报告不当而被罚款。

三大数据质量挑战

数据量带来了质量挑战。每当有大量数据在发挥作用时，新信息的数量往往成为确定数据是否可信的重要考虑因素。出于这个原因，具有前瞻性思维的公司在数据的收集、存储和处理方面有健全的流程。

随着技术革命的快速发展，数据质量面临的三大挑战包括：

1.隐私和保护法

《通用数据保护条例》（GDPR）和《加州消费者隐私法》（CCPA）赋予人们访问个人数据的权利，这大大增加了公众对准确客户记录的需求。组织必须能够几乎立即定位个人的全部信息，而不会因为数据不准确或不一致而丢失所收集的数据的一小部分。

2.人工智能（AI）和机器学习（ML）

随着越来越多的公司将人工智能和机器学习应用程序应用于其商业智能战略，数据用户可能会发现越来越难以跟上新的大数据浪潮。由于这些实时数据流平台不断传输大量新信息，现在出现错误和数据质量不准确的机会甚至更多。

此外，大型公司必须努力管理其系统，这些系统既位于本地，也通过云服务器。丰富的数据系统也使复杂任务的监控变得更加具有挑战性。

3.数据治理实践

数据治理是一种数据管理系统，它遵守信息收集、存储和共享的一套内部标准和策略。通过确保公司每个部门的所有数据一致、可信且不被滥用，管理人员可以保证遵守重要法规，并降低企业被罚款的风险。

如果没有正确的数据治理方法，公司可能永远无法解决整个组织不同系统内的不一致问题。例如，根据部门的不同，可以列出不同的客户名称。销售人员可能会说“Sally”。物流部门使用“Sallie”。客户服务部门会将这个名字列为“Susan”。这种糟糕的数据管理可能会导致客户感到困惑，因为随着时间的推移，客户会与每个部门进行多次互动。

关于如何确定数据质量的6种方法

数据质量评估框架（DQAF）是一组数据质量维度，分为六大类：完整性、及时性、有效性、完整性、唯一性和一致性。

在任何时间点评估特定数据集的质量时，这些维度都很有用。大多数数据管理器为每个维度分配0-100的分数，即平均DQAF。

1.完整性

完整性被定义为数据集中缺失数据的百分比。对于产品或服务，数据的完整性对于帮助潜在客户在不同的销售项目之间进行比较、对比和选择至关重要。例如，如果一个产品描述不包括预计交付日期（而所有其他产品描述都包括），那么该“数据”是不完整的。

2.及时性

及时性衡量数据在任何特定时刻的最新程度或过时程度。例如，如果你有2008年的客户信息，现在是2021年，那么数据的及时性和完整性都会出现问题。

在确定数据质量时，及时性维度可能会对其整体准确性、可行性和可靠性产生巨大影响，无论是积极的还是消极的。

3.有效性

有效性是指不符合特定公司格式、规则或流程的信息。例如，许多系统可能会询问客户的出生日期。然而，如果客户没有使用正确的格式输入他们的出生日期，数据质量水平就会自动受到影响。因此，今天许多组织设计他们的系统来拒绝出生日期信息，除非它是使用预先分配的格式输入的。

4.诚信

数据的完整性是指信息的可靠性和可信赖程度。数据是否真实？例如，如果您的数据库有一个分配给特定客户的电子邮件地址，而事实证明该客户实际上在几年前删除了该帐户，那么数据完整性和及时性都会出现问题。

5.唯一性

唯一性是一种数据质量特征，通常与客户档案相关。一项记录可以使你的公司在电子商务销售中获胜并击败竞争对手。

更准确地汇编独特的客户信息，包括每个客户与个别公司产品和营销活动相关的相关绩效分析，通常是长期盈利和成功的基石。

6.一致性

数据的一致性通常与分析有关。它确保信息收集的来源是基于部门或公司的独特目标捕获正确的数据。

例如，假设您有两条类似的信息：

• 客户开户的存档日期与。
• 他们最后一次登录帐户的时间。

这些日期的差异可能为当前或未来营销活动的成功率提供有价值的见解。

确定公司数据的整体质量是一个永无止境的过程。有效的数据质量管理最关键的组成部分是快速主动地识别和解决潜在问题。

数据质量管理工具和最佳实践

数据是由人生成的，他们天生就容易犯人为错误。为了避免未来的问题并保持数据质量的连续性，您的组织可以采用某些最佳实践，以确保您的数据质量管理系统在未来几年的完整性。这些措施包括：

在整个企业中建立员工和部门间的认同。

• 设置明确定义的指标。
• 通过制定数据治理准则来确保数据质量。
• 创建一个流程，让员工可以报告有关数据输入或访问的任何可疑故障。
• 建立一个逐步调查负面报告的流程。
• 启动数据审核过程。
• 建立并投资于高质量的员工培训计划。
• 建立、维护并持续更新数据安全标准。
• 在整个公司的每个级别都分配一名数据管理员。
• 利用潜在的云数据自动化机会。
• 尽可能集成和自动化数据流。

Alation为实施具有成本效益的数据质量管理系统提供了各种企业级工具和解决方案。我们帮助组织整合孤立和分布式的企业数据，建立数据实践的一致性，并提高决策过程的速度和质量。有关我们的数据质量管理解决方案的更多信息，请立即联系Alation。

我们如何在OpenMetadata中民主化数据质量？

企业已经将目光转向数据。它不再将数据视为实现公司愿景的必要燃料，而是成为推动市场的产品。

• 谷歌为我们精心绘制了一幅描述网络的巨大图表，以准确地找到我们需要的东西。
• 脸书对每一位用户进行了简介，以帮助营销人员接触到的不是更广泛的受众，而是他们的目标。
• 数据分析师构建仪表盘来推动高管的决策。

是什么让你的仪表盘与众不同？为什么数百万用户选择谷歌？脸书是如何在网络广告市场占据主导地位这么长时间的？相信

有很多数据质量工具可以提供信任，但团队仍在努力维护和扩展数据质量实践。在这篇文章中，我们将讨论如何在OpenMetadata中打破竖井并使数据质量民主化。

不同的人物有不同的需求

一名数据工程师、一名数据分析师和一名数据科学家走进酒吧。他们都订购不同的东西，因为他们是不同的人，有不同的需求，使用不同的工具。

作为数据从业者，我们已经意识到，我们的工作不会在发送表、管道或仪表板时结束。从数据资产转移到数据产品需要用户信任我们想要提供的见解。然而，数据质量工具专注于单个角色，而不考虑为数据平台提供动力的多个配置文件。

数据工程师致力于验证管道和内部流程。他们必须确保数据在规定的时间到达目的地，并达到预期的记录数量。

• DBA监控数据的使用情况及其在数据库中占用的物理空间，重点关注速度和优化。
• 数据分析师了解业务，知道数据中有必须遵守的规则。
• 数据科学家利用他们的统计知识来检查数据分布中的特征漂移和任何演变。经过训练的ML模型不会永远存在！

单个数据资产具有许多质量需求，这些需求对于不同的人物角色是不同的。

此外，这些角色与数据的交互方式也有所不同。他们的知识和工具针对他们需要实现的目标。但数据质量解决方案试图找到一个中间立场，这意味着必须有人妥协。要么很难在面向工程师的实现上构建和添加测试，要么由于高层抽象，测试变得有限和僵化。

数据质量所有权

当一个团队成为单一的数据质量提供商时，就会出现摩擦，这是一个很难解决的问题。这项任务通常落在工程师的肩上，他们知道如何进行测试，但离业务更远。

这导致了外部用户请求的连续队列，这些请求并不总是共享相同的语言或期望。在这里，我们不仅需要考虑跨团队调整路线图的困难，还需要考虑降低个人和团队自主权的后果，这会降低他们对数据产品的所有权和数据质量要求。

数据质量民主化

不一致、不正确和碎片化的元数据使组织无法释放其全部数据潜力。在数据质量问题上抛出另一个工具只会增加（元）数据与人之间的脱节。

我们在OpenMetadata的目标是创建一个集中和共享的元数据平台，该平台涉及数据质量测试的整个生命周期。数据质量民主化意味着使所有数据从业者能够独立满足数据质量需求，而不会出现团队之间的通信差距和瓶颈，也不会影响或限制功能。

我们已经能够率先推动这一民主化进程；得益于两种主要成分：

• 一个由JSONSchema提供支持的元数据标准，它帮助我们围绕数据质量测试指定一种通用语言。有了这样的定义，我们可以使用OpenMetadata中直接定义的测试，也可以集成来自Great Expectations或 DBT.等工具的测试结果。
• 以API为中心的模型，允许用户与不同级别的数据质量测试交互：UI、编程语言SDK和/或通过API调用与服务器直接通信。

OpenMetadata的所有开发都是从构建API开始的。用户可以通过UI执行的任何操作都是一个API调用，可以在需要时自动执行，没有任何限制。

Data Quality view in OpenMetadata

结果如何？数据分析师和数据科学家可以100%依赖UI来创建测试、运行和安排测试，并在出现任何问题时向Slack或Teams添加通知。不需要其他团队的干预！

任何其他自动化都可以通过依赖Python SDK使用OpenMetadata的工作流定义或与API交互来实现，以创建新的测试并从现有的数据质量过程中发送测试结果。

OpenMetadata没有强迫团队根据其提供的交互选择工具，而是在各个级别上提供了对数据质量功能的完全控制：从无代码到直接API通信。

使用OpenMetadata建立数据信任

您想看到OpenMetadata的强大数据质量功能发挥作用吗？观看我们的网络研讨会，开始在任何级别建立对您数据的信任：

• 从OpenMetadata UI，
• 使用Python客户端拥有您的工作流，
• 或者直接使用API创建自己的测试定义。

 

数据质量是大多数数据产品需要解决的一个挑战；不这样做可能会产生严重的潜在后果。例如，缺失的值可能会导致生产系统出现故障，而不正确的数据可能会导致做出错误的业务决策。在机器学习中，数据分布的变化可能会破坏模型的性能；在推荐系统的背景下，这可能会导致糟糕的客户体验，并影响您的收入。在医疗保健等行业，其后果可能要严重得多。它可能导致虐待和误诊。例如，处方错误不仅代价高昂（健康创新卓越网络估计每年210亿美元），而且据信也是美国每年7000多人死亡的原因。

幸运的是，数据质量框架可以帮助我们将低质量数据的风险降至最低。它们不仅可以帮助我们尽早发现问题，还可以以自动化和可重复的方式进行识别。尽管可以开发自己的数据质量框架，但它可能既复杂又耗时。有了丰富的开源和商业框架，它们很好地满足了大多数需求，使用现有的框架是有意义的。然而，有许多不同的数据质量框架可供选择。在这里，我们将研究如何选择适合您的项目的框架。

弄清楚哪种框架适合您的数据产品的需求

选择最适合您项目的数据质量框架在很大程度上取决于上下文——您现在所处的位置以及您试图实现的目标。以下是一些常见的场景，这些场景将有助于演示如何选择框架。

场景1：快速评估继承的遗留数据产品

您继承了一个潜在的大型数据产品；然而，目前还没有任何测试用例，您也不了解它的质量。您需要快速确定这一点，然后与领域专家一起发展测试。

在这种情况下，您的数据质量框架最重要的功能是分析、自动测试创建和用户界面（UI），该用户界面能够与领域专家合作，以加快对测试差距和当前数据本身质量的理解。

场景2：监测时间序列数据量的峰值或下降

您正在构建一个基于时间序列的数据产品，例如，来自移动应用程序的用户分析事件。您需要识别事件数据量中可能表明数据质量问题的可疑峰值或下降。

此场景最重要的功能是随着时间的推移对数据量进行异常检测。

场景3：违反数据质量标准的每日警报

您有一个数据产品，它包含许多属性每天都在变化的复杂数据点（例如，从CRM每天增量导入）。这意味着您需要每天检查预定义的数据质量标准是否得到满足，确保属性不为空，并且所有属性都在有效的数据范围内。

此场景中最重要的功能是约束测试（基于规则的测试）和Slack集成，当违反标准时可以提供警报。

场景4：特定领域的质量标准

在某些域中，您需要您的数据产品来满足特定的业务规则。例如，在处理销售数据的数据产品中，可能有一个要求，即销售日期永远不应该是未来日期。

此场景最重要的功能是能够为质量检查编写自定义约束。

场景5：大型数据组织的可发现数据质量

您所在的组织有多个围绕数据产品组织的数据团队。您希望确保您的数据产品消费者在开始将每个数据产品用于其分析用例之前了解其数据质量，从而使下游消费者能够轻松确定当前的质量水平是否足以构建其用例。数据将用于的用例类型可能要求不同的质量水平。

此场景最重要的功能是易于进行数据目录集成，从而能够将数据质量检查结果自动发布到目录中。

特征矩阵

有许多开源数据质量框架非常好——我们在Great experiences、Deequ和Soda Core的客户项目中有过积极的经验。它们都可以通过一系列功能帮助您实现数据质量测试。根据您需要的集成级别，以下是需要考虑的一些关键功能：

Feature	Great Expectations	Deequ	Soda
核心功能
许可	Open-source	Open-source	Soda Core: Open-source   Soda Cloud: Commercial
通用约束的开箱即用的基于约束的测试	Yes	Yes	Yes
开发的主要语言	Python	Python/Scala	Soda Checks Language (SodaCL) in Python
对任何框架的严格依赖	No	Yes. Hard dependency on Spark as it cannot be executed outside of a Spark cluster.	No
质量指标可视化	Partial	No	Yes. In-built integration with popular dashboarding tools. Also has a Reporting API on Soda Cloud.
支持增量数据的数据验证	Yes	Yes	Yes. Available via Soda Cloud metrics store.
状态度量计算	No	Yes Stateful Metrics Computation - awslabs/deequ · GitHub.	Available via Soda Cloud metrics store.
自动化功能
数据概况	Yes	Yes. More powerful than the other 2 - richer in-built profiling functions and customizable.	Yes
测试创建	Yes	Partial	No
约束条件建议	No	Yes	No
异常检测	No	Yes	Yes. Available via Soda Cloud.
内置集成
编排解决方案	Yes GreatExpectationsOperator	No	Yes via In-built integrations
Apache Spark	Yes	Yes	Yes via Soda Spark
Slack Alerting	Yes	No	Yes
票务	No	No	In-built integrations
CI/CD	Yes. Integrates with Github Actions	No. Need to write a custom step within a CI/CD pipeline and use the test results.	No. Need to write a custom step (Soda Scan) using the Soda CLI within a CI/CD pipeline and use the result of the scan.
数据目录	No	No	Yes. In-built integrations

您的项目的正确框架是什么？

您为用例定义的场景（包括我们讨论的场景）将有助于确定您需要查看的功能，以比较不同的数据质量框架。

例如，在场景3中，我们需要为任何违反数据质量标准的时间创建警报。我们发现这意味着我们需要基于约束的测试和Slack集成。因此，通过查看特征矩阵，我们可以看到所有三个被评估的框架都提供了基于约束的测试；远大前程和苏打水还提供集成的Slack警报。

在场景2中，我们需要监控分析事件数据中的流量峰值和下降，我们发现异常检测尤为重要。在我们的特征矩阵中，我们可以看到Deequ为异常检测提供了坚实的支持，商业版的Soda也是如此。

总之，通过从数据产品质量标准开始，我们可以通过使用上面的特征矩阵来考虑哪个框架最适合我们的上下文和需求。