今天早些时候，我加入了一场激动人心的讨论，在开放源数据峰会上，与一些杰出的行业专家一起参与——Russell Spitzer（Snowflake的高级工程师，Apache Iceberg贡献者，代表Polaris项目），Lisa N. Cao（Datastrato的产品经理，代表Apache Gravitino），Denny Lee（Databricks的高级开发倡导者，代表Unity Catalog），以及主持人Kyle Weller，Onehouse的产品负责人（Apache Hudi）。我们深入探讨了“开源数据目录的兴起”这一话题，讨论了Unity Catalog、DataHub、Apache Gravitino和Apache Polaris。

在这篇文章里，我将总结小组讨论中的关键点，并分享更多的见解和收获。

谁来编目这些编目？

在过去的五年里，数据格局越来越倾向于独立、中立的存储，这种存储与计算层（如数据库和仓库）分离。这种转变带来了更大的灵活性，使得数据存储更加独立，但也带来了数据治理方面的挑战。

开源数据目录已经作为关键解决方案出现，平台如DataHub、Unity Catalog、Apache Gravitino和Apache Polaris正逐渐受到欢迎。今天我们讨论了这些目录如何促进数据治理，以及为什么开源方法对现代数据管理至关重要。

面板首先讨论了非结构化数据治理和生成式AI相关的问题。随着GenAI（生成式AI）的迅速发展，对非结构化数据处理的需求也在增加。然而，随着这种需求的增加，也对更强大的治理提出了要求，以确保这些数据被有效且负责任地管理。

问题一： “鉴于无结构数据带来的挑战，从存储到合规，有哪些举措或策略正在被采取来应对无结构数据治理方面的这些挑战？”

Denny 强调，GenAI 的兴起将非结构化数据置于前沿位置，使其治理成为关键问题。随着非结构化数据成为许多 AI 模型的基础，组织必须优先考虑确保数据准确性、隐私和合规性的框架。这种转变将随着 GenAI 的持续采用，发挥重要作用，以降低风险并提高效果。

来自Apache Iceberg的Russell表示，他们正处于将非结构化数据（如二进制大对象（BLOBs））整合进其元数据结构的早期阶段。传统上，Iceberg专注于具有明确定义的模式和表格的结构化数据。然而，由于人工智能和机器学习对非结构化数据的需求不断增长，Iceberg正积极扩展其能力。这一过程仍处于探索阶段，正在进行的努力是为了扩展其元数据架构以处理非结构化数据。

从我的角度看，随着生成式AI的快速崛起，将非结构化数据转换为结构化数据，这为整个行业带来了巨大的机会，也对元数据平台提出了重大挑战。AI系统正在被指向大量的非结构化数据，需要像DataHub这样的平台去适应并扩展其职责，以处理非结构化数据。这种扩展对于理解和描绘整个数据生命周期至关重要，从原始数据生成到转换，再到最终使用。通过扩大范围，像DataHub这样的元数据系统可以提供在AI时代的全面数据旅程视图，确保更好的治理和更深入的洞察力。

在调试管道的过程中，没有什么比追踪表中某些列或属性的源头更糟糕的了。当数据经过多个阶段转换时，这种困境常常会出现，导致复杂的血统关系，让源数据和转换逻辑变得模糊不清。如果没有清晰的数据流视图，识别问题会变得非常费时。

想象一个场景，数据值的不一致促使进行调查。如果数据的来源不清楚，你可能会发现自己在层层转换中筛选和查找各种脚本、配置或甚至手动输入，这些都对最终结果有影响。这不仅会耗费你很多时间，还可能让你感到沮丧，并对数据的完整性产生怀疑。

此外，缺乏明确的来源可能带来重大风险，例如因误判或错误信息导致的决策失误或违规行为，尤其是在受监管的行业（如金融或医疗）中。当团队无法轻松地将数据追溯到其源头时，这会阻碍他们确保数据质量和治理。

问题二：「数据谱系、数据文档、数据合同……你们社区在这一类的元数据方面做了些什么？」

高效的元数据管理工具和数据溯源解决方案对于克服这些挑战至关重要。它们帮助理解数据如何转换、来源以及在系统中的流动情况。通过投资这些工具和解决方案，组织可以增强调试并增加透明度，最终增强对数据的信任。

从我的角度来看，数据血统 绝对是至关重要的——我们在 DataHub 的发展中很早就意识到，手动追踪数据血统在复杂环境中并不现实。因此，我们优先开发了能自动捕获跨多种系统（包括主要行业平台）数据血统的连接器。我们的高级目录辅助 SQL 解析器 让我们能够提供详细的血统洞察，这对于理解数据流动和保障数据完整性至关重要。

然后就是文档的挑战。但是没有人喜欢编写数据文档。在我工作于领英时，特别是在实施GDPR标注（大约在2016-2018年）时，这给我上了重要的一课。我们意识到需要采取双管齐下的办法。一方面，我们需要使文档和注解的体验变得简单，嵌入到用户界面以方便使用。随着GenAI的出现，我们有机会进一步减少首次创建数据文档的摩擦。另一方面，我们需要从一开始就将文档整合到开发过程中，使其成为工作流程中无缝的一部分。

通过“左移”——即将这些实践尽早融入开发流程中——我们确保在数据进入目录之前，文档已经准备就绪。这不仅能够增强系统使用者对系统的信任，同时也确保了责任归属和透明操作，这些都是数据驱动文化中不可或缺的部分。

最终，我们对数据谱系和文档的重视不仅仅是为了合规。这关乎于让用户能够从他们的数据中提取全部潜在价值。一个既重视数据谱系又重视文档的文化会造就更强大的团队并促进更明智的决策，他们可以协作创建有意义的数据协议，营造一个数据真正成为竞争优势的环境，让数据成为真正的资产。有关有意义的数据协议的更多信息，请访问我们的网站。

问题三：Iceberg 社区已经创建了简单明了的规范，包括表、视图以及 REST 目录。你能解释一下Polaris是如何在这个基础上进行构建的呢，特别是在Polaris目录实现中集成Iceberg REST目录规范的部分，以及开发我们刚才讨论的这些特定功能很重要吗？

Russell指出，他们确实专注于在Iceberg社区和Polaris项目中构建好的规格说明。

从我个人的经验来看，我很高兴看到之前非常复杂的（难以理解，更别提实现了）Hive 元数据 API 正在被一个更用户友好且易于实现的 API 所取代。这一转变为客户带来了更多选择。转向更易用的 API 意味着我们可以期待更多的创新，我真心希望最好的方案能脱颖而出，从而惠及整个数据社区。

问题四：你如何看待开源数据目录中“普适性”集成的重要性，以推动采用和社区发展壮大，特别是在与Delta Lake、Apache Hudi和Apache Iceberg等格式的数据存储兼容，以及与各种查询引擎的整合方面？

当我反思我们在DataHub的角色时，我认识到我们的责任是从众多的数据工具中提取和表示元数据信息。随着我们遇到的工具和API数量的增加，挑战也随之加大，使我们的工作更加繁重。这促使我们创建了一个可扩展且易于维护的开源数据摄取连接器框架，这也是为什么我们看到许多贡献者的连接器提交到DataHub项目中，并且激励了许多其他人建立类似的系统。在过去的几年中，我们发现与那些拥有稳定且维护良好的API的系统集成是可靠且高效的。相反，处理快速变化的系统常常会导致复杂的问题。这不仅是因为标准缺失，更多的是因为这些API的管理情况，如果我们可以淘汰或替换某些工具或API，我完全支持这样的举措！

问题五：‘目录的目录’究竟是什么意思，开发人员在理解和使用这一概念时，与选择单一数据目录相比，有什么不同之处？

如今有大量的目录可供选择，开发人员在选择合适的目录变得非常艰巨。丽莎在我们的讨论中对此发表了一些精彩的见解。

在我看来，定义一个目录，我们必须首先回答一个根本性的问题：它包含了什么？例如，梅西百货的目录展示了商店的产品系列。同样，Unity Catalog 是 Databricks 生态系统中关键资产的一个目录，比如表和数据集。因此，目录可以理解为特定平台或上下文中各项资源的清单。

根据这一定义，DataHub 不仅仅是为编目实际存在的事物而服务的。人们可以创建像数据产品或领域这样的完全合乎逻辑的概念，而这些概念在其他地方是不存在的。你可以扩展元数据模型，从而创建全新的事物类型。它既作为“图”，代表数据资产，也代表其他对组织来说重要的数据资产间的关系。有些人可能会称这类类别为“目录的目录”，但这个标签可能会带来误导。例如，虽然 Apache Gravitino 可能符合这一定义，但它并不涵盖数据血缘或者与数据产品和领域相关的逻辑概念，而这对于理解数据领域中不同元素之间的关系至关重要。

当开发人员考虑使用哪个目录时，首先要考虑清楚自己的需求：我为什么需要一个目录，以及我打算用它来做什么？如果你的目标只是查询系统中某个名称的表，那么像Iceberg或Unity这样的表目录就合适了；或者如果你想将这种访问权限合并或统一，你可能会考虑在这些系统前面使用Apache Gravitino。然而，如果你的目标是理解跨系统的所有操作流程，以监控数据质量或在实施变更前评估变更的影响，那么像DataHub这样的跨系统元数据图是必不可少的工具。

要进一步探讨这个话题，请观看我与Onehouse的创始人兼CEO Vinoth Chandar的《Decoding Data Live (DDL) — “驾驭混乱：深入探讨表格式和目录管理。”》对话。
(解密数据现场)
https://www.youtube.com/watch?v=yPqSR18BzO4&list=PLdCtLs64vZvEBpEPWFlO8kxsKSRk0P7MA

请问，你能详细解释一下开源数据治理的重要性吗？特别是开发和使用开源数据目录时的独特优势吗？

Russell 和 Denny 都强调了为什么避免供应商锁定对于这类问题至关重要。您的元数据层代表了您的核心业务知识、政策和规则，这很重要。作为希望始终为下一次变化和下一次创新做好规划的领导者，您希望确保您选择作为“保管您的核心资产”的系统应该不会在您更换数据或 AI 平台提供商时，让迁移变得像噩梦一样复杂。不会在您更换数据或 AI 平台提供商时，让迁移变得像噩梦一样复杂，可以考虑将其简化为：“不会让迁移变得像噩梦一样复杂”。这里的“核心资产”可以替换为“核心价值”以避免重复。

我认为这是一个非常好的观点，接下来我想谈谈为什么在选择元数据或数据目录领域中的产品时，“开放性”很重要，还有另外三个好处。

1. 不断变化的问题空间： 随着我对数据目录和元数据管理不断变化的问题空间的观察，很明显，这种动态变化带来了不确定性。采用开放的方式使我们能够快速适应这些变化，确保我们的方法与数据的动态性质保持一致。通过参与社区，我们可以利用丰富的知识和经验，最终促进我们的解决方案的创新性和响应性。这种适应性对于在快速变化的数据环境中保持相关性至关重要。
2. 社区贡献： 开源项目依靠来自不同公司和用户的多样贡献，从而促进创新的协同生态系统。这种集体输入不仅提升了产品的质量和功能，还允许快速改进以跟上用户需求和行业趋势。通过利用广泛的观点和专业知识，开源项目可以比传统的闭源替代方案更快地发展，最终为社区提供更大的价值。通过这些贡献，社区形成了惯用术语，从而形成了数据管理概念和实践的一种有机标准化形式。
3. 透明度： 开源代码通过提供系统如何运作的完全透明度，使用户受益，这对安全性和合规性至关重要。理解代码库内部运作使组织能够识别漏洞、评估风险并确保符合监管要求。这种程度的洞察力增强了用户和利益相关者之间的信任，因为它允许他们验证所采取的安全措施，并自信地与软件互动，因为他们有权限审计和修改代码。

在做出选择时把这些要点放在心上，这会对你有很大帮助，并且最后，重要的是它必须保持开放状态才能正常工作。

毕竟，仅仅因为名字里有“Open”、“OpenAPI”或“开源”这些词，并不真正意味着它是开放的。要注意该项目是否真的被行业领导者采用，他们是否回馈代码，社区是否活跃且充满活力，是否有多个系统集成商在积极推广该项目？这些都是项目真正开放并为了行业利益不断演进和塑造的良好迹象。

当我们回顾近几年的情况——以及我们现在进行的讨论，比如今天的小组讨论——很明显，数据格局已经转向独立、中立的存储解决方案，数据湖仓架构的兴起就是一个很好的例子。虽然这提供了很大的灵活性，但也带来了数据治理的新挑战。因此，开源数据目录，例如 Unity Catalog、DataHub、Apache Gravitino 和 Apache Polaris 正在成为组织中的重要工具。这些目录不仅增强了治理能力，还促进了社区协作，推动了行业的创新。我鼓励大家积极参与有关开源数据治理在塑造我们行业中的角色的持续讨论中。

请点击这里了解更多关于DataHub项目的内容