Azure HDInsight Interactive Query クラスター (Hive LLAP) サイズ設定ガイド

[アーティクル]
12/08/2023

このドキュメントでは、標準的なワークロードで適切なパフォーマンスを実現するための HDInsight Interactive Query クラスター (Hive LLAP クラスター) のサイズ設定について説明します。このドキュメントに示す推奨事項は一般的なガイドラインであり、ワークロードによっては個別にチューニングが必要となるので注意してください。

HDInsight Interactive Query クラスター (LLAP) に対する Azure の既定の VM 種類

ノードの種類	インスタンス	サイズ
Head	D13 v2	8 `vcpus`、56 GB RAM、400 GB SSD
ワーカー	D14 v2	16 `vcpus`、112 GB RAM、800 GB SSD
ZooKeeper	A4 v2	4 `vcpus`、8 GB RAM、40 GB SSD

注意事項: 推奨されるすべての構成値は、D14 v2 タイプのワーカーノードに基づいています。

構成:

構成キー	推奨値	説明
yarn.nodemanager.resource.memory-mb	102400 (MB)	ノード上のすべての YARN コンテナーに割り当てられるメモリの合計 (MB)
yarn.scheduler.maximum-allocation-mb	102400 (MB)	RM でのすべてのコンテナー要求に対する最大割り当て (MB)。この値を超えるメモリ要求は有効になりません
yarn.scheduler.maximum-allocation-vcores	12	Resource Manager でのすべてのコンテナー要求に対する CPU コアの最大数。この値を超える要求は有効になりません。
yarn.nodemanager.resource.cpu-vcores	12	コンテナーに割り当てることができる NodeManager あたりの CPU コア数
yarn.scheduler.capacity.root.llap.capacity	85 (%)	LLAP キューに対する YARN 容量割り当て
tez.am.resource.memory.mb	4096 (MB)	tez AppMaster で使用されるメモリの量 (MB)
hive.server2.tez.sessions.per.default.queue	<number_of_worker_nodes>	hive.server2.tez.default.queues で指定された各キューのセッション数。この数はクエリコーディネーター (Tez AM) の数に対応します。
hive.tez.container.size	4096 (MB)	指定された Tez コンテナーのサイズ (MB)
hive.llap.daemon.num.executors	19	LLAP デーモンあたりの Executor の数
hive.llap.io.threadpool.size	19	Executor のスレッドプールサイズ
hive.llap.daemon.yarn.container.mb	81920 (MB)	個々の LLAP デーモンで使用されるメモリの合計 (MB) (デーモンあたりのメモリ)
hive.llap.io.memory.size	242688 (MB)	SSD キャッシュが有効である場合の LLAP デーモンあたりのキャッシュサイズ (MB)
hive.auto.convert.join.noconditionaltask.size	2048 (MB)	マップ結合を行うためのメモリサイズ (MB)

LLAP アーキテクチャ/コンポーネント:

`LLAP Architecture/Components`.

LLAP デーモンのサイズ見積もり

1.ノード上のすべてのコンテナーに対する YARN メモリ割り当ての合計の決定

構成: yarn.nodemanager.resource.memory-mb

この値は、各ノードの YARN コンテナーが使用できるメモリの最大合計 (MB) を示します。指定する値は、当該ノードの物理メモリの合計容量より小さくする必要があります。
ノード上のすべての YARN コンテナーに対するメモリ合計 = (物理メモリの合計 – OS とその他サービス用のメモリ)
この値は、使用可能な RAM サイズの 90% 以下に設定します。
D14 v2 の場合、推奨値は 102400 MB です。

2.YARN コンテナー要求あたりの最大メモリ容量の決定

構成: yarn.scheduler.maximum-allocation-mb

この値は、Resource Manager でのすべてのコンテナー要求に対する最大割り当て (MB) を示します。指定された値より大きいメモリ要求は有効になりません。 Resource Manager では、yarn.scheduler.minimum-allocation-mb を増分単位としてコンテナーにメモリを割り当てることができ、yarn.scheduler.maximum-allocation-mb で指定されたサイズを超えることはできません。指定する値は、yarn.nodemanager.resource.memory-mb で指定された、ノード上のすべてのコンテナーに割り当てられるメモリの合計以下にする必要があります。
D14 v2 のワーカーノードでの推奨値は、102400 MB です。

3.`vcores`YARN コンテナー要求あたりの最大仮想コア数の決定

構成: yarn.scheduler.maximum-allocation-vcores

この値は、Resource Manager でのすべてのコンテナー要求に対する仮想 CPU コアの最大数を示します。この値を超える vcores 数の要求は有効にはなりません。これは YARN スケジューラのグローバルプロパティです。 LLAP デーモンコンテナーの場合、この値は使用可能な vcores の合計の 75% に設定できます。残りの 25% は、NodeManager、DataNode、およびワーカーノードで実行されているその他のサービスのために確保しておく必要があります。
D14 v2 の VM には 16 個の16 vcores があり、合計 16 個の 16 vcores の 75% を LLAP デーモンコンテナーで使用できます。
D14 v2 での推奨値は 12 です。

4.同時クエリの数

構成: hive.server2.tez.sessions.per.default.queue

この構成値により、並列で起動できる Tez セッションの数が決まります。これらの Tez セッションは、"hive.server2.tez.default.queues" で指定されたキューごとに起動されます。これは Tez AM (クエリコーディネーター) の数に対応します。ワーカーノードの数と同じにすることをお勧めします。 Tez AM の数は、LLAP デーモンノードの数より大きくなる可能性があります。 Tez AM の主な役割は、クエリの実行を調整し、クエリプランフラグメントを対応する LLAP デーモンに割り当てて実行することです。より高いスループットを実現するには、この値は常に LLAP デーモンノードの数の倍数にしてください。

既定の HDInsight クラスターでは、4 つのワーカーノードで 4 つの LLAP デーモンが実行されるため、推奨値は 4 です。

Hive 構成変数の Ambari UI スライダーhive.server2.tez.sessions.per.default.queue:

`LLAP maximum concurrent queries`.

5.Tez コンテナーおよび Tez アプリケーションマスターのサイズ

構成: tez.am.resource.memory.mb, hive.tez.container.size

tez.am.resource.memory.mb - Tez アプリケーションマスターのサイズを定義します。
推奨値は 4096 MB です。

hive.tez.container.size - Tez コンテナーに割り当てられるメモリ量を定義します。この値は、YARN 最小コンテナーサイズ (yarn.scheduler.minimum-allocation-mb) と YARN 最大コンテナーサイズ (yarn.scheduler.maximum-allocation-mb) の間に設定する必要があります。 LLAP デーモンの Executor は、この値を使用して Executor あたりのメモリ使用量を制限します。
推奨値は 4096 MB です。

6.LLAP キューの容量割り当て

構成: yarn.scheduler.capacity.root.llap.capacity

この値は、LLAP キューに割り当てる容量の割合を示します。 YARN キューの構成方法によっては、容量割り当ての値がワークロードごとに異なる可能性があります。ワークロードが読み取り専用操作の場合は、これを容量の 90% のように高く設定しても機能します。ただし、ワークロードがマネージドテーブルを使用する更新、削除、マージの混合操作である場合は、容量の 85% を LLAP キューに割り当てることをお勧めします。残りの 15% の容量は、圧縮などのその他のタスクが既定のキューからコンテナーを割り当てるために使用できます。これにより、既定のキュー内のタスクによって YARN リソースが使われることはなくなります。

D14 v2 のワーカーノードでの LLAP キューの推奨値は 85 です。
(読み取り専用のワークロードの場合は、必要に応じて 90 まで引き上げることができます。)

7.LLAP デーモンコンテナーのサイズ

構成: hive.llap.daemon.yarn.container.mb

LLAP デーモンは、各ワーカーノードで YARN コンテナーとして実行されます。 LLAP デーモンコンテナーの合計メモリサイズは、次の要因によって決まります。

YARN コンテナーサイズの構成 (yarn.scheduler.minimum-allocation-mb、yarn.scheduler.maximum-allocation-mb、yarn.nodemanager.resource.memory-mb)
ノード上の Tez AM の数
ノード上のすべてのコンテナーに対して構成された合計メモリと LLAP キューの容量

Tez アプリケーションマスター (Tez AM) に必要なメモリは、次のように計算できます。
Tez AM はクエリコーディネーターとして動作し、Tez AM の数は、処理される多数の同時実行クエリに基づいて構成できます。理論的には、ワーカーノードごとに 1 つの Tez AM を検討できます。ただし、1 つのワーカーノードに複数の Tez AM が表示されることもあります。計算上の目的により、Tez AM はすべての LLAP デーモンノード/ワーカーノードに均等に分布されていると見なします。 Tez AM あたりのメモリは 4 GB にすることをお勧めします。

Tez Ams の数 = value specified by Hive config hive.server2.tez.sessions.per.default.queue.
LLAP デーモンノードの数 = Ambari UI の環境変数 num_llap_nodes_for_llap_daemons で指定。
Tez AM のコンテナーサイズ = Tez 構成 tez.am.resource.memory.mb で指定した値。

ノードあたりの Tez AM メモリ = (ceil ( Tez AM の数 / LLAP デーモンノードの数 )x Tez AM コンテナーサイズ)
D14 v2 の場合、既定の構成の Tez AM の数と LLAP デーモンノードの数はそれぞれ 4 つです。
ノードあたりの Tez AM メモリ = (ceil(4/4) x 4 GB) = 4 GB

各ワーカーノードで LLAP キューに使用できるメモリの合計は、次のように計算できます。
この値は、ノード上のすべての YARN コンテナーで使用できるメモリの総量 (yarn.nodemanager.resource.memory-mb) および LLAP キューに対して構成されている容量の割合 (yarn.scheduler.capacity.root.llap.capacity) によって決まります。
ワーカーノード上の LLAP キューの合計メモリ = ノード上のすべての YARN コンテナーで使用できる合計メモリ x LLAP キューに対する容量の割合。
D14 v2 では、この値が (100 GB x 0.85) = 85 GB となります。

LLAP デーモンコンテナーのサイズは、次のように計算されます。

LLAP デーモンコンテナーのサイズ = (ワーカーノード上の LLAP キューのメモリ合計) – (ノードあたりの Tez AM メモリ) - (サービスマスターのコンテナーサイズ)
ワーカーノードのいずれかで生成されたクラスターのサービスマスター (LLAP サービスのアプリケーションマスター) は 1 つだけです。計算上の目的により、1 つのワーカーノードにあるサービスマスターは 1 つと見なします。
D14 v2 ワーカーノード、HDI 4.0 の場合、推奨値は (85 GB - 4 GB - 1 GB)) = 80 GB です

8.LLAP デーモンあたりの Executor の数の決定

構成: hive.llap.daemon.num.executors, hive.llap.io.threadpool.size

hive.llap.daemon.num.executors:
この構成は、LLAP デーモンあたりの、タスクを並列で実行できる Executor の数を制御します。この値は、仮想コアの数、Executor ごとに使用されるメモリの量、および LLAP デーモンコンテナーで使用できるメモリの合計量によって決まります。 Executor の数は、ワーカーノードあたりの使用可能な仮想コアの 120% にオーバーサブスクライブされる場合があります。ただし、メモリ要件を満たしていない場合は、Executor ごとに必要なメモリと LLAP デーモンコンテナーのサイズに基づいて調整する必要があります。

各 Executor は 1 つの Tez コンテナーに相当し、4 GB のメモリ (Tez コンテナーサイズ) を使用します。 LLAP デーモン内のすべての Executor は、同じヒープメモリを共有します。すべての Executor がメモリ集中型の操作を同時に実行するわけではないと仮定すると、Executor ごとに Tez コンテナーサイズ (4 GB) の 75% が妥当です。このように考え、並列処理を向上するために各 Executor のメモリを少なくする (3 GB など) ことで、Executor の数を増やすことができます。ただし、対象のワークロードに合わせてこの設定を調整することをお勧めします。

D14 v2 の VM には仮想コアが 16 個あります。 D14 v2 の場合、Executor 数の推奨値は、Executor ごとに 3 GB とすると、各ワーカーノードで (16 個の仮想コア x 120%) ~= 19 となります。

hive.llap.io.threadpool.size:
この値は、Executor のスレッドプールサイズを指定します。 Executor は指定したとおりに固定されるため、これは LLAP デーモンあたりの Executor の数と同じになります。
D14 v2 の場合、推奨値は 19 です。

9.LLAP デーモンのキャッシュサイズの決定

構成: hive.llap.io.memory.size

LLAP デーモンのコンテナーメモリは、次のコンポーネントで構成されます。

ヘッドルーム
Executor (Xmx) が使用するヒープメモリ
デーモンごとのメモリ内キャッシュ (そのオフヒープメモリのサイズ。SSD キャッシュが有効になっている場合は適用されません)
メモリ内キャッシュのメタデータサイズ (SSD キャッシュが有効になっている場合のみ適用できます)

ヘッドルームサイズ: このサイズは、Java VM のオーバーヘッド (メタスペース、スレッドスタック、gc データ構造など) に使用されるオフヒープメモリの一部を示します。一般に、このオーバーヘッドはヒープサイズ (Xmx) の約 6% です。さらに安全性を高める場合、この値は LLAP デーモンのメモリサイズの合計の 6% として計算できます。
D14 v2 の場合、推奨値は ceil(80 GB x 0.06) ~= 4 GB です。

ヒープサイズ (Xmx) :すべての Executor で使用可能なヒープメモリの量です。合計ヒープサイズ = Executor の数 x 3 GB
D14 v2 の場合、この値は 19 x 3 GB = 57 GB

Ambari environment variable for LLAP heap size:

`LLAP heap size`.

SSD キャッシュが無効になっている場合は、LLAP デーモンコンテナーのサイズからヘッドルームサイズとヒープサイズを取り除いたあとに残るメモリの量がメモリ内キャッシュとなります。

SSD キャッシュが有効になっている場合は、キャッシュサイズの計算が異なります。 hive.llap.io.allocator.mmap = true に設定すると、SSD キャッシュが有効になります。 SSD キャッシュを有効にすると、メモリの一部が SSD キャッシュのメタデータの格納に使用されます。メタデータはメモリに格納されます。それは、SSD キャッシュサイズの最大 8% になると予想されます。
SSD キャッシュのメモリ内メタデータサイズ = LLAP デーモンのコンテナーサイズ - (ヘッドルーム + ヒープサイズ)
D14 v2、HDI 4.0 の場合の SSD キャッシュのメモリ内メタデータサイズ = 80 GB - (4 GB + 57 GB) = 19 GB

SSD キャッシュのメタデータの格納に使用できるメモリのサイズから、サポートできる SSD キャッシュのサイズを計算できます。
SSD キャッシュのメモリ内メタデータサイズ = LLAP デーモンのコンテナーサイズ - (ヘッドルーム + ヒープサイズ) = 19 GB
SSD キャッシュのサイズ = SSD キャッシュのメモリ内メタデータのサイズ (19 GB) / 0.08 (8%)

D14 v2、HDI 4.0 の場合の推奨 SSD キャッシュサイズ = 19 GB / 0.08 ~= 237 GB

10.マップ結合メモリの調整

構成: hive.auto.convert.join.noconditionaltask.size

このパラメーターを有効にするには、hive.auto.convert.join.noconditionaltask が有効になっていることを確認してください。この構成は、Hive オプティマイザーによる MapJoin の選択に関するしきい値を決定します。Hive オプティマイザーは、他の Executor からのメモリのオーバーサブスクリプションによってインメモリハッシュテーブルに余裕が生まれ、より多くのマップ結合変換が可能になると見なします。 Executor あたり 3 GB と考えると、このサイズは 3 GB までオーバーサブスクライブが可能ですが、他の操作によって、バッファーの並べ替え、バッファーのシャッフルなどにヒープメモリが使用されることもあります。
そのため、D14 v2 で Executor ごとに 3 GB のメモリを使用する場合は、この値を 2048 MB に設定することをお勧めします。

(注: この値には、ワークロードに適した調整が必要な場合があります。この値の設定が低すぎる場合は、autoconvert 機能を使用できません。設定値が大きすぎると、メモリの例外や GC の一時停止が発生し、パフォーマンスが低下する可能性があります。)

11.LLAP デーモンの数

Ambari 環境変数: num_llap_nodes, num_llap_nodes_for_llap_daemons

num_llap_nodes - Hive LLAP サービスで使用されるノードの数を指定します。これには、LLAP デーモン、LLAP サービスマスター、Tez アプリケーションマスター (Tez AM) を実行するノードが含まれます。

`Number of Nodes for LLAP service`.
num_llap_nodes_for_llap_daemons - LLAP デーモンにのみ使用されるノードの数を指定します。 LLAP デーモンコンテナーのサイズは最大限適合するノードに設定され、結果的に、各ノードの llap デーモンは 1 つとなります。

`Number of Nodes for LLAP daemons`.

どちらの値も、Interactive Query クラスターのワーカーノードの数と同じにしておくことをお勧めします。

ワークロード管理に関する考慮事項

LLAP のワークロード管理を有効にする場合は、ワークロード管理が想定どおり機能するのに十分な容量を確保してください。ワークロード管理には、llap キューに加えて、カスタム YARN キューの構成が必要です。ワークロードの要件に従って、クラスターリソースの総容量を llap キューとワークロード管理キューに割り当ててください。ワークロード管理は、リソースプランがアクティブ化されたときに、Tez アプリケーションマスター (Tez AM) を生成します。

注:

リソースプランをアクティブ化することで生成される Tez AM は、hive.server2.tez.interactive.queue で指定されたワークロード管理キューからリソースを消費します。
Tez AM の数は、リソースプランで指定された QUERY_PARALLELISM の値によって変わります。
ワークロード管理がアクティブになると、LLAP キューの Tez AM は使用されません。クエリ調整に使用されるのは、ワークロード管理キューの Tez AM のみです。 llap キュー内の Tez AM は、ワークロード管理が無効になっているときに使用されます。

次に例を示します。クラスターの合計容量である 100 GB のメモリは、LLAP、ワークロード管理、および既定のキューに次のように割り当てられます。

LLAP のキューの容量 = 70 GB
ワークロード管理のキューの容量 = 20 GB
既定のキューの容量 = 10 GB

ワークロード管理のキューの容量が 20 GB の場合、リソースプランでは QUERY_PARALLELISM 値に 5 を指定できます。これは、コンテナーサイズが 4 GB の Tez AM をワークロード管理が 5 つ起動できることを意味します。 QUERY_PARALLELISM が容量を超えている場合は、一部の Tez AM が ACCEPTED 状態で応答を停止している可能性があります。 Hive server 2 Interactive は、RUNNING 状態ではない Tez AM にクエリフラグメントを送信することはできません。

次のステップ

これらの値を設定しても問題が解決しない場合は、次のいずれかにアクセスしてください。

Azure コミュニティのサポートを通じて Azure エキスパートから回答を得る。
@AzureSupport に問い合わせる - Microsoft Azure 公式アカウントです。Azure コミュニティを適切なリソース (回答、サポート、エキスパート) に結び付けることで、カスタマーエクスペリエンスを向上します。
さらにヘルプが必要な場合は、Azure portal からサポートリクエストを送信できます。メニューバーから [サポート] を選択するか、 [ヘルプとサポート] ハブを開いてください。詳細については、「Azure サポート要求を作成する方法」を参照してください。サブスクリプション管理と課金サポートへのアクセスは、Microsoft Azure サブスクリプションに含まれていますが、テクニカルサポートはいずれかの Azure のサポートプランを通して提供されます。
その他の参考資料