草榴社区地址 读数据工程之说念: 遐想和构建健壮的数据系统14源系统
发布日期：2024-10-21 10:08 点击次数：81
草榴社区地址
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. 图数据库还不错处理事务用例草榴社区地址
