ToB企服应用市场:ToB评测及商务社交产业平台

标题: 读数据工程之道：设计和构建结实的数据系统06底层设计（下） [打印本页]

作者: 涛声依旧在 时间: 2024-10-12 11:04
标题: 读数据工程之道：设计和构建结实的数据系统06底层设计（下）

1. 数据问责制

1.1. 数据问责制意味着分配一个人来管理一部门数据

1.1.1. 负责人和谐其他利益相干者的管理活动
1.1.2. 如果没有人对相干数据负责，那么管理数据质量就会很困难
1.1.3. 负责数据的人不一定是数据工程师
1.1.4. 负责人可能由软件工程师、产品经理或其他角色担任
1.1.5. 负责人通常不具备维护数据质量所需的所有资源
- 1.1.5.1. 他们与所有接触数据的人和谐，包括数据工程师

1.2. 数据问责制可以发生在各个层面

1.2.1. 问责制可以发生在表或日志流的级别，但也可以是与出现在多个表中的单个字段实体一样的细粒度级别

2. 数据质量

2.1. 数据质量是数据向抱负状态的优化
2.2. 数据工程师确保整个数据工程生命周期中的数据质量

2.2.1. 涉及执行数据质量测试，并确保数据符合模式预期、数据完整性和精度

2.3. 正确性

2.3.1. 收集到的数据是否真实？是否有重复值？数值正确吗？
2.3.2. 任何机器人生成的事件都被错误分类为人类存在的数据正确性问题，反之亦然

2.4. 完整性

2.4.1. 记录是否完整？所有必填字段都包含有效值吗？

2.5. 实时性

2.5.1. 记录是否实时可用？

2.6. 数据质量超过了人类和技术问题的边界

2.6.1. 数据工程师需要强盛的流程来收集有关数据质量的可操作的人工反馈，并利用技术工具在卑鄙用户看到之前先检测出质量问题

2.7. 主数据管理

2.7.1. 主数据是有关业务实体的数据，例如员工、客户、产品和位置
2.7.2. 主数据管理(Master Data Management，MDM)是构建同等的实体定义（称为黄金记录）的实践
- 2.7.2.1. 黄金记录和谐整个构造及其合作伙伴的实体数据
- 2.7.2.2. MDM是一种通过构建和部署技术工具来促进的业务运营流程

3. DataOps

3.1. DataOps将敏捷方法、DevOps和统计过程控制(Statistical Process Control，SPC)的最佳实践映射到数据

3.1.1. DevOps旨在提高软件产品的发布和质量
3.1.2. DataOps则针对数据产品也是做同样的事情

3.2. 数据产品与软件产品的区别在于数据的利用方式

3.2.1. 软件产品为终端用户提供特定的功能和技术特性
3.2.2. 数据产品是围绕合理的业务逻辑和指标建立的，其用户可以做出决议或构建执行主动化操作的模型

3.3. 数据工程师必须相识构建软件产品的技术方面以及将创建良好数据产品的业务逻辑、质量和指标
3.4. 实现

3.4.1. 快速创新和实行，以更快的速度为客户提供新的见解
3.4.2. 极高的数据质量和极低的错误率
3.4.3. 跨复杂的人员、技术和情况阵列进行协作
3.4.4. 结果的清晰丈量、监控和透明度

3.5. DataOps是一套文化习惯

3.5.1. 数据工程团队需要接纳与业务沟通和协作、打破孤岛、不停从成功和错误中学习以及快速迭代的循环
3.5.2. 只有这些文化习惯养成后，团队才气从技术和工具中获得最好的结果

3.6. DataOps具有三个核心技术要素：主动化、可观测性和监控以及事件相应

3.6.1. 发起首先从可观测性和监控开始，相识系统性能，然后添加主动化和事件相应

3.7. 主动化

3.7.1. 主动化可确保DataOps流程的可靠性和同等性，并答应数据工程师快速部署新产品功能和对现有工作流程进行改进
3.7.2. DataOps成熟度较低的构造通常会尝试利用cron作业来安排数据转换过程的多个阶段
3.7.3. 随着构造数据成熟度的增长，数据工程师通常会接纳编排框架，可能是Airflow或Dagster
3.7.4. 数据工程师意识到Airflow会带来操作负担，但编排的好处终极会凌驾其复杂性
3.7.5. 每个作业都可以在上游数据准备就绪后立即开始，而不是在固定的、预先确定的时间开始

3.8. “拥抱变化”

3.8.1. 并不意味着为了改变而改变，而是以目标为导向的改变

3.9. 可观测性和监控

3.9.1. 数据是一个无声的杀手
3.9.2. 可怕的故事是为报告创建数据的系统随机制止工作，导致报告耽误数天
- 3.9.2.1. 数据团队在利益相干者扣问为什么报告耽误或产生陈旧信息之前并不知情
- 3.9.2.2. 各个利益相干者对核心数据团队的能力失去了信任，开始了自己的分裂团队
- 3.9.2.3. 其结果是许多不同的不稳定系统、不同等的报告和孤岛
3.9.3. 如果你不观测和监控你的数据和生成数据的系统，你将不可制止地经历自己的数据可怕故事
3.9.4. 可观测性、监控、日志记录、警报和跟踪对于在数据工程生命周期中提前解决任何问题都是至关紧张的

3.10. 事件相应

3.10.1. 利用DataOps的高效数据团队将可以或许快速交付新的数据产品
3.10.2. 数据工程师必须为灾难做好准备，以尽可能迅速且有效地做出相应
3.10.3. 数据工程师应该在业务报告问题之前主动发现问题
- 3.10.3.1. 失败发生了，当利益相干者或终端用户看到问题时，他们会提出问题
3.10.4. 事件相应既是对事件的追溯相应，也是在事件发生之前主动解决事件

4. 数据架构

4.1. 数据架构反映了支持构造长期数据需求和战略的数据系统的当前和未来状态
4.2. 数据工程师应该首先相识业务需求并收集新用例的需求

4.2.1. 数据工程师需要将这些需求转化为设计新方法去捕获和提供数据，并在成本和操作简单性之间取得均衡
4.2.2. 并不意味着数据工程师就是数据架构师，因为两者通常是两个独立的角色

4.3. 如果数据工程师与数据架构师一起工作，则数据工程师应该可以或许交付数据架构师的设计并提供架构反馈
5. 编排

5.1. 编排不但是DataOps的核心流程，也是数据作业工程和部署流程的关键部门
5.2. 编排是和谐许多作业以尽可能快速且高效地按照预定节奏运行的过程
5.3. 答应编排系统在没有人为干预的情况下持续感知和监控，并随时运行在部署的新作业
5.4. 编排系统还构建作业历史记录功能、可视化和警报

5.4.1. 高级编排引擎可以在新的DAG或到DAG添加单个任务时回填

5.5. 编排不停是数据处理的关键功能，但除了大公司以外，通常不是最紧张的，也不是任何人都可以利用的
5.6. Apache Oozie在21世纪10年代非常盛行，但它是为在Hadoop集群中工作而设计的，很难在更加异构的情况中利用
5.7. Facebook在21世纪00年代后期开发了供内部利用的Dataswarm

5.7.1. 这激发了Airflow等盛行工具的灵感，Airbnb于2014年推出了该工具

5.8. Airflow从一开始就是开源的，并被广泛接纳

5.8.1. 它是用Python编写的，因此可以高度扩展到险些任何可以想象的用例
5.8.2. Airflow的到来恰逢数据处理变得更加抽象和易于访问，工程师们对和谐跨多个处理器和存储系统的复杂流程越来越感兴趣，尤其是在云情况中

5.9. 编排严格来讲是一个批处理的概念

5.9.1. 编排任务DAG的流式替代方案是流式DAG
5.9.2. 流式DAG的构建和维护仍然具有挑衅性，但Pulsar等下一代流式平台旨在显着减轻工程和运营负担

6. 软件工程

6.1. 软件工程不停是数据工程师的一项核心技能

6.1.1. 应该醒目软件工程以理解API、提取和转换数据、处理异常等

6.2. 核心数据处理代码仍然需要编写，并且贯穿于整个数据工程生命周期

6.2.1. 无论是在获取、转换还是数据服务方面，数据工程师都需要醒目和高效地利用Spark、SQL或Beam等框架和语言

6.3. 重点已经从直接的数据处理转移到抽象的阶梯上
6.4. 流数据处理本质上比批处理更复杂，而且工具和范式可以说还没有那么成熟

6.4.1. 随着流数据在数据工程生命周期的每个阶段变得越来越广泛，数据工程师面临着有趣的软件工程问题

6.5. 窗口化答应实时系统盘算有代价的指标，如尾随统计数据

6.5.1. 数据工程师有许多框架可供选择，包括用于处理单个事件的各种函数平台(OpenFaaS、AWS Lambda、Google Cloud Functions)或用于分析流以支持报告和实时处理的专用流处理器（Spark、Beam、Flink或Pulsar）

6.6. 基础设施即代码(Infrastructure as Code，IaC)将软件工程实践应用于基础设施的设置和管理
6.7. 流水线即代码是当今编排系统的核心概念，它涉及数据工程生命周期的每个阶段
6.8. 无论数据工程师接纳哪种高级工具，他们都会在整个数据工程生命周期中遇到非常情况，这些情况要求他们解决所选工具范围之外的问题并编写自定义代码

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

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)