获得高质量数据的第一准则：停止加载质量差的数据

获得高质量数据的第一准则：停止加载低质量数据。其实就这么简单。我看到很多公司都犯了这个错误，然后就纳闷为什么他们的数据质量这么差。

数据快餐：捕获所有数据！

“先摄入，后管理。” 这基本上是十年前大数据的口号。某种程度上，它甚至比快餐更糟糕，因为吃快餐至少你知道自己摄入了多少卡路里——即使你选择忽略它。而这种策略，你根本不知道数据里有什么。

很多公司在数据计划的起步阶段，往往只是尽可能地收集数据，这很有道理，因为几十年来他们一直缺乏数据。90年代和00年代的数据仓库根本算不上大数据，只有少数人才能访问，并决定谁如何使用这些数据。因此，当云计算和大数据技术出现时，最大限度地利用数据就显得尤为重要。就像快餐一样，这种方法能带来即时的满足感，您的第一个用例很快就会上线。

但负面影响随后而来。大多数数据质量问题的根本原因是源系统在未经通知的情况下发生变化。它们的模式会变，底层技术会变，部署它们的基础架构会变，安全设置会变，它们存在的整个目的也会变……无时无刻不在变化。每次中断都需要几个小时来排除故障、调试和修复。即使是每年只更改一次的稳定源也会导致大量中断。数据部门提取 1,000 多个表的情况并不罕见。如果每个表平均每年更改一次，这意味着每年有 1,000 次更改，或者每天有 2-3 次更改。这导致数据团队大部分时间都处于故障修复模式。

不要只治疗症状！

一旦数据质量问题变得显而易见，数据团队通常会主动采取措施来解决问题。以下这些方法只能治标不治本：

模式演变：啊，数据源改变了吗？不用担心，我们会将所有变化反映到数据湖中。或者更好的是，我们正在进行数据保管，这样我们就可以添加更多卫星表来捕获变化的数据。但这行不通，因为即使你设计的数据管道再智能，也无法应对未来的变化。货币列从“文本”更改为“十进制”，该cust列被重命名为customerid，该country字段被删除，或者更糟的是，它被留空，或者整个表格凭空消失。 质量监控：虽然知道崩溃情况很棒，但这无法从一开始就阻止崩溃。数据质量监控固然有用，但它并不能解决数据质量问题，只能让问题更加显而易见。 安装数据治理工具：你知道吗，如果我们确定每个数据源的所有者、数据源中包含的内容，并要求他们记录所有内容，那么他们就会更加负责！不，这会产生大量无人阅读的文书工作。与数据质量监控一样，数据治理工具也有其作用，但它并不能解决这个问题。 设立变更委员会：我们要修复这个流程！所有想要对生产环境进行变更的人都必须先在令人敬畏的CAB（变更咨询委员会）上宣布，这样我们才能与所有依赖您系统的人讨论。我们每年都会发布4个重要版本，以确保可控。但这行不通，因为源系统通常不知道或者几乎不知道他们的数据正在用于分析。这只是事后才想到的。即使数据团队及时获悉变更，并获得了正确的新测试数据来准备迁移数据管道，仍然经常出错。因为测试数据永远无法与实际生产数据相符。而且您仍然需要加班加点地从中断中恢复。 GenAI 将解决所有的问题：这其实不言而喻，但我还是要说，因为有些公司 100% 确信这就是解决之道：不，你无法用 GenAI 解决这个问题。我知道有些数据部门基本上停止了数据治理计划，因为“现在你可以直接向聊天机器人询问任何关于数据的问题，它都会回答。” 哦，你会得到答案。但答案基于什么呢？如果你的数据太乱，连人类专家都无法手动解决，那么 ChatGPT 也无法解答。

您需要一个与源系统的接口

软件工程师们有一个使用了数十年的技巧，那就是 API。每当软件团队想要相互交互时，无论是在公司内部还是外部，你们都可以通过这些 API 进行通信。团队在每个 API 背后做什么与你无关。他们可能会更改技术，可能会更改底层基础设施或安全设置，甚至可能会更改架构。只要他们遵守 API 的约定，你就可以在应用中使用它们。

但是重大变更怎么办？嗯，他们有专门的流程，叫做“弃用 API”。这还是挺烦人的。但变更确实会发生，而且有些变更是重大的。当你使用v1任何 API 时，他们可以发布一个版本，v2并给你 6 个月到 1 年的时间，等你准备好了再迁移到 v2。这完美吗？不完美。但确实有效。

这是否意味着我们现在都需要在数据世界中开始托管 API？完全不是。但我们可以开始与源系统就接口达成一致。这意味着他们准备一组能够很好地表示其系统中数据的表，而无需暴露每个内部表。源团队决定格式。他们可以将该模式在自己的数据库中提供，也可以将数据推送到整个公司用于分析的通用数据库/Lakehouse。如果他们有任何重大更改，他们可以v2以不同的模式发布其中一个表，同时仍然可以v1并行发布。一旦所有消费者都迁移到v2，就可以终止该v1接口。

如果你做得好，你的界面设计就能让数据使用起来更便捷。操作系统通常以规范化格式存储数据。因此，你需要进行 300 次异质连接才能获得任何洞察。你可以发布 4 个宽表来准备数据使用，而不是发布数百个小表。这能让你的界面保持简洁易懂。

障碍：为什么这还不普遍？

几乎所有数据部门的人都觉得这个想法很棒。而且它在软件领域已经有过明显的成功先例。那么，为什么我们没有一直这样做呢？有几个障碍：

这给运营源系统的团队带来了额外的工作和责任。他们有不同的预算、不同的待办事项、不同的部门……他们为什么要投资于此？他们实际上并没有动力让其他人使用他们的数据。如果他们想自己做分析，他们是最了解自己数据的人，所以他们可以直接连接到数据并运行一些查询。 设置起来比仅仅复制源数据更困难：没有什么比一个 JDBC 连接和一个SELECT *每晚运行的命令更简单的了。如果你足够幸运，甚至不需要和另一端的工程师沟通。你可以随时随地以你最喜欢的格式复制所有你想要的数据。你会感觉效率极高。有些公司甚至有关于有多少数据源已经被录入数据湖的指标。 这些想法相对较新：虽然在软件领域很常见，但在数据领域却相对较新。数据网格的概念仅在几年前才被提出。数据产品思维仍然是一个年轻的概念。数据契约主要存在于博客和领英帖子中，在生产环境中并不常见。

如何开始对源数据采用数据产品思维？

先到先得

如果你还没有在生产环境中实现商业价值的数据用例，那就先实现它。除非你能够证明对组织有重大价值，否则你不会获得更多预算，也不会说服任何外部团队为你做事。所以，先把第一个用例拼凑起来。直接从源头提取数据。忘掉我上面写的一切。创造价值。至于如何做到这一点，那是另一篇文章的主题。

处理业务关键用例

残酷的事实是，企业通常不会改变，除非它们有真正的理由去改变。你可能用几个简单的 Tableau 仪表板创造了巨大的价值，而且每个月都需要更新。恭喜你，这是一个不错的选择。这可能意味着你只有几个重要的数据源，而且它们偶尔会出问题。不用担心，你下周就能修复。一旦你开始根据你采集的数据进行主动交易，或者你使用来自运营系统的数据构建一个面向客户的人工智能机器人，数据质量问题就可能开始带来巨大的经济损失、声誉损失，甚至两者兼而有之。相信我，现在你已经得到了组织高层领导的倾听，这很棒，因为你的下一步需要它。

获得领导层的支持

杰夫·贝佐斯曾给亚马逊全体员工发了一封著名的电子邮件，大意是要求使用API进行相互沟通。你的领导层很可能不如杰夫·贝佐斯精通技术。不过，现在是时候向他们寻求帮助了。因为，还记得第一个障碍吗？这会给运营团队带来工作。他们需要预算来做这件事。除了预算之外，他们还需要明白这一点。如果你已经完成了第一步和第二步，那么就很容易让他们相信你所做工作的价值。但即便如此，也会有部门渴望加入，也会有部门抵制任何改变。不要试图一下子改变整个组织。让你最忠实的追随者获得成功。如果其他业务领导者看到这一点，他们很快也会转变。而对于那些不可避免地落后的少数人，公司领导层可以轻易地否决他们。顺序在这里很重要。不要一开始就充当数据警察，强迫每个人在价值实现之前为你工作。你有责任让他们相信你所带来的价值。

安装正确的工具来监控进度并进行治理

如果您想赋予域更多职责，则需要落实一些措施。但以下是一些常见的做法：

数据质量工具：是的，您确实需要它们。因为即使出于良好的意图，您仍然会创建质量低劣的数据。您需要尽早发现这些问题，并理想情况下阻止质量低劣的数据向下游蔓延。 数据契约：API 之于软件世界，数据契约之于数据世界。您需要就哪些数据可供下游使用达成一致。数据契约可以是一个简单的文档页面。但如果它是一种能够主动执行这些契约的解决方案，那就更好了，这样您就不会意外违反自己的契约。 数据目录：如果您至少在数据目录中记录您的接口，这也很有帮助，这样人们就可以了解每个数据集的含义以及谁拥有它。 数据产品市场：如果您采用去中心化的方式工作，多个团队将共同创建数据产品。数据仓库类似于集中式共产主义生产，而数据产品则相当于一个自由市场。您希望团队能够发布他们的数据产品，记录其用途、内容和所有者。您希望其他团队能够以受管控的方式使用数据产品。您希望了解您的数据在组织中的使用情况，并形成一个高层次的沿袭。

为团队做好跑腿工作

别忘了他们需要帮助——即使他们怀有最好的意图。我们采取的一个有效方法是，让数据部门负责最重要的数据源。这意味着核心数据团队负责创建与数据源一致的数据产品。在这种情况下，让来自源领域的某个人成为数据产品负责人至关重要。即使这仅仅意味着每周与团队开一次会，也必须确保发布数据的业务所有权掌握在真正了解这些数据的人手中。令人惊讶的是，这几乎从来都不是数据团队的。我们通常不知道我们正在获取的数据意味着什么。我们也不应该知道，我们无法将十几个不同部门的数据都塞进我们的脑子里。

逐步将更多责任下放到部门

如果每个部门不各自负责数据，就无法真正扩大组织的数据应用规模。我遇到过一些团队，他们试图将所有工作集中化，结果不可避免地遇到了瓶颈。我遇到过一位天才数据分析师——我们姑且叫他德塔吧。德塔是我见过的最聪明的人之一。他在公司的数据部门工作了十多年，对数据仓库的数据了如指掌。他勤于记录自己的发现，最终形成了数百页的数据描述。在会议上，他能在5分钟内回答初级分析师需要3个月才能解答的问题。 “啊，你想要这个见解？那么你需要将数据库 X 中的表 A 与大型机中的表 B 和 C 连接起来。小心忽略该custid列。我知道它仍然在那里，但自从 4 年前换了新系统后，如果你尝试执行你想做的事情，该字段可能会不准确。最好custid从数据库 Y 中获取。但我的记忆有点生疏；我得再查一遍文档才能确切地知道该怎么做。”“哇，谢谢德塔，没有你我们永远也搞不定这个问题。一百万年也搞不定。”问题是，我知道只有少数组织有德塔。即使是有的组织，德塔也需要休假。而且德塔可能快退休了。此外，尽管德塔是个天才，但他不可能把公司的所有数据都记在脑子里。德塔通常是第一个承认这一点的人。

所以，责任迟早应该转移到各个部门。对于渴望权力的数据领导者来说，这可能是一个难以下咽的苦果。因为你的直接控制权减少了。你需要问自己一个问题：我在这里是为了实现所有的数据用例吗？答案是否定的。你的公司也没有专门负责发送所有电子邮件的电子邮件部门。你的职责是帮助组织最大限度地利用数据。这项支持工作应该由数据团队集中完成。你越能将单个用例推送到各个部门，你就能创造更大的影响力。可以这样想：你现在拥有的不再是一个由 30 人组成的集中数据团队，而是一个由 300 人组成的分布式数据团队。最棒的是，虽然他们都在努力从数据中创造价值，但只有 10% 的人在你的预算范围内工作。

小结

解决数据质量问题不能仅靠工具来实现。它需要组织变革。以下是成功的途径：

价值至上 处理业务关键用例 获得领导层的支持 安装正确的工具来监控进度并进行治理 为团队做跑腿工作 逐步将更多责任压实到部门