全文共字，预计学习时长11分钟
图源：unsplash随着企业越来越多地利用数据驱动数字产品、推动决策制定和创新，了解这些最关键资产的状况和可靠性至关重要。几十年来，企业一直依赖数据目录来推动数据治理。但这就足够了吗？
AppZen的工程副总裁DebashisSaha，以及MonteCarlo的首席执行官及共同创始人BarrMoses，讨论了数据目录不能满足现代数据栈的需求的原因，以及我们对于元数据管理新方法——数据发现的迫切渴望。
这不是什么秘密：了解数据的位置以及谁有访问权限，对于了解其对业务的影响至关重要。事实上，要构建一个成功的数据平台，关键是要将数据组织好并集中起来，但同时还要易于发现。
与实体的图书馆目录类似，数据目录起到元数据目录的作用，并向用户提供评估数据可访问性、健康状况和位置的所需信息。在自助商业智能时代，数据目录也成为了数据管理和数据治理的强大工具。
无怪乎对于大多数数据领导者来说，他们的首要任务之一就是建立数据目录。数据目录至少应该回答：
·应该在哪里查找数据?
·这些数据重要吗?
·这些数据代表什么?
·这些数据是否相关且重要?
·如何使用这些数据?
然而，随着数据操作的成熟以及数据管道变得越来越复杂，传统的数据目录往往不能满足这些需求。所以，一些最好的数据工程团队正在创新他们的元数据管理方法。比起传统方法，他们正创新着什么呢？
数据目录有哪些不足之处
虽然数据目录能够记录数据，但在很大程度上，允许用户“发现”和收集有意义的、实时的数据状况的根本性难题仍未解决。数据目录无法跟上这种新的现实情况的步伐：主要有三个原因：缺乏自动化；无法随着数据栈的增长和多样性进行扩展；以及它们的非分布式格式。
自动化需求的增长
传统的数据目录和治理方法通常依赖于数据团队手工完成数据输入的繁重工作，并他们还需负责随着数据资产的发展而更新目录。这种方法不仅是时间密集型的，而且需要大量的人工工作，而这些工作本来是可以自动化的。
作为一名数据专家，了解数据的状态是一场持久战，这表明需要更高程度的、更定制化的自动化。
也许这个场景让人想起了：在召开干系人会议之前，你是否经常发现自己疯狂地搜索Slackchannel，以弄清楚是什么数据集为正在使用的特定报告或模型提供信息——以及为什么上周数据没有到达?为了解决这个问题，你是否和团队挤在一个房间里，开始用白板记录所有的上下游联系，以完成一份具体的关键报告?
血淋淋的细节就不赘述了，它可能看起来是这样的：
你的数据沿袭看起来像一团乱线和箭头吗?英雄所见略同。图源：Shutterstock
是的，很多人会感同身受，你并不孤单。许多需要解决这一依赖性拼图的公司踏上了多年的旅程，即人工规划所有的数据资产。有些公司能够投入资源开发短期黑客工具，甚至内部工具，让他们能够搜索和探索自己的数据。
即使达到了最终目标，也会给数据组织带来沉重的负担，让数据工程团队花费更多的时间和金钱，而这些时间和金钱本可以花在其他事情上，比如产品开发或实际使用数据。
随着数据的变化而扩展的能力
当数据结构化时，数据目录非常好用，但在年，情况并非总是如此。随着机器生成数据的增加和公司对机器学习项目的投资，非结构化数据变得越来越普遍，占所有新产生数据的90%以上。
非结构化数据通常存储在数据湖中，没有预定义的模型，必须经过多次转换才能使用。非结构化数据是非常动态的，其形态、来源和含义在处理的各个阶段(包括转换、建模、聚合)中一直在变化。对这些非结构化数据所做的工作(即转换、建模、聚合和可视化)，使得很难在数据的理想状态下编目。
此外，除了简单地描述使用者访问和使用的数据，越来越多的人需要根据数据的意图和目的来理解数据。数据生产者描述数据资产的方式可能与数据使用者理解其功能的方式截然不同，而且即使数据使用者之间也可能存在对数据含义的理解上的巨大差异。
例如，从Salesforce提取的数据集对数据工程师的意义与对销售团队的意义完全不同。虽然工程师会理解“DW_7_V3”的意思，但销售团队会绞尽脑汁，试图确认该数据集是否与Salesforce中的“年收入预测”仪表盘相关。这样的例子不胜枚举。
静态数据描述受到其性质的限制。到年，我们必须接受并适应这些新的、不断发展的动态，才能真正理解数据。
数据是分布式的，但目录不是
尽管现代数据架构的分布以及半结构化和非结构化数据成为常态的趋势，但大多数数据目录仍然将数据视为一维实体。当数据被聚合和转换时，它会流经数据栈的不同元素，使得几乎不可能对其进行记录。
传统的数据目录在接收状态下管理元数据(关于数据的数据)，但是数据是不断变化的，使得很难理解数据在管道中演进时的状况。图源：BarrMoses
现在，数据倾向于自描述，在单个包中包含了数据和描述该数据的格式和含义的元数据。
由于传统的数据目录不是分布式的，因此几乎不可能使用它作为数据真实性的中心源。随着越来越多的用户(从BI分析师到运营团队)能够访问数据，以及支持机器学习、运营和分析的管道变得越来越复杂，这个问题只会越来越严重。
如今的数据目录需要跨域联合数据的含义。数据团队需要能够理解这些数据域如何相互关联，以及聚合视图的哪些方面比较重要。他们需要一种集中的方式从总体上来回答这些分布式的问题——换句话说，就是一个分布式的、联邦的数据目录。
从一开始就投资于正确的方法来构建数据目录将有利于构建更好的数据平台，帮助团队更轻松地探索数据，密切