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

标题: 读数据工程之道：设计和构建健壮的数据系统07数据架构的原则 [打印本页]

作者: 冬雨财经 时间: 2024-10-13 09:10
标题: 读数据工程之道：设计和构建健壮的数据系统07数据架构的原则

1. 企业架构

1.1. 企业架构有很多子集，包括业务、技术、应用步伐和数据
1.2. TOGAF

1.2.1. The Open Group Architecture Framework，是The Open Group的一个标准
1.2.2. 被誉为当今利用最广泛的架构框架
1.2.3. 定义
1.2.3.1. “企业架构”上下文中的术语“企业”可以表现整个企业——包括其所有信息和技术服务、流程和底子办法——或企业内的一个特定领域
1.2.3.2. 架构都超过多个系统和企业内的多个职能部分

1.3. Gartner

1.3.1. 一家全球研究和咨询公司，撰写与企业相关的趋势研究文章和报告
1.3.2. 定义
1.3.2.1. 企业架构(EA)是一门学科，通过辨认和分析变动实行环境，实现预期业务愿景和结果，主动和全面地领导企业对粉碎性力量做出响应

1.4. EABOK

1.4.1. Enterprise Architecture Book of Knowledge
1.4.2. 一份由MITRE Corporation制作的企业架构参考资料
1.4.3. 定义
1.4.3.1. 企业架构是一种组织模型、一个企业的抽象表现，它和谐战略、运营和技术以创建乐成的蹊径图

1.5. 该书定义

1.5.1. 企业架构是支持企业变动的系统设计，通过仔细的权衡的评估做出灵活且可逆的决策来实现

1.6. 共同的主线

1.6.1. 变动
1.6.2. 对齐
1.6.3. 组织
1.6.4. 时机
1.6.5. 问题解决和迁移

1.7. 关键领域

1.7.1. 灵活和可逆的决
1.7.2. 变动管理
1.7.3. 权衡的评估

1.8. 单向门是一个几乎无法逆转的决策
1.9. 双向门是一个很轻易逆转的决策

1.9.1. 每个可逆决策（双向门）的风险都很低，因此组织可以做出更多决策、迭代、改进并快速网络数据
1.9.2. 变动管理与可逆决策密切相关，是企业架构框架的中央主题
1.9.3. 即使强调可逆决策，企业也常常必要采取重放肆措

1.10. 架构师不但是简单地规划IT流程，也不是模糊地展望遥远的乌托邦式未来

1.10.1. 积极解决业务问题并创造新的时机
1.10.2. 技术解决方案的存在不是为了它们自己，而是为了支持业务目标
1.10.3. 辨认当前状态下的问题（数据质量差、可扩展性限制、亏损的业务线），定义期望的未来状态（敏捷的数据质量改进、可扩展的云数据解决方案、改进的业务流程），并通过实行小而详细的步骤实现筹划

1.11. 数字系统终极会受到耽误、可靠性、密度和能耗等物理限制的约束

1.11.1. 修补软件错误比重新设计和更换飞机机翼要轻易得多
1.11.2. 工程师还面临各种非物理限制，如编程语言和框架的特性，以及管理复杂性、预算等方面的实际限制
1.11.3. 神奇的想法终极导致糟糕的工程
1.11.4. 数据工程师必须在设计最佳系统的每一步都进行权衡，同时最大限度地减少高息技术债

2. 数据架构

2.1. 架构代表了塑造系统的重要设计决策，其中重要的部分是通过变化的成本来衡量的
2.2. 乐成的数据工程建立在坚如磐石的数据架构之上

2.2.1. 数据架构是企业架构的一个子集，继承了它的属性：流程、计谋、变动管理和评估权衡
2.2.2. 好的数据架构提供了使数据生命周期的每一步和底层设计无缝衔接的能力
2.2.3. 数据工程架构是构成数据工程生命周期关键部分的系统和框架
2.2.3.1. 运行架构包含与人、流程和技术相关的功能需求

2.3. 定义

2.3.1. TOGAF定义
2.3.1.1. 对企业主要数据范例和泉源、逻辑数据资产、物理数据资产和数据管理资源的结构和交互的描述
2.3.2. DAMA的定义
2.3.2.1. 辨认企业的数据需求（无论结构如何）并设计和维护主蓝图以满意这些需求
2.3.2.2. 利用主蓝图来指导数据集成、控制数据资产并使数据投资与业务战略保持同等
2.3.3. 该书定义
2.3.3.1. 数据架构是系统设计，以支持企业不停变化的数据需求，由通过仔细评估权衡做出的灵活且可逆的决策来实现

2.4. 数据架构师的目标是做出重大决策，从而在底子层面上形成好的架构

2.4.1. 好的数据架构通过一组通用的、可广泛重用的构建块来满意业务需求，同时保持灵活性并做出适当的权衡

2.5. 好的数据架构

2.5.1. 敏捷性是好的数据架构的底子
2.5.1.1. 承认天下是活动的
2.5.1.2. 天下是动态的，数据空间的变化步伐正在加快
2.5.2. 好的数据架构是灵活且易于维护。它的发展是为了响应业务内部的变化，从而大概在未来释放更多代价的新技术和实践
2.5.3. 理想环境下，通过在设计架构时考虑到可逆性，变动的成本会更低
2.5.4. 好的数据架构是有生命力的
2.5.4.1. 变动和演进是数据架构意义和目的的核心

2.6. 糟糕的数据架构

2.6.1. 糟糕的数据架构是紧耦合的、僵化的、过分会合的，大概利用了错误的作业工具，阻碍了开发和变动管理

3. 2002年贝索斯API指令

3.1. 今后所有团队都将通过服务接口公开他们的数据和功能
3.2. 团队必须通过这些接口相互沟通
3.3. 不答应其他形式的进程间通信

3.3.1. 不答应直接连接
3.3.2. 不答应直接读取另一个团队的数据存储
3.3.3. 没有共享内存模型
3.3.4. 没有任何后门
3.3.5. 唯一答应的通信是通过网络的服务接口调用

3.4. 团队利用什么技术并不重要
3.5. 所有服务接口，无一例外，都必须重新开始设计为可外部化的

3.5.1. 团队必须进行规划和设计，才能将接口暴露给外界的开发者

3.6. 将数据和服务置于API之后实现了松耦合，并终极促成了我们现在所知道的AWS
4. AWS Well-Architected Framework

4.1. 卓越运营
4.2. 安全
4.3. 可靠性
4.4. 性能效率
4.5. 成本优化
4.6. 可持续性
5. 谷歌云的云原生架构

5.1. 主动化设计
5.2. 智能处理状态
5.3. 智能处理状态
5.4. 实行纵深防御
5.5. 始终进行架构设计
6. 原则1：明智地选择通用组件

6.1. 数据工程师的主要工作之一是选择可以在整个组织中广泛利用的通用组件和实践
6.2. 当架构师选择得当并领导有效时，通用组件就会成为促进团队协作和突破孤岛的结构
6.3. 通用组件可以是在组织内具有广泛适用性的任何东西
6.4. 常见组件包括对象存储、版本控制系统、可观测性、监控和编排系统，以及处理引擎
6.5. 每个有适当用例的人都应该可以访问通用组件，并且鼓励团队依靠已经在利用的通用组件，而不是重新发明轮子
6.6. 通用组件必须支持强大的权限和安全性，以实现团队之间的资产共享，同时防止未经授权的访问
6.7. 云平台是采用通用组件的理想场所
6.8. 选择通用组件是一种平衡行为

6.8.1. 必要关注整个数据工程生命周期和团队的需求，利用对单个项目有效的通用组件，同时促进互操作和协作
6.8.2. 架构师应该制止做出会阻碍工程师处理特定领域问题的生产力的决策，由于这些决策会迫使工程师采用一刀切的技术解决方案

7. 原则2：为失败做筹划

7.1. 只要经过足够的时间，任何硬件组件都会出现故障

7.1.1. 要构建高度健壮的数据系统，你必须在设计中考虑故障

7.2. 可用性

7.2.1. IT服务或组件处于可操作状态的时间百分比

7.3. 可靠性

7.3.1. 系统在指定时间隔断内实行其预期功能时满意规定标准的概率

7.4. 恢复时间目标

7.4.1. 服务或系统中断的最长可接受时间
7.4.2. 恢复时间目标(Recovery Time Objective，RTO)通常是通过确定故障对业务的影响来设置的

7.5. 恢复点目标

7.5.1. 恢复后的可接受状态
7.5.2. 恢复点目标(Recovery Point Objective，RPO)指的是可接受的最大数据丢失

7.6. 工程师在设计故障时必要考虑可接受的可用性、可靠性、RTO和RPO
8. 原则3：可扩展性架构

8.1. 可扩展系统可以放大以处理大量数据
8.2. 可扩展系统可以缩小

8.2.1. 一旦负载峰值下降，我们应该主动移除容量以降低成本
8.2.2. 一些可扩展系统也可以扩展到零：它们在不利用时完全关闭

8.3. 弹性系统可以动态扩展以响应负载，理想环境下以主动化方式进行

8.3.1. 许多无服务器系统[比方，无服务器函数和无服务器联机分析处理(Online Analytical Processing，OLAP)数据库]可以主动扩展到零

8.4. 部署不适当的扩展计谋大概会导致系统过于复杂和成本高昂
8.5. 具有一个故障转移节点的直接关系数据库大概更适合应用步伐而不是复杂的集群安排
8.6. 测量你当前的负载、估计负载峰值并估计未来几年的负载，以确定你的数据库架构是否符合
9. 原则4：架构是领导力

9.1. 强大的领导能力与高超的技术能力相团结是稀有且极其宝贵的
9.2. 领导力并不意味着对技术的命令-控制型方法

9.2.1. 过去，架构师选择一种专有数据库技术并强制每个团队将数据存放在那里的环境并不少见
9.2.2. 现代架构不应该是命令-控制型或瀑布式的，而是协作和敏捷的

9.3. 数据架构师拥有数据工程师的技术技能，但不再从事日常数据工程

9.3.1. 指导当前的数据工程师，在与他们的组织协商后做出谨慎的技术选择，并通过培训和领导力传播专业知识
9.3.2. 以最佳实践培训工程师，并将公司的工程资源整合在一起，以追求技术和业务方面的共同目标

9.4. 作为数据工程师，你应该实践架构领导力并寻求架构师的指导
10. 原则5：始终进行架构设计

10.1. 数据架构师的职责不仅仅是维护现有状态，相反，他们不停设计新的和令人兴奋的东西以应对业务和技术的变化
10.2. 架构师的工作是深入了解基线架构（当前状态），开发目标架构，并订定排序筹划以确定优先级和架构变化的顺序
10.3. 数据架构师维护随时间变化的目标架构和排序筹划

10.3.1. 目标架构成为一个移动的目标，根据内部和全球的业务和技术变化进行调整
10.3.2. 排序筹划确定交付的即时优先级

11. 原则6：构建松耦合系统

11.1. 技术特征

11.1.1. 系统被分解成许多小组件
11.1.2. 系统通过抽象层与其他服务对接
11.1.3. 对一个系统组件的内部改变不必要在其他部分进行修改
11.1.3.1. 代码更新的细节被隐藏在稳定的API后面
11.1.4. 整个系统没有瀑布式的全球发布周期

11.2. 组织特征

11.2.1. 许多小团队对一个大型的、复杂的系统进行设计
11.2.2. 团队通过API定义、消息模式等向其他团队发布其组件的抽象细节
11.2.2.1. 团队不必要关心其他团队的组件
11.2.2.2. 只是利用发布的API或消息规范来调用这些组件
11.2.2.3. 不必要团队去担心所请求的功能的内部技术细节
11.2.2.4. 团队通过松耦合的沟通方式一起工作
11.2.3. 每个团队都可以快速发展和改进自己的组件，不受其他团队工作的影响
11.2.4. 团队可以在最短的停机时间内发布组件更新

11.3. 技术和人的系统的松耦合将使你的数据工程团队可以或许更有效地相互协作，并与公司的其他部分协作
12. 原则7：做出可逆的决策

12.1. 数据格局正在迅速变化

12.1.1. 今天的热门技术或栈是明天的事后想法
12.1.2. 大众舆论迅速变化
12.1.3. 你应该以可逆决策为目标，由于这些决策往往会简化你的架构并保持其敏捷性

13. 原则8：优先考虑安全

13.1. 每个数据工程师都必须对其构建和维护的系统的安全性承担责任
13.2. 强化边界和零信任安全模型

13.2.1. 要了解传统的强化边界安全模型及其局限性
13.2.2. 在强化的组织安全边界利用人类目标的安全漏洞的威胁越来越大
13.2.3. 在云原生环境中，强化边界的概念被进一步减弱
13.2.3.1. 所有资产都在某种程度上与外界相连
13.2.3.2. 可以在没有外部连接的环境下定义假造私有云(Virtual Private Cloud，VPC)网络，但工程师用来定义这些网络的API控制面仍然面向互联网

13.3. 共同责任模型

13.3.1. 云的安全
13.3.2. 云中的安全
13.3.3. 所有云提供商都以某种形式的这种责任共担模型运作

13.4. 在当今的企业界，对安全采取命令和控制方法非常广泛，其中安全与网络团队管理边界和一般安全实践
13.5. 所有数据工程师都应该将自己视为安全工程师
13.6. 不承担这些新的隐性责任大概会导致可怕的后果
13.7. 数据处理的人员必须假设他们终极要对数据的安全负责
14. 原则9：拥抱FinOps

14.1. FinOps是一种不停发展的云财务管理学科和文化实践，通过帮助工程、财务、技术和业务团队协作订定数据驱动的支出决策，使组织可以或许得到最大的业务代价
14.2. 提倡DevOps和财务之间建立协作工作关系，从而促进对底子办法支出的迭代和数据驱动管理（即降低云的单元经济效益），同时提高成本效率以及终极提高云环境的红利能力
14.3. 在云时代，数据的成本结构发生了巨大变化

14.3.1. 责任方必须根据所需的计算和存储容量来平衡他们的预算
14.3.2. 过分购买意味着浪费资金，而购买不敷则意味着阻碍未来的数据项目，并导致人员花费大量时间来控制系统负载和数据巨细
14.3.3. 购买不敷大概必要更快的技术更新周期，以及相关的额外成本

14.4. 在云时代，大多数数据系统都是即付即得且易于扩展的

14.4.1. 系统可以在查询成本模型、处理能力成本模型或即付即得模型的另一种变体上运行
14.4.2. 数据领导者面临的新挑战是管理预算、优先级和效率

14.5. 云工具必要一组用于管理支出和资源的流程

14.5.1. 过去，数据工程师从性能工程的角度考虑，在一组固定的资源上最大化数据处理的性能，并购买足够的资源以满意未来的需求
14.5.2. 借助FinOps，工程师必要学会思考云系统的成本结构

14.6. FinOps改进了运营监控模型，以持续监控支出

14.6.1. FinOps不是简单地监控Web服务器的请求和CPU利用率，而是监控无服务器功能处理流量的持续成本，以及支出触发警报的峰值
14.6.2. 运营团队还应该考虑成本攻击

14.7. 在公开共享数据时，数据团队可以通过设置请求者付费政策来解决这些问题，大概简单地监控过分的数据访问支出，并在支出开始上升到不可接受的水平时迅速取消访问
14.8. 在遇到高昂的云费用之前尽早开始考虑FinOps

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

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