Cloudera の特別な点とその調理方法

によると、分散コンピューティングとビッグデータの市場 統計、年間18〜19％で成長しています。 これは、これらの目的のためにソフトウェアを選択するという問題が依然として重要であることを意味します。 この投稿では、分散コンピューティングが必要な理由から始め、ソフトウェアの選択について詳しく説明し、Cloudera での Hadoop の使用について説明し、最後にハードウェアの選択とそれがパフォーマンスに与える影響について説明します。さまざまな方法で。

通常のビジネスにおいてなぜ分散コンピューティングが必要なのでしょうか? すべては単純であると同時に複雑でもあります。 シンプル - ほとんどの場合、情報単位ごとに比較的単純な計算を実行するためです。 難しいのは、そのような情報がたくさんあるからです。 とてもたくさんあります。 結果として、それは、 1000 スレッドでテラバイトのデータを処理する。 したがって、ユースケースは非常に汎用的であり、さらに大きなデータ配列で多数のメトリックを考慮する必要がある場合はどこにでも計算を適用できます。

最近の例: ドドピザ 定義済み 顧客の注文ベースの分析に基づくと、ユーザーは通常、任意のトッピングのピザを選ぶとき、XNUMX つの基本的な材料セットと XNUMX つのランダムな材料セットだけを使用して操作します。 これに応じてピッツェリアは仕入れを調整した。 さらに、注文段階で提供された追加商品をユーザーにより適切に推奨できるようになり、利益が増加しました。

別の例： анализ 商品のおかげで、H&M は売上の水準を維持しながら、個々の店舗の品揃えを 40% 削減することができました。 これは、売れ行きの悪いポジションを除外することで達成され、計算では季節性が考慮されました。

ツールの選択

この種のコンピューティングの業界標準は Hadoop です。 なぜ？ なぜなら、Hadoop は優れた十分に文書化されたフレームワークであり (同じ Habr がこのトピックに関する詳細な記事を多数公開しています)、ユーティリティとライブラリのセット全体が付属しているからです。 構造化データと非構造化データの両方の巨大なセットを入力として送信でき、システム自体がそれらをコンピューティング能力間で分散します。 さらに、これらの同じ容量はいつでも増加または無効にすることができ、同じ水平方向のスケーラビリティが動作します。

2017 年、影響力のあるコンサルティング会社 Gartner 終わったHadoop は間もなく廃止されるでしょう。 その理由はかなり平凡です。アナリストは、企業はコンピューティング能力の使用に基づいて料金を支払うことができるため、クラウドに大規模に移行すると考えています。 Hadoop を「埋める」ことができると考えられる XNUMX 番目の重要な要素は、作業速度です。 Apache Spark や Google Cloud DataFlow などのオプションは、基盤となる Hadoop の MapReduce よりも高速であるためです。

Hadoop はいくつかの柱に基づいています。その中で最も注目に値するのは、MapReduce テクノロジ (サーバー間で計算用のデータを分散するシステム) と HDFS ファイル システムです。 後者は、クラスター ノード間で情報を分散して保存するように特に設計されています。固定サイズの各ブロックを複数のノードに配置でき、レプリケーションのおかげで、システムは個々のノードの障害に耐性があります。 ファイル テーブルの代わりに、NameNode と呼ばれる特別なサーバーが使用されます。

以下の図は、MapReduce がどのように機能するかを示しています。 第 XNUMX 段階では、データは特定の属性に従って分割され、第 XNUMX 段階では計算能力によって分散され、第 XNUMX 段階では計算が行われます。

MapReduce はもともと Google によって検索のニーズのために作成されました。 その後、MapReduce はフリー コードになり、Apache がプロジェクトを引き継ぎました。 Google は徐々に他のソリューションに移行してきました。 興味深いニュアンスです。現在、Google には、Google Cloud Dataflow と呼ばれるプロジェクトがあり、Hadoop の次のステップとして、その迅速な代替として位置付けられています。

詳しく見ると、Google Cloud Dataflow は Apache Beam のバリエーションに基づいていることがわかりますが、Apache Beam には十分に文書化された Apache Spark フレームワークが含まれており、これによりソリューションの実行速度はほぼ同じになります。 Apache Spark は HDFS ファイル システム上で正常に動作するため、Hadoop サーバーにデプロイできます。

ここに、Google Cloud Dataflow に対する Hadoop と Spark の大量のドキュメントと既製のソリューションを追加すると、ツールの選択が明確になります。 さらに、エンジニアは、タスク、経験、資格に重点を置いて、Hadoop または Spark でどのコードを実行するかを自分で決定できます。

クラウドまたはローカルサーバー

クラウドへの一般的な移行の傾向により、Hadoop-as-a-service などの興味深い用語さえ生まれました。 このようなシナリオでは、接続されたサーバーの管理が非常に重要になります。 なぜなら、悲しいことに、その人気にもかかわらず、純粋な Hadoop は手動で多くのことを行う必要があるため、設定がかなり難しいツールだからです。 たとえば、サーバーを個別に構成し、そのパフォーマンスを監視し、多くのパラメーターを微調整できます。 一般に、アマチュアの仕事では、どこかで失敗したり、何かを見落としたりする可能性が大いにあります。

そのため、便利な導入ツールや管理ツールが最初から備わっているさまざまなディストリビューションが非常に人気になっています。 Spark をサポートし、作業を容易にする最も人気のあるディストリビューションの XNUMX つは Cloudera です。 有料バージョンと無料バージョンの両方があり、後者では、ノード数の制限なく、すべての主要な機能を利用できます。

セットアップ中に、Cloudera Manager は SSH 経由でサーバーに接続します。 興味深い点: インストールするときは、いわゆる 小包: 特別なパッケージ。それぞれには、相互に動作するように構成された必要なコンポーネントがすべて含まれています。 実際、これはパッケージ マネージャーの改良版です。

インストール後、クラスター管理コンソールが表示され、クラスターのテレメトリ、インストールされているサービスを確認できるほか、リソースの追加/削除、クラスター構成の編集が可能です。

その結果、そのロケットの切断面が目の前に現れ、BigDataの輝かしい未来へとあなたを導きます。 しかし、「行きましょう」と言う前に、ボンネットの下で早送りしてみましょう。

ハードウェア要件

Cloudera は Web サイトで、可能なさまざまな構成について言及しています。 それらが構築される一般原則を図に示します。

MapReduce を使用すると、この楽観的な状況がぼやけてしまう可能性があります。 前のセクションの図をもう一度見ると、ほとんどの場合、ディスクまたはネットワークからデータを読み取るときに MapReduce ジョブがボトルネックに遭遇する可能性があることがわかります。 これは Cloudera ブログにも記載されています。 その結果、リアルタイム計算によく使用される Spark を含む高速計算では、I/O 速度が非常に重要になります。 したがって、Hadoop を使用する場合は、バランスの取れた高速なマシンをクラスターに組み込むことが非常に重要ですが、控えめに言っても、クラウド インフラストラクチャには必ずしもそれが提供されているわけではありません。

負荷分散のバランスは、強力なマルチコア CPU を搭載したサーバー上で OpenStack 仮想化を使用することで実現されます。 データ ノードには、独自のプロセッサ リソースと特定のディスクが割り当てられます。 私たちの決定では Atos Codex データレイク エンジン 広範な仮想化が実現されるため、パフォーマンス (ネットワーク インフラストラクチャへの影響が最小限に抑えられる) と TCO (余分な物理サーバーが排除される) の両方の点で当社が勝利を収めています。

BullSequana S200 サーバーを使用する場合、いくつかのボトルネックがなく、非常に均一な負荷が得られます。 最小構成には、それぞれ 3 つの JBOD を備えた 200 台の BullSequana S200 サーバーが含まれており、さらにオプションで XNUMX つのデータ ノードを含む追加の SXNUMX が接続されます。 TeraGen テストでの負荷の例を次に示します。

異なるデータ量とレプリケーション値を使用したテストでは、クラスター ノード間の負荷分散という点では同じ結果が示されます。 以下は、パフォーマンス テストによるディスク アクセスの分布のグラフです。

計算は、3 台の BullSequana S200 サーバーの最小構成に基づいています。 これには、9 つ​​のデータ ノードと 3 つのマスター ノードに加え、OpenStack Virtualization に基づく保護を導入する場合の予約済み仮想マシンが含まれます。 TeraSort テスト結果: 暗号化を使用したレプリケーション係数 512 の 23,1 MB ブロック サイズは XNUMX 分です。

どうすればシステムを拡張できるのでしょうか？ Data Lake Engine では、さまざまな種類の拡張機能を使用できます。

• データノード: 40 TB の使用可能なスペースごと
• GPUをインストールできる分析ノード
• ビジネス ニーズに応じたその他のオプション (たとえば、Kafka などが必要な場合)

Atos Codex Data Lake Engine 複合体には、サーバー自体と、ライセンス付きの Cloudera キットを含むプレインストールされたソフトウェアの両方が含まれています。 Hadoop 自体、RedHat Enterprise Linux カーネルに基づく仮想マシンを備えた OpenStack、データ レプリケーションおよびバックアップ システム (バックアップ ノードおよび Cloudera BDR の使用を含む - バックアップと災害復旧)。 Atos Codex Data Lake Engine は認定された最初の仮想化ソリューションです クルデラ.

詳細にご興味がございましたら、コメント欄でご質問にお答えいたします。

出所： habr.com