读数据工程之道：设计和构建健壮的数据系统14源系统

2024-10-20 08:29 由躺柒发表于 #数据库

1. 源系统中的数据生成

1.1. 数据工程师的工作是从源系统获取数据，对其进行处理，使其有助于为下游用例提供服务

1.2. 数据工程师的角色将在很大程度上转向理解数据源和目的地之间的相互作用

1.3. 数据工程的最基本的数据管道任务——将数据从A移动到B

2. 数据源

2.1. 数据是无组织的、缺乏内容描述的事实和数据特征的集合

2.1.1. 模拟的
2.1.1.1. 模拟数据是在现实世界中生成的，例如语音、手语、纸上书写或演奏乐器
2.1.1.2. 模拟数据通常是瞬态的，如通常的口头对话，在对话结束后声音数据也就消失了
2.1.2. 数字的
2.1.2.1. 数字数据要么是通过将模拟数据转换为数字形式生成的，要么是数字系统直接生成的
2.1.2.2. 将模拟语音转换为数字文本的移动短信应用程序
2.1.2.3. 电子商务平台上的信用卡交易信息

2.2. 数据在我们周围的世界无处不在

2.2.1. 物联网设备、信用卡终端、望远镜传感器、股票交易等都在生成数据

3. 源系统

3.1. 源系统以各种方式生成数据

3.2. 文件和非结构化数据

3.2.1. 文件是字节序列，通常存储在磁盘上
3.2.2. 应用程序经常将数据写入文件
3.2.3. 文件可以存储本地参数、事件、日志、图像和音频
3.2.4. 文件是一种通用的数据交换媒介
3.2.5. 主要源文件格式类型（手动生成或源系统输出的文件）有Excel、CSV、TXT、JSON和XML
3.2.5.1. 结构化的(Excel、CSV)
3.2.5.2. 半结构化的(JSON、XML、CSV)
3.2.5.3. 非结构化的(TXT、CSV)

3.3. API

3.3.1. 应用程序接口是系统间交换数据的标准方式
3.3.2. API仍然存在许多针对数据的复杂性，需要工程师管理
3.3.3. 数据工程师也必须投入大量资金和相当多的精力用于维护自定义的API连接

3.4. 应用程序数据库（OLTP系统）

3.4.1. 应用程序数据库存储应用程序的状态
3.4.2. 应用程序数据库是联机事务处理系统
3.4.2.1. 以高速率读取和写入单个数据记录的数据库
3.4.2.2. OLTP系统通常被称为事务数据库，但这并不一定意味着所讨论的系统支持原子事务
3.4.2.3. OLTP数据库支持低延迟和高并发
3.4.2.4. 当成千上万甚至数百万用户可能同时与应用程序交互、同时更新和写入数据时，OLTP数据库可以很好地作为应用程序后端
3.4.3. OLTP系统不太适合由大规模分析驱动的用例，由于其单个查询也必须扫描大量数据
3.4.4. 小公司直接在OLTP上运行分析
3.4.4.1. 适用于短期但最终无法扩展

3.5. 联机分析处理系统

3.5.1. 联机分析处理系统是为运行大型分析查询而构建的，通常在处理单个记录的查找方面效率低下
3.5.2. OLAP来指代任何支持大规模交互式分析查询的数据库系统
3.5.3. OLAP的在线部分通过不断地监听传入的查询，使OLAP系统适合交互式分析

3.6. 变更数据捕获

3.6.1. 变更数据捕获是一种提取数据库中发生的每个变更事件（插入、更新、删除）的方法
3.6.2. CDC经常用于近乎实时地在数据库之间进行复制或为下游处理创建事件流
3.6.3. 关系数据库通常直接生成存储在数据库服务器上的事件日志，可以对其进行处理以创建一个流
3.6.4. 许多云端NoSQL数据库可以将日志或事件流发送到目标存储位置

3.7. 日志

3.7.1. 日志收集有关系统中发生的事件的信息
3.7.2. 日志是一个丰富的数据源，对下游数据分析、ML和自动化具有潜在价值
3.7.2.1. 操作系统
3.7.2.2. 应用程序
3.7.2.3. 服务器
3.7.2.4. 容器
3.7.2.5. 网络
3.7.2.6. 物联网设备
3.7.3. 所有日志都跟踪事件和其元数据
3.7.4. 日志应该记录谁、发生了什么和什么时候
3.7.4.1. 与事件关联的人员、系统或服务账户
3.7.4.2. 事件和相关元数据
3.7.4.3. 事件的时间戳
3.7.5. 日志编码
3.7.5.1. 二进制编码日志

>  3.7.5.1.1. 通过自定义的紧凑格式编码数据来提高空间效率和I/O速度

3.7.5.2. 半结构化日志

>  3.7.5.2.1. 被编码为对象序列化格式（JSON，也可能是其他）的文本

>  3.7.5.2.2. 半结构化日志是机器可读和可移植的

>  3.7.5.2.3. 效率远低于二进制日志

3.7.5.3. 纯文本（非结构化）日志

>  3.7.5.3.1. 存储从软件的控制台输出的日志

3.7.6. 日志分辨率
3.7.6.1. 日志以各种分辨率和日志等级创建
3.7.6.2. 日志分辨率是指一个日志中捕获的事件数据量
3.7.6.3. 捕获大数据系统中的所有数据变化通常是不切实际的
3.7.6.4. 日志等级是指记录一个日志条目所需的条件，具体涉及错误和调试信息
3.7.7. 日志延迟：批处理或实时
3.7.7.1. 批处理日志通常被连续写入一个文件
3.7.7.2. 将单个日志条目写入消息系统

3.8. 数据库日志

3.8.1. 预写日志
3.8.1.1. 以特定数据库的格式存储的二进制文件
3.8.1.2. 在数据库的保证和可恢复性中起着至关重要的作用
3.8.1.3. 确认伴随着与日志相关的保证：即使服务器出现故障，它也可以通过完成日志中未完成的工作来在重新启动时恢复其状态
3.8.2. 数据库日志在数据工程中非常有用，特别是利用CDC从数据库更改中生成事件流

3.9. CRUD

3.9.1. 代表创建、读取、更新和删除，是编程中常用的事务模式，代表持久化存储的四种基本操作
3.9.2. CRUD是在数据库中存储应用程序状态的最常见模式
3.9.3. CRUD的一个基本原则是数据必须在使用前创建

3.10. ⑩仅插入

3.10.1. 仅插入模式将历史记录直接保留在数据的表中
3.10.2. 新记录没有更新记录，而是插入了一个新的时间戳，指示它们的创建时间
3.10.3. 仅插入模式直接在表本身中维护数据库日志，如果应用程序需要访问历史记录，则这种模式特别有用
3.10.4. 仅插入模式的分析通常与常规CRUD应用程序表一起使用
3.10.5. 在仅插入模式ETL中，只要CRUD表中发生更新，数据管道就会在目标分析表中插入一条新记录
3.10.6. 缺点
3.10.6.1. 表可能会变得非常大，尤其是在数据频繁更改的情况下
3.10.6.2. 记录查找会产生额外的开销，因为查找当前状态涉及运行MAX(created_timestamp)

3.11. ⑾消息和流

3.11.1. 消息是在两个或多个系统之间通信的原始数据
3.11.1.1. 消息通常通过消息队列从一个发布者到一个消费者，一旦消息被传递，它就会从队列中移除
3.11.1.2. 在事件驱动系统中，消息是离散的单一信号
3.11.2. 流是事件记录的仅追加日志
3.11.2.1. 流被获取并存储在事件流平台中
3.11.2.2. 当事件发生时，它们会按时间戳或ID顺序累积
3.11.2.3. 在分布式系统下需要注意，事件并不总是按准确的顺序传递
3.11.2.4. 当你关心许多事件中发生的事情时，推荐使用流
3.11.2.5. 由于流的仅追加性质，流中的记录会保存很长时间（通常为数周或数月），从而允许对记录进行复杂的操作
3.11.2.6. 处理流的系统也可以处理消息，流平台经常用于消息传递
3.11.2.7. 当我们想要执行消息分析时，我们经常在流中累积消息

3.12. ⑿时间类型

3.12.1. 时间是所有数据获取的基本考虑因素，但在流处理的上下文中它变得更加关键和微妙，因为我们将数据视为连续数据并期望在生成后不久就使用它
3.12.2. 事件时间表示事件在源系统中何时产生，包括原始事件本身的时间戳
3.12.3. 在事件被下游获取和处理之前，会发生不确定的时间滞后
3.12.4. 事件经过的每个阶段的时间戳都需要被记录
3.12.5. 日志需要记录事件发生时以及每个阶段的时间（创建、获取和处理时间）
3.12.6. 时间戳日志可以准确跟踪数据在数据管道中的移动
3.12.7. 处理时间发生在获取时间之后，此时数据被处理（通常是转换）
3.12.8. 处理时长是处理数据所花费的时间，以秒、分钟、小时等为单位

4. ACID

4.1. 对原子事务的支持是数据库关键特征之一，统称为ACID

4.1.1. 原子性
4.1.1.1. 原子事务

>  4.1.1.1.1. 原子事务是在一个提交中有多个更改

4.1.2. 一致性
4.1.2.1. 一致性意味着数据库的任何读取检索都将返回最后写入版本
4.1.3. 隔离性
4.1.3.1. 隔离性意味着如果针对同一事物同时进行两个更新，则最终数据库状态将与这些更新的提交顺序一致
4.1.4. 持久性
4.1.4.1. 持久性表示提交的数据永远不会丢失，即使在停电的情况下也是如此

4.2. 支持应用程序后端不需要完全具备ACID特性，放宽这些限制可以大大提高性能和规模

4.3. 文档数据库集群可以通过降低一致性来获取更高的文档提交率

4.4. 图数据库还可以处理事务用例