1.1. 在了解数据源、所用源系统的特征以及数据的存储方式之后，你需要收集数据

1.2. 数据工程生命周期的下一阶段是从源系统中获取数据

1.2.1. 源系统和获取代表了数据工程生命周期中最重要的瓶颈

1.2.2. 源系统通常不在你的直接控制范围内，可能会随机变得无响应或提供质量差的数据

1.2.3. 你的数据获取服务可能出于多种原因神秘地停止工作

1.2.4. 不可靠的源和获取系统会在整个数据工程生命周期中产生连锁反应

1.3. 主要问题

1.3.1. 正在获取的数据的用例有哪些？

1.3.1.1. 可以重用这些数据而不是创建同一数据集的多个版本吗？

1.3.2. 系统是否可靠地生成和获取这些数据，这些数据是否在我需要时可用？

1.3.3. 获取后的数据目的地是什么？

1.3.4. 需要多久访问一次数据？

1.3.5. 数据通常以多大的体积到达？

1.3.6. 数据的格式是什么？

1.3.6.1. 下游存储和转换系统可以处理这种格式吗？

1.3.7. 源数据是否处于良好状态以供直接下游使用？

1.3.7.1. 如果是这样，持续多长时间，什么可能导致它无法使用？

1.3.8. 如果数据来自流媒体源，是否需要在到达目的地之前进行转换？

1.3.8.1. 在数据流本身内转换数据的情况下，进行中的转换是否合适？

1.4. 批处理与流处理

1.4.1. 处理的所有数据本质上都是流式传输的

1.4.2. 数据几乎总是在其源头不断地产生和更新

1.4.3. 批量获取只是一种专门且方便的大块处理数据流的方法

1.4.4. 流式获取使我们能够以连续、实时的方式向下游系统提供数据

1.4.4.1. 实时（或接近实时）意味着数据在生成后的很短的时间内（例如，不到1秒后）就可以供下游系统使用

1.4.4.2. 符合实时性要求的延迟因领域和要求而异

1.4.4.3. 流处理似乎是个好主意，但它并不总是直截了当的；额外的成本和复杂性必然会发生

1.4.5. 批量数据在预定的时间间隔或当数据达到预设大小阈值时被获取

1.4.5.1. 批量获取是一扇单向门：一旦数据被分成批次，下游消费者的延迟就会受到固有的限制

1.4.6. 批处理长期以来一直是获取数据的默认方式

1.4.6.1. 批处理仍然是为下游消费提取数据的一种非常流行的方式，特别是在分析和ML中

1.4.7. 许多系统中存储和计算的分离以及事件流和处理平台的普遍存在，使得数据流的连续处理更容易获得并且越来越受欢迎

1.4.7.1. 选择在很大程度上取决于使用情况和对数据实时性的期望

1.4.8. 关键考虑因素

1.4.8.1. 如果我实时获取数据，下游存储系统能否处理数据流的速率？

1.4.8.2. 需要毫秒级的实时数据获取吗？

1.4.8.2.1. 或者采用微批处理方法，例如每分钟收集和获取数据？

1.4.8.3. 流式获取的用例有哪些？

1.4.8.3.1. 通过实施流处理，我有哪些具体优势？

1.4.8.3.2. 如果我实时获取数据，我可以对这些数据采取什么行动来改进批处理？

1.4.8.4. 流处理方法在时间、金钱、维护、停机时间和机会成本方面是否会比简单地进行批处理花费更多？

1.4.8.5. 如果基础设施出现故障，我的流处理管道和系统是否可靠且冗余？

1.4.8.6. 哪些工具最适合用例？

1.4.8.7. 如果我正在部署ML模型，在线预测和可能的持续训练对我有什么好处？

1.4.8.8. 我是从实时生产实例获取数据吗？

1.4.8.8.1. 如果是这样，我的获取过程对此源系统有何影响？

1.4.9. 许多出色的获取框架确实可以处理批处理和微批处理获取方式

1.4.9.1. 批处理是许多常见用例的绝佳方法，例如模型训练和每周报告

1.4.9.2. 只有在确定了可以权衡使用批处理的业务用例之后，才能采用真正的实时流

1.5. 推送与拉取

1.5.1. 在数据获取的推送模型中，源系统将数据写入目标系统，无论是数据库、对象存储还是文件系统

1.5.2. 在拉取模型中，数据是在源系统中检索

1.5.3. 推送和拉取范式之间的界限可能非常模糊

1.5.4. 数据在数据管道的各个阶段工作时，经常会被推送和拉取

1.5.5. 在传统的ETL中，获取系统按固定的时间表查询当前源表快照

1.5.6. 连续CDC

1.5.6.1. 每当源数据库中的一行发生更改时，一种常用方法都会触发一条消息

1.5.6.2. 这条消息被推送到一个队列中，获取系统在队列中获取它

1.5.6.3. CDC方法使用二进制日志，它记录对数据库的每次提交

1.5.6.3.1. 获取系统读取日志但不直接与数据库交互

1.5.6.3.2. 这几乎不会对源数据库增加额外负载

1.5.6.4. 某些版本的批处理CDC使用拉取模式

1.5.6.4.1. 在基于时间戳的CDC中，获取系统查询源数据库并提取上次更新以来已更改的行

1.6. 通过流式获取，数据绕过后端数据库并直接推送到终端，通常由事件流平台缓冲数据

1.6.1. 此模式对于发射传感器数据的IoT传感器队列很有用

1.6.2. 我们不是依靠数据库来维护当前状态，而是简单地将每个记录的读数视为一个事件

1.6.3. 简化了实时处理，允许应用程序开发人员为下游分析定制消息，并极大地简化了数据工程师的工作

2.1. 数据工程生命周期的下一个阶段是转换，这意味着数据需要从其原始形式转变为对下游用例有用的形式

2.1.1. 如果没有适当的转换，数据将处于惰性状态，并且不会以对报告、分析或ML有用的形式出现

2.1.2. 转换阶段是数据开始为下游用户消费创造价值的阶段

2.2. 在获取后，基本转换立即将数据映射到正确的类型，将记录放入标准格式，并删除错误的记录

2.2.1. 转换的后期阶段可能会转换数据模式并应用规范化

2.2.2. 在下游，我们可以应用大规模聚合来报告或对ML过程的数据进行特征化

2.3. 主要考虑因素

2.3.1. 转换的成本和投资回报率(Return On Investment，ROI)是多少？

2.3.1.1. 相关的商业价值是什么？

2.3.2. 转换是否尽可能简单和自我隔离？

2.3.3. 转换支持哪些业务规则？

2.4. 可以批量转换数据，也可以在传输过程中进行流式转换

2.4.1. 几乎所有数据都以连续流的形式开始，批处理只是处理数据流的一种特殊方式

2.4.2. 批处理转换非常受欢迎，但鉴于流处理解决方案的日益普及和流数据量的普遍增加，预计流式转换的受欢迎程度将继续增长，也许很快就会在某些领域完全取代批处理

2.5. 转换视为数据工程生命周期的一个独立领域，但生命周期的实际情况在实践中可能要复杂得多

2.6. ML的数据特征化是另一个数据转换过程

2.6.1. 特征化旨在提取和增强对训练ML模型有用的数据特征

2.6.2. 特征化可能是一门暗黑艺术，它结合了领域专业知识（以确定哪些特征可能对预测很重要）与数据科学方面的丰富经验

3.1. 数据工程生命周期的最后阶段

3.1.1. 现在数据已被获取、存储并转换为连贯且有用的结构，是时候从你的数据中获取价值了

3.1.2. 从数据中“获取价值”对不同的用户意味着不同的事情

3.1.3. 数据服务可能是数据工程生命周期中最令人兴奋的部分

3.2. 当数据用于实际目的时，它才有价值

3.2.1. 未使用或未查询的数据只是惰性的

3.3. 数据虚荣项目是公司的一个主要风险

3.3.1. 在数据湖中收集大量数据集，这些数据集从未以任何有用的方式使用过

3.4. 分析

3.4.1. 是大多数数据工作的核心

3.4.2. 一旦你的数据被存储和转换，你就可以生成报告或仪表板并对数据进行临时分析

3.4.3. 商业智能

3.4.3.1. BI通过收集数据来描述企业的过去和当前状态

3.4.3.2. BI需要使用业务逻辑来处理原始数据

3.4.3.3. 用于分析的数据服务是数据工程生命周期各个阶段可能会纠缠在一起的另一个领域

3.4.3.4. 业务逻辑通常在数据工程生命周期的转换阶段应用于数据，但读取逻辑方法越来越流行

3.4.3.4.1. 数据以干净但相当原始的形式存储，具有最少的后处理业务逻辑

3.4.3.5. BI系统维护一个业务逻辑和定义的存储库

3.4.3.5.1. 此业务逻辑用于查询数据仓库，以使报告和仪表板与业务定义保持一致

3.4.4. 数据质量差、组织孤岛和缺乏足够的数据技能通常会阻碍分析技术的广泛使用

3.4.5. 运营分析

3.4.5.1. 运营分析侧重于运营的精细细节，促进报告用户可以立即采取行动

3.4.5.2. 运营分析侧重于运营的精细细节，促进报告用户可以立即采取行动

3.4.5.3. 数据是实时消费的，直接来自源系统或流数据管道

3.4.5.4. 运营分析中的洞察类型与传统BI不同，因为运营分析侧重于当前，不一定关注历史趋势

3.4.6. 嵌入式分析

3.4.6.1. 在SaaS平台上提供给客户的分析带有一组单独的要求和复杂性

3.4.6.2. 内部BI面向的受众有限，一般呈现的统一视图数量有限

3.4.6.3. 访问控制很关键，但并不特别复杂

3.4.6.4. 使用少数角色和访问层来管理访问

3.4.6.5. 每个客户都必须看到他们的数据，而且只能看到他们的数据

3.5. 多租户

3.5.1. 数据工程师可能会选择将许多客户的数据存放在公用表中，以便为内部分析和机器学习提供统一的视图

3.5.2. 该数据通过具有适当定义的控件和过滤器的逻辑视图在外部呈现给各个客户

3.5.3. 数据工程师有责任了解他们部署的系统中多租户的细节，以确保绝对的数据安全和数据隔离

3.6. 机器学习

3.6.1. 一旦组织达到高水平的数据成熟度，他们就可以开始识别适合机器学习的问题并开始围绕它组织实践

3.6.2. 数据工程师的职责在分析和机器学习方面有很大的重叠，而且数据工程、机器学习工程和分析工程之间的界限可能很模糊

3.6.3. 特征存储是最近开发的一种结合了数据工程和机器学习工程的工具

3.6.3.1. 在实践中，数据工程师是支持机器学习工程的特征存储的核心支持团队的一部分

3.6.4. 注意事项

3.6.4.1. 数据质量是否足以执行可靠的特征工程？

3.6.4.1.1. 质量要求和评估是与使用数据的团队密切合作制定的

3.6.4.2. 数据是否可发现？

3.6.4.2.1. 数据科学家和机器学习工程师能否轻松找到有价值的数据？

3.6.4.3. 数据工程和机器学习工程之间的技术和组织边界在哪里？

3.6.4.4. 数据集是否正确代表了基本事实？

3.6.4.4.1. 是否存在偏见

3.6.5. 在将大量资源投入机器学习之前，请花时间建立坚实的数据基础

3.6.5.1. 意味着在数据工程和机器学习生命周期中建立最佳系统和架构

3.6.5.2. 通常最好在转向机器学习之前先培养分析能力

3.6.5.3. 许多公司已经因为在没有适当基础的情况下采取举措而破灭了机器学习梦想

3.7. 反向ETL

3.7.1. 向ETL长期以来一直是数据中的一个实际现实，被视为一种我们不喜欢谈论或用名字来表示的反模式

3.7.2. 反向ETL从数据工程生命周期的输出端获取经过处理的数据，并将其反馈回源系统

3.7.3. 随着企业越来越依赖SaaS和外部平台，反向ETL变得尤为重要

3.7.3.1. 广告平台是一个日常用例