1.1. 通过与数据分析师和科学家交谈，用户发现了一个包含客户账单记录相关细节的数据集

1.2. 企业内部并不缺乏数据，但是如何使用数据来解决业务问题是当前的一大挑战

1.3. 以仪表盘和机器学习模型的形式构建洞察需要对数据属性（称为元数据）有清晰的理解

1.4. 在缺乏全面的元数据的情况下，人们可能对数据的意义及质量做出不准确的假设，从而产生不正确的洞察

1.5. 即写模式（schema-on-write）

1.5.1. 在大数据时代之前，数据在被添加到中央仓库之前先经过整理—元数据的模式、沿袭、所有者、业务分类等详细信息首先被编目

1.5.2. 在将数据模式和其他元数据写入数据仓库之前首先生成元数据目录

1.6. 即读模式（schema-on-read）

1.6.1. 如今，使用数据湖的方法是首先聚合数据，然后在使用时推断数据细节

1.6.2. 先聚合数据湖中的数据，然后在读取数据时推断数据模式和其他元数据属性

1.7. 复杂性的另一个维度是给定数据集的元数据是孤立的

1.8. 理想情况下，数据用户应该拥有一个元数据目录服务，该服务提供跨多个系统和孤岛的端到端元数据层

1.8.1. 该服务创建了单一数据仓库的抽象，并且是唯一的事实来源

1.8.2. 目录应该允许用户使用团队知识和业务上下文来丰富元数据

1.8.3. 元数据目录还可以作为一个集中式服务，各种计算引擎可以使用它来访问不同的数据集

1.8.4. 该服务的成功标准是减少数据的解释耗时

1.8.5. 加快对合适数据集的识别速度，并消除由于对可用性和质量的错误假设而导致的不必要迭代，从而减少洞察的整体时间

1.9. 为了成功地提取洞察，了解与数据相关的元数据至关重要：在哪里、什么、如何、何时、谁、为什么等

1.9.1. 作为数据平台中必不可少的一环，元数据目录服务需要将这些信息集中起来作为单一的事实来源

2.1. 解释数据集的需求是数据科学家探索的起点

2.2. 理解数据集

2.2.1. 作为构建新模型、检测新指标或进行即席分析的第一步，数据科学家需要理解数据的来源、使用方式、持久化方式等细节

2.2.2. 通过理解数据细节，他们可以在开发洞察时做出明智的决策，筛选出正确的数据集做进一步分析

2.2.3. 元数据目录成为数据问题的唯一事实来源

2.2.4. 元数据目录还存储数据集的运行健康状况，并用于对数据集模式的任何更改或已发现的任何其他团队已经使用过的错误进行影响分析

2.2.5. 可以帮助快速调试数据管道中的中断环节，还可以对降低数据可用性而违反SLA的事件、在部署后出现数据质量问题以及其他操作问题进行告警

2.3. 分析数据集

2.3.1. 数据科学家可以根据数据集的属性和查询类型，使用合适的工具来分析数据集

2.3.2. 单个数据集可以使用多个查询引擎来交叉读取，如Pig、Spark、Presto、Hive等

2.3.3. 为了支持使用多个查询处理框架，需要将规范数据类型映射到各自的数据存储和查询引擎类型

2.4. 知识扩展

2.4.1. 当数据科学家在项目中使用不同的数据集时，会发现有关业务词汇、数据质量等额外的细节，这些学习被称为团队知识

2.4.2. 团队知识目标是通过丰富数据集的元数据目录细节，在数据用户之间积极分享团队知识

3.1. 解释耗时代表数据科学家在建立洞察之前理解数据集细节所花费的时间

3.2. 这是提取洞察的第一步，较长的解释耗时会影响整体的洞察时间

3.3. 对数据集的错误假设会导致在洞察开发过程中出现多次不必要的迭代，并且会降低洞察的整体质量

3.4. 技术元数据

3.4.1. 技术元数据包括数据集的逻辑元数据和物理元数据

3.4.2. 物理元数据包括与物理布局和持久性相关的细节

3.4.3. 逻辑元数据包括数据集模式、数据源细节、生成数据集的过程，以及数据集的所有者和使用者

3.4.4. 技术元数据是通过抓取单个数据源来提取的，不一定要在多个数据源之间进行关联

3.4.5. 关键挑战

3.4.5.1. 格式不同

3.4.5.1.1. 每个数据平台存储元数据的方式都不同

3.4.5.1.2. 典型的策略是应用最小公分母，但这将导致抽象泄露

3.4.5.1.3. 数据集按照不同的数据格式存储在诸多存储中，提取元数据需要不同的驱动程序来连接和提取不同的系统

3.4.5.2. 模式推断

3.4.5.2.1. 不是自描述的数据集是需要推断模式的

3.4.5.2.2. 数据集的模式难以提取，对于半结构化数据集，难以进行模式推断

3.4.5.2.3. 没有通用的方法来实现对数据源的访问和生成DDL（Data Definition Language，数据定义语言）

3.4.5.3. 跟踪修改

3.4.5.3.1. 元数据在不断变化

3.4.5.3.2. 鉴于数据集的高流失率和不断增长的数量，保持元数据的更新是一个挑战

3.5. 操作元数据

3.5.1. 关键部分

3.5.1.1. 沿袭

3.5.1.1.1. 跟踪数据集是如何生成的，以及它对其他数据集的依赖关系

3.5.1.1.2. 对于一个给定的数据集，沿袭包括所有依赖的输入表、派生表、输出模型和仪表盘

3.5.1.1.3. 包括实现转换逻辑以派生最终输出的作业

3.5.1.2. 数据分析统计

3.5.1.2.1. 跟踪可用性和质量指标

3.5.1.2.2. 捕获数据集的列级和数据集全局特征，还包括捕获完成时间、处理的数据以及与管道相关的错误信息的执行统计

3.5.2. 捕获数据集的列级和数据集全局特征，还包括捕获完成时间、处理的数据以及与管道相关的错误信息的执行统计

3.5.3. 复杂性的另一个方面是获得完整的数据沿袭

3.5.3.1. 由于访问数据事件的日志数量可能非常大，因此传递闭包的大小可能也非常大

3.6. 收集团队知识

3.6.1. 团队知识是元数据的重要组成部分

3.6.2. 类别

3.6.2.1. 用户以注释、文档和属性描述的形式定义元数据

3.6.2.1.1. 这些信息是通过社区的参与和协作创建的，通过鼓励对话和对所有权的自豪感来创建一个自我维护的文档存储库

3.6.2.2. 业务分类规则或术语表，以业务直观的层次结构关联和组织数据对象和指标

3.6.2.2.1. 还有与数据集相关联的业务规则，如测试账户、策略账户等

3.6.2.3. 数据集在合规性、个人识别信息（PII）数据属性、数据加密要求等方面的状态

3.6.2.4. 机器学习增强元数据的形式，包括最常用的表、查询等，再加上检查源码，提取任何一条附带的注释

3.6.2.4.1. 这些注释往往质量很高，其词法分析可以提供捕捉模式语义的短语

3.6.3. 挑战

3.6.3.1. 很难让数据用户轻松直观地分享团队知识

3.6.3.2. 元数据的形式是松散自由的，但是又必须进行验证以确保正确性

3.6.3.3. 信息的质量难以核实，特别是在信息相互矛盾的情况下

4.1. 元数据目录服务能够提供元数据的一站式服务，并且该服务是事后的，即在各种管道创建或更新数据集之后收集元数据，而不影响数据集所有者或用户

4.2. 元数据目录服务在后台以非侵入的方式收集有关数据集及其使用情况的元数据

4.3. 事后方式（post-hoc）不需要对数据集进行前期管理

4.4. 接口

4.4.1. 一个Web门户，用于支持导航、搜索、沿袭可视化、注释、讨论和社区参与

4.4.2. 一个API终端，提供统一的REST接口，以访问各种数据存储的元数据

4.5. 关键模块

4.5.1. 技术元数据提取器

4.5.1.1. 专注于连接数据源，提取与数据集相关的基本元数据

4.5.2. 操作元数据提取器

4.5.2.1. 在数据转换中跨系统缝合元数据，创建一个端到端（E2E）视图

4.5.3. 团队知识聚合器

4.5.3.1. 允许用户对数据集相关的信息进行注释，从而实现整个数据团队的知识扩展

4.6. 提取技术元数据的需求

4.6.1. 需求的第一部分是了解提取技术元数据所需的技术清单

4.6.1.1. 目标是确保使用合适的方式来提取元数据，并正确表示数据模型

4.6.1.2. 调度器（如Airflow、Oozie和Azkaban）

4.6.1.3. 查询引擎（如Hive、Spark和Flink）

4.6.1.4. 关系型数据存储和NoSQL数据存储（如Cassandra、Druid和MySQL）

4.6.2. 需求的另一部分是元数据的版本支持—跟踪元数据的版本与最新版本的差异

4.6.2.1. 能够查询元数据在过去的某个时间点是什么样子，这不仅对于审计和调试很重要，对于重新处理和回滚用例也很有用

4.6.2.2. 作为这个需求的一部分，了解需要持久化的历史记录数量，以及访问API来查询快照的历史记录很重要

4.7. 操作技术元数据的需求

4.7.1. 为了提取处理作业的数据沿袭信息，需要解析查询以提取源表和目标表

4.7.2. 需求分析包括获取所有数据存储和查询引擎（包括流处理和批处理）的查询类型清单，包括UDF

4.7.3. 目标是找到支持这些查询的合适的查询解析器

4.7.4. 数据集的可用性告警

4.7.5. 作为数据质量指示的元数据的异常跟踪

4.7.6. 管道执行的SLA告警

4.8. 团队知识聚合器的需求

4.8.1. 是否需要业务术语

4.8.2. 需要限制可以添加到团队知识中的用户类型，即限制访问控制和添加团队知识所需的审批流程

4.8.3. 需要验证规则或元数据检查

4.8.4. 需要使用沿袭来传播团队知识

5.1. 三个级别

5.1.1. 特定源连接器模式

5.1.1.1. 简化连接到不同数据源，并提取与数据相关的元数据信息的过程

5.1.1.2. 特定源连接器模式从源数据提取元数据，以聚合技术元数据

5.1.1.3. 数据集使用基于URN的命名来识别

5.1.1.4. 构建模块

5.1.1.4.1. 自定义提取器

5.1.1.4.1.1. 特定源连接器用于连接和持续获取元数据

5.1.1.4.1.2. 自定义提取器需要适当的访问权限，以授权凭据连接到RDBMS、Hive、GitHub等数据存储

5.1.1.4.2. 联合持久性

5.1.1.4.2.1. 元数据细节以标准化的方式持久化，各个系统仍然是模式元数据（schema metadata）的事实来源，因此元数据目录在其存储中不会将其具体化

5.1.1.4.2.2. 元数据目录只直接存储关于数据集的业务和用户定义的元数据，它还将数据集的所有信息发布到搜索服务中，以供用户发现

5.1.1.5. 特定源连接器用于从源系统收集元数据

5.1.1.6. 优点

5.1.1.6.1. 该模式详尽地聚合了多个系统的元数据，创建了一个单一仓库的抽象

5.1.1.6.2. 它将特定源的元数据规范化为一种通用格式

5.1.1.7. 缺点

5.1.1.7.1. 难以与新的适配器保持同步

5.1.1.7.2. 在数百万个数据集的极端规模下，连接源并提取数据的事后方法是行不通的

5.1.2. 沿袭关联模式

5.1.2.1. 自动提取与源表和目标表相关的转换沿袭

5.1.2.2. 沿袭关联模式将跨数据和作业的操作元数据组装在一起，并与执行状态结合

5.1.2.3. 通过将作业执行记录与沿袭相结合，该模式可以用来解决一些问题，包括数据时效性、SLA、调整指定表的下游作业、基于使用情况对管道中的表进行排序等

5.1.2.4. 构建块

5.1.2.4.1. 查询解析

5.1.2.4.1.1. 通过分析即席查询或按预定的ETL运行的查询，可以完成对数据沿袭的跟踪

5.1.2.4.1.2. 查询解析的输出是输入表和输出表的列表，即由查询读取和写入的表

5.1.2.4.1.3. 查询解析不是一次性的活动，而是需要根据查询的更新而不断更新

5.1.2.4.2. 管道关联

5.1.2.4.2.1. 一个数据或机器学习管道由多个数据转换作业组成

5.1.2.4.2.2. 通过加入与每个查询关联的输入表和输出表来构建管道沿袭视图

5.1.2.4.3. 用执行统计丰富沿袭

5.1.2.4.3.1. 执行统计（包括完成时间、处理的数据基数、执行中的错误、表的访问频率、表的计数等）都会添加到沿袭视图相应的表和作业中

5.1.2.5. Atlas还通过跟踪以下依赖类型来支持列级沿袭

5.1.2.5.1. 简单依赖

5.1.2.5.1.1. 输出列与输入列具有相同的值

5.1.2.5.2. 表达式依赖

5.1.2.5.2.1. 输出列在运行时由某个表达式在输入列上进行转换

5.1.2.5.3. 脚本依赖

5.1.2.5.3.1. 输出列由用户提供的脚本进行转换

5.1.2.6. 优势

5.1.2.6.1. 它提供了一种非侵入的方法来重建依赖关系

5.1.2.7. 缺点

5.1.2.7.1. 对于查询类型来说，沿袭可能没有100%的覆盖率，而且是近似的

5.1.2.8. 对于每天运行数百个管道并保证性能和质量SLA的部署来说，沿袭关联模式至关重要

5.1.3. 团队知识模式

5.1.3.1. 简化聚合业务上下文和数据用户之间的知识共享的过程

5.1.3.2. 团队知识模式侧重于数据用户定义的元数据，以丰富与数据集关联的信息

5.1.3.3. 其目标是让数据用户分享经验，并帮助跨团队扩展知识

5.1.3.4. 当数据集没有很好的记录、有多个事实来源、质量参差不齐，以及数据集的大部分数据不再被维护时，该模式尤其有价值

5.1.3.5. 主要类型

5.1.3.5.1. 数据文档

5.1.3.5.1.1. 包括属性含义、枚举和数据描述的细节

5.1.3.5.1.2. 用户可以根据自己的经验使用自由形式的元数据来注释表列

5.1.3.5.1.3. 数据集所有者可以用描述注释数据集，以帮助用户找出哪些数据集适合他们

5.1.3.5.2. 业务分类和标签

5.1.3.5.2.1. 包括在业务中使用概念作为分类法，根据业务领域和主题领域对数据进行分类

5.1.3.5.2.2. 为了便于对表的数据生命周期进行管理，可以对表打上标签

5.1.3.5.2.3. 数据集审计人员可以对包含敏感信息的数据集进行标记，并提醒数据集所有者或提示审查，以确保数据处理得当

5.1.3.5.3. 可插拔式验证

5.1.3.5.3.1. 表的所有者可以将关于表的审计信息作为元数据对外提供

5.1.3.5.3.2. 可以提供列默认值和验证规则，用于写入表

5.1.3.5.3.3. 验证还包括用于开发数据的业务规则

5.2. 元数据目录服务正越来越多地作为数据平台的一部分来实现

5.2.1. FINRA的Herd项目

5.2.2. Uber的Databook项目

5.2.3. LinkedIn的WhereHows项目和DataHub项目

5.2.4. Netflix的Metacat项目

5.2.5. Apache的Atlas项目

5.2.6. AWS Glue项目