数据目录已死？为什么要重新思考元数据管理和数据治理？
全文共4233字，预计学习时长11分钟
图源：unsplash
随着企业越来越多地利用数据驱动数字产品、推动决策制定和创新，了解这些最关键资产的状况和可靠性至关重要。几十年来，企业一直依赖数据目录来推动数据治理。但这就足够了吗？
AppZen的工程副总裁Debashis Saha，以及Monte Carlo的首席执行官及共同创始人Barr Moses，讨论了数据目录不能满足现代数据栈的需求的原因，以及我们对于元数据管理新方法——数据发现的迫切渴望。
这不是什么秘密：了解数据的位置以及谁有访问权限，对于了解其对业务的影响至关重要。事实上，要构建一个成功的数据平台，关键是要将数据组织好并集中起来，但同时还要易于发现。
与实体的图书馆目录类似，数据目录起到元数据目录的作用，并向用户提供评估数据可访问性、健康状况和位置的所需信息。在自助商业智能时代，数据目录也成为了数据管理和数据治理的强大工具。
无怪乎对于大多数数据领导者来说，他们的首要任务之一就是建立数据目录。数据目录至少应该回答：
· 应该在哪里查找数据?
· 这些数据重要吗?
· 这些数据代表什么?
· 这些数据是否相关且重要?
· 如何使用这些数据?
然而，随着数据操作的成熟以及数据管道变得越来越复杂，传统的数据目录往往不能满足这些需求。所以，一些最好的数据工程团队正在创新他们的元数据管理方法。比起传统方法，他们正创新着什么呢？
数据目录有哪些不足之处
虽然数据目录能够记录数据，但在很大程度上，允许用户“发现”和收集有意义的、实时的数据状况的根本性难题仍未解决。数据目录无法跟上这种新的现实情况的步伐：主要有三个原因：缺乏自动化；无法随着数据栈的增长和多样性进行扩展；以及它们的非分布式格式。
自动化需求的增长
传统的数据目录和治理方法通常依赖于数据团队手工完成数据输入的繁重工作，并他们还需负责随着数据资产的发展而更新目录。这种方法不仅是时间密集型的，而且需要大量的人工工作，而这些工作本来是可以自动化的。
作为一名数据专家，了解数据的状态是一场持久战，这表明需要更高程度的、更定制化的自动化。
也许这个场景让人想起了：在召开干系人会议之前，你是否经常发现自己疯狂地搜索Slack channel，以弄清楚是什么数据集为正在使用的特定报告或模型提供信息——以及为什么上周数据没有到达?为了解决这个问题，你是否和团队挤在一个房间里，开始用白板记录所有的上下游联系，以完成一份具体的关键报告?
血淋淋的细节就不赘述了，它可能看起来是这样的：
是的，很多人会感同身受，你并不孤单。许多需要解决这一依赖性拼图的公司踏上了多年的旅程，即人工规划所有的数据资产。有些公司能够投入资源开发短期黑客工具，甚至内部工具，让他们能够搜索和探索自己的数据。
即使达到了最终目标，也会给数据组织带来沉重的负担，让数据工程团队花费更多的时间和金钱，而这些时间和金钱本可以花在其他事情上，比如产品开发或实际使用数据。
随着数据的变化而扩展的能力
当数据结构化时，数据目录非常好用，但在2020年，情况并非总是如此。随着机器生成数据的增加和公司对机器学习项目的投资，非结构化数据变得越来越普遍，占所有新产生数据的90%以上。
非结构化数据通常存储在数据湖中，没有预定义的模型，必须经过多次转换才能使用。非结构化数据是非常动态的，其形态、来源和含义在处理的各个阶段(包括转换、建模、聚合)中一直在变化。对这些非结构化数据所做的工作(即转换、建模、聚合和可视化)，使得很难在数据的理想状态下编目。
此外，除了简单地描述使用者访问和使用的数据，越来越多的人需要根据数据的意图和目的来理解数据。数据生产者描述数据资产的方式可能与数据使用者理解其功能的方式截然不同，而且即使数据使用者之间也可能存在对数据含义的理解上的巨大差异。
例如，从Salesforce提取的数据集对数据工程师的意义与对销售团队的意义完全不同。虽然工程师会理解“DW_7_V3”的意思，但销售团队会绞尽脑汁，试图确认该数据集是否与Salesforce中的“2021年收入预测”仪表盘相关。这样的例子不胜枚举。
静态数据描述受到其性质的限制。到2021年，我们必须接受并适应这些新的、不断发展的动态，才能真正理解数据。
数据是分布式的，但目录不是
尽管现代数据架构的分布以及半结构化和非结构化数据成为常态的趋势，但大多数数据目录仍然将数据视为一维实体。当数据被聚合和转换时，它会流经数据栈的不同元素，使得几乎不可能对其进行记录。
传统的数据目录在接收状态下管理元数据(关于数据的数据)，但是数据是不断变化的，使得很难理解数据在管道中演进时的状况。| 图源：BarrMoses
现在，数据倾向于自描述，在单个包中包含了数据和描述该数据的格式和含义的元数据。
由于传统的数据目录不是分布式的，因此几乎不可能使用它作为数据真实性的中心源。随着越来越多的用户(从BI分析师到运营团队)能够访问数据，以及支持机器学习、运营和分析的管道变得越来越复杂，这个问题只会越来越严重。
如今的数据目录需要跨域联合数据的含义。数据团队需要能够理解这些数据域如何相互关联，以及聚合视图的哪些方面比较重要。他们需要一种集中的方式从总体上来回答这些分布式的问题——换句话说，就是一个分布式的、联邦的数据目录。
从一开始就投资于正确的方法来构建数据目录将有利于构建更好的数据平台，帮助团队更轻松地探索数据，密切关注重要的数据资产并充分利用它们的潜力。
数据目录2.0=数据发现
如果有刚性模型，数据目录会非常好用，但随着数据管道变得越来越复杂，非结构化数据成为金标，我们对数据的理解(它用做什么，谁来使用，如何使用等)不能反映现实。我们相信下一代数据目录将具有学习、理解和推断数据的能力，使用户能够以自助方式利用其洞见。但要怎么做到呢?
数据发现可以通过提供关于跨不同领域数据的分布式实时洞察来取代如今的数据目录，同时遵守一组集中的治理标准。| 图源：BarrMoses
除了编目数据外，元数据和数据管理策略还必须包含数据发现，这是一种实时了解分布式数据资产运行状况的新方法。
数据发现借鉴了由Zhamak Deghani和Thoughtworks的数据网格模型提出的面向分布式领域的体系结构，假设不同的数据所有者需要对他们的数据产品负责，同时也要促进不同位置的分布式数据之间的通信。一旦数据服务于给定的域并由其转换，域数据所有者就可以利用数据满足他们的操作或分析需求。
数据发现取代了对数据目录的需求，因为其能通过使用者接收、存储、聚合和使用数据的方式，提供特定于领域的、动态的数据理解。与数据目录一样，治理标准和工具跨域联合了起来(允许更高的可访问性和互操作性)，但与数据目录不同的是，数据发现可以实时了解数据的当前状态，而不是理想状态或“已编目”状态。
数据发现可以回答这些问题，不仅针对数据的理想状态，而且针对每个域的数据的当前状态：
· 哪些数据集是最近的?哪些数据集可以弃用?
· 最后一次更新该表是什么时候?
· 在我的领域中给定字段的含义是什么?
· 谁有权访问这些数据?上次使用这些数据是什么时候?由谁使用的?
· 这些数据的上游和下游依赖关系是什么?
· 这是生产-质量数据吗?
· 哪些数据对我所处领域的业务需求重要?
· 我对这些数据的假设是什么，它们得到满足了吗?
换句话说，下一代的数据目录——数据发现，将具有以下特点：
· 自助发现和自动化
数据团队应该能够轻松地利用数据目录，而无需专门的支持团队。数据工具的自助服务、自动化和工作流编制消除了数据管道阶段之间的竖井，并使理解和访问数据更容易。更高的可访问性自然会导致更多的数据采纳，从而减少数据工程团队的负载。
· 随数据发展的可扩展性
随着公司接收的数据越来越多，非结构化数据成为常态，满足这些需求的能力将对数据项目的成功至关重要。数据发现利用机器学习来获得数据资产的鸟瞰图，以确保理解随着数据的发展而变化。通过这种方式，数据使用者可以做出更明智的决策，而不是依赖过时的文档或更糟糕的基于直觉的决策。
· 分布式发现的数据沿袭
数据发现在很大程度上依赖于自动的表级和字段级沿袭来映射数据资产之间的上下游依赖关系。沿袭有助于在正确的时间显示正确的信息(数据发现的核心功能)及绘制数据资产之间的连接,以便在数据管道发生故障时更好地进行故障排除，随着现代数据栈不断发展以适应更复杂的用例，这个问题变得越来越常见。
· 数据可靠性确保数据的黄金标准——始终如此
事实上，你的团队可能以这样或那样的方式已经在数据发现方面进行了投资。无论是通过团队手工验证数据，还是工程师编写的自定义验证规则，或者仅仅是基于破碎的数据或未被注意到的无声错误所做出的决策的成本。
如今，数据团队已经开始利用自动化方法，在数据管道的每个阶段确保高度可信的数据，从数据质量监控到更健壮的端到端数据可观察性平台，这些平台可以监控和警报数据管道中的问题。此类解决方案会在数据损坏时进行通知，以便能够快速识别根本原因，快速解决问题，防止将来宕机。
数据发现使数据团队能够相信他们关于数据的假设与现实相符，从而支持跨数据基础设施的动态发现和高可靠性，而不需要考虑领域。
下一步是?
如果坏数据比没有数据还要糟糕，那么没有数据发现的数据目录比没有数据目录还要糟糕。要获得真正可发现的数据，重要的是你的数据不仅要“编目”，而且要准确、干净、完全可观测，从接收到使用——换句话说：可靠。
一种强大的数据发现方法依赖于自动化和可扩展的数据管理，它适用于数据系统的新分布式特性。因此，要真正实现组织中的数据发现，需要重新考虑如何处理数据目录。
只有理解数据、数据状态以及如何全方位地使用数据，我们才能开始信任它。
如转载，请后台留言，遵守转载规范