元数据，被忽视的 IT 盲点

最近清理存档时，我发现了一篇 1976 年发表的关于数据字典/目录系统 (DD/DS) 的旧文章。其作者是 L. Delport。如今，我们已经不再使用 DD/DS 这个术语，而是使用“数据目录”，或者只简称其为“元数据系统”。但在当时，对于存储、描述和管理元数据的系统而言，DD/DS 还是一个时髦的术语。

许多年过去了，元数据管理有改进吗？

我决定阅读这篇文章，因为我想知道这些年来元数据的状况有何改进。最重要的是，此文对组织管理元数据的水平之低发出了长篇哀叹。令我印象深刻的是，作者几乎所有的批评至今仍适用于许多组织。因此，在阅读这篇文章后，我得出的结论是，元数据管理在这 46 年中并没有太大变化。（顺便说一句，我还有一个邪恶的计划，就是将这篇文章中的部分术语替换为现在使用的术语，然后重新发布。我敢打赌，如果这样做，大多数读者都不会注意到这篇文章最早成文于 46 年前。）

元数据管理怎么可能没有改变呢？很少有人会说元数据不重要。事实上，大多数人都认为它很重要。那么，我们为何不更妥善地管理元数据，并以更智能的方式为组织提供元数据呢？换句话说，为何元数据还是 IT 的盲点？对我而言，这仍是个谜。

我的总体建议是按照数据架构的设计方法设计一种元数据架构。这涉及到研究需要访问元数据的用户和应用程序的需求。接下来，我详述几个示例。

分析需求

在过去，元数据主要留给 IT 专业人员使用。他们需要详细了解所有文件、表和列是什么。这种需求仍然存在，但也有对元数据感兴趣的新用户。如今，企业用户（尤其是开发自己的仪表板和创建数据科学模型的用户）需要访问元数据。他们需要查看描述、分类、沿袭等等。他们需要确切了解自己所查看内容的属性。他们需要搜索元数据，以找到正确的数据来编写报告或开发数据科学模型。他们还需要借助元数据来明确如何解读数据。因此，我们需要详细分析企业用户需要哪些类型的元数据。

研究他们希望如何访问元数据也很重要。例如，如果企业用户使用的仪表板充斥着大量财务数据，则对所有数值含义的描述应该随时可以获得。他们可能希望在将鼠标悬停在特定数值上两秒钟后即可自动查看相关的元数据。他们可能不想另启动一个系统来查看这些描述，因为这既不方便，又很耗时。了解用户希望如何使用元数据非常重要。

元数据也可以纳入运营系统。例如，如果为不同的数据对象分配了不同的安全级别，则相关的数据隐私和安全规则可以引用这些级别。举例来说，没有适当凭据的用户组将无法查看具有高安全级别的列。

如今，出于数据隐私、安全性、可审计性和可治理性的原因，必须妥善管理元数据，这可能需要强大的版本控制方式。

业务用户可能希望以批注的形式自行添加元数据描述。同样，对于设计适当的元数据架构而言，这将是一个重要需求。

此外，必须从其他系统输入和提取元数据。对于提取，可能需要类似 ETL 的解决方案从源系统中提取元数据，并定期执行此类提取，因为元数据可能会发生变化。请注意，元数据的 ETL 可能并非简单地从某些结构化数据源中提取元数据。这可能意味着从 ETL 程序、数据库存储的过程和报告工具的语义层中提取元数据描述。元数据 ETL 的源并不总是数据库，有时也是代码和规范。

在未来的架构中，元数据不可或缺

所有这些需求不会如魔法般地出现；必须对它们进行分析、设计和开发。因此，架构师应该意识到这些需求。需要适当工具实现这一目标，并且必须以适当的方式管理元数据，使其可以被正确访问。

在未来的数据架构中，无论是数据网格、数据编织、数据仓库还是数据湖库架构，元数据都是必不可少的，尤其是对于开发自己的仪表板并生成自己的报告的现代企业用户。他们需要无障碍地访问元数据。

我知道这一切听起来仿佛多此一举，但为何元数据在 40 多年后仍然是被忽视的 IT 继子？本不应该这样。