读数据工程之道：设计和构建结实的数据体系22获取阶段思量因素 ...

1. 有界限与无界限数据

1.1. 无界限数据是现实中存在的数据，是变乱发生时的数据，要么是间断的，要么是连续的、连续的和流动的
1.2. 有界限数据是超过某种界限（如时间）对数据进行归类的一种便捷方式

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

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

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

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

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. 同步获取与异步获取

3.1. 在同步获取的情况下，数据源、获取过程和写入目标有复杂的依赖关系并且是精密耦合的
3.2. 在异步获取的情况下，依赖关系如今可以体如今单个变乱的层面上，就像它们在由微服务构建的软件后端一样

• 3.2.1. 变乱一旦被获取，就会在存储中可用
  
• 3.2.2. 当变乱产生的速率变低并且管道中没有任何积压时，新增的变乱会快速通过管道
  

4. 序列化与反序列化

4.1. 序列化意味着对来自源头的数据进行编码，这种编码会作为传输和中间存储阶段的数据结构
4.2. 在获取数据时，要确保你的下游可以或许反序列化它所收到的数据
5. 吞吐量与可扩展性

5.1. 理论上讲，数据获取不应该是体系的瓶颈
5.2. 在实践中，数据获取瓶颈是相当常见的
5.3. 从那里获取数据是很告急的
5.4. 处理突发性数据获取的本领

• 5.4.1. 数据很少以恒定的速率天生，速率往往是起伏不定的
  
• 5.4.2. 体系需要内置的缓存来收集高峰期的变乱，以防止数据丢失
  
• 5.4.3. 存在体系扩展时起到桥梁作用，使存储体系在动态可扩展的体系中适应突发情况
  
• 5.4.4. 只要有可能，就利用托管服务来处理体系扩展问题
  

6. 可靠性与持久性

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. 有效负载

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. 模式的变化经常发生在源体系中，而且往往不受数据工程师的控制
  

1. >  7.3.8.6.1. 添加一个新的列
3. >  7.3.8.6.2. 改变一个列的类型
5. >  7.3.8.6.3. 创建一个新的表
7. >  7.3.8.6.4. 重命名一个列

复制代码

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

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

复制代码

• 7.3.8.8. 模式注册表
  

1. >  7.3.8.8.1. 在流数据中，每个消息都有一个模式，这些模式可能在生产者和消费者之间演变
3. >  7.3.8.8.2. 模式注册表是一个元数据存储库，用于在不断变化的模式面前保持模式和数据类型的完整性
5. >  7.3.8.8.3. 模式注册表还可以跟踪模式的版本和历史
7. >  7.3.8.8.4. 描述了消息的数据模型，允许生产者和消费者之间进行一致的序列化和反序列化
9. >  7.3.8.8.5. 大多数主要的数据工具和云平台都使用了模式注册表

复制代码

• 7.3.8.9. 元数据
  

1. >  7.3.8.9.1. 元数据是关于数据的数据
3. >  7.3.8.9.2. 元数据和数据本身一样重要
5. >  7.3.8.9.3. 没有对数据的详细描述，它就可能没有什么价值

复制代码

8. 推送、拉取与轮询模式

8.1. 推送策略涉及源体系向目标体系发送数据
8.2. 拉取策略则需要目标体系直接从源体系读取数据
8.3. 与拉取有关的模式是轮询

• 8.3.1. 轮询包括定期检查数据源的任何变化
  
• 8.3.2. 当检测到变化时，目标体系就会自动拉取数据
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。