第一部分　数据发现自助服务

第2章　元数据目录服务

假设一个数据用户准备开发一个收入仪表盘。通过与数据分析师和科学家交谈，用户发现了一个包含客户账单记录相关细节的数据集。在这个数据集中，有一个称为“计费率”的属性。这个属性的意义是什么？它是事实的来源，还是从另一个数据集衍生而来的？他们还会遇到各种其他问题。比如：数据的模式是什么？谁负责管理这些数据？这些数据是如何转换的？数据质量的可靠性如何？数据什么时候刷新？等等。企业内部并不缺乏数据，但是如何使用数据来解决业务问题是当前的一大挑战。这是因为以仪表盘和机器学习模型的形式构建洞察需要对数据属性（称为元数据）有清晰的理解。在缺乏全面的元数据的情况下，人们可能对数据的意义及质量做出不准确的假设，从而产生不正确的洞察。

如何获取可靠的元数据是数据用户的痛点。在大数据时代之前，数据在被添加到中央仓库之前先经过整理——元数据的模式、沿袭、所有者、业务分类等详细信息首先被编目。这就是所谓的即写模式（schema-on-write），如图2-1所示。如今，使用数据湖的方法是首先聚合数据，然后在使用时推断数据细节。这就是所谓的即读模式（schema-on-read），如图2-2所示。因此，数据用户没有管理良好的元数据目录可以使用。复杂性的另一个维度是给定数据集的元数据是孤立的。例如，考虑存储在MySQL事务数据库中的销售数据集。为了在数据湖中获得这些数据，需要在Spark上编写ETL作业，并在Airflow（一个开源的任务调度框架）上进行调度。转换后的数据交由TensorFlow ML模型使用。每个框架都有自己端到端元数据的局部视图。考虑到用于数据持久性、任务调度、查询处理、服务数据库、机器学习框架等的技术种类繁多，加之缺乏端到端元数据的单一规范化表示，因此数据用户使用这些数据变得更加困难。

理想情况下，数据用户应该拥有一个元数据目录服务，该服务提供跨多个系统和孤岛的端到端元数据层。该服务创建了单一数据仓库的抽象，并且是唯一的事实来源。此外，目录应该允许用户使用团队知识和业务上下文来丰富元数据。元数据目录还可以作为一个集中式服务，各种计算引擎可以使用它来访问不同的数据集。该服务的成功标准是减少数据的解释耗时。这样可以加快对合适数据集的识别速度，并消除由于对可用性和质量的错误假设而导致的不必要迭代，从而减少洞察的整体时间。