在过去的几年里，数据湖已成为现代数据栈的必备品。但是虽然支持我们访问和分析数据的技术已经成熟，但在分布式环境中理解和信任这些数据的机制却落后了。

数据发现^[1]可以帮助确保您的数据湖不会变成数据沼泽。数据团队在构建数据平台^[2]时必须做出的首要决策之一（可能仅次于“我们为什么要构建这个平台？”）是选择数据仓库还是数据湖^[3]来为他们的分析提供存储和计算能力。虽然数据仓库提供的结构使数据团队可以轻松有效地操作数据（即收集分析见解和支持机器学习能力），但这种结构可能会使它们对于某些应用程序不灵活且成本高昂。另一方面数据湖具有无限的灵活性和可定制性，可以支持广泛的用例，但随着灵活性的提高，还会出现许多与数据组织和治理相关的其他问题。因此Lakehouse的数据团队经常难以回答有关其数据的关键问题，例如：

• • 我的数据在哪里？

• • 谁有权访问它？

• • 我如何使用这些数据？

• • 这些数据是最新的吗？

• • 企业如何使用这些数据？

随着数据操作的成熟和数据管道变得越来越复杂，传统的数据目录^[4]往往无法回答这些问题。这就是为什么一些最好的数据工程团队正在重新考虑他们构建数据目录的方法——以及数据湖需要什么。

数据目录可能淹没在湖中

数据目录^[5]用作元数据清单，并提供有关数据健康、可访问性和位置的信息。它们帮助数据团队回答有关在哪里查找数据、数据代表什么以及如何使用数据的问题。但是如果我们不知道这些数据是如何组织的，那么我们所有的计划都是徒劳的。Intuit 数据平台总监 Seshu Adunuthula 在最近的一篇文章^[6]中恰当地问读者：“您的数据湖是像旧书店还是组织良好的图书馆？” 对于现代数据团队来说，它越来越重要。随着公司陷入困境，他们经常损害在仓库中存储数据的组织和秩序。数据仓库迫使数据工程团队对其数据进行结构化或至少半结构化，这使得根据业务用户的需求进行分类、搜索和检索变得容易。

从历史上看，许多公司使用数据目录来执行数据质量和数据治理标准，因为他们传统上依赖数据团队随着数据资产的发展手动输入和更新目录信息。在数据湖中数据是分布式的，因此随着数据在其生命周期中的演变而难以记录。

非结构化数据是有问题的，因为它与数据目录相关，因为它没有组织，如果是，它通常不会被声明为有组织的。这可能适用于在数据仓库中管理的结构化或半结构化数据，但在分布式数据湖的上下文中，如果没有一定程度的自动化，随着数据的发展手动强制数据治理是无法扩展的。

现在：手动和集中目录

了解不同数据资产之间的关系——随着时间的推移而演变——是一个关键，但通常缺乏传统数据目录的维度。虽然包括数据湖在内的现代数据架构通常是分布式的，但数据目录通常不是分布式的，将数据视为一维实体。非结构化数据没有大多数数据目录用来完成工作的那种预定义模型，并且必须经过多次转换才能使用。

尽管如此，公司仍需要知道他们的数据在哪里以及谁可以访问它，并且能够衡量其整体健康状况——即使存储在湖中而不是仓库中也是如此。如果没有对数据沿袭的这种可见性，当下游出现数据问题时，团队将继续花费宝贵的时间进行救火和故障排除。

数据工程师需要从数据目录中获得什么

传统的数据目录通常可以满足仓库中结构化数据的需求，但是数据工程师如何使用数据湖数据呢？虽然许多数据目录都有以 UI 为中心的工作流，但数据工程师需要灵活地以编程方式与其目录进行交互。他们使用目录来管理模式和元数据，并且需要一种 API 驱动的方法，以便他们可以完成广泛的数据管理任务。此外，数据可以通过多个入口点进入数据湖，工程师需要一个能够适应并解释每个入口点的目录。与数据在进入之前将被清理和处理的仓库不同，数据湖在不假设端到端健康的情况下接收原始数据。在湖中存储数据既便宜又灵活，但这使得了解您拥有什么以及如何使用它成为一个真正的挑战。数据可能以多种方式存储，例如 JSON 或 Parquet，数据工程师根据要完成的工作以不同的方式与数据交互。他们可能使用 Spark 进行聚合作业，或使用 Presto 进行报告或临时查询——这意味着损坏或坏数据有很多机会导致故障。如果没有沿袭，数据湖中的这些故障可能会很混乱且难以诊断。在数据湖中数据可以通过多种方式进行交互，并且目录必须能够提供对正在使用和未使用的内容的理解。当传统目录不足时，我们可以将数据发现视为前进的道路。

未来：数据发现

数据发现^[7]是一种扎根于分布式面向领域架构的新方法，由 Zhamak Deghani 和 Thoughtworks 的数据网格模型^[8]提出。在此框架下，特定领域的数据所有者对其作为产品的数据负责，并负责促进跨领域的分布式数据之间的通信。现代数据发现通过四种关键方式填补了传统数据目录不足的空白：

跨湖扩展的自动化

使用机器学习，数据发现可以自动跟踪表和字段级沿袭，映射上游和下游依赖关系。随着数据的发展，数据发现可确保您也了解数据及其使用方式。

实时了解数据健康状况

与传统的数据目录不同，数据发现提供了对数据当前状态的实时可见性，而不是其“编目”或理想状态。由于发现包括消费者如何摄取、存储、聚合和使用您的数据，因此您可以收集见解，例如哪些数据集已过时并且可以弃用，给定数据集是否符合生产质量，或者给定表何时上次更新。

用于了解数据的业务影响的数据沿袭

这种灵活性和活力使数据发现非常适合将血统带入数据湖，使您能够在正确的时间显示正确的信息，并在许多可能的输入和流出之间建立联系。使用沿袭，您可以在数据管道确实中断时更快地解决问题，因为将检测到经常被忽视的问题，例如架构更改并映射相关的依赖关系。

跨域自助发现

数据发现还支持自助服务，使团队无需专门的支持团队即可轻松利用和理解他们的数据。为了确保这些数据值得信赖和可靠，团队还应该投资于数据可观察性，当数据湖或下游管道出现问题时，它使用机器学习和自定义规则提供实时警报和监控。

跨湖治理与优化

现代数据发现使公司不仅可以了解在其生命周期过程中正在使用、消费、存储和弃用哪些数据，还可以了解如何使用，这对于数据治理至关重要，并提供可用于优化整个湖的洞察力.

从治理的角度来看，查询和处理湖中的数据通常使用各种工具和技术（Databricks 上的 Spark，EMR 上的 Presto 等），因此通常没有一个单一的工具和技术，可靠的读写数据源（就像仓库提供的一样）。适当的数据发现工具可以作为事实的来源。

从优化的角度来看，数据发现工具还可以让利益相关者轻松识别最重要的数据资产（那些不断被查询的！）以及那些未被使用的，这两者都可以为团队优化提供洞察力他们的管道。

数据湖的分布式发现

随着公司不断增加数据的摄取、存储和利用，提高透明度和可发现性的技术将成为关键。越来越多的最佳目录在分布式、特定于域的发现中分层，为团队提供了在其生命周期的所有阶段完全信任和利用数据所需的可见性。

就个人而言，我们对即将发生的事情感到非常兴奋。通过正确的方法，也许我们最终可以将“数据沼泽”双关语一并抛诸脑后？

引用链接

[1] 数据发现: [https://www.montecarlodata.com/data-catalogs-are-dead-long-live-data-discovery/](https://www.montecarlodata.com/data-catalogs-are-dead-long-live-data-discovery/)
[2] 构建数据平台: [https://towardsdatascience.com/how-to-build-your-data-platform-like-a-product-6677e8abe318](https://towardsdatascience.com/how-to-build-your-data-platform-like-a-product-6677e8abe318)
[3] 数据仓库还是数据湖: [https://towardsdatascience.com/how-to-build-your-data-platform-choosing-a-cloud-data-warehouse-3de66862f41c](https://towardsdatascience.com/how-to-build-your-data-platform-choosing-a-cloud-data-warehouse-3de66862f41c)
[4] 数据目录: [https://www.montecarlodata.com/what-we-got-wrong-about-data-governance/](https://www.montecarlodata.com/what-we-got-wrong-about-data-governance/)
[5] 数据目录: [https://www.montecarlodata.com/what-we-got-wrong-about-data-governance/](https://www.montecarlodata.com/what-we-got-wrong-about-data-governance/)
[6] 一篇文章: [https://medium.com/intuit-engineering/is-your-data-lake-more-like-a-used-book-store-or-a-public-library-f444ef6a1798](https://medium.com/intuit-engineering/is-your-data-lake-more-like-a-used-book-store-or-a-public-library-f444ef6a1798)
[7] 数据发现: [https://www.montecarlodata.com/data-catalogs-are-dead-long-live-data-discovery/](https://www.montecarlodata.com/data-catalogs-are-dead-long-live-data-discovery/)
[8] 数据网格模型: [https://martinfowler.com/articles/data-monolith-to-mesh.html](https://martinfowler.com/articles/data-monolith-to-mesh.html)