1.1. 云数据共享的核心概念是，多租户系统支持租户之间共享数据的安全策略

1.2. 任何具有细粒度权限系统的公有云对象存储系统都可以成为数据共享的平台

1.3. 数据共享也简化了数据市场的概念，在几个流行的云和数据平台上都可用

1.4. 数据共享还可以简化组织内的数据管道

1.5. 数据共享和数据网格与我们的通用架构组件的理念紧密结合

2.1. 技术的消费者化意味着每家公司现在基本上都是技术公司

2.2. 数据是有黏性的，通过允许将公司的数据集成和扩展到用户的应用中，就会产生一个巨大的推动

2.3. 副作用是现在几乎有无限的第三方数据来源

2.4. 第三方数据的直接访问通常是通过API、云平台上的数据共享，或数据下载来完成

3.1. 事件驱动架构在软件应用程序中无处不在

3.2. 消息队列

3.2.1. 消息队列是一种使用发布和订阅模式在离散系统之间异步发送数据（通常是小的单独消息，以千字节计）的机制

3.2.2. 消息队列允许应用程序和系统相互解耦，并被广泛用于微服务架构中

3.2.3. 消息队列对消息进行缓冲，以处理瞬时的负载高峰，并通过具有复制功能的分布式架构使消息持久

3.2.4. 消息队列是解耦微服务和事件驱动架构的一个关键要素

3.2.5. 消息队列需要注意的一些事项是交付频率、消息排序和可扩展性

3.2.5.1. 消息的排序和交付

3.2.5.1.1. 消息的创建、发送和接收顺序会对下游用户产生重大影响

3.2.5.1.2. 消息队列通常采用模糊的顺序概念或者先进先出(First In，First Out，FIFO)的概念

3.2.5.1.3. 除非你的消息队列技术保证，否则不要假设你的消息会按顺序交付

3.2.5.1.4. 通常需要以不按顺序的消息传递进行架构设计

3.2.5.2. 发送频率

3.2.5.2.1. 消息可以发送恰好一次，或至少发送一次

3.2.5.2.2. 如果消息被发送恰好一次，那么在订阅者确认消息后，消息就会消失，不会再被发送

3.2.5.2.3. 至少发送一次的消息可以被多个订阅者或同一订阅者多次使用

3.2.5.2.4. 系统应该是幂等的

3.2.5.2.4.1. 在一个幂等的系统中，处理一次消息的结果与多次处理消息的结果是相同的

3.2.5.3. 可扩展性

3.2.5.3.1. 在事件驱动的应用程序中使用的最流行的消息队列是横向可扩展的，这可以使事务在多个服务器上运行

3.2.5.3.2. 队列可以动态地扩大和缩小规模，在系统落后时缓冲消息，并且持久地存储消息以避免故障

3.2.6. 消息队列主要用于传导具有一定交付保证的消息

3.3. 事件流平台

3.3.1. 流数据（在这种情况下，消息和流）跨越了许多数据工程生命周期阶段

3.3.1.1. RDBMS通常直接连接到一个应用程序，而流数据的界限有时并不那么清晰

3.3.2. 同样的事件流平台可以在获取和转换阶段使用，为实时分析处理数据

3.3.3. 事件流平台是消息队列的延续，即消息从生产者提供给消费者

3.3.4. 事件流平台是用来获取和处理记录有序的数据的

3.3.5. 在事件流平台中，数据被保留一段时间，并且有可能从过去的时间点重放消息

3.3.6. 主题

3.3.6.1. 在一个事件流平台中，生产者将事件流向一个主题，即相关事件的集合

3.3.7. 流分区

3.3.7.1. 流分区是将一条消息流细分为多条流

3.3.7.2. 信息通过分区键分布在各分区中

3.3.7.3. 具有相同分区键的消息将总是在同一个分区中结束

3.3.7.4. 设置一个分区键，使应该一起处理的消息具有相同的分区键

3.3.7.5. 流分区的一个关键问题是确保你的分区键不会产生热点，即交付给一个分区的消息数量不平均

3.3.8. 容错性和弹性

3.3.8.1. 事件流平台是典型的分布式系统，数据流存储在不同的节点上

3.3.8.2. 如果一个节点坏了，另一个节点会取代它，而流仍然可以访问

3.3.8.2.1. 这意味着记录不会丢失

3.3.8.3. 当你需要一个能够可靠地产生、存储和获取事件数据的系统时，流媒体平台的容错性和弹性使它成为一个不错的选择

4.1. 系统和数据利益相关者

4.1.1. 数据利益相关者拥有并控制你对想要的数据的访问，一般由IT部门、数据治理小组或第三方处理

4.1.2. 系统和数据利益相关者通常是不同的人或团队

4.1.2.1. 可能是相同的

4.1.3. 在数据工程师和源系统的利益相关者之间建立一个反馈途径，促进源系统相关人员建立对数据如何被消费和使用的意识

4.2. 当上游源数据发生某种情况时，无论是架构或数据更改、服务器或数据库故障，还是其他重要事件，你需要意识到这些问题将对你的数据工程系统产生的影响

5.1. 数据契约是源系统所有者和从该系统获取数据的团队之间的书面协议

5.2. 契约应该说明获取什么数据、通过什么方法（完全、增量）、多长时间，以及谁（个人、团队）是源系统和获取的联系人

5.3. 数据合同应该存储在一个知名的、容易找到的地方

6.1. 安全

6.1.1. 安全是至关重要的

6.1.2. 最不希望的就是意外地在源系统中创造一个漏洞点

6.1.3. 源系统的架构是否对数据进行了安全和加密，包括静止的数据和传输中的数据？

6.1.4. 是否必须通过公共互联网访问源系统，或者你是否使用虚拟专用网络(Virtual Private Network，VPN)？

6.1.5. 将源系统的密码、令牌和凭证安全地锁起来

6.1.6. 信任源系统吗？

6.2. 数据管理

6.2.1. 只能对源系统和它们产生的数据进行外围控制

6.2.2. 上游数据和系统是否以可靠的、易于理解的方式进行管理？

6.2.3. 谁来管理这些数据？

6.2.4. 如何确保上游系统的数据质量和完整性？

6.2.5. 上游模式是可能发生变化的

6.2.6. 上游记录的创建是否由主数据管理实践或系统控制？

6.2.7. 是否能接触到原始数据，或者数据是否会被混淆？

6.2.8. 根据法规，你是否应该访问这些数据？

6.3. Data Ops

6.3.1. 确保你能观察和监控源系统的正常运行时间和使用情况，并在事件发生时做出反应

6.3.2. 在数据工程和支持源系统的团队之间建立一个清晰的沟通链

6.3.3. 将DevOps纳工作流和文化

6.3.3.1. 有助于实现DataOps（DevOps的一个兄弟姐妹）的目标，迅速解决和减少错误

6.3.4. 自动化

6.3.4.1. 自动源系统会受到自动化的影响，如代码更新和新功能化

6.3.4.2. 为你的数据工作流设置的DataOps自动化

6.3.5. 可观测性

6.3.5.1. 当源系统出现问题时，你如何得知

6.3.5.2. 设置检查以确保来自源系统的数据符合下游使用的期望

6.3.6. 事故响应

6.3.6.1. 如果有坏事发生，你有什么计划？

6.4. 数据架构

6.4.1. 与数据管理类似，除非你参与了源系统架构的设计和维护，否则你对上游源系统架构的影响很小

6.4.2. 应该了解上游架构是如何设计的，以及它的优势和劣势

6.4.3. 可靠性

6.4.3.1. 所有的系统在某些时候都会受到熵的影响，输出会偏离预期的内容

6.4.3.2. 漏洞被引入，随机故障发生

6.4.4. 持久性

6.4.4.1. 一切都会失败

6.4.5. 可用性

6.4.5.1. 如何保证源系统在它应该运行的时候是正常的、运行的、可用的？

6.4.6. 人员

6.4.6.1. 谁负责源系统的设计，你怎么知道架构中是否有突破性变化？

6.5. 编排

6.5.1. 确保你的编排能够访问源系统，这需要正确的网络访问、认证和授权

6.5.2. 节奏和频率

6.5.2.1. 数据是否按照固定的时间表提供，或者你是否可以随时访问新的数据？

6.5.3. 通用框架

6.5.3.1. 软件和数据工程师是否使用相同的容器管理器

6.6. 软件工程

6.6.1. 随着数据格局向简化和自动访问源系统的工具转变，你很可能需要写代码

6.6.2. 网络

6.6.2.1. 确保你的代码能够访问源系统所在的网络

6.6.3. 认证和授权

6.6.4. 访问模式

6.6.4.1. 如何访问数据的？

6.6.5. 编排

6.6.5.1. 代码是否与编排框架集成，并且可以作为编排工作流执行？

6.6.6. 并行化

6.6.6.1. 如何管理和扩展对源系统的并行访问的？

6.6.7. 部署

6.6.7.1. 如何处理源代码变化的部署的？

7.1. DevOps、DataOps、MLOps、XOps

7.2. 应该在整个栈上下延伸，并且支持数据工程和生命周期

7.3. 很理想，但往往不能完全实现

7.4. 源系统和它们的数据在数据工程的生命周期中是至关重要的

7.5. 软硬皆施

7.5.1. 与源系统团队更好的合作可以带来更高质量的数据、更成功的结果，以及更好的数据产品

7.6. 在数据工程中，主动沟通你的数据需求来帮助应用程序团队

7.7. 寻找机会来建立面向用户的数据产品