读数据架构知识体系指南20技术(上)

读数据架构知识体系指南20技术(上)

1. 技术

1.1. 关键决策是选择开源解决方案，还是云服务提供商的产品

1.2. 重要的软件框架：Hadoop、Databricks和Snowflake

1.3. 记住数据技术的世界并不是非黑即白

2. 开源解决方案

2.1. 开源软件指的是免费发布且其源代码开放，任何人都可以查看、修改和分发的程序

2.2. 由一个团队共同开发，团队中的程序员贡献自己的知识和专业技术来创造和改进软件

2.3. 开源软件有着丰富的历史，源于20世纪80年代的自由软件运动

  • 2.3.1. 由理查德·斯托曼(Richard Stallman)领导，主张软件自由

2.4. 1998年成立的开源倡议(OSI)制定了“开源定义”​，并设立了OSS许可证的标准，确保软件保持自由、开放，任何人都可以使用

2.5. OSS项目包括MySQL、PostgreSQL、MongoDB、Apache Hadoop、Apache Spark、Apache Kafka、Presto和Apache Airflow

2.6. 许多数据架构使用OSS，但很少有完全依赖OSS的架构

2.7. 大多数架构将OSS与云服务提供商的产品结合使用

2.8. 在数据架构中引入OSS是值得考虑的

2.9. 原因

  • 2.9.1. 节省成本

  • 2.9.1.1. OSS通常是免费的，这使得它成为优化预算的组织的有吸引力的选择

  • 2.9.2. 灵活性和定制化

  • 2.9.2.1. OSS允许用户修改和定制源代码以满足特定需求

  • 2.9.3. 透明性和信任

  • 2.9.3.1. OSS的源代码是公开的，任何人都可以审查代码的安全性漏洞、缺陷和潜在后门

  • 2.9.3.2. 透明性促进了信任，并且为代码审查和改进提供了协作的环境

  • 2.9.4. 快速创新和协作

  • 2.9.4.1. OSS受益于全球开发者团队的贡献，他们为软件的改进提供专业知识

  • 2.9.4.2. 协作环境促进了快速的创新，加速了软件开发周期，从而产生了更可靠和功能更丰富的解决方案

  • 2.9.5. 供应商独立性

  • 2.9.5.1. 使用OSS，组织不依赖特定供应商或被专有软件绑定

  • 2.9.5.2. 组织有自由选择服务提供商，或根据需要定制软件

2.10. 缺陷

  • 2.10.1. 支持有限

  • 2.10.1.1. 与云服务提供商的软件不同，OSS可能没有专门的客户支持或服务级别协议

  • 2.10.2. 学习曲线和用户体验

  • 2.10.2.1. 使用OSS解决方案通常需要熟练的开发人员或技术人员来有效地实施、定制和维护

  • 2.10.3. 碎片化、标准化与兼容性

  • 2.10.3.1. 由于OSS开发的分布式性质以及大量OSS项目和版本的存在，编码风格、约定和方法几乎没有统一标准

  • 2.10.3.2. 可能导致碎片化，增加选择合适解决方案或确保不同OSS组件兼容性的难度、与现有系统的集成等方面可能需要更多的努力

  • 2.10.4. 安全性和责任

  • 2.10.4.1. 即使在全球社团的严格审查下，OSS中仍可能存在漏洞和缺陷

  • 2.10.4.2. 如果使用OSS，必须保持警惕，及时应用安全补丁和更新

  • 2.10.4.3. 如果用户的组织修改了OSS代码，用户将承担维护该定制版本的安全性和完整性的责任

  • 2.10.5. 项目维护的不确定性

  • 2.10.5.1. 并非所有的OSS项目都在积极开发或提供长期的维护

  • 2.10.5.2. 有时项目可能会停滞，更新或安全补丁较少

  • 2.10.6. 知识产权考虑

  • 2.10.6.1. 在使用或贡献OSS时，组织必须处理知识产权和许可义务

  • 2.10.6.2. 了解OSS许可证的条款和条件至关重要，以确保合规并避免法律问题

3. 内部部署解决方案

3.1. 原因

  • 3.1.1. 互联网连接缓慢或没有互联网

  • 3.1.2. 需要毫秒级的性能

  • 3.1.3. 将应用程序迁移到云会破坏第三方支持合同

  • 3.1.4. 与数据中心有长期的锁定租约，或刚刚购买了大量硬件设备

  • 3.1.5. 有大量的本地数据，需要迁移到云中，但云迁移管道限制太大，无法满足用户的报告需求

  • 3.1.6. 计划在不久的将来替换或下市应用程序和数据库

  • 3.1.7. 数据非常敏感

3.2. 限制

  • 3.2.1. 扩展性限制

  • 3.2.1.1. 本地解决方案的扩展性受到购买硬件的限制

  • 3.2.1.2. 如果必须使用某些供应商的设备，或者现有硬件存在兼容性问题，或者硬件供应商出现生产延迟，硬件可能成为限制因素

  • 3.2.1.3. 数据中心的物理空间也是有限的

  • 3.2.1.4. 当没有足够的空间再添加更多的服务器时，将面临两种非常昂贵的选择：扩展现有数据中心或建立另一个数据中心

  • 3.2.2. 前期成本高

  • 3.2.2.1. 购买本地解决方案所需的硬件需要大量的前期资本支出

  • 3.2.2.2. 硬件包括服务器硬件、用于容纳硬件的数据中心空间、额外的存储设备、防火墙、网络交换机、高速网络（带冗余）以访问数据、保持系统正常运行所需的电力和冗余电源供应，以及确保和备份数据的费用

  • 3.2.2.3. 如果数据仓库是关键任务系统，那么还需要配置灾难恢复站点，实际上将成本加倍

  • 3.2.2.4. 如果公司有自己的本地数据中心，那么他们实际上是在做空调生意，因为他们必须保持所有硬件的冷却

  • 3.2.2.5. 大多数公司更倾向于与云服务提供商合作，享受每年的运营费用

  • 3.2.3. 人员成本

  • 3.2.3.1. 将需要支付具有专业技术的员工或顾问，以便设置、管理、维护和支持硬件和软件，调整产品性能，并将产品和解决方案部署到生产环境中

  • 3.2.3.2. 当出现问题时，这可能会成为瓶颈，并且系统的责任依然掌握在客户手中，而非供应商

  • 3.2.4. 软件成本

  • 3.2.4.1. 组织通常需要支付数十万美元的软件许可费用，用于数据仓库软件和附加软件包，并且还需要支付许可费用，以便允许其他终端用户（如客户和供应商）访问数据

  • 3.2.4.2. 此类软件的年度支持合同费用通常是原始许可证费用的20%

4. 云提供商解决方案

4.1. 好处

  • 4.1.1. 可扩展性和灵活性

  • 4.1.1.1. 云服务提供商(CSP)软件设计上便于无缝扩展

  • 4.1.1.2. 可以动态地为存储和计算资源分配，满足峰值和稳定使用期间变化工作负载的需求，容量可以根据需求随时调整

  • 4.1.2. 成本

  • 4.1.2.1. 在云系统中，容量规划和管理的复杂性和成本都已内建、自动化，并由云订阅费用覆盖

  • 4.1.2.2. CSP还提供灵活的定价模式，因此只需支付实际使用的资源，从而优化成本

  • 4.1.2.3. 随着需求减少，可以减少硬件或选择无服务器选项

  • 4.1.2.4. 意味着可以快速构建解决方案，如果它不起作用，只需删除项目所使用的所有云资源

  • 4.1.2.5. 失败的成本大大降低，这意味着可以冒险并尝试新的事物

  • 4.1.2.6. 不需要为硬件、电力、建造和维护数据中心的人员，或开发自己的升级费用买单

  • 4.1.3. 易于部署和管理

  • 4.1.3.1. CSP软件通常提供集成的部署和管理工具，简化了设置和配置过程

  • 4.1.3.2. 简化了资源的供应、扩展、监控和维护任务，减少了运营开销

  • 4.1.3.3. 在数小时甚至几分钟内创建所需的所有云资源​，而在本地启动一个解决方案可能需要几周甚至几个月的时间

  • 4.1.4. 供应商支持和服务水平协议(SLA)

  • 4.1.4.1. 提供专门的支持和服务水平协议(SLA)，提供帮助、故障排除和保证服务可用性

  • 4.1.5. 集成生态系统

  • 4.1.5.1. CSP的软件与该供应商的其他服务可无缝集成

  • 4.1.5.2. 可以实现不同服务之间更轻松的集成和互操作性，并帮助用户充分利用供应商的各项服务功能

  • 4.1.6. 托管服务

  • 4.1.6.1. 通常处理软件基础设施的特定方面，例如托管数据库、机器学习服务或无服务器计算

  • 4.1.7. 持续创新和功能更新

  • 4.1.7.1. 定期推出新功能、服务和更新，用户可以从它们的创新中受益，而无须投资于升级或集成新功能

  • 4.1.8. 更容易招聘

  • 4.1.8.1. 使用CSP产品的用户数量庞大；相比之下，OSS的用户群体较小

  • 4.1.9. 全球可用性和高可用性

  • 4.1.9.1. CSP的数据中心分布在全球范围内，可以将软件部署到离目标用户更近的地方，或利用多区域冗余来提高高可用性

  • 4.1.9.2. CSP使用负载均衡将流量均匀分配到多个服务器，确保没有单个服务器过载而导致停机

  • 4.1.9.3. 全球基础设施确保了低延迟的服务，并具有容错能力

  • 4.1.9.4. 如果发生硬件或软件故障，服务将自动切换到备用实例，确保不中断、可靠的访问

  • 4.1.9.5. 可以在几分钟内为存储设置灾难恢复

  • 4.1.10. 安全性和合规性

  • 4.1.10.1. CSP在加密、访问控制和定期审计等安全措施方面进行了大量投资，以保护数据并确保符合行业标准和法规的要求

4.2. 总拥有成本(TCO)

  • 4.2.1. 所有的CSP都提供总拥有成本(TCO)计算器，可以利用它来估算将应用程序和数据库工作负载迁移到云时可能实现的成本节约

5. 云服务模型

5.1. 基础设施即服务

  • 5.1.1. IaaS

  • 5.1.2. CSP托管和管理硬件基础设施，提供虚拟化的计算资源，如服务器、存储和网络，这些资源可以根据需要轻松扩展或缩减

  • 5.1.3. 客户负责操作系统、应用程序和数据

  • 5.1.4. 大多数服务都托管在虚拟机(VM)中，终端用户将远程访问这些虚拟机

  • 5.1.5. 提供了更多的灵活性和可扩展性，但仍需要一定水平的IT专业知识来管理操作系统、应用程序和数据架构

5.2. 平台即服务

  • 5.2.1. PaaS

  • 5.2.2. 提供一个平台，供开发者构建、测试和部署应用程序和数据库，以及一个底层基础设施

  • 5.2.3. 包括开发工具、数据库管理系统和商业智能服务

  • 5.2.4. 控制运行时、中间件和操作系统环境—不再使用虚拟机

  • 5.2.5. 使得开发人员能够专注于编码和管理应用程序，而不必担心管理平台和底层基础设施

  • 5.2.6. 模型比IaaS更抽象、更易于使用，但在灵活性和可定制性方面有所限制

  • 5.2.7. 更倾向于在数据仓库中使用PaaS

  • 5.2.7.1. 不必处理虚拟机(VM)

5.2.7.1.1. 虚拟机存在于某个地方并托管数据库，但永远不需要远程连接到服务器或以任何方式管理它—可以通过CSP门户或第三方工具完成所有操作

  • 5.2.7.2. 不需要负责打补丁或升级：大多数CSP数据库都会在不中断服务的情况下进行打补丁

  • 5.2.7.3. 会得到数据库备份，无须再进行设置和监控

  • 5.2.7.4. PaaS使灾难恢复(DR)变得更加简单

  • 5.2.7.5. 大多数IaaS的DR解决方案设置和监控都很麻烦，但在PaaS中，基本上只需要选择希望DR数据库所在的区域

  • 5.2.7.6. CSP会负责设置和维护

5.3. 软件即服务

  • 5.3.1. SaaS

  • 5.3.2. 托管并完全管理软件和基础设施；客户通过互联网访问软件，不需要自行管理任何硬件或软件

  • 5.3.3. 是最简单、最容易使用的模型，但在定制和控制方面可能有限

  • 5.3.4. 提供的数据架构工具是“类似SaaS”的：即它们不像Salesforce那样完全托管，而需要进行一些轻微的应用程序管理

  • 5.3.5. 在任何云服务模型中，都可以使用最新版本的数据库产品

  • 5.3.6. 所有的CSP都提供内建的高级威胁检测功能，使用监控来检测可能表明异常且潜在有害的访问或利用数据库的活动

  • 5.3.6.1. 提供评估，帮助发现、跟踪并修复潜在的数据库漏洞

  • 5.3.6.2. 并为发现、分类、标记和报告数据库中的敏感数据提供高级功能

5.4. 主要云服务提供商

  • 5.4.1. Microsoft Azure

  • 5.4.1.1. 深度融入Microsoft生态系统的企业可能会倾向选择Azure

  • 5.4.2. Amazon Web Services

  • 5.4.2.1. 需要广泛服务的企业可能会选择AWS

  • 5.4.3. Google Cloud Platform

  • 5.4.3.1. 专注于高级数据处理的企业可能会选择GCP

5.5. 多云解决方案

  • 5.5.1. 许多组织在选择采用三大CSP中的一个，还是使用多个CSP服务之间进行权衡，这种方式通常称为“多云”方法

  • 5.5.2. 把所有的鸡蛋放在一个篮子里

  • 5.5.3. 担心CSP可能成为他们的竞争对手

  • 5.5.4. 好处

  • 5.5.4.1. 主要是可以利用各个CSP的优缺点

5.5.4.1.1. 如果一个CSP在延迟上更低，另一个CSP在可用性或灾难恢复方面表现更好，使用两个CSP可以提升组织满足SLA的能力

5.5.4.1.2. 如果一个CSP没有想要的所有功能，可以依赖另一个CSP来弥补

5.5.4.1.3. 这种差异化如今已不如以前那么明显

5.5.4.1.3.1. 如今，所有三大CSP的服务差异较小，许多功能和产品都非常相似

  • 5.5.4.2. 数据主权

5.5.4.2.1. 并非所有CSP都拥有相同的云区域，这对合规性尤为重要

  • 5.5.5. 缺点

  • 5.5.5.1. 云并非设计为互通，数据和计算的移动往返可能会很慢且烦琐

  • 5.5.5.2. 一个CSP的产品并不总是能与另一个CSP的产品兼容

  • 5.5.5.3. 将数据和应用从一个CSP迁移到另一个CSP，或者启动另一个产品可能会非常昂贵，尤其是如果需要重新设计应用程序以支持多个云

  • 5.5.5.4. CSP还会对将数据从其云迁移到竞争对手的云中收取出口费用，并且数据并不容易迁移到另一个CSP

  • 5.5.5.5. 对于人员管理，需要雇用和培训员工来理解两个或更多的云，这将大大增加成本

  • 5.5.5.6. 需要为安全问题进行不同的处理，使其能够协同工作

  • 5.5.5.7. 将有两个地方来添加、删除或更新用户，有两个地方需要监控，还有两个账单声明，这将增加显著的行政复杂性

  • 5.5.5.8. 拥有两个云服务提供商并不一定能避免停机

5.5.5.8.1. CSP专门设计了它们的网络，以确保一个区域的停机不会影响到其他区域

5.5.5.8.2. 灾难恢复解决方案应该是转移到同一CSP的另一个区域，而不是转移到另一个CSP

  • 5.5.6. 对于企业许可证协议(ELA)，CSP会根据在其云中的消费承诺提供更高的折扣—使用得越多，折扣越大

  • 5.5.6.1. 当加入基于层级的定价和持续使用折扣时，可能通过只选择一个CSP来节省更多费用

posted @ 2026-10-10 06:40  躺柒  阅读(12)  评论(0)    收藏  举报