读数据工程之道：设计和构建结实的数据系统14源系统 ...

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. 二进制编码日记
  

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

复制代码

• 3.7.5.2. 半布局化日记
  

1. >  3.7.5.2.1. 被编码为对象序列化格式（JSON，也可能是其他）的文本
3. >  3.7.5.2.2. 半结构化日志是机器可读和可移植的
5. >  3.7.5.2.3. 效率远低于二进制日志

复制代码

• 3.7.5.3. 纯文本（非布局化）日记
  

1. >  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. 原子事务
  

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. 图数据库还可以处理事务用例

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