1. 技术1.1. 关键决策是选择开源解决方案还是云服务提供商的产品1.2. 重要的软件框架Hadoop、Databricks和Snowflake1.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 Airflow2.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. IaaS5.1.2. CSP托管和管理硬件基础设施提供虚拟化的计算资源如服务器、存储和网络这些资源可以根据需要轻松扩展或缩减5.1.3. 客户负责操作系统、应用程序和数据5.1.4. 大多数服务都托管在虚拟机(VM)中终端用户将远程访问这些虚拟机5.1.5. 提供了更多的灵活性和可扩展性但仍需要一定水平的IT专业知识来管理操作系统、应用程序和数据架构5.2. 平台即服务5.2.1. PaaS5.2.2. 提供一个平台供开发者构建、测试和部署应用程序和数据库以及一个底层基础设施5.2.3. 包括开发工具、数据库管理系统和商业智能服务5.2.4. 控制运行时、中间件和操作系统环境—不再使用虚拟机5.2.5. 使得开发人员能够专注于编码和管理应用程序而不必担心管理平台和底层基础设施5.2.6. 模型比IaaS更抽象、更易于使用但在灵活性和可定制性方面有所限制5.2.7. 更倾向于在数据仓库中使用PaaS5.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. SaaS5.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 Azure5.4.1.1. 深度融入Microsoft生态系统的企业可能会倾向选择Azure5.4.2. Amazon Web Services5.4.2.1. 需要广泛服务的企业可能会选择AWS5.4.3. Google Cloud Platform5.4.3.1. 专注于高级数据处理的企业可能会选择GCP5.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还会对将数据从其云迁移到竞争对手的云中收取出口费用并且数据并不容易迁移到另一个CSP5.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的另一个区域而不是转移到另一个CSP5.5.6. 对于企业许可证协议(ELA)CSP会根据在其云中的消费承诺提供更高的折扣—使用得越多折扣越大5.5.6.1. 当加入基于层级的定价和持续使用折扣时可能通过只选择一个CSP来节省更多费用