各テーブルに約 500 万行ある 6 つのテーブルを結合しようとしています。すべてのテーブルで昇順で並べ替えられているアカウント番号に参加しようとしています。マップ タスクは正常に終了し、リデューサーは 66.68% で動作を停止しました。レデューサーの数を増やすなどのオプションを試し、他のオプションも試しました set hive.auto.convert.join = true; hive.hashtable.max.memory.usage = 0.9; を設定します。hive.smalltable.filesize = 25000000L; を設定します。しかし、結果は同じです。少数のレコード (5000 行など) で試したところ、クエリは非常にうまく機能しました。
それを機能させるためにここで何ができるかを提案してください。
リデューサーは 66% で実際のリデュースを開始します (0-33% はシャッフル、33-66% はソート)。ハイブとの結合では、リデューサーは 2 つのデータ セット間でデカルト積を実行しています。
すべてのデータ セットに頻繁に現れる外部キーが少なくとも 1 つあると推測します。NULL とデフォルト値に注意してください。
For example, in a join, imagine the key "abc" appears ten times in each of the six tables (10^6). That's a million output records for that one key. If "abc" appears 1000 times in one table, 1000 in another, 1000 in another, then twice in the other three tables, you get 8 billion records (1000^3 * 2^3). You can see how this gets out of hand. I'm guessing there is at least one key that is resulting in a massive number of output records.
This is general good practice to avoid in RDBMS outside of Hive as well. Doing multiple inner joins between many-to-many relationships can get you in a lot of trouble.
現在および将来的にこれをデバッグするために、JobTracker を使用して、問題の Reducer のログを見つけて調べることができます。その後、reduce 操作をインストルメント化して、何が起こっているかをより適切に把握できます。もちろん、ロギングで爆破しないように注意してください。たとえば、削減操作に入力されたレコードの数を調べてみてください。