ビッグデータタスクの仕事で最も厄介なのは、動作パラメータの設定、OOMなどの問題が際限なく発生し、リソースの決定方法がよくわからない人が多いので、それについてお話ししましょう。
今日のビッグデータプロジェクトでは、データクラスターのコアはhadoop + hiveですが、プロジェクトを構築するときにネイティブのものを直接使用することは通常できません。さまざまなメーカーがこれらのネイティブなものを独自の製品にパッケージ化します。名前ですが、実際には常にそうです。切り離せない、どのように変化しても、基盤となるテクノロジーはこれらのネイティブテクノロジーを使用しているため、構成されているか使用されているかにかかわらず、実際には同じです。もちろん、会社の特性に沿ったものもあります。 。いくつかの使用方法ですが、それらはすべて浅いものであり、コアを置き換えるものではありません
ここでは、最も人気のあるバッチストリーム統合ハイブ+ Hadoop + Spark on Yarnフレームワークモデルを使用して例を示します。まず、特別な目的でない限り、本番環境フレームワークの規模は完全に分散されます。は、通常はhadoopです。sparkクラスターとsparkクラスターはどちらも3ノード以上であるため、リソースは確かに私たち自身のテスト環境ほど小さくはありません。
ネイティブスパークの場合、タスクが送信されると、デフォルトで次の5つのパラメーター値があります。これらの5つのパラメーター値はコア5です。他のすべての構成は、これら5つを最適化するため、またはこれら5つに基づいています。構成
spark.executor.memory 默认值1g
spark.executor.cores 默认值1核
spark.executor.instances 默认值2个
spark.yarn.am.memory 默认值512m
spark.yarn.am.cores 默认值1核
これらの構成はコア構成です。上から順に、各エグゼキュータは1gのメモリと1つのコア番号を使用し、1つのタスクは2つのエグゼキュータインスタンスに対応し、applicationmasterは520mのメモリと1つのコア番号を使用します。
上記の構成から、すべてのユーザーを確認できます。最初に自分で計算し、合計でどのくらいのリソースが占有されているかを計算します
私が期待したことが悪くなければ、この考えによれば、言わなければ、全員が3コア2.5gとして数えられます。実際、最初に正解をお伝えします。このタスクが実行されると、糸3コア7gリソースを占有します。次のことを説明します。理由について話しましょう。
理由1：上記のデフォルト構成に従って実行する場合、エグゼキュータを初期化するときに、後で実行する1gのタスクに加えて、各エグゼキュータはその操作と初期化のためにもう少しメモリを消費します。つまり、実際にはそうではありません。 1gにのみ適用されます。
理由2、mrの動作原理に精通している場合、applicationmasterは直接生成されないことがわかります。これは、タスクのタスクを受け入れる最初の子ノードのエグゼキュータで生成されます。つまり、デフォルトです。構成は2つのエグゼキュータに対応するタスクですが、アプリケーションマスターの初期化に使用されるエグゼキュータを含めて、実際には、タスク中に合計3つのエグゼキュータが開始されます。
3つ目の理由は、糸では、リソースを最大限に活用するために、適用するリソースの最小数と正則化係数の2つの属性があります。正則化係数は受け入れません。個別の割り当て。これは、適用できるリソースの最小数と同じです。、適用されるリソースの最小数は、デフォルトで1024です。正則化係数の機能は、に従ってリソースを1つの部分に分割することです。適用できるリソースの最小量。
タスク全体に実際に3人のエグゼキュータが存在し、インスタンス化時に適用されるリソースの数が実際に1Gを超え、正則化係数のために適用されるリソースが正則化されるのは、まさに上記の3つの理由によるものです。 2 + 2 + 2 = 6gに達する
ただし、これらの6 gは、直接1回限りのアプリケーションではありません。興味がある場合は、タスクを送信した直後に、送信されたヤーンページのビューに移動できます。タスクが開始されていない場合は、タスクを見つけることができます。初期化フェーズで送信されたばかりで、最初にエグゼキュータのメモリとアプリケーションマスターのリソースを申請するだけです。最初のエグゼキュータのコア数は役に立たないため、初期化フェーズでは適用されないことに注意してください。また、applicationmasterは512Mのメモリにのみ適用されるため、正則化Yingziは直接1gを与え、最終的なデフォルトになります。構成タスクの初期化フェーズでは、最初に要求されるリソースは1エグゼキュータ+1コア+ 3gメモリです。
applicationmasterが初期化された後、その初期化の完了によって占有されているエグゼキュータは強制終了されませんが、applicationmasterなどの必要な機能を実行するために使用され、実際にタスクを実行する他の2つのエグゼキュータもapplicationmasterによってインタラクティブに生成されます。そして、正則化係数により、それぞれが合計2g + 1コアを占有します。これにより、タスクの最終的なリソース占有は1 + 2 + 2 + 2 = 7g、1 + 1 + 1 = 3コアになります。
このブログ投稿では、コアリソース占有率の計算形式について説明しました。最初に述べたように、他のアイデアはこのアイデアに基づいて最適化されています。また、この考え方に従って構成知識を多様化することをお勧めします。たとえば、sparkは実際にフレキシブルエグゼキュータの数を設定します。これにより、フレキシブル生成の最大値と最小値を制御することもできます。
私はスパークオンヤーンフレームワークを使用していますが、実際にはすべてのフレームワークは同じです。準備するときは、最初に各構成アイテムが何に使用されるかを考える必要がありますか？それが何のために使われるかを知ることは簡単に設定できます
また、タスクを構成するときは、リソースを100％使用したり、負荷を使用したりしないようにしてください。そうしないと、遅かれ早かれ問題が発生します。たとえば、子ノードが3つしかない場合は、各タスクを実行します。実行するのは最大2つにするのが最適です。タスク。実行中のアプリケーションマスターは1つだけで十分です。必要な場合を除いて、1つのサブノードに複数のタスクを引き受けさせないでください。結局のところ、タスクはたくさんあります。1つのクラスターはそれに耐えられず、クラッシュします。
最後に、体験をさせていただきます。ほとんどの場合、あなたの考えは正しいのですが、タスクを送信すると、占有されているリソースが正しく表示されないことに気付きます。つまり、あなたの考えとは異なります。 、クラスターが最適化されていても、今回は間違えたくない、確かにそのような状況があります。一般的に3つの理由があります
1つ目は、リソーススケジューラのリソース制御方式です。100％の選択が適切であるとは言えず、リソースを何度も正しく使用することは不可能です。この確率の問題は、それを許可する必要があります。 。可能な限り、構成する際にはもっと考慮すると言えます。
2番目の理由は最も一般的です。さまざまな非ネイティブツールに表示されます。現在、開発にツールを使用しています。これらのツールには通常、最適化戦略が組み込まれています。送信する構成パラメータは、内部最適化戦略では適切と見なされない場合があります。Iこれが発生した場合は、それを探し、最後にタスクの実行をトリガーするコマンドを使用して、構成と同じかどうかを確認します。最適化されている可能性が高く、一部のメーカーは製品を使用しています、構成可能なパラメーターは制限されており、構成できるのはごくわずかであるため、カスタマイズした他の操作はまったく効果がなく、その一部にすぎません。
3つ目は、最も役に立たない問題です。タスクを送信するときに、yarnタスクのチェックに移動して、初期化タスクのリソースが構成したものと同じであるが、最初は異なっていることを確認します。このタイプの問題はクラスターです。特定の最適化が必要です。そうしないと、タスクを実行するときにそのようなクラスターが確実にリソースを浪費します。たとえば、初期化タスクは多くのリソースを消費し、十分に活用されません。