1.       开源软件

1.1.         开源软件(Open Source Software，OSS)是一种软件发行模式，在这种模式下，软件和底层代码库通常在特定的许可条款下可供普遍开发者使用

1.2.         社区管理的开源软件

• 1.2.1.           大部分开源软件项目都是社区管理的开源软件

• 1.2.2.           流行的开源软件项目社区拥有更多的全球开发人员的创新和贡献的比率

• 1.2.3.           心智份额

• 1.2.3.1.            避免采用没有吸引力和知名度的OSS项目

• 1.2.3.2.            参考GitHub星数、分叉数、提交量和回访率

• 1.2.4.           成熟度

• 1.2.4.1.            该项目已经存在了多长时间，现在有多活跃

• 1.2.5.           故障排除

• 1.2.5.1.            如果出现问题，你将如何处理？

• 1.2.5.2.            你是一个人去解决问题，还是有社区可以帮助你解决问题

• 1.2.6.           项目管理

• 1.2.6.1.            查看Git出现的问题及其解决方式

• 1.2.7.           团队

• 1.2.7.1.            是否有公司赞助开源软件项目？

• 1.2.7.2.            谁是核心贡献者？

• 1.2.8.           开发者关系和社区管理

• 1.2.8.1.            该项目正在做什么来鼓励促进被接纳和采用

• 1.2.9.           贡献

• 1.2.9.1.            是否鼓励并接受拉取请求？

• 1.2.10.      路线图

• 1.2.10.1.        是否清晰透明？

• 1.2.11.      自托管和维护

• 1.2.12.      回馈社会

• 1.2.13.      可以继续使用社区管理的开源软件版本，但你需要继续自己维护管理（更新、维护服务器/容器、错误修复的拉取请求等）​

1.3.         商业开源软件

• 1.3.1.           取决于开源应用程序，其需要的时间和精力可能是微不足道的，也可能是极其复杂并且烦琐的

• 1.3.2.           商业开源软件通常也属于社区开源软件项目

• 1.3.3.           你也可以向供应商付款，使用商业开源软件，让其为你承担管理所需要工作

• 1.3.4.           价值

• 1.3.4.1.            供应商来管理的价值是否更高？

• 1.3.5.           交付模式

• 1.3.5.1.            如何获取该服务？

• 1.3.5.2.            确保你可以轻松访问初始版本和后续版本

• 1.3.6.           技术支持

• 1.3.6.1.            技术支持的重要性不能被低估，而且对买家来说技术支持往往是不透明的

• 1.3.7.           发布和错误修复

• 1.3.8.           销售周期和定价

• 1.3.9.           公司财务

• 1.3.9.1.            公司有生存能力吗？

• 1.3.10.      影响力与收入

• 1.3.10.1.        公司是关注增加客户的数量（影响力）​，还是关注增加收入？

• 1.3.11.      社区支持

1.4.         云也提供自己的托管开源产品

2.       私有技术

2.1.         自主发行

• 2.1.1.           数据工具领域在过去几年呈指数级增长

• 2.1.2.           数据工具的公司的销售通常不会将产品作为开源软件发布，而是提供一个专有的解决方案

2.2.         互操作性

• 2.2.1.           确保该工具与你选择的其他工具（开源软件、其他自主发行、云产品等）能互通

2.3.         心智份额和市场份额

• 2.3.1.           该产品的解决方案受欢迎吗？

• 2.3.2.           在市场上占有一席之地吗？

• 2.3.3.           是否拥有积极的客户评价？

2.4.         文档和支持

2.5.         定价

2.6.         寿命

• 2.6.1.           公司能否生存足够长的时间让你从它的产品中获得价值？

3.       云平台产品

3.1.         云供应商开发和销售他们的专有服务，例如存储、数据库等更多的服务

3.2.         DynamoDB服务

• 3.2.1.           该服务现在是各种规模的公司使用的高成熟度的顶级产品

3.3.         云供应商通常会将产品捆绑在一起以更好地协同工作

• 3.3.1.           每个云都可以通过创建强大的集成来与其用户群建立黏性生态系统

3.4.         性能与价格比较

3.5.         购买注意事项

• 3.5.1.           按需定价可能很昂贵

• 3.5.2.           你能通过保留容量或者签订长期承诺协议来降低成本吗？

4.       单体与模块化

4.1.         单体与模块化系统是软件架构领域的另一个长期争论的问题

4.2.         评估单体与模块化选项时

• 4.2.1.           互操作性

• 4.2.1.1.            共享和互操作性的架构

• 4.2.2.           避免“空头陷阱”

• 4.2.2.1.            容易上手的事物可能会很痛苦或无法逃脱

• 4.2.3.           灵活性

• 4.2.3.1.            现在数据领域中的事物发展很快

• 4.2.3.2.            致力于单体模式会降低灵活性和决策的可逆性

5.       单体

5.1.         单体系统是独立的，通常执行单一系统下的多种功能

• 5.1.1.           单体倾向于简单化，一切功能都在一个地方

• 5.1.2.           对单个实体进行分析更容易，你可以更快迁移，因为需要改变的部件更少

5.2.         几十年来一直是技术支柱

• 5.2.1.           瀑布式的旧时代意味着软件发布是巨大的、紧密耦合的、并且步调平稳的

• 5.2.2.           单体数据系统一直延续到今天，老软件供应商（如Informatica）和开源框架（如Spark）仍然采用这种模式

5.3.         单体的优点是易于推理分析，只需要较低的认知和较少的上下文切换，因为一切都是独立的

5.4.         缺点

• 5.4.1.           单体很脆弱

• 5.4.1.1.            因为有大量的移动部件，更新和发布需要更长的时间，并且往往会变得烦琐

• 5.4.1.2.            如果一个系统有错误——但愿软件已经彻底通过发布前测试——它会损害整个系统

• 5.4.2.           用户引发的问题也会发生在单体应用中

• 5.4.2.1.            如果在任何地方有任何东西发生故障导致这个管道任务失败，整个过程不得不重新开始

• 5.4.3.           单体系统中的多租户也可能是一个严重的问题

• 5.4.3.1.            隔离多个用户的工作负载具有非常大的挑战性

• 5.4.3.2.            在本地数据仓库中，一个用户定义的函数可能会消耗许多的CPU以至于减慢其他用户的系统速度

• 5.4.4.           如果供应商倒闭或开源项目夭折，切换到一个新的系统会非常痛苦

• 5.4.4.1.            你所有的过程都包含在单体架构内，从那个系统中抽离出来，并进入一个新的平台，这在时间和金钱上的花费都是昂贵的

5.5.         单体系统中的依赖关系和资源争用之间的冲突是常见的问题

5.6.         虽然单体很有吸引力，因为它易于理解且减少了复杂性，但这是有高代价的

• 5.6.1.           它可能导致灵活性的丧失，机会成本和在开发周期里持续的高冲突

6.       模块化

6.1.         模块化倾向于采用解耦的、最佳组合技术执行它们独特的任务

• 6.1.1.           考虑到数据世界中产品的变化率，你应该追求在不断变化的一系列解决方案之间的互操作性

6.2.         是软件工程中的一个古老概念

• 6.2.1.           系统不再是依靠庞大的单体来处理需求，而是将系统和流程分解为相关的独立区域

• 6.2.2.           微服务可以通过API通信，这允许开发人员在制作应用程序时专注于他们的领域，同时其他微服务也可以访问

• 6.2.2.1.            这是软件工程的趋势，在现代数据系统中越来越流行

• 6.2.2.2.            大型科技公司一直是微服务的主要推动者

• 6.2.2.3.            著名的贝索斯API指令减少了应用程序之间的耦合，允许重构和分解

• 6.2.2.4.            贝索斯还实施了两个比萨原则（任何团队都不应大到两个比萨饼无法喂饱整个团队

>  6.2.2.4.1.             意味着团队最多有五名成员

>  6.2.2.4.2.             这个上限也限制了团队的责任和领域的复杂性——特别是它可以管理的代码库

6.3.         在模块化的微服务环境中，组件是可交换的，而且能够创建一个多语言（多编程语言）应用程序

• 6.3.1.           Java服务可以替代用Python编写的服务

• 6.3.2.           服务客户只需要考虑服务API的技术规范，而不是幕后细节如何执行

6.4.         数据处理技术通过对互操作性的强大支持转向模块化

• 6.4.1.           数据采用标准的格式（如Parquet格式）将对象存储存放在数据湖和数据湖仓中

• 6.4.2.           任何支持其格式的读取工具都可以读取数据并将处理后的结果由另一个工具写回数据湖中

• 6.4.3.           云数据仓库通过使用标准格式和外部表导入导出，支持与对象存储的互操作

• 6.4.3.1.            查询直接在数据湖中的数据中运行

6.5.         模块化允许工程师为每项工作或流程中的每一步挑选最佳的技术

6.6.         缺点

• 6.6.1.           模块化不再是关注和处理一个单一系统，现在你可能有无数系统需要了解和操作

• 6.6.2.           编排5～10个系统比编排一个系统要复杂得多

• 6.6.2.1.            编排变成将数据各类技术栈模块绑定在一起的黏合剂

7.       分布式单体模式

7.1.         分布式单体模式存在许多单体架构的局限性

7.2.         其基本思想是运行一个分布式系统来执行不同的任务

• 7.2.1.           服务和节点享有一套共同的依赖关系或共同的代码库

7.3.         一个标准示例是传统的Hadoop集群

• 7.3.1.           一个Hadoop集群可以同时托管多个框架

• 7.3.1.1.            Hive、Pig或Spark

• 7.3.2.           该集群具有许多内部依赖性

• 7.3.3.           集群还运行Hadoop核心组件

• 7.3.3.1.            Hadoop公共库、HDFS、YARN和Java

• 7.3.4.           一个集群对各种组件通常有一个版本

7.4.         标准的本地Hadoop系统需要管理一个公共环境，该环境适用于所有用户和所有作业

• 7.4.1.           强制现有任务升级依赖关系会有破坏环境的风险，而维持一个框架的两个版本会带来额外的复杂性

7.5.         分布式单体模式问题的一种解决方案是在云环境中使用临时的基础设施

• 7.5.1.           第二种解决方案是使用容器将分布式单体分解为多个软件环境