1. 数据工程生命周期
1.1. 数据领域正在经历新数据技术和实践的爆炸式增长，抽象程度和易用性不断提高
1.2. 由于技术抽象程度的增加，数据工程师将越来越多地成为数据生命周期工程师，根据数据生命周期管理的原则来进行思考和操作
1.3. 数据工程生命周期包括将原始数据成分转化为有用的最终产品的阶段，可供分析师、数据科学家、机器学习工程师和其他人使用
1.4. 五个阶段
-
1.4.1. 生成
-
1.4.2. 存储
-
1.4.3. 获取
-
1.4.4. 转换
-
1.4.5. 中间阶段
- 1.4.5.1. 可能会有点混乱
-
1.4.6. 服务
-
1.4.7. 生命周期的各个阶段可能会以有趣和意想不到的方式重复、无序、重叠或交织在一起
1.5. 作为基石的是横跨数据工程生命周期多阶段的底层设计
-
1.5.1. 安全
-
1.5.2. 数据管理
-
1.5.3. DataOps
-
1.5.4. 数据架构
-
1.5.5. 编排和软件工程
-
1.5.6. 没有这些底层设计，数据工程生命周期的任何部分都无法充分发挥作用
2. 数据生命周期
2.1. 数据工程生命周期是完整数据生命周期的一个子集
2.2. 完整的数据生命周期涵盖整个生命周期中的数据，而数据工程生命周期则侧重于数据工程师控制的阶段
3. 生成：源系统
3.1. 源系统是数据工程生命周期中使用的数据的来源
-
3.1.1. IoT设备
-
3.1.2. 应用程序的消息队列
-
3.1.3. 事务数据库
3.2. 数据工程师需要对源系统的工作方式、它们生成数据的方式、数据的频率和速度以及它们生成的数据的多样性有一个工作上的理解
- 3.2.1. 还需要与源系统所有者保持开放的沟通渠道，了解可能破坏管道和分析的更改
3.3. 数据工程的一个主要挑战是工程师必须处理和理解令人眼花缭乱的数据源阵列
3.4. 随着软件开发实践的各种现代演变，应用程序+数据库模式在今天仍然很流行
3.5. 源系统评估问题
-
3.5.1. 数据源的本质特征是什么？
- 3.5.1.1. 它是一个应用程序，还是一个物联网设备集群？
-
3.5.2. 数据如何持久化在源系统中？
- 3.5.2.1. 数据是长期保存的，还是临时的并被迅速删除？
-
3.5.3. 数据生成的速率是多少？
-
3.5.3.1. 每秒有多少事件？
-
3.5.3.2. 每小时有多少数据量？
-
-
3.5.4. 从输出数据中期望什么程度的一致性？
- 3.5.4.1. 如果你对输出数据进行数据质量检查，数据不一致（数据空值、糟糕的格式等）的发生频率是多少？
-
3.5.5. 错误发生的频率如何？
-
3.5.6. 数据会包含重复项吗？
-
3.5.7. 某些数据是否会延迟到达，是否会比同时生成的其他消息晚很多？
-
3.5.8. 获取数据的模式是什么？
- 3.5.8.1. 是否需要跨多个表甚至多个系统进行连接才能获得数据的全貌？
-
3.5.9. 如果数据结构发生变化（例如，添加了一个新列），如何处理并传达给下游利益相关者？
-
3.5.10. 应该多久从源系统中提取一次数据？
-
3.5.11. 数据是否以定期快照或变更数据捕获(Change Data Capture，CDC)的更新事件提供？
-
3.5.11.1. 执行更改的逻辑是什么？
-
3.5.11.2. 如何在源数据库中跟踪这些更改？
-
-
3.5.12. 将为下游消费传输数据的数据提供者是谁/什么？
-
3.5.13. 从数据源读取会影响其性能吗？
-
3.5.14. 源系统是否有上游数据依赖？
- 3.5.14.1. 上游系统的特点是什么？
-
3.5.15. 是否进行了检查延迟或丢失的数据的质量检查？
3.6. 数据源产生的数据供下游系统消费，包括人工生成的电子表格、物联网传感器以及网络和移动应用程序
-
3.6.1. 每个来源都有其独特的数据生成量和节奏
-
3.6.2. 数据工程师应该知道来源如何生成数据，包括相关的怪癖或细微差别
3.7. 源数据最具挑战性的细微差别之一是模式
-
3.7.1. 无模式
-
3.7.1.1. 无模式并不意味着没有模式
-
3.7.1.2. 意味着应用程序在写入数据时定义模式，无论是写入消息队列、平面文件、blob还是文档数据库（如MongoDB）
-
-
3.7.2. 固定模式
- 3.7.2.1. 建立在关系数据库存储之上的更传统的模型使用数据库中强制执行的固定模式，应用程序写入必须符合该模式
3.8. 模式随时间变化
- 3.8.1. 事实上，在软件开发的敏捷方法中鼓励模式演变
3.9. 在源系统模式中获取原始数据输入，并将其转换为有价值的分析输出
4. 存储
4.1. 选择存储解决方案是在数据生命周期其余部分取得成功的关键，而且出于各种原因，它也是数据生命周期中最复杂的阶段之一
-
4.1.1. 云上的数据架构通常利用多种存储解决方案
-
4.1.2. 很少有数据存储解决方案纯粹用作存储，许多支持复杂的转换查询，甚至对象存储解决方案也可能支持强大的查询功能
-
4.1.3. 虽然存储是数据工程生命周期的一个阶段，但它经常涉及其他阶段，例如获取、转换和服务
4.2. 数据的存储方式会影响数据在数据工程生命周期的所有阶段中的使用方式
4.3. Apache Kafka和Pulsar等流式框架可以同时作为消息的获取、存储和查询系统，对象存储是数据传输的标准层
4.4. 评估存储系统
-
4.4.1. 该存储解决方案是否与架构所需的写入和读取速度兼容？
-
4.4.2. 存储是否会给下游流程造成瓶颈？
-
4.4.3. 了解这种存储技术的工作原理吗？
-
4.4.3.1. 你是在最佳地利用存储系统还是在做出不自然的行为？
-
4.4.3.2. 你是否在对象存储系统中应用了高速率的随机访问更新
-
-
4.4.4. 该存储系统能否处理预期的未来规模？
-
4.4.5. 下游用户和进程是否能够在所需的服务等级协定(Service Level Agreement，SLA)中检索数据？
-
4.4.6. 你是否正在捕获有关模式演变、数据流、数据血缘等的元数据？
-
4.4.7. 这是一个纯存储解决方案（对象存储），还是支持复杂的查询模式（即云数据仓库）？
-
4.4.8. 存储系统是模式不可知的（对象存储）吗？
-
4.4.8.1. 灵活的模式(Cassandra)吗？
-
4.4.8.2. 是强制模式（云数据仓库）吗？
-
-
4.4.9. 如何跟踪主数据、黄金记录数据质量和数据血缘以进行数据治理？
-
4.4.10. 何处理法规遵从性和数据主权？
- 4.4.10.1. 能否将数据存储在某些地理位置而不是其他位置？
4.5. 数据访问频率
-
4.5.1. 并非所有数据都以相同的方式访问
-
4.5.2. 检索模式将因存储和查询的数据不同而有很大差异
-
4.5.3. 数据访问频率将决定数据的温度
-
4.5.3.1. 访问频率最高的数据称为热数据
4.5.3.1.1. 热数据通常每天被检索多次，甚至每秒可能被检索几次
-
4.5.3.2. 不冷不热的数据可能会每隔一段时间访问一次
-
4.5.3.3. 冷数据很少被查询，适合存储在归档系统中
4.5.3.3.1. 出于合规目的或在另一个系统发生灾难性故障的情况下，通常会保留冷数据
4.5.3.3.2. 在“过去”，冷数据将存储在磁带上并运送到远程档案设施
4.5.3.3.3. 在云环境中，供应商提供专门的存储层，每月存储成本非常低廉，但数据检索的价格很高
-