IT评测·应用市场-qidao123.com技术社区

标题: 读数据工程之道：设计和构建结实的数据体系16源体系实际细节（下） [打印本页]

---

作者: 半亩花草    时间: 2024-10-22 10:25
标题: 读数据工程之道：设计和构建结实的数据体系16源体系实际细节（下）

1. 数据共享

1.1. 云数据共享的核心概念是，多租户体系支持租户之间共享数据的安全战略
1.2. 任何具有细粒度权限体系的公有云对象存储体系都可以成为数据共享的平台
1.3. 数据共享也简化了数据市场的概念，在几个流行的云和数据平台上都可用
1.4. 数据共享还可以简化组织内的数据管道
1.5. 数据共享和数据网格与我们的通用架构组件的理念紧密联合
2. 第三方数据源

2.1. 技术的消费者化意味着每家公司现在基本上都是技术公司
2.2. 数据是有黏性的，通过允许将公司的数据集成和扩展到用户的应用中，就会产生一个巨大的推动
2.3. 副作用是现在几乎有无限的第三方数据来源
2.4. 第三方数据的直接访问通常是通过API、云平台上的数据共享，或数据下载来完成
3. 消息队列和事件流平台

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. 和谁一起工作

4.1. 体系和数据长处相干者

• 4.1.1. 数据长处相干者拥有并控制你对想要的数据的访问，一般由IT部分、数据管理小组或第三方处理
  
• 4.1.2. 体系和数据长处相干者通常是不同的人或团队
  
  
  
  • 4.1.2.1. 可能是雷同的
    
  
  
• 4.1.3. 在数据工程师和源体系的长处相干者之间建立一个反馈途径，促进源体系相干职员建立对数据如何被消费和使用的意识
  

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

5.1. 数据契约是源体系全部者和从该体系获取数据的团队之间的书面协议
5.2. 契约应该阐明获取什么数据、通过什么方法（完全、增量）​、多长时间，以及谁（个人、团队）是源体系和获取的联系人
5.3. 数据条约应该存储在一个知名的、轻易找到的地方
6. 数据底层设计及其对源体系的影响

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. 卓越运营

7.1. DevOps、DataOps、MLOps、XOps
7.2. 应该在整个栈上下延伸，而且支持数据工程和生命周期
7.3. 很理想，但往往不能完全实现
7.4. 源体系和它们的数据在数据工程的生命周期中是至关重要的
7.5. 软硬皆施

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

7.6. 在数据工程中，主动沟通你的数据需求来资助应用程序团队
7.7. 寻找机会来建立面向用户的数据产品

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

---

欢迎光临 IT评测·应用市场-qidao123.com技术社区 (https://dis.qidao123.com/)

Powered by Discuz! X3.4