读数据工程之谈：设想和构建健壮的数据系统03数据工程人命周期上

1. 数据工程人命周期

1.1. 数据规模正在履历新数据技艺和实践的爆炸式增长，空洞程度和易用性不休晋升

1.2. 由于技艺空洞程度的加多，数据工程师将越来越多地成为数据人命周期工程师，凭据数据人命周期照管的原则来进行念念考和操作

1.3. 数据工程人命周期包括将原始数据身分漂浮为有效的最终产物的阶段，可供分析师、数据科学家、机器学习工程师和其他东谈主使用

1.4. 五个阶段

1.4.1. 生成1.4.2. 存储1.4.3. 获取1.4.4. 转化1.4.5. 中间阶段1.4.5.1. 可能会有点芜乱1.4.6. 处事1.4.7. 人命周期的各个阶段可能会以道理和出东谈主预见的表情重复、无序、肖似或交汇在一谈

1.5. 当作基石的是横跨数据工程人命周期多阶段的底层设想

1.5.1. 安全1.5.2. 数据照管1.5.3. DataOps1.5.4. 数据架构1.5.5. 编排和软件工程1.5.6. 莫得这些底层设想，数据工程人命周期的任何部分都无法充分推崇作用

2. 数据人命周期

2.1. 数据工程人命周期是完竣数据人命周期的一个子集

2.2. 完竣的数据人命周期涵盖所有这个词人命周期中的数据，而数据工程人命周期则侧重于数据工程师按捺的阶段

3. 生成：源系统

3.1. 源系统是数据工程人命周期中使用的数据的开首

3.1.1. IoT开导3.1.2. 应用才能的音讯队伍3.1.3. 事务数据库

3.2. 数据工程师需要对源系统的责任表情、它们生成数据的表情、数据的频率和速率以及它们生成的数据的千般性有一个责任上的意会

3.2.1. 还需要与源系统所有者保捏绽放的同样渠谈，了解可能龙套管谈和分析的更正

3.3. 数据工程的一个主要挑战是工程师必须处理和意会令东谈主头晕眼花的数据源阵列

3.4. 跟着软件开发实践的各式当代演变，应用才能+数据库花式在今天仍然很流行

3.5. 源系统评估问题

3.5.1. 数据源的推行特征是什么？3.5.1.1. 它是一个应用才能，已经一个物联网开导集群？3.5.2. 数据怎么捏久化在源系统中？3.5.2.1. 数据是永久保存的，已经临时的并被速即删除？3.5.3. 数据生成的速率是若干？3.5.3.1. 每秒有若管事件？3.5.3.2. 每小时有若干数据量？3.5.4. 从输出数据中生机什么程度的一致性？3.5.4.1. 要是你对输出数据进行数据质料查验，数据不一致（数据空值、倒霉的体式等）的发生频率是若干？3.5.5. 造作发生的频率怎么？3.5.6. 数据会包含重复项吗？3.5.7. 某些数据是否会蔓延到达，是否会比同期生成的其他音讯晚许多？3.5.8. 获取数据的花式是什么？3.5.8.1. 是否需要跨多个表以致多个系统进行王人集才能获取数据的全貌？3.5.9. 要是数据结构发生变化（举例，添加了一个新列），怎么处理并传达给下流利益关系者？3.5.10. 应该多久从源系统中索求一次数据？3.5.11. 数据是否以如期快照或变更数据拿获(Change Data Capture，CDC)的更新事件提供？3.5.11.1. 扩充更正的逻辑是什么？3.5.11.2. 如安在源数据库中追踪这些更正？3.5.12. 将为下流消耗传输数据的数据提供者是谁/什么？3.5.13. 从数据源读取会影响其性能吗？3.5.14. 源系统是否有上游数据依赖？3.5.14.1. 上游系统的特色是什么？3.5.15. 是否进行了查验蔓延或丢失的数据的质料查验？

3.6. 数据源产生的数据供下流系统消耗，包括东谈主工生成的电子表格、物联网传感器以及蚁合和挪动应用才能

3.6.1. 每个开首都有其特有的数据生成量和节律3.6.2. 数据工程师应该知谈开首怎么生成数据，包括关系的怪癖或微弱死别

3.7. 源数据最具挑战性的微弱死别之一是花式

3.7.1. 无花式3.7.1.1. 无花式并不虞味着莫得花式3.7.1.2. 意味着应用才能在写入数据时界说花式，不管是写入音讯队伍、平面文献、blob已经文档数据库（如MongoDB）3.7.2. 固定花式3.7.2.1. 设置在关所有据库存储之上的更传统的模子使用数据库中强制扩充的固定花式，应用才能写入必须顺应该花式

3.8. 花式随期间变化

3.8.1. 事实上，在软件开发的敏捷方法中饱读舞花式演变

3.9. 在源系统花式中获取原始数据输入，并将其转化为有价值的分析输出

4. 存储

4.1. 采纳存储惩办有蓄意是在数据人命周期其余部分取得告成的关键，况且出于各式原因，它亦然数据人命周期中最复杂的阶段之一

4.1.1. 云上的数据架构无为应用多种存储惩办有蓄意4.1.2. 很少稀有据存储惩办有蓄意隧谈用作存储，许多营救复杂的转化查询，以致对象存储惩办有蓄意也可能营救弘远的查询功能4.1.3. 固然存储是数据工程人命周期的一个阶段，但它接续涉偏执他阶段，举例获取、转化和处事

4.2. 数据的存储表情会影响数据在数据工程人命周期的所有阶段中的使用表情

4.3. Apache Kafka和Pulsar等流式框架不错同期当作音讯的获取、存储和查询系统，对象存储是数据传输的方法层

4.4. 评估存储系统

4.4.1. 该存储惩办有蓄意是否与架构所需的写入和读取速率兼容？4.4.2. 存储是否会给下流历程变成瓶颈？4.4.3. 了解这种存储技艺的责任道理吗？4.4.3.1. 你是在最好地应用存储系统已经在作念出不当然的行动？4.4.3.2. 你是否在对象存储系统中应用了高速率的当场探望更新4.4.4. 该存储系统能否处理预期的将来范围？4.4.5. 下流用户和程度是否粗略在所需的处事等第协定(Service Level Agreement，SLA)中检索数据？4.4.6. 你是否正在拿获推测花式演变、数据流、数据血统等的元数据？4.4.7. 这是一个纯存储惩办有蓄意（对象存储），已经营救复杂的查询花式（即云数据仓库）？4.4.8. 存储系统是花式弗成知的（对象存储）吗？4.4.8.1. 生动的花式(Cassandra)吗？4.4.8.2. 是强制花式（云数据仓库）吗？4.4.9. 怎么追踪主数据、黄金纪录数据质料和数据血统以进行数据治理？4.4.10. 那处理规定坚信性和数据主权？4.4.10.1. 能否将数据存储在某些地舆位置而不是其他位置？

4.5. 数据探望频率

4.5.1. 并非所稀有据都以同样的表情探望4.5.2. 检索花式将因存储和查询的数据不同而有很大各异4.5.3. 数据探望频率将决定数据的温度4.5.3.1. 探望频率最高的数据称为热数据4.5.3.1.1. 热数据无为每天被检索屡次，以致每秒可能被检索几次4.5.3.2. 不温不火的数据可能会每隔一段期间探望一次4.5.3.3. 冷数据很少被查询，得当存储在存档系统中4.5.3.3.1. 出于合规办法或在另一个系统发生横祸性故障的情况下，无为会保留冷数据4.5.3.3.2. 在“畴昔”，冷数据将存储在磁带上并输送到辛苦档案设施4.5.3.3.3. 在云环境中，供应商提供专诚的存储层，每月存储资本终点便宜，但数据检索的价钱很高