有效的数据治理是指通过设计嵌入到数据流程中的数据质量、完整性和安全控制等的应用。这与传统数据治理模式形成鲜明对比，传统数据治理工作在实施后花费了大量精力来发现数据系统、构建数据沿袭以及实施数据质量和完整性控制。在实践中如何运作呢?
一个简单的例子
让我们举一个我在实践中多次看到的简单例子：
有一个客户创建流程，其中收集并创建某些客户数据以创建新的客户档案。该数据被发送到存储客户数据的系统中。基于该中央系统中的数据，存在三个使用该数据的下游系统。首先，有一个产品开放系统，客户开始消费所提供的一些产品和服务。其次，有一个营销系统来宣传新的、额外的产品和服务。第三，有一个客户管理系统，如果客户致电提出疑问或问题，呼叫中心的代理可以访问客户信息。
传统的数据治理方法
在传统方法中，将这些数据系统和流程纳入治理可能是一项艰巨的任务。我们必须确定流程和关键数据，定义需求，然后开始设计控制措施以确保数据确实得到充分管理。
对于示例中的 5 个过程中的每一个，我们都可以识别所涉及的关键数据。然后我们可以识别它们之间的数据流并创建数据沿袭。数据沿袭的一种常见方法是从下游的数据开始，明确数据流，返回上游。然后，我们从中央数据平台获取数据，将其提取到数据质量工具中，并测量数据质量。我们还从消费流程中获取数据，再次测量数据质量，并将其与集中存储的客户数据进行比较以确保一致性。
这种方法面临许多挑战。众所周知，记录数据沿袭非常困难且耗时。将数据质量纳入数据质量工具的成本非常高，因为这相当于有效地复制数据。衡量系统之间和跨系统的一致性很困难，因为系统可能来自不同的技术和供应商，具有不同的预构建模式和元数据实践，并且可能是相隔数年构建的。需要理解数据转换并将其嵌入到数据质量规则中。
适当的数据访问和使用很难证明，因为数据流没有集中跟踪，并且它们使用不同的模式。通过大量的手动工作，相应的系统和应用程序所有者(如果存在)可能可以解释数据访问过程，但这取决于他们的个人理解和本地保存(并且很少维护)的文档，因此这种数据治理模式具有很大的挑战性。
那么我们怎样才能做得更好——更加智能、可扩展且面向未来
(1)数据采集控制
让我们从数据捕获开始，自上而下地处理所述的流程。对于客户创建流程，定义收集和创建的关键数据元素，并花时间明确记录每个数据元素的要求。现在掌握了要求，返回创建功能并实施控制措施，以防止首先创建不准确和不完整的数据。此步骤极其关键 — 预防数据问题的成本效益至少比稍后在下游修复问题的成本效益高 10 倍。
有许多简单但功能强大的选项来实现数据捕获控件。可以嵌入控件以确保进度停止，直到完成必填字段。下拉菜单非常适合邮政编码或国家/地区等标准化字段。如果给定数据元素没有有限的有效值集，请考虑在接受格式之前如何检查格式。有效性或一致性规则可以扫描非法字符、不可能的重复字符或意外的数据长度。人工智能也可以发挥作用，例如将数据与公共和第三方数据或从扫描图像检索的数据进行比较。无需完全停止该过程，而是可以向创建功能模块发送弹出窗口以确认数据的准确性，如果需要，可以覆盖该弹出窗口。
一些数据捕获控制可以是基于流程的，而不是由技术驱动的。以一家健康诊所为例，我们发现多达 40% 的患者电话号码不准确。审查并澄清了数据采集职责，并实施了简单的流程变更。当创建患者病例时，前台人员现在会要求他们验证电话号码，这实际上消除了数据质量问题。
(2)源头数据质量
客户数据几乎对任何组织都至关重要。在我们的示例中，我们定义了 3 个消费系统，但在现实生活中通常有数十个使用该数据的系统。因此，客户数据的存储应作为“数据产品”在战略位置进行管理。无论此数据产品是通过 CRM、MDM、CDP 还是其他类型的解决方案启用，都建议在源头控制数据质量。
也就是说，无论数据存储在何处，都应将其质量作为标准、持续的实践进行衡量和发布。该解决方案应该内置数据质量控制。按照冷冻食品存储控制的类比，您想知道在任何时间存储了哪些食物以及存储温度。如果温度升高超过某个阈值，您会想立即知道- 而不是想等待每月更新的仪表板。冰箱至少应该配备集成温度控制装置，可以显示温度并在超出阈值时发出警报。如果可以避免的话，您不想在事后手动构建这些东西。
根据所涉及的解决方案技术，可以考虑许多选项。所有领先的数据平台都允许应用标准和规则。适用于数据捕获点的类似规则和要求(例如，与邮政编码格式的有效性相关)也可以在数据源处强制执行。许多平台可以根据可用元数据自动计算表中包含的数据的数据质量指标。同样，数据质量检查可以轻松嵌入到现有的摄取和整合作业中，以便过滤掉、拒绝、修复和/或安排数据管理员审查包含可能不正确数据的记录。
并不总是需要创建数据质量规则并执行它们。如果嵌入了数据质量控制来保证数据以给定格式到达并且之后不会被损坏(例如，因为值必须继续匹配一组参考数据)，那么数据质量指标可能会变得多余。这一切都是为了确保数据完整性，但如何做到这一点取决于您。
(3)数据访问控制
客户数据应受到保护，以确保只有具有适当权限的人员和流程才能访问它。与基于角色的访问控制相关的最 佳实践是众所周知的并且已记录在案，因此无需深入研究。
然而，从数据治理的角度来看，仅仅引用访问控制是不够的。特别是对于云原生应用程序，建议实现不可变的、自动生成的访问和审核日志。每当访问数据时，都会在日志中创建一个条目，该条目指定谁或什么获得了访问权限以及基于什么凭据。这些日志可以存储在相对冷的仓库中，以最大限度地降低成本。
在源头，可以对数据进行屏蔽或模糊处理，以确保通过适当配置的数据访问流程，人员和流程只能根据他们拥有的权限访问他们真正需要的数据。
上述所有控件的共同点是它们都是内置的、可扩展的且灵活的。当建立系统、应用程序和集成时，它们非常容易实现。之后，如果数据量或使用量激增，或者添加新角色，也不会影响控制的有效性。
(4)可发现的数据流
为了创建和实现数据流，无论数据流的技术或性质、大小和频率如何，都需要定义一些事情：数据来自哪里，在传输过程中对数据做了什么，以及它被发送到哪里。任何经验丰富的数据治理专家都知道为已经存在一段时间的系统和应用程序构建数据沿袭的恐怖故事。然而，在创建时，当数据工程师仍在设计他们的管道时，通过稍微调整它们来确保这些流可以通过设计发现是相对简单的工作。
跨数据流模式，为与流本身一起提供的元数据脚本或文件定义模板。这些脚本应该标准化，并包含最少的业务和技术元数据集，例如源、目的地、频率、包含的关键数据元素以及一系列指标(例如分类、PII 指标)。最 佳实践是每次更新数据流时都会更新这些元数据文件(如果可能的话，自动更新)并在目录中维护。然后，确保将这些元数据文件推送或拉入元数据管理工具(例如数据目录)、谱系图可以自动创建。
遵循上述准则并坚持互操作性标准，可以推动“通过设计实现数据沿袭”。
(5)数据变更控制
我们示例中的下游系统 - 产品开放、营销和呼叫中心客户管理，全部使用来自中央客户数据存储平台的数据。我们需要确保实际上使用了正确、准确的数据。我们不需要重新衡量数据质量，唯一需要控制的是数据与我们的权威来源一致。如果那里的数据不准确或丢失，那么应该在那里检测并解决问题——而不是下游。那么我们如何保证这种一致性呢?
一种简单的方法是在客户数据平台中构建直接接口。例如对于呼叫中心运营来说，这是非常可行的。如果代理需要审查或编辑客户数据，则可以直接与源连接来完成此操作，从而保证数据质量在传输过程中不会受到损坏。
出于营销目的，例如推动向特定目标客户的邮政地址发送定制信件的活动，这可能不可行。在这种情况下，数据协调检查是首选解决方案。数据协调是描述数据传输期间验证阶段的术语，其中将目标数据与原始源数据进行比较，以确保数据已正确传输。
我并不是说要提出任何新的建议——对账控制已经存在了几十年。我的意思是，应该将特定的数据标准嵌入到变更方法中，该方法要求实施控制以确保关键数据与源同步，以便在处于设计阶段时自动且强制地考虑这一点将创建或更改数据流的任何类型的转换。确保将其直接嵌入到数据流中，而不是痛苦地创建全新的脚本来提取数据并将其与原始源数据进行比较。
很久以前，我负责一家银行抵押贷款信用风险模型的回测过程。我的一个脚本每月运行一次，以检查信用风险模型的性能。这是一个复杂的脚本——要收集所有客户及其金融产品的数据，以及长达 48 个月的交易数据，超过 2500 行代码用于连接到源系统，将交易映射到产品，将产品映射到客户，并构建各种统计模型来计算违约概率、违约风险和违约损失。当脚本启动时，需要一个小时才能完成(当时还没有进入可扩展的云处理时代)，因此在此过程中停下来检查中间结果并不容易。
我内置了各种类型的对帐检查，如果出现问题，它们会向我发出警报。例如，在代码中的不同点，我会添加一行代码来计算给定子集的客户或交易数量，并将其直接与相同的总和进行比较，通过不同的逻辑，我可以直接从源数据重新计算。大多数情况下，警报不会响起。但有一天，尽管脚本的执行看似没有错误，但对账检查显示有几条记录存在差异。随后的分析表明，一些新客户端的记录在传输中被丢弃，因为我正在使用的处理引擎无法读取某些“非法”字符，因此丢弃了这些记录。在这种情况下，一些自定义代码解决了该问题，但更可持续，从源头开始，数据质量控制将确保这些非法字符不会再次出现在新客户端中。
小结
上述两种方法都可以得出结论：数据确实得到了适当的管理，但只有源头治理、过程治理的方法具有可扩展性、成本效益和创造价值。
