問題タブ [tez]

[いくつかの回答とコメントの後、ここで得た知識に基づいて新しい質問をしました: Out of memory in Hive/tez with LATERAL VIEW json_tuple ]

私のクエリの 1 つが一貫してエラーで失敗します。

ここでのキーワードは のようjava.lang.OutOfMemoryError: Java heap spaceです。

あたりを見回しましたが、Tez から理解したと思っていたことが役に立ちませんでした。

• yarn-site/yarn.nodemanager.resource.memory-mb が上限に達している => 使用できるすべてのメモリを使用しています
• yarn-site/yarn.scheduler.maximum-allocation-mb: yarn.nodemanager.resource.memory-mb と同じ
• 糸サイト/yarn.scheduler.minimum-allocation-mb = 1024
• hive-site/hive.tez.container.size = 4096 (yarn.scheduler.minimum-allocation-mb の倍数)

私のクエリには 4 つのマッパーがあり、3 つは非常に高速で、4 番目は毎回停止します。クエリの Tez グラフィカル ビューを次に示します。

この画像から：

• テーブル contact には 1 億 5000 万行、283 GB の ORC 圧縮データがあります (1 つの大きな json フィールドがあり、LATERAL VIEW されています)
• テーブル m には 1M 行、20MB の ORC 圧縮データがあります
• テーブル c には 2,000 行あり、< 1MB の ORC 圧縮
• テーブル e には 80 万行があり、7 GB の ORC が圧縮されています
• e は他のすべてのテーブルと LEFT JOIN されます

e と contact はパーティション化されており、WHERE 句で 1 つのパーティションのみが選択されています。

したがって、マップの数を増やしてみました。

• tez.grouping.max-size: デフォルトで 650MB、- tez.grouping.min-size (16MB) に下げても違いはありません
• tez.grouping.split-count を 1000 に増やしても違いはありません
• デフォルトでは tez.grouping.split-wave 1.7 ですが、5 に増やしても違いはありません

関連する場合は、他のメモリ設定を次に示します。

• mapred-site/mapreduce.map.memory.mb = 1024 (最小コンテナー サイズ)
• mapred-site/mapreduce.reduce.memory.mb = 2048 (2 * コンテナーの最小サイズ)
• mapred-site/mapreduce.map.java.opts = 819 (0.8 * 最小コンテナー サイズ)
• mapred-site/mapreduce.reduce.java.opts = 1638 (0.8 * mapreduce.reduce.memory.mb)
• mapred-site/yarn.app.mapreduce.am.resource.mb = 2048 (2 * コンテナーの最小サイズ)
• mapred-site/yarn.app.mapreduce.am.command-opts = 1638 (0.8 * yarn.app.mapreduce.am.resource.mb)
• mapred-site/mapreduce.task.io.sort.mb = 409 (0.4 * 最小コンテナー サイズ)

私の理解では、tez は作業を多くの負荷に分割できるため、時間がかかりますが、最終的には完了します。私は間違っていますか、それとも私が見つけていない方法がありますか?

コンテキスト: hdp2.6、32GB RAM を備えた 8 つのデータノード、ビーライン経由で実行される json に基づく分厚い横方向ビューを使用したクエリ。

ドキュメントは明確ではありません。Hive LLAP (Long Live and Process) に関するブログ投稿の例はすべて Tez 実行エンジンを使用していますが、Spark/MR ハイブ エンジンでも LLAP を使用できますか?