1.1. 不同的数据仓库和数据湖通过数据集成层来进行桥接

1.2. AWS Glue、Fivetran和Matillion等数据集成工具从不同来源收集数据，统一这些数据，并将其转换为上游来源

1.3. 数据集成的一个典型用例是收集数据湖的数据并以结构化格式将其加载到数据仓库中

1.4. ETL是数据集成中一个众所周知的过程

1.4.1. ETL通常描述集成的步骤，其中首先从一个或多个数据存储库中提取数据，转换为新的结构或格式，最后加载到目标数据存储库中

2.1. 你无法修复你无法测量的东西

2.1.1. 如果没有数据质量指标，你就无法获得数据质量

2.2. 数据宕机的时间（也就是你的数据不完整、有错误、出现缺失或者其他不准确的时间段）来度量数据质量

2.2.1. 公司会仔细度量宕机时间，并投入大量资源来避免发生服务中断的情况

2.3. 问题列表

2.3.1. 数据是最新的吗？

2.3.2. 数据是完整的吗？

2.3.3. 字段是否在预期的范围内？

2.3.4. 空值率是否高于或低于应有的水平？

2.3.5. 模式是否已经更改？

2.4. 可扩展性

2.4.1. 跟踪大量的表和大数据集可能会非常棘手

2.5. 监控栈的其他部分

2.5.1. 构建真正可靠的数据管道并实现数据可观测性需要的远不只是收集指标这么简单

2.6. Snowflake

2.6.1. Snowflake是最流行的云数据仓库工具之一，其设计从一开始就优先考虑了数据质量和数据完整性

2.6.2. 映射清单

2.6.3. 监控数据的新鲜度和容量

2.6.3.1. 度量视图的新鲜度和容量并不简单，因为这是底层查询指令中包含的表的函数

2.6.4. 建立你的查询历史记录

2.6.4.1. 拥有在Snowflake环境中运行的所有查询的可靠历史记录是解决问题时非常有用的工具，它可以让你准确了解最近一次写入表的方式和时间

2.6.5. 健康检查

2.7. 数据仓库最重要的功能之一就是能够直接从其中提取数据质量指标并将其可视化以便进行简单的分析

2.8. 为跟踪数据质量指标而提取的信息需要随时能够提供给团队中的其他成员使用，特别是当事情发生变化或你正处于对数据管道进行根因分析的痛苦之中时

3.1. 问题

3.1.1. 谁在访问这些数据？

3.1.2. 来自上游的哪里？

3.1.3. 来自上游的哪里？

3.1.4. 平均多久执行一次特定的转换？

3.1.5. 有多少行会受到影响？

3.2. 查询日志表通常仅存储某些天数的查询历史记录，且其中所包含的信息比数据质量计划所需要的多得多

3.3. 一个处理数据质量指标查询日志的健壮的解决方案需要具有前瞻性，并将所需的指标和聚合存储在一个更为永久的位置

4.1. 数据栈中的另一个关键元素是数据目录，它在理解数据质量方面起着重要的作用

4.1.1. 数据目录作为元数据清单，为投资者提供了评估数据可访问性、健康状况和位置所需的信息

4.1.2. 不仅可以监测数据，还可以与机器学习和自动化相集成，让数据更易于被发现、更具协作性，并且更符合当前组织、行业甚至政府的相关规则

4.2. 由于数据目录提供了有关公司数据源的单一真相来源，因此你可以很容易地利用数据目录来管理管道中的数据

4.2.1. 数据目录可以用来存储元数据，让利益相关方更好地了解特定来源的沿袭，从而增强对数据本身的信任

4.2.2. 数据目录可以方便地记录个人身份信息的存放位置和下游蔓延位置，以及组织中谁有权通过管道来访问这些信息

4.3. 问题

4.3.1. 应该在哪里查找数据？

4.3.2. 这些数据重要吗？

4.3.3. 这些数据代表了什么？

4.3.4. 这些数据的相关性和重要性如何？

4.3.5. 该如何使用这些数据？

4.4. 传统上使用Excel来解决数据编目问题的方式

4.4.1. 自动化能够让数据工程师和分析师腾出时间来专注于真正能取得进展的项目

4.5. 当前存储的大部分数据都是非结构化且高度流动的

4.5.1. 人们越来越需要根据数据的意图和目的来理解数据，而不是简单地描述消费者访问和使用的数据

4.5.2. 数据编目可以发现并组织恰当的元数据来解释你的数据管道

4.6. 构建数据目录

4.6.1. 在构建或投资数据目录之前，你需要与运营和分析团队的下游利益相关方一起合作，了解哪些数据对业务最为重要，从而需要进行记录和编目

4.6.2. 最基本的，数据目录是元数据集合，可提供对数据位置、所有权和潜在用例的背景信息和洞察

4.6.3. Sqlparse、ANTLR、Apache Calcite和MySQL的SQL Parser都是流行的开源SQL解析解决方案

4.6.4. GraphQL、REST和Cube.js等开源查询语言工具将允许你在数据库中查询SQL并将其呈现在编目可视化服务中

4.6.5. Amundsen、Apache Atlas、DataHub或CKAN

4.6.6. 当你拥有严格的模型时，数据目录的效果很好，但随着数据管道变得越来越复杂，非结构化数据开始成为黄金标准，我们对数据的理解（数据做什么、谁在使用它、如何使用它）并不能反映现实情况

4.6.7. 下一代数据目录将具有学习、理解和推断数据的能力，让用户能够以自助式服务的方式利用其洞察力

4.6.7.1. 数据目录将支持自动数据发现和主动元数据

4.6.8. 数据管理策略还必须包含数据发现，这是一种实时了解分布式数据资产健康状况的新方法

4.6.8.1. 数据发现借鉴了Zhamak Dehghani和Thoughtworks的数据网格模型提出的面向领域的分布式架构，认为不同的数据所有者都应对其数据产品负责，并推动不同位置的分布式数据之间的通信

4.6.8.2. 一旦数据被提供给某一特定领域并在该领域转换后，该领域数据的所有者就可以利用这些数据来满足其自身的运营或分析需求

4.6.9. 数据发现取代了对数据目录的需要，它根据一组特定消费者如何摄取、存储、聚合和使用数据，提供了对特定领域数据的动态解读

4.6.9.1. 数据治理的标准和工具同样是跨领域联合的，以支持更高的可访问性和互操作性

4.6.9.2. 数据发现可以实时了解数据的当前状态，而不是其理想状态或“编目”状态

4.7. 以数据质量为优先的数据目录

4.7.1. 自助式服务的数据发现与自动化

4.7.1.1. 即使没有专门的支持团队，数据团队也应该能轻松利用其数据目录

4.7.1.2. 自助式服务、自动化和工作流编排等数据工具消除了数据管道各阶段之间及其过程中产生的孤岛，让数据变得更容易理解和访问

4.7.1.3. 更高的可访问性自然会提高数据的采用率，从而减轻数据工程团队的负担

4.7.2. 随数据演变的可扩展性

4.7.2.1. 随着公司接收越来越多的数据且非结构化数据开始成为常态，通过扩展来满足这些需求的能力对于数据计划的成功将变得至关重要

4.7.3. 用于分布式数据发现的数据沿袭

4.7.3.1. 数据发现严重依赖自动化表格和字段级的沿袭来映射数据资产之间的上下游依赖关系

4.7.3.2. 数据发现让数据团队能够相信团队对数据的假设与现实相符，从而在不考虑领域的前提下，在数据基础设施中实现动态发现和高度的可靠性

4.7.3.3. 你的团队可能已经以某种方式在数据发现方面进行了投资，无论是通过团队为验证数据而正在进行的手动工作，还是通过工程师编写的自定义验证规则，或者仅仅是基于损坏的数据或未被察觉的隐性错误所做出的决策成本

4.8. 要获得真正可发现的数据，很重要的一点在于数据不仅要“编目”，而且从摄取到利用这一过程要准确、干净且完全可观测

4.8.1. 要可靠

4.8.2. 只有了解你的数据及其状态，以及在其生命周期的所有阶段和跨领域的使用方式，我们才能开始信任它