分佈式計算和大數據市場，根據 , 每年以 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 是第一個獲得認證的虛擬化解決方案 .
如果您對細節感興趣，我們很樂意在評論中回答我們的問題。
來源： www.habr.com