1.1. 无边界数据是现实中存在的数据，是事件发生时的数据，要么是间断的，要么是连续的、持续的和流动的

1.2. 有边界数据是跨越某种边界（如时间）对数据进行归类的一种便捷方式

1.2.1. 所有的数据在有边界之前都是无边界的

1.3. 长期以来，业务流程通过切割离散的批次对数据施加人为的限制

1.3.1. 牢记数据的真正无边界性

1.4. 流式获取系统是一种用于保持数据的无边界性的工具，以便数据生命周期中的后续步骤也能连续地处理数据

2.1. 数据获取频率

2.1.1. 在较慢的一端，一家企业可能每年向会计公司发送一次税务数据

2.1.2. 在较快的一端，变更数据捕获系统可以每分钟从源数据库中检索一次新的日志更新

2.1.3. 更快的是，系统可以连续从物联网传感器获取事件并在几秒内处理这些事件

2.2. 数据获取的频率往往是混合的，这取决于使用场景和技术

2.2.1. 获取过程可以是批处理、微批处理或实时处理

2.2.2. 没有一个获取系统是真正实时的

2.2.2.1. 任何数据库、队列或管道在向目标系统提供数据时都有固有的延迟

2.2.2.2. 更准确的说法是近实时

2.2.3. 当事件到达时，要么会在管道中被逐一处理，要么会以微批（在简短的时间间隔内批处理）的形式处理

2.2.4. 即使使用流式数据获取过程，下游使用批处理也是相对常见的

2.3. 数据在生命周期中将被分解成不同的批次

2.3.1. 一旦选择批处理，处理频率就会成为所有下游处理的瓶颈

2.4. 流式系统是许多数据源的最佳选择

2.4.1. 在物联网应用程序中，典型的模式是每个传感器将事件或测量值直接写入流式系统

2.4.2. 数据也可以直接写入数据库，但流式获取平台（如Amazon Kinesis或Apache Kafka）更适合这类场景

2.4.3. 在事件发生时将其写入消息队列，而不是让下游系统从后端数据库拉取事件和状态信息

2.4.3.1. 对于已经通过队列交换消息的事件驱动型架构来说效果特别好

2.5. 流式架构通常与批处理共存

3.1. 在同步获取的情况下，数据源、获取过程和写入目标有复杂的依赖关系并且是紧密耦合的

3.2. 在异步获取的情况下，依赖关系现在可以体现在单个事件的层面上，就像它们在由微服务构建的软件后端一样

3.2.1. 事件一旦被获取，就会在存储中可用

3.2.2. 当事件产生的速率变低并且管道中没有任何积压时，新增的事件会快速通过管道

4.1. 序列化意味着对来自源头的数据进行编码，这种编码会作为传输和中间存储阶段的数据结构

4.2. 在获取数据时，要确保你的下游能够反序列化它所收到的数据

5.1. 理论上讲，数据获取不应该是系统的瓶颈

5.2. 在实践中，数据获取瓶颈是相当常见的

5.3. 从哪里获取数据是很重要的

5.4. 处理突发性数据获取的能力

5.4.1. 数据很少以恒定的速率生成，速率往往是起伏不定的

5.4.2. 系统需要内置的缓存来收集高峰期的事件，以防止数据丢失

5.4.3. 存在系统扩展时起到桥梁作用，使存储系统在动态可扩展的系统中适应突发情况

5.4.4. 只要有可能，就使用托管服务来处理系统扩展问题

6.1. 可靠性和持久性在数据管道的获取阶段是至关重要的

6.2. 可靠性意味着获取系统的高正常运行时间和适当的故障转移

6.3. 持久性需要确保数据不会丢失或损坏

6.4. 一些数据源（如物联网设备和缓存）中的数据如果没有被正确获取，则可能会丢失

6.4.1. 数据一旦丢失，它就永远消失了

6.4.2. 数据获取系统的可靠性会直接影响生成数据的持久性

6.5. 理论上，如果数据已经被获取，在下游进程暂时中断的情况下理论上可能会延迟运行

6.6. 评估风险，并根据丢失数据的影响和成本建立适当的冗余和自我修复机制

6.7. 可靠性和持久性都有直接和间接的成本

6.7.1. 没有什么是免费的

6.7.2. 一定要不断地评估可靠性和持久性的成本与收益

6.8. 在许多极端情况下，获取数据实际上并不重要

6.8.1. 如果互联网瘫痪，即使你在有独立电源的地下掩体中建立了多个空气密封的数据中心，那么也无法获取数据

7.1. 有效负载是你正在获取的数据集并且具有种类、形态、大小、模式和数据类型以及元数据等特征

7.2. 数据种类直接影响到它在数据工程生命周期中下游的处理方式

7.2.1. 类型直接影响到数据的格式或表现形式，包括字节、名称和文件扩展名等

7.2.2. 图像，它的格式是JPG或PNG，它本质上是非结构化的

7.3. 数据形态在整个数据工程生命周期中都是至关重要的

7.3.1. 每个有效负载都有一个描述其维度的形态

7.3.2. 表格

7.3.2.1. 数据集中的行和列的数量，通常表示为M行和N列

7.3.3. 半结构化的JSON

7.3.3.1. 键值对和嵌套深度与子元素一起出现

7.3.4. 非结构化文本

7.3.4.1. 文本正文中的字数、字符数或字节数

7.3.5. 图像

7.3.5.1. 宽度、高度和RGB颜色深度

7.3.6. 无压缩的音频

7.3.6.1. 道数（例如，两个立体声）

7.3.6.2. 采样深度（例如，每样本16位）

7.3.6.3. 采样率（例如，48kHz）

7.3.6.4. 长度（例如10003s)

7.3.7. 大小

7.3.7.1. 据的大小描述了一个有效负载的字节数

7.3.7.2. 一个有效负载的大小范围可能是从单个字节到太字节，甚至更大

7.3.7.3. 一个超大的有效负载也可以被分割成若干个块，这可以有效地将有效负载的数据减少到较小的子段中

7.3.7.4. 分割是一种常见的做法，因为小文件更容易在网络上传输（特别是当它们被压缩后）

7.3.7.5. 较小的块文件被发送到目的存储，然后在所有数据到达后对它们进行重新组装

7.3.8. 模式和数据类型

7.3.8.1. 大多数数据的有效负载都有相应的模式，如表格和半结构化数据

7.3.8.2. 模式描述了字段和这些字段的数据类型

7.3.8.3. 模式不仅仅是针对数据库的

7.3.8.4. 大部分从源模式中获取数据的工作都发生在数据工程生命周期的转换阶段

7.3.8.5. 沟通是理解源数据的关键，数据工程师也有机会扭转沟通的方向，并帮助软件工程师优化数据产生的方式

7.3.8.6. 模式的变化经常发生在源系统中，而且往往不受数据工程师的控制

7.3.8.6.1. 添加一个新的列

7.3.8.6.2. 改变一个列的类型

7.3.8.6.3. 创建一个新的表

7.3.8.6.4. 重命名一个列

7.3.8.7. 越来越多的获取工具可以自动检测模式变化甚至自动更新目标表

7.3.8.7.1. 自动化是件好事，当数据发生变化时，依赖数据的分析师和数据科学家应该被告知对其工作的影响

7.3.8.8. 模式注册表

7.3.8.8.1. 在流数据中，每个消息都有一个模式，这些模式可能在生产者和消费者之间演变

7.3.8.8.2. 模式注册表是一个元数据存储库，用于在不断变化的模式面前保持模式和数据类型的完整性

7.3.8.8.3. 模式注册表还可以跟踪模式的版本和历史

7.3.8.8.4. 描述了消息的数据模型，允许生产者和消费者之间进行一致的序列化和反序列化

7.3.8.8.5. 大多数主要的数据工具和云平台都使用了模式注册表

7.3.8.9. 元数据

7.3.8.9.1. 元数据是关于数据的数据

7.3.8.9.2. 元数据和数据本身一样重要

7.3.8.9.3. 没有对数据的详细描述，它就可能没有什么价值

8.1. 推送策略涉及源系统向目标系统发送数据

8.2. 拉取策略则需要目标系统直接从源系统读取数据

8.3. 与拉取有关的模式是轮询

8.3.1. 轮询包括定期检查数据源的任何变化

8.3.2. 当检测到变化时，目标系统就会主动拉取数据