1. 数据问责制

1.1. 数据问责制意味着分配一个人来管理一部分数据

• 1.1.1. 负责人协调其他利益相关者的治理活动

• 1.1.2. 如果没有人对相关数据负责，那么管理数据质量就会很困难

• 1.1.3. 负责数据的人不一定是数据工程师

• 1.1.4. 负责人可能由软件工程师、产品经理或其他角色担任

• 1.1.5. 负责人通常不具备维护数据质量所需的所有资源

  • 1.1.5.1. 他们与所有接触数据的人协调，包括数据工程师

1.2. 数据问责制可以发生在各个层面

• 1.2.1. 问责制可以发生在表或日志流的级别，但也可以是与出现在多个表中的单个字段实体一样的细粒度级别

2. 数据质量

2.1. 数据质量是数据向理想状态的优化

2.2. 数据工程师确保整个数据工程生命周期中的数据质量

• 2.2.1. 涉及执行数据质量测试，并确保数据符合模式预期、数据完整性和精度

2.3. 准确性

• 2.3.1. 收集到的数据是否真实？是否有重复值？数值准确吗？

• 2.3.2. 任何机器人生成的事件都被错误分类为人类存在的数据准确性问题，反之亦然

2.4. 完整性

• 2.4.1. 记录是否完整？所有必填字段都包含有效值吗？

2.5. 及时性

• 2.5.1. 记录是否及时可用？

2.6. 数据质量跨越了人类和技术问题的边界

• 2.6.1. 数据工程师需要强大的流程来收集有关数据质量的可操作的人工反馈，并使用技术工具在下游用户看到之前先检测出质量问题

2.7. 主数据管理

• 2.7.1. 主数据是有关业务实体的数据，例如员工、客户、产品和位置

• 2.7.2. 主数据管理(Master Data Management，MDM)是构建一致的实体定义（称为黄金记录）的实践

  • 2.7.2.1. 黄金记录协调整个组织及其合作伙伴的实体数据

  • 2.7.2.2. MDM是一种通过构建和部署技术工具来促进的业务运营流程

3. DataOps

3.1. DataOps将敏捷方法、DevOps和统计过程控制(Statistical Process Control，SPC)的最佳实践映射到数据

• 3.1.1. DevOps旨在提高软件产品的发布和质量

• 3.1.2. DataOps则针对数据产品也是做同样的事情

3.2. 数据产品与软件产品的区别在于数据的使用方式

• 3.2.1. 软件产品为终端用户提供特定的功能和技术特性

• 3.2.2. 数据产品是围绕合理的业务逻辑和指标建立的，其用户可以做出决策或构建执行自动化操作的模型

3.3. 数据工程师必须了解构建软件产品的技术方面以及将创建优秀数据产品的业务逻辑、质量和指标

3.4. 实现

• 3.4.1. 快速创新和实验，以更快的速度为客户提供新的见解

• 3.4.2. 极高的数据质量和极低的错误率

• 3.4.3. 跨复杂的人员、技术和环境阵列进行协作

• 3.4.4. 结果的清晰测量、监控和透明度

3.5. DataOps是一套文化习惯

• 3.5.1. 数据工程团队需要采用与业务沟通和协作、打破孤岛、不断从成功和错误中学习以及快速迭代的循环

• 3.5.2. 只有这些文化习惯养成后，团队才能从技术和工具中获得最好的结果

3.6. DataOps具有三个核心技术要素：自动化、可观测性和监控以及事件响应

• 3.6.1. 建议首先从可观测性和监控开始，了解系统性能，然后添加自动化和事件响应

3.7. 自动化

• 3.7.1. 自动化可确保DataOps流程的可靠性和一致性，并允许数据工程师快速部署新产品功能和对现有工作流程进行改进

• 3.7.2. DataOps成熟度较低的组织通常会尝试使用cron作业来安排数据转换过程的多个阶段

• 3.7.3. 随着组织数据成熟度的增长，数据工程师通常会采用编排框架，可能是Airflow或Dagster

• 3.7.4. 数据工程师意识到Airflow会带来操作负担，但编排的好处最终会超过其复杂性

• 3.7.5. 每个作业都可以在上游数据准备就绪后立即开始，而不是在固定的、预先确定的时间开始

3.8. “拥抱变化”

• 3.8.1. 并不意味着为了改变而改变，而是以目标为导向的改变

3.9. 可观测性和监控

• 3.9.1. 数据是一个无声的杀手

• 3.9.2. 可怕的故事是为报告创建数据的系统随机停止工作，导致报告延迟数天

  • 3.9.2.1. 数据团队在利益相关者询问为什么报告延迟或产生陈旧信息之前并不知情

  • 3.9.2.2. 各个利益相关者对核心数据团队的能力失去了信任，开始了自己的分裂团队

  • 3.9.2.3. 其结果是许多不同的不稳定系统、不一致的报告和孤岛

• 3.9.3. 如果你不观测和监控你的数据和生成数据的系统，你将不可避免地经历自己的数据恐怖故事

• 3.9.4. 可观测性、监控、日志记录、警报和跟踪对于在数据工程生命周期中提前解决任何问题都是至关重要的

3.10. 事件响应

• 3.10.1. 使用DataOps的高效数据团队将能够快速交付新的数据产品

• 3.10.2. 数据工程师必须为灾难做好准备，以尽可能迅速且有效地做出响应

• 3.10.3. 数据工程师应该在业务报告问题之前主动发现问题

  • 3.10.3.1. 失败发生了，当利益相关者或终端用户看到问题时，他们会提出问题

• 3.10.4. 事件响应既是对事件的追溯响应，也是在事件发生之前主动解决事件

4. 数据架构

4.1. 数据架构反映了支持组织长期数据需求和战略的数据系统的当前和未来状态

4.2. 数据工程师应该首先了解业务需求并收集新用例的需求

• 4.2.1. 数据工程师需要将这些需求转化为设计新方法去捕获和提供数据，并在成本和操作简单性之间取得平衡

• 4.2.2. 并不意味着数据工程师就是数据架构师，因为两者通常是两个独立的角色

4.3. 如果数据工程师与数据架构师一起工作，则数据工程师应该能够交付数据架构师的设计并提供架构反馈

5. 编排

5.1. 编排不仅是DataOps的核心流程，也是数据作业工程和部署流程的关键部分

5.2. 编排是协调许多作业以尽可能快速且高效地按照预定节奏运行的过程

5.3. 允许编排系统在没有人为干预的情况下持续感知和监控，并随时运行在部署的新作业

5.4. 编排系统还构建作业历史记录功能、可视化和警报

• 5.4.1. 高级编排引擎可以在新的DAG或到DAG添加单个任务时回填

5.5. 编排一直是数据处理的关键功能，但除了大公司以外，通常不是最重要的，也不是任何人都可以使用的

5.6. Apache Oozie在21世纪10年代非常流行，但它是为在Hadoop集群中工作而设计的，很难在更加异构的环境中使用

5.7. Facebook在21世纪00年代后期开发了供内部使用的Dataswarm

• 5.7.1. 这激发了Airflow等流行工具的灵感，Airbnb于2014年推出了该工具

5.8. Airflow从一开始就是开源的，并被广泛采用

• 5.8.1. 它是用Python编写的，因此可以高度扩展到几乎任何可以想象的用例

• 5.8.2. Airflow的到来恰逢数据处理变得更加抽象和易于访问，工程师们对协调跨多个处理器和存储系统的复杂流程越来越感兴趣，尤其是在云环境中

5.9. 编排严格来讲是一个批处理的概念

• 5.9.1. 编排任务DAG的流式替代方案是流式DAG

• 5.9.2. 流式DAG的构建和维护仍然具有挑战性，但Pulsar等下一代流式平台旨在显著减轻工程和运营负担

6. 软件工程

6.1. 软件工程一直是数据工程师的一项核心技能

• 6.1.1. 应该精通软件工程以理解API、提取和转换数据、处理异常等

6.2. 核心数据处理代码仍然需要编写，并且贯穿于整个数据工程生命周期

• 6.2.1. 无论是在获取、转换还是数据服务方面，数据工程师都需要精通和高效地使用Spark、SQL或Beam等框架和语言

6.3. 重点已经从直接的数据处理转移到抽象的阶梯上

6.4. 流数据处理本质上比批处理更复杂，而且工具和范式可以说还没有那么成熟

• 6.4.1. 随着流数据在数据工程生命周期的每个阶段变得越来越普遍，数据工程师面临着有趣的软件工程问题

6.5. 窗口化允许实时系统计算有价值的指标，如尾随统计数据

• 6.5.1. 数据工程师有许多框架可供选择，包括用于处理单个事件的各种函数平台(OpenFaaS、AWS Lambda、Google Cloud Functions)或用于分析流以支持报告和实时处理的专用流处理器（Spark、Beam、Flink或Pulsar）​

6.6. 基础设施即代码(Infrastructure as Code，IaC)将软件工程实践应用于基础设施的配置和管理

6.7. 流水线即代码是当今编排系统的核心概念，它涉及数据工程生命周期的每个阶段

6.8. 无论数据工程师采用哪种高级工具，他们都会在整个数据工程生命周期中遇到极端情况，这些情况要求他们解决所选工具范围之外的问题并编写自定义代码