作者：晓晓来源：数据驱动智能

全文共2712字，建议阅读7分钟

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

数据发现可以帮助确保数据湖不会变成数据沼泽。数据发现可以通过提供跨不同域的数据的分布式实时洞察力来取代现代数据目录，同时遵守一组统一的治理标准。数据发现通过根据一组特定消费者摄取、存储、聚合和使用数据的方式提供对数据的特定领域动态理解，从而取代了对数据目录的需求。

在构建数据平台时，数据团队必须做出的首要决定之一是选择数据仓库还是数据湖来为他们的分析提供存储和计算能力。

虽然数据仓库提供的结构使数据团队可以轻松高效地操作数据，即收集分析洞察力和支持机器学习功能，但该结构可能会使它们在某些应用程序中变得不灵活且成本高昂。

数据湖具有无限的灵活性和可定制性，可以支持广泛的用例，但随着这种更大的敏捷性，出现了许多与数据组织和治理相关的其他问题。因此，数据团队在转向数据湖的路线往往难以回答有关其数据的关键问题，例如：

数据存放在哪里？
谁有权访问它？
这个数据是最新的吗？
如何使用这些数据？

随着数据操作的成熟和数据管道变得越来越复杂，传统的数据目录往往无法回答这些问题。

这就是为什么一些最好的数据工程团队正在重新考虑他们构建数据目录的方法以及数据湖需要什么。

01 数据目录可能在湖中失效

数据目录作为元数据清单，并提供有关数据健康状况、可访问性和位置的信息。它们帮助数据团队回答有关在哪里查找数据、数据代表什么以及如何使用数据的问题。但是，如果我们不知道这些数据是如何组织的，那么所有最好的计划或更确切地说是管道都是徒劳的。

对于现代数据团队来说，它越来越重要。随着公司向数据湖发展，他们通常会损害在仓库中存储数据时隐含的组织和顺序。数据仓库使数据工程团队构建或至少半构建他们的数据，这使得根据业务用户的需求进行分类、搜索和检索变得容易。

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

非结构化数据是有问题的，因为它与数据目录相关，因为它没有组织，即便被组织通常也不会被作为组织整体拥有。这可能适用于在数据仓库中管理的结构化或半结构化数据，但在分布式数据湖的背景下，如果没有某种自动化措施，随着数据的发展手动实施数据治理是无法持续的。

02 现在：手动和集中式目录

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

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

数据发现可以通过跨数据堆栈的不同部分提供分布式、实时的数据洞察来取代或补充现代数据目录，同时遵守通用治理和可访问性标准。

传统的数据目录通常可以满足仓库中结构化数据的需求，但是数据工程师如何在数据湖的复杂水域中航行呢？

虽然许多数据目录具有以 UI 为中心的工作流，但数据工程师需要以编程方式与目录进行交互。他们使用目录来管理模式和元数据，并且需要一种 API 驱动的方法来完成范围广泛的数据管理任务。

此外，数据可以通过多个入口点进入一个湖泊，工程师需要一个能够适应并说明每个入口点的目录。与数据在输入前进行清理和处理的仓库不同，数据湖在不对端到端健康状况做任何假设的情况下接收原始数据。

在湖中，存储数据既便宜又灵活，但这让我们了解拥有什么以及如何使用这些数据成为真正的挑战。数据可能以多种方式存储，例如 JSON 或 Parquet，数据工程师根据要完成的工作以不同方式与数据交互。他们可能将 Spark 用于聚合作业或将 Presto 用于报告或临时查询——这意味着损坏或不良数据有很多机会导致故障。如果没有沿袭，数据湖中的那些故障可能会变得混乱且难以诊断。

在湖中，可以通过多种方式与数据进行交互，而目录必须能够提供对正在使用的内容和未使用的内容的理解。当传统目录不足时，我们可以将数据发现作为前进的道路。