分布式计算和大数据市场，根据 , 每年以 18-19% 的速度增长。 这意味着为这些目的选择软件的问题仍然很重要。 在这篇文章中，我们将从为什么需要分布式计算开始，我们将更详细地讨论软件的选择，我们将讨论将 Hadoop 与 Cloudera 结合使用，最后我们将讨论硬件的选择及其对性能的影响以不同的方式。
为什么我们在普通业务中需要分布式计算？ 一切都既简单又复杂。 简单 - 因为在大多数情况下，我们对每单位信息执行相对简单的计算。 困难——因为有很多这样的信息。 很多。 因此，必须 . 因此，用例非常普遍：可以在需要考虑更大数据阵列上的大量指标的任何地方应用计算。
最近的一个例子：Dodo Pizza 根据对客户订单基础的分析，当选择带有任意配料的比萨饼时，用户通常只使用六组基本配料和几组随机配料。 因此，比萨店调整了采购量。 此外，它能够更好地向用户推荐在订单阶段提供的额外产品，从而增加利润。
另一个例子： 商品使 H&M 将个别商店的商品种类减少了 40%，同时保持了销售水平。 这是通过排除销售不佳的头寸实现的，并且在计算中考虑了季节性因素。
工具选择
这种计算的行业标准是 Hadoop。 为什么？ 因为 Hadoop 是一个优秀的、文档齐全的框架（同一个 Habr 给出了许多关于这个主题的详细文章），它伴随着一整套实用程序和库。 您可以提交大量结构化和非结构化数据作为输入，系统本身将在计算能力之间分配它们。 此外，这些相同的容量可以随时增加或禁用——同样的水平可扩展性在起作用。
2017年，具有影响力的咨询公司Gartner Hadoop 很快就会过时。 原因很平庸：分析人士认为，公司将大规模迁移到云端，因为他们将能够根据计算能力的使用情况付费。 据称能够“埋没”Hadoop 的第二个重要因素是工作速度。 因为 Apache Spark 或 Google Cloud DataFlow 之类的选项比底层 Hadoop 的 MapReduce 更快。
Hadoop 依赖于几个支柱，其中最引人注目的是 MapReduce 技术（一种用于在服务器之间分发计算数据的系统）和 HDFS 文件系统。 后者专门用于存储分布在集群节点之间的信息：固定大小的每个块可以放置在多个节点上，并且由于复制，系统可以抵抗单个节点的故障。 使用称为 NameNode 的特殊服务器代替文件表。
下图显示了 MapReduce 的工作原理。 第一阶段，数据按照某种属性划分，第二阶段，按算力分布，第三阶段，进行计算。
MapReduce 最初是由 Google 出于其搜索的需要而创建的。 然后 MapReduce 进入免费代码，Apache 接管了该项目。 嗯，谷歌逐渐迁移到其他解决方案。 一个有趣的细微差别：目前，Google 有一个名为 Google Cloud Dataflow 的项目，定位为 Hadoop 之后的下一步，作为其快速替代品。
仔细观察就会发现，Google Cloud Dataflow 基于 Apache Beam 的一个变体，而 Apache Beam 包含有据可查的 Apache Spark 框架，这让我们可以谈论几乎相同的解决方案执行速度。 好吧，Apache Spark 在 HDFS 文件系统上运行良好，允许您将其部署在 Hadoop 服务器上。
在此处添加 Hadoop 和 Spark 针对 Google Cloud Dataflow 的大量文档和现成解决方案，工具的选择就变得显而易见了。 此外，工程师可以自行决定执行哪些代码（在 Hadoop 或 Spark 下），重点关注任务、经验和资格。
云端或本地服务器
普遍向云过渡的趋势甚至催生了 Hadoop 即服务这样一个有趣的术语。 在这种情况下，连接服务器的管理变得非常重要。 因为，唉，尽管它很流行，但纯 Hadoop 是一个相当难以配置的工具，因为您必须手动做很多事情。 例如，您可以单独配置服务器、监控它们的性能并微调许多参数。 一般来说，为业余爱好者工作，很有可能在某个地方搞砸或遗漏某些东西。
因此，各种发行版变得非常流行，它们最初配备了方便的部署和管理工具。 Cloudera 是支持 Spark 并使事情变得简单的更流行的发行版之一。 它有付费版和免费版 - 在后者中，所有主要功能都可用，并且不限制节点数量。
在安装过程中，Cloudera Manager 将通过 SSH 连接到您的服务器。 一个有趣的点：安装时，最好指定由所谓的执行 包裹：特殊包，每个包都包含配置为相互配合使用的所有必要组件。 事实上，这就是包管理器的改进版本。
安装后，我们会得到一个集群管理控制台，您可以在其中查看集群的遥测数据、已安装的服务，此外您还可以添加/删除资源和编辑集群配置。
于是，那枚火箭的切割出现在你的面前，它将带你走向大数据的光明前景。 但在我们说“走吧”之前，让我们快进到引擎盖下。
硬件要求
在他们的网站上，Cloudera 提到了不同的可能配置。 构建它们的一般原则如图所示：
MapReduce 可以模糊这幅乐观的图景。 再次查看上一节中的图表，很明显在几乎所有情况下，MapReduce 作业在从磁盘或网络读取数据时都会遇到瓶颈。 Cloudera 博客上也提到了这一点。 因此，对于任何快速计算，包括通过经常用于实时计算的 Spark，I/O 速度都非常重要。 因此，在使用 Hadoop 时，平衡且快速的机器进入集群非常重要，说得客气一点，云基础设施并不总是提供集群。
负载分配的平衡是通过在具有强大多核 CPU 的服务器上使用 Openstack 虚拟化来实现的。 数据节点分配有自己的处理器资源和某些磁盘。 在我们的决定中 Atos Codex 数据湖引擎 实现了广泛的虚拟化，这就是我们在性能（网络基础设施的影响最小化）和 TCO（消除了额外的物理服务器）方面都获胜的原因。
在使用 BullSequana S200 服务器的情况下，我们获得了非常均匀的负载，没有一些瓶颈。 最低配置包括 3 个 BullSequana S200 服务器，每个服务器有两个 JBOD，另外还可以选择连接包含四个数据节点的附加 S200。 以下是 TeraGen 测试中的示例负载：
不同数据量和复制值的测试在跨集群节点的负载分布方面显示出相同的结果。 下面是性能测试的磁盘访问分布图。
计算基于 3 个 BullSequana S200 服务器的最低配置。 它包括9个数据节点和3个主节点，以及在部署基于OpenStack虚拟化的保护的情况下预留的虚拟机。 TeraSort 测试结果：512 MB 的块大小，复制因子为 23,1，加密时为 XNUMX 分钟。
系统如何扩展？ Data Lake 引擎可以使用各种类型的扩展：
- 数据节点：每 40 TB 可用空间
- 能够安装GPU的解析节点
- 其他根据业务需求选择（比如你需要Kafka之类的）
Atos Codex Data Lake Engine 综合体包括服务器本身和预装软件，包括带有许可证的 Cloudera 套件； Hadoop 本身、带有基于 RedHat Enterprise Linux 内核的虚拟机的 OpenStack、数据复制和备份系统（包括使用备份节点和 Cloudera BDR - 备份和灾难恢复）。 Atos Codex Data Lake Engine 是第一个获得认证的虚拟化解决方案 .
如果您对细节感兴趣，我们很乐意在评论中回答我们的问题。
来源： habr.com