商业Hadoop发行版提供了来自Apache软件基础和其他地方的各种开源组件组合 - 这个想法是各种组件已集成到单个产品中，从而节省我们必须努力组装自己的集成组件。
除了开源软件外，供应商通常提供专有软件，支持，咨询服务和培训。

我们如何从可用的众多选项中选择Hadoop分发？
谈到设置自己的环境时，我们就是必须选择的人，并且选择应基于一系列标准来尽可能做出最佳决策。

并非所有Hadoop发行版都具有相同的组件(虽然它们都有Hadoop的核心函数)，但并非所有特定分发中的所有组件都与其他分布兼容。

选择最合适的分发的标准可以阐明为本一组重要问题：

• Hadoop你想实现什么？

• 如何使用Hadoop获得商业洞察力？

• 你想解决哪些业务问题？

• 将分析哪些数据？

• 我们是否愿意使用专有组件，或者我们更喜欢开源产品吗？

• 是Hadoop基础架构，我们是否考虑到所有用例都足够灵活？

• 我们想要与Hadoop集成的现有工具？

• 管理员是否需要管理工具？ (Hadoop的核心分布不包括行政工具。)

• 提供的提供我们是否会选择允许我们移动到不同的产品，没有供应商锁定等障碍物？ (不可转移到所有存储在专有格式的分发或者数据的应用程序代码代表了锁定的良好示例。)

• 我们考虑的分发是否会满足我们未来的需求，因为我们能够预测这些需求

比较分发的一种方法是创建一个函数矩阵 - 详细介绍了我们正在考虑的每个分发的规范和特征。
然后，选择可以依赖于最能解决特定业务问题的要求的函数和规格集。

另一方面，如果要求包括原型化和实验，则选择最新的Apache Hadoop发行版可能被证明是最好的方法。
最近的发布肯定有最新的最令人兴奋的函数，但如果你想要稳定，你不想兴奋。
对于稳定性，寻找一个足够长的较旧的释放分支以具有一些增量版本(这些通常包括错误修复和次要函数)。

每当我们考虑开源Hadoop发行版时，给出一瞬间的思想(或者也许很多时刻的思想)到开源保真度的概念 - 特定分布与它所取决于的开源组件兼容的程度。
高保真促进与其他符合这些开源组件兼容的产品的集成。
低保真度？
没那么多。

软件开发本身的开源方法是Hadoop计划的重要组成部分，因为它促进了与我们可以在我们自己的Hadoop部署中杠杆杠杆的大型第三方工具的兼容性。
开源方法也能够与Apache Hadoop社区接触，这反过来又为我们提供了挖掘更深层次的技能和创新的机会，以丰富Hadoop体验。

由于Hadoop是一种快速增长的生态系统，因此一些部件继续成熟，因为社区开发了符合行业需求的工具。
此演变的一个方面被称为backporting，我们可以在那里将新的软件修改或者修补程序应用于比修补程序适用的版本更旧的软件版本。

一个例子是nameNode故障转移：此函数是Hadoop 2的一部分，但是在Hadoop 2普遍可用之前，通过许多分布式向Hadoop-1的产品中被送回(其Beta表格)。

并非每一个分发都会积极地与相同程度的新内容进行主动，尽管大多数是用于错误修复的项目。
如果我们想要流放技术的生产许可证，这肯定是一种选择;然而，为了稳定，这不是一个好主意。

大多数Hadoop分布包括某种专有代码，它经常以安装人员和一组管理工具为单词。
这些分布通常来自不同的商业模式。

例如，一个商业模式可以通过这种方式概括："将自己作为一个开源领导者和先锋，使作为具有最佳专业知识，并将其作为服务的专业知识销售。
" Red Hat，Inc。
是使用此模型的供应商的示例。

与此方法相比，拥抱和扩展商业模式具有扩展开源软件函数的供应商构建函数。
Mapr和IBM，它都为Hadoop分布式文件系统(HDFS)提供替代文件系统，是很好的例子。

人们有时会错误地抛出这些创新的"叉子"标签，利用软件程序员使用的术语来描述某人将开源计划副本作为自己(独立)开发的起点的情况。

MapR和IBM提供的替代文件系统是完全不同的文件系统，而不是开源HDFS的叉子。
两家都支持客户选择其专有的分布式文件系统或者HDFS。
然而，在这种方法中，兼容性至关重要，供应商必须与不断变化的接口保持最新状态。
客户需要知道供应商可以依赖于支持他们的扩展。