2.2　最小化解释耗时

解释耗时代表数据科学家在建立洞察之前理解数据集细节所花费的时间。这是提取洞察的第一步，较长的解释耗时会影响整体的洞察时间。此外，对数据集的错误假设会导致在洞察开发过程中出现多次不必要的迭代，并且会降低洞察的整体质量。数据集的细节被划分为三部分：技术元数据、操作元数据和团队元数据。如图2-3所示。

2.2.1　提取技术元数据

技术元数据包括数据集的逻辑元数据和物理元数据。物理元数据包括与物理布局和持久性相关的细节。例如，创建和修改时间戳、物理位置和格式、存储层级和保留细节。逻辑元数据包括数据集模式、数据源细节、生成数据集的过程，以及数据集的所有者和使用者。

技术元数据是通过抓取单个数据源来提取的，不一定要在多个数据源之间进行关联。收集技术元数据有三个关键挑战：

格式不同

每个数据平台存储元数据的方式都不同。例如，Hadoop分布式文件系统（HDFS）元数据是按照文件和目录的形式存储的，而Kafka的元数据是按照主题的形式存储的。创建一个适用于所有平台的统一标准化元数据模型并非易事。典型的策略是应用最小公分母，但这将导致抽象泄露。数据集按照不同的数据格式存储在诸多存储中，提取元数据需要不同的驱动程序来连接和提取不同的系统。

模式推断

不是自描述的数据集是需要推断模式的。但是，数据集的模式难以提取，对于半结构化数据集，难以进行模式推断。没有通用的方法来实现对数据源的访问和生成DDL（Data Definition Language，数据定义语言）。

跟踪修改

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

2.2.2　提取操作元数据

操作元数据由以下两个关键部分组成。

沿袭

跟踪数据集是如何生成的，以及它对其他数据集的依赖关系。对于一个给定的数据集，沿袭包括所有依赖的输入表、派生表、输出模型和仪表盘。它包括实现转换逻辑以派生最终输出的作业。例如，如果作业J读取数据集D1并生成数据集D2，那么D1的沿袭元数据包含D2作为其下游数据集之一，反之亦然。

数据分析统计

跟踪可用性和质量指标。它捕获数据集的列级和数据集全局特征，还包括捕获完成时间、处理的数据以及与管道相关的错误信息的执行统计。

操作元数据不是通过连接到数据源产生的，而是通过跨多个系统将元数据状态拼接在一起产生的。例如，在Netflix中，数据仓库由大量存储在Amazon S3（通过Hive）、Druid、ElasticSearch、Redshift、Snowflake和MySQL中的数据集组成。查询引擎（即Spark、Presto、Pig和Hive）用于使用、处理和生成数据集。

考虑到多种不同类型的数据库、调度器、查询引擎和商业智能（BI）工具，如何在不同的处理框架、数据平台和调度系统中弄清整体数据流和沿袭是一个挑战。鉴于处理框架的多样性，挑战在于将细节拼接在一起。从代码中推断沿袭并非易事，特别是对于UDF、外部参数等。

复杂性的另一个方面是获得完整的数据沿袭。由于访问数据事件的日志数量可能非常大，因此传递闭包的大小可能也非常大。通常，要在沿袭关联的完整性和效率之间进行权衡，通过只处理日志中数据访问事件的抽样，并且只在几跳内实现下游和上游关系的具体化，而不是计算真正的传递闭包。

2.2.3　收集团队知识

团队知识是元数据的重要组成部分。随着数据科学团队的发展，将这些细节持久化地保存下来供他人利用至关重要。团队知识有4类：

• 用户以注释、文档和属性描述的形式定义元数据。这些信息是通过社区的参与和协作创建的，通过鼓励对话和对所有权的自豪感来创建一个自我维护的文档存储库。
• 业务分类规则或术语表，以业务直观的层次结构关联和组织数据对象和指标。此外，还有与数据集相关联的业务规则，如测试账户、策略账户等。
• 数据集在合规性、个人识别信息（PII）数据属性、数据加密要求等方面的状态。
• 机器学习增强元数据的形式，包括最常用的表、查询等，再加上检查源码，提取任何一条附带的注释。这些注释往往质量很高，其词法分析可以提供捕捉模式语义的短语。

在收集团队知识时，有三个比较大的挑战：

• 很难让数据用户轻松直观地分享团队知识。
• 元数据的形式是松散自由的，但是又必须进行验证以确保正确性。
• 信息的质量难以核实，特别是在信息相互矛盾的情况下。