如何构建连接数据目录？ - Tony

什么是数据目录？
Gartner 将数据目录定义为“通过发现、描述和组织数据集 [构建] 的数据资产清单。目录提供上下文，使数据分析师、数据科学家、数据管理员和其他数据消费者能够找到并理解相关数据集，以提取商业价值。”

人们常说数据目录提供了“亚马逊数据购物体验”。这是一个令人兴奋的想法，大多数大型组织都已经建立了数据目录，但正如数据集成的情况一样，承诺的业务价值常常无法实现。这是为什么？

最大的问题之一是缺乏标准化。不同的部门对数据进行组织和分类的方式不同——这可能会导致混乱和效率低下，因为用户可能不知道在哪里可以找到他们需要的数据。

数据目录的另一个问题是它们很快就会过时。随着数据集的添加、修改或删除，数据目录中的元数据可能不会始终更新以反映这些更改。

此外，数据目录通常缺乏与其他数据管理工具和系统集成的能力。这会使用户难以访问他们需要的数据并将其用于他们的分析和报告。

最后，在更基本的层面上，在现实世界中，一切都相互联系。相互不连接的孤立数据集通常用途有限。通常情况下，我们需要多个连接的数据集来提取任何真正的商业价值。

我们称之为数据集成问题，这是一个难以破解的难题。人工智能将在整合我们的数据方面发挥越来越重要的作用，但如果人工智能真的要帮助你，你必须首先教会它你业务的细节。这种最初的辅导是一个以人为中心的过程，很难在大型组织中扩大规模。

因此，要启动他们的 AI 并大规模集成，组织必须表演一些技巧；他们必须解决数据集成问题。组织需要将数据集成的成本从收集数据集的中央团队转移到提供它们的所有应用程序。

反向数据集成的过程始于为可以为您的组织带来商业价值的概念创建精确的、可共享的定义。这些标准化定义正是大多数数据目录所缺少的。
通过为结构化数据提供标准化词汇表，schema.org使网站管理员可以更轻松地提供有关其页面的清晰、准确的信息。Schema.org 成功地解决了集成问题。在另一篇文章中，我解释了如何构建您自己的 schema.org，这样您就可以在您的组织范围内做同样的事情。

令人惊讶的是，拥有像数据目录实际是什么的共享定义这样简单的东西可以实现标准化、减少数据集陈旧性、为与下游工具集成铺平道路并最终提供“乐高式”数据集连接。

你自己的 schema.org
让我们向 schema.org 询问数据目录是什么的可共享定义：https://schema.org/DataCatalog

我们可以看到数据目录是一种包含数据集集合的创造性作品。这个定义真的很准确。它为我们提供了编辑器、发布日期和测量技术等属性。其中一些属性很复杂，我们可以单击它们并查看它们的定义。例如，如果我们点击数据集，那么我们会得到一个详细的定义： https: //schema.org/Dataset

这些定义如何反转构建和维护数据目录的成本？好吧，这个数据集的定义非常精确，您实际上可以使用它在网络上共享您的数据集。

Schema.org 提供了数据集的可共享定义，然后各个网站通过符合该共享定义，使其数据集可供任何搜索引擎使用。
数据集保留在各个发布者的网络服务器上，但现在都可以从一个中央位置发现它们。这是一个无尺度架构，对您可以添加的数据集数量没有限制。正是这种扩展人类努力的能力使这种架构模式与众不同。

当像 Google 这样的消费者抓取网络并找到这些数据集之一时，他们只需将预先集成的数据加载到他们的目录中。任务完成。
然后谷歌可以公开该目录供所有人搜索。你可以在这里找到谷歌的实验数据目录，如果我搜索 10 年期英国债券，我会得到一个数据集列表，包括在撰写本文时由 Trading Economics 提供的数据集。

这种模式可以在您自己的组织内部使用，以创建数据目录，降低数据集成的成本，并最终将您的所有数据连接在一起！我们可以将创建去中心化数据目录的过程分为三个阶段。

第一阶段：去中心化数据集注册
对于大多数组织而言，第一阶段代表了相当激进的范式转变。您组织内的所有应用程序都需要提供它们所持有的重要数据集的[url=https://schema.org/DataCatalog]目录[/url]。
在此阶段，应用程序不需要提供数据本身，只需提供有关此数据集包含的内容的信息。您可以将其视为提供菜单而不是餐点。
数据目录架构标记可以作为应用程序网站中的 JSON-LD 岛提供，或者从应用程序 Web API返回，它可以是关于Kafka[url=https://dattell.com/data-architecture-blog/what-is-a-kafka-topic/]主题的[/url]消息，甚至可以只是写入到应用程序网站上的某个共享文件夹网络。Web API 更可取，但真正重要的是数据符合您对数据目录的共享定义，并且应用程序向中央团队注册了可以找到它的位置。

中央数据目录为您的组织提供了一个位置，每个人都可以在其中搜索所有目录中的所有数据集，即使目录本身保留在各种应用程序服务器上也是如此。中央数据目录的存储和查询机制并不重要，但使用知识图最简单，因为它们能够直接摄取 JSON-LD。
一句警告：当您开始构建数据目录时，很容易回到旧习惯。说服应用程序团队发布预先集成的数据将很困难。从表面上看，自己简单地编写几个脚本或构建一个中央页面似乎要容易得多，所有应用程序都可以在其中记录其数据集的详细信息。诚然，这是我自己掉入的陷阱。
但是，要大规模集成，您必须通过在数据发布者之间分配数据集成成本来解决数据集成问题。从技术上讲，这个问题已经解决了——schema.org 已经证明了这一点，而且您可以方便地简单地复制他们的开源代码。然而，在大多数组织中，这种方法所需的“数据文化”远未得到解决。迟早，您将不得不查明您的组织是否有能力进行如此广泛的合作。并非所有组织都是，最好快速失败。如果不能实现文化变革，那么在技术上花钱就毫无意义。
因此，第一阶段结束时的成功本身就是一项重大成就。它将是一个单一的专业知识图谱，为您组织内大部分应用程序提供的各个数据目录编制索引。有了这个，您现在就可以看到您面前的集成任务的规模。您将拥有一个可衡量的路线图，可用于绘制您的组织从当前状态到完全数据连接的旅程。也许最重要的是，您会知道您的组织可以进行大规模协作。

第二阶段：建模
到目前为止，您已经能够重用由 schema.org 开发的共享数据集和数据目录定义。为了提供真正的价值，您现在需要对影响特定组织底线的特定概念进行建模。Schema.org 或许能够为您提供一个起点，但最终您需要扩展其模型以适应您的特定领域。

这里的关键是从大处着眼，从小处着手。您需要选择一个现有 IT 工作尚未解决但看起来仍然可行的问题。例如，客户 360 的某些方面或提供有关应用程序、服务器和软件的 IT 清单的洞察力。
使用新创建的数据目录来识别解决问题所需的数据集。具有明确业务发起人的问题和来自不同权威来源的 3 到 5 个数据集是理想的候选人。
接下来，您需要将业务用户、数据科学家和数据集发布者聚集在一起。该小组必须制定出需要添加到您的内部 schema.org 网站中的共享定义。这种概念建模可能很困难，因为它需要深层次的协作。外部标准在这里可以提供帮助，并且通常有利于简单性和业务可理解性。
当建模完成后，数据发布者应该尝试分解他们的数据集，以便它们被很好地分解。这意味着每个数据集都应对应于您的 schema.org 中定义的一个主要概念。例如，您将拥有人员数据集、建筑物数据集、客户数据集等。
在撰写本文时， schema.org 缺少可用于将数据集链接到它相关的主要概念的属性，因此我建议同时为此目的使用conforms to属性。

尽量不要陷入关于物理和逻辑模型的讨论中，因为这是传统数据集成再次响起的警笛声。在这个反向集成成本的“美丽新世界”中，我们只关心您的 schema.org 中定义的共享概念。每个应用程序都应该发布映射到这些定义的数据集——就这么简单。
此阶段结束时的成功是所有感兴趣的各方就一个模型达成一致，该模型包含解决业务问题所需的所有概念的精确、可共享的定义。

第三阶段：交付
在第三阶段，我们最终从阅读菜单转移到交付（至少对于解决这个初始业务问题所需的数据而言）。在提供数据下载时，每个应用程序必须映射到其数据集符合的共享概念。

发布者可以使用数据集  distribution属性来指定该下载的位置。
发布应用程序负责确保所有标识符与其他数据集中提供的数据相匹配。

有了所有可用的数据集，您现在可以创建一个特定的知识图来加载解决此业务问题所需的数据。现在，交付团队可以构建能够提供真正商业价值的查询、机器学习模型和报告。此阶段结束时的成功是交付用例，或许还可以生成一份可以为您的 CEO 总结项目的独立报告。

冲洗并重复
现在你回到第二阶段并重复这个过程，选择另一个要解决的问题，最好是与你已有的数据有一些重叠的问题，然后再做一次。继续迭代此过程，通过允许项目同时运行来慢慢提升它。这种模式的美妙之处在于不同的组可以同时在分布式图的不同部分上工作。
使用具有可下载分布的数据集的百分比来衡量您的进度。当您的覆盖率达到 30% 时，毫无疑问您将在转型后的组织中工作。

• 您的连接数据目录可以按照对您的组织最重要的概念进行整齐地组织；这样用户就可以更容易地找到他们需要的数据。
• 去中心化数据目录过时的可能性也小得多；因为发布数据集的责任现在由提供数据本身的同一个团队承担。
• 您可以根据 schema.org 中定义的概念自动生成下游报告工具的语义层；使用户可以轻松访问他们需要的数据并将其用于分析和报告。
• 最重要的是，数据集将相互连接；因此用户可以通过将多个数据集组合在一起来提取真正的商业价值。