JD.com の 10,000 台のマシンからなる Hadoop クラスター |分散リソース管理とジョブスケジューリング

JD.com が数万台のマシン規模で Hadoop を構築したいのはなぜでしょうか?

JD.com のビジネスが拡大するにつれ、元の Hadoop クラスターでは急速に増大するストレージとコンピューティングのニーズに対応できなくなりました。クラスターを分割すると、ある程度の負荷を分散できますが、他の問題も発生します。たとえば、クラスターを分割した後にビジネスで別のクラスターからのデータが必要になる場合、クラスター間でのデータの読み取りの問題が発生し、ジョブ実行の効率に重大な影響を及ぼします。一方、各クラスターには常にアイドル時間とビジー時間が存在します。クラスターがアイドル状態の場合、これらのリソースは無駄になり、価値は生成されません。

生産効率を高め、コストを節約するためには、これまでさまざまな場所に分散していたクラスタリソースの管理を一元化し、超大規模クラスタを形成して外部にサービスを提供し、さまざまな並列フレームワークがそのストレージとコンピューティングリソースを業務処理に利用できるようにする必要があります。

Hadoop の概要

ビッグデータ処理プラットフォームとしてのHadoopには10年以上の歴史があります。設計のアイデアは、安価なデスクトップ コンピューターを使用して、分散コンピューティングとデータ ストレージ用の大規模なクラスターを形成し、冗長バックアップを使用してデータのセキュリティと高可用性を確保し、並列コンピューティングによって超大規模データ セットの高速処理を完了することです。

ノードを追加することで、Hadoop クラスターのコンピューティング機能とストレージ機能を向上させます。通常、分散並列モードでデータを処理する場合、コンピューティング コードを移動するコストはデータを移動するコストよりも低くなります。したがって、Hadoop の MapReduce フレームワークは、データの局所性とネットワークの相互作用の減少を利用して、コンピューティング コードを各データ ノードに分散して実行し、パフォーマンスを向上させます。

Hadoop 2.0 より前の Hadoop は、2 つの部分で構成されるように設計されていました。最初の部分は分散ストレージ HDFS で、もう 1 つの部分は MapReduce コンピューティング フレームワークでした。 Hadoop 2.0 以降、コンピューティング フレームワークは最適化され、アップグレードされて、現在使用されている YARN (Yet Another Resource Negotiator) になりました。 YARN は、分散リソース管理とジョブ スケジューリング機能を提供し、統一されたプログラミング モデルも提供します。このプログラミング モデルを通じて、多くのコンピューティング フレームワークを YARN に移行できます。

ビジョンの面では、Hadoop は複雑なデータの処理と計算の解決、構造化データと非構造化データのストレージの処理、大量データの分散並列処理の提供に取り組んでいます。

振り返ってみると、分散処理プログラムを実装するために MPI と OpenMP を使用しました。当時は、プログラムのリモート起動と停止を自分たちで制御し、フォールトトレラントなコードを自分たちで書く必要がありました。現在、Hadoop は、これらの煩雑で多用途な機能を最適化と抽象化によってフレームワークにカプセル化しており、開発者はエラー再試行や通信関連のコードを書く必要がなく、独自のビジネス ロジック コードのみに集中できるため、開発効率が大幅に向上しています。同時に、コードを書くのがあまり得意ではないデータエンジニアでも、Hadoop クラスターを使用して独自の分散処理および分析プログラムを簡単に実装できます。

Hadoop 2.0 YARN アーキテクチャには、主に次のコンポーネントがあります。

1. ResourceManager: ノード情報を維持し、リソース管理とジョブのスケジュールを管理するマスター ノード サービス。 2台のマシンに導入でき、Zookeeperを使用して高可用性を実現できます。

2. NodeManager: 現在のノード上のコンテナ プロセスのコンピューティングと管理を担当するコンピューティング ノード サービス。 1～Nユニット配置可能

3. ApplicationMaster: ユーザーが送信した各アプリケーションには、リソースを申請または解放するために RM と通信し、タスクを開始および停止するために NM と通信する役割を担う ApplicationMaster が含まれます。タスクの実行ステータスを監視する

4. コンテナ: コンテナは YARN におけるリソース抽象化であり、CPU、メモリ、ディスクなどの複数の次元のリソースをカプセル化します。

5. クライアント: ジョブの送信とコマンドラインツールの提供を担当

JD Hadoop 分散リソース管理とジョブ スケジューリングの概要

JD.com はかなり前から Hadoop を使い始めていましたが、多くの落とし穴に遭遇しました。手探りで進み、現在ある程度の成功を収めるまでに、私たちはビジネス上の問題と Hadoop フレームワーク自体の問題の両方に直面しました。

これらの問題を解決することで、Hadoop に多くの機能アップグレードと変更を加え、その一部はコミュニティにフィードバックされ、その他は独自のブランチ バージョンに組み込まれました。現在、当社の Hadoop ビッグデータ プラットフォームは、JD のビッグデータ ビジネスを保護するための豊富な機能と完全なツールを提供しています。

現在、JD のビッグデータ環境では、さまざまな業務の運用環境要件を満たすために、Docker On YARN モデルを使用して運用環境を分離し、誰もが独自の運用環境をカスタマイズし、独自のアルゴリズム ライブラリをインストールできるようにしています。 Linux CGroup モードは、コンピューティング リソースの厳密な分離をサポートし、各ジョブのコンピューティング リソースが他のジョブの影響を受けないようにします。リソースとスケジューリング モデルも拡張され、GPU やその他のハードウェアのスケジューリング サポートが追加されました。ビジネス関係者がエラーを迅速に見つけられるように、統合ログ クエリ ツールが提供されます。

過去には、Presto や Alluxio など、ビッグデータ プラットフォーム上にさまざまな小規模なクラスターが存在していました。各小規模クラスターには独自のマシン バッチがあり、各マシンは 1 つのサービスのみをデプロイする場合があります。マシン上のこれらのサービスの利用率は高くなく、無駄でさえありました。これを学んだ後、私たちは統合されたリソース管理とスケジューリングに YARN を使用することを決定しました。数年にわたる開発を経て、ほとんどの並列フレームワーク (Presto や Alluxio など) を YARN 上で実行できるように移植し、YARN の利点とスケジュール機能を活用してこれらのマシン リソースを最大限に活用し、クラスター リソースの使用率を大幅に向上させました。

同時に、アルゴリズム エンジニアがアルゴリズム処理に Hadoop クラスターを直接使用できるように、Tensorflow On YARN や Caffe On YARN などの一連のディープラーニング フレームワークとツールも開発しました。アルゴリズムとビジネスの反復の速度が大幅に加速されました。これにより、ビッグデータ プラットフォームはディープラーニング処理機能を獲得できるようになります。

その後、マルチサイトのアクティブ/アクティブと地域間拡張機能をより適切にサポートするために、再度変革とアップグレードを行い、10,000 個の Hadoop クラスターの分散リソース管理およびスケジューリング システムを実装し、以前の単一クラスター拡張のボトルネックと、コンピューター ルーム間のスケジューリングと災害復旧を効果的にサポートできない問題を解決しました。このシステムはオンラインで導入され、今年の618プロモーションのテストに合格しました。まさに岩のように堅固であると言えるでしょう。

システムが徐々に展開され稼働を開始した後、地域をまたいで JD の複数のビッグデータ コンピュータ ルームを相互接続しました。同時に、当社の HDFS にも同じコンピュータ ルーム間機能が実装されました。 JD のビッグデータ処理プラットフォーム システムが、地域を超えて展開および拡張できる能力を真に備えたのもこの頃でした。

このシステムは非常に柔軟性が高く、スケジューリング ルーティング戦略とストレージ データ マッピング テーブルを変更することで、コンピュータ ルーム間のジョブ移行とデータ移行を簡単に実現できます。同じコンピュータ ルーム内の異なるクラスター間のサブクラスター全体でジョブを実行し、各クラスターのリソースを最大限に活用できます。機能は、ユーザーの関与なしにサブクラスターの負荷に応じていつでも動的にオン/オフを切り替えることができ、ユーザーに対して完全に透過的です。

新しいビッグデータ プラットフォーム システムをよりユーザーフレンドリーにし、管理と使用を容易にするために、チームはインターフェース プロジェクトを立ち上げました。 WEB技術を活用し、管理者向けのビッグデータプラットフォーム管理システムを実装します。この管理システムを使用すると、サブクラスターを柔軟かつ便利にオンラインおよびオフラインにすることができ、スケジュール戦略をリアルタイムで管理および変更できます。従来のように、関連するコマンドを実行するために、対応する物理サーバーにログインする必要はありません。標準化と体系化により、操作コマンドと保守コマンドをコード内にカプセル化しました。各コマンドには実行前と実行後に関連するチェックと権限認証があり、手動操作でのエラーを削減します。エラーが発生した場合、システムは自動的にロールバックします。

このプラットフォームは、ユーザー レベルの権限管理を提供します。これにより、クラスター内のコンピューティング リソースの権限を柔軟に管理して、各ユーザーが使用できるコンピューティング リソースの量を制御し、リソース プールの使用権限を認証できます。

実際の運用環境では、プラットフォームは特定の使用ルールに従ってリソースを分割し、対応する人または部門に適切な権限を割り当てるため、一部のユーザーが悪意を持って他のユーザーのリソース プールにジョブを送信することを防ぐことができます。同時に、プラットフォームでは操作権限も改良され、一部のユーザーが悪意を持って他の人のジョブを操作すること（実行の停止など）を防止します。

以前は、ビッグデータ プラットフォーム上に複数のクラスターがあり、各クラスターには独自のクライアントがあり、各クライアントには独自の構成ファイルがあったため、運用と保守が面倒で、管理者にとって不便でした。

スケジューリング アーキテクチャが変更およびアップグレードされると、スケジューリング抽象化のレイヤー (ルーター) が追加され、元の 2 レベル スケジューリングが 3 レベル スケジューリングに変更されることが論理的に理解できます。つまり、サブクラスターの戦略選択です。課題を提出するための現在のプロセスは次のとおりです。

1. クライアントはまずルータにジョブ送信要求を送信します

2. ルータは設定されたスケジュール情報に従ってジョブ要求を対応するサブクラスタに転送する。

3. ジョブ要求を受け取った後、サブクラスタはジョブの実行をスケジュールします。

このように、各クライアントは同じ構成ファイル セットを使用するため、クライアントは軽量になり、以前のようにクラスター情報を区別する必要がなくなります。すべてのスケジューリング戦略とロジックは、ルーター コンポーネントにカプセル化されます。 （すべてのスケジュール戦略と制御情報はDBMSに保存されます）

ジョブのサブクラスター間でリソースを動的に借用する機能が追加され、キュー内の関連ジョブをサブクラスター間で実行する必要があるかどうかをいつでも制御できるようになりました。これにより、リソースが不足しているときに、単一のサブクラスターが別のアイドル クラスターからリソースを動的に借用できるようになります。

論理キュー名の概念が追加されました。ユーザーは自分の論理キュー名だけを気にすればよく、ジョブが実際にどの物理キューで実行されているかを気にする必要はありません。この機能により、プラットフォームはいつでも、どのサブクラスターのどの物理キューで論理キューが実際に実行されているかを制御できます。迅速な移行や災害復旧の目的を達成します。

ルータの偶発的な損失や障害を回避するために、ルータ コンポーネントの高可用性と負荷分散機能を独自に開発しました。クラスター全体に複数のルーター ノードが展開され、各コンピューター ルームに 1 つ以上のルーターが配置されます。クライアントの要求に応じて、負荷と距離に基づいて複数の分散ルーター サーバーの中から最適なものが選択されます。同時に、ルーターの障害をいつでもサポートします（ルーターの接続状態が利用できない場合、クライアントは自動的に別のアクティブなルーターに切り替えます）

以下は、このアーキテクチャの論理ブロック図です。これには、アーキテクチャ全体のすべてのコンポーネントが含まれています。新しいコンポーネントは、ルーターと状態およびポリシー ストアです。前者はクライアントに直接接続し、バックエンドの RM サブクラスター関連情報をシールドし、送信およびジョブ情報のクエリ機能を提供します。複数のデバイスを同時に展開して外部サービスを提供することができます。後者は、現在のすべてのサブクラスタのステータス情報、アクティブ RM のアドレス情報、およびスケジューリング ポリシー情報を保存する役割を担います。 (サブクラスターは、定期的に現在のサービス ステータスをハートビートの形式で報告し、StateStore に保存します。) 現在、さまざまなシナリオでのスケジュールのニーズを満たすために、さまざまなスケジュール戦略をサポートしています。

具体的な提出手順は以下のとおりです。

1. クライアントがルータにジョブを送信する

2. ルータは論理キューのスケジューリングポリシー情報を取得する

3. ジョブ送信要求を対応するリソースマネージャに転送し、アプリケーション関連情報をStateStoreに保存します。

4. リクエストを受信すると、ResourceManager は AppMaster を起動し、AppMaster は AMRMProxy にリソース リクエストを送信します。

5. この要求を受け取った後、AMRMProxy は State&Store ポリシーからポリシー情報を読み取り、このジョブをサブクラスタ間で実行する必要があるかどうかを判断します。

6. 対応するサブクラスタにリソース要求を送信し、AppMasterは要求されたコンテナを起動する責任を負います。

大規模 Hadoop クラスターの最適化戦略とアイデア

ネイティブ スケジューラには多くの問題があります。最も重要な問題はパフォーマンスです。この問題に対処するために、キューミラーリングに基づく多方向割り当て戦略を開発しました。これにより、ResourceManager スケジューラのパフォーマンスが大幅に向上し、単一の YARN サブクラスターで 10,000 台を超えるマシンの規模でリソースを管理およびスケジュールできるようになりました。

一方、スケジューラのリソース割り当てのアルゴリズムロジックが充実し、多次元でのソートやフィルタリングのルールが追加されました。メモリに基づく、負荷に基づく、使用量に基づくなど、複数のルールを組み合わせて使用​​できます。

リソース計算プロセスの簡素化、ロックの分割など、ResourceManager のパフォーマンス関連のコード最適化もいくつかあります。

MapReduce ではサービス パフォーマンスとフレームワーク機能が最適化されています。主にシャッフルサービスに関連します。

最適化、分析、テストツール

ベンチマーク

• HiBench https://github.com/intel-hadoop/HiBench
• Hadoopにはベンチマークが付属

JVMプロファイリングツール

• 翻訳元:
• 翻訳元:

Linux パフォーマンス分析

• パフォーマンス
• NMON
• Google ツール

今後の展望と期待

JD.com のビッグデータ プラットフォームの実践では、参考となる技術アーキテクチャと実装方法を提供します。今後も、JD のビッグデータ プラットフォームは、電子商取引レベルの分散アーキテクチャと技術ソリューションの進化の方向に前進し続けます。これに関しては、いくつかの新機能も近々オンラインになる予定です。

1. グループ内のリソースを活用してコストを節約する方法

これまでは、毎年の大きなプロモーションには、前年のトラフィックに基づいて機械を購入する必要がありました。プロモーション後、これらのマシンの稼働率は非常に低く、多くのコストが無駄になりました。この問題を解決するために、現在のビッグデータ プラットフォームは、グループ独自のクラウドである Archimedes に接続されています。プラットフォームは自動スケーリングを通じてクラウド リソースを柔軟に使用できます。この機能は、将来の大規模なプロモーションでいくつかのコンピューティング タスクを実行するために使用されます。

2. ビッグデータプラットフォームの製品化

JD はビッグデータ処理において豊富な経験を蓄積し、優れたミドルウェアおよびサービス製品を開発してきました。今後はこれらの製品を段階的にクラウド化し、外部サービスとして提供していく予定です。