数据目录已死?为什么要重新思考元数据管理和数据治理?( 二 )


例如 , 从Salesforce提取的数据集对数据工程师的意义与对销售团队的意义完全不同 。 虽然工程师会理解“DW_7_V3”的意思 , 但销售团队会绞尽脑汁 , 试图确认该数据集是否与Salesforce中的“2021年收入预测”仪表盘相关 。 这样的例子不胜枚举 。
静态数据描述受到其性质的限制 。 到2021年 , 我们必须接受并适应这些新的、不断发展的动态 , 才能真正理解数据 。
数据是分布式的 , 但目录不是
尽管现代数据架构的分布以及半结构化和非结构化数据成为常态的趋势 , 但大多数数据目录仍然将数据视为一维实体 。 当数据被聚合和转换时 , 它会流经数据栈的不同元素 , 使得几乎不可能对其进行记录 。

数据目录已死?为什么要重新思考元数据管理和数据治理?
文章图片
传统的数据目录在接收状态下管理元数据(关于数据的数据) , 但是数据是不断变化的 , 使得很难理解数据在管道中演进时的状况 。 |图源:BarrMoses
现在 , 数据倾向于自描述 , 在单个包中包含了数据和描述该数据的格式和含义的元数据 。
由于传统的数据目录不是分布式的 , 因此几乎不可能使用它作为数据真实性的中心源 。 随着越来越多的用户(从BI分析师到运营团队)能够访问数据 , 以及支持机器学习、运营和分析的管道变得越来越复杂 , 这个问题只会越来越严重 。
如今的数据目录需要跨域联合数据的含义 。 数据团队需要能够理解这些数据域如何相互关联 , 以及聚合视图的哪些方面比较重要 。 他们需要一种集中的方式从总体上来回答这些分布式的问题——换句话说 , 就是一个分布式的、联邦的数据目录 。
从一开始就投资于正确的方法来构建数据目录将有利于构建更好的数据平台 , 帮助团队更轻松地探索数据 , 密切关注重要的数据资产并充分利用它们的潜力 。
数据目录2.0=数据发现
如果有刚性模型 , 数据目录会非常好用 , 但随着数据管道变得越来越复杂 , 非结构化数据成为金标 , 我们对数据的理解(它用做什么 , 谁来使用 , 如何使用等)不能反映现实 。 我们相信下一代数据目录将具有学习、理解和推断数据的能力 , 使用户能够以自助方式利用其洞见 。 但要怎么做到呢?

数据目录已死?为什么要重新思考元数据管理和数据治理?
文章图片
数据发现可以通过提供关于跨不同领域数据的分布式实时洞察来取代如今的数据目录 , 同时遵守一组集中的治理标准 。 |图源:BarrMoses
除了编目数据外 , 元数据和数据管理策略还必须包含数据发现 , 这是一种实时了解分布式数据资产运行状况的新方法 。
数据发现借鉴了由ZhamakDeghani和Thoughtworks的数据网格模型提出的面向分布式领域的体系结构 , 假设不同的数据所有者需要对他们的数据产品负责 , 同时也要促进不同位置的分布式数据之间的通信 。 一旦数据服务于给定的域并由其转换 , 域数据所有者就可以利用数据满足他们的操作或分析需求 。
数据发现取代了对数据目录的需求 , 因为其能通过使用者接收、存储、聚合和使用数据的方式 , 提供特定于领域的、动态的数据理解 。 与数据目录一样 , 治理标准和工具跨域联合了起来(允许更高的可访问性和互操作性) , 但与数据目录不同的是 , 数据发现可以实时了解数据的当前状态 , 而不是理想状态或“已编目”状态 。
数据发现可以回答这些问题 , 不仅针对数据的理想状态 , 而且针对每个域的数据的当前状态:
·哪些数据集是最近的?哪些数据集可以弃用?
·最后一次更新该表是什么时候?
·在我的领域中给定字段的含义是什么?
·谁有权访问这些数据?上次使用这些数据是什么时候?由谁使用的?
·这些数据的上游和下游依赖关系是什么?
·这是生产-质量数据吗?
·哪些数据对我所处领域的业务需求重要?
·我对这些数据的假设是什么 , 它们得到满足了吗?
换句话说 , 下一代的数据目录——数据发现 , 将具有以下特点:
·自助发现和自动化
数据团队应该能够轻松地利用数据目录 , 而无需专门的支持团队 。 数据工具的自助服务、自动化和工作流编制消除了数据管道阶段之间的竖井 , 并使理解和访问数据更容易 。 更高的可访问性自然会导致更多的数据采纳 , 从而减少数据工程团队的负载 。
·随数据发展的可扩展性
随着公司接收的数据越来越多 , 非结构化数据成为常态 , 满足这些需求的能力将对数据项目的成功至关重要 。 数据发现利用机器学习来获得数据资产的鸟瞰图 , 以确保理解随着数据的发展而变化 。 通过这种方式 , 数据使用者可以做出更明智的决策 , 而不是依赖过时的文档或更糟糕的基于直觉的决策 。