MaxCompute:実行中の失敗に関するFAQ

MaxComputeタスクを実行するLogviewを開き、StdOut列の値を表示します。 Logviewの使用方法の詳細については、「LogViewを使用したジョブ情報の表示」をご参照ください。 前の図に示すこのインスタンスの入力レコード数が他のインスタンスの入力レコード数よりもはるかに大きい場合は、プライマリキーは同じで値が異なるベクトルがデータに含まれているかどうかを確認します。 データに主キーは同じで値が異なるベクトルが含まれている場合、データベース内のデータは重複排除されません。 Reducer1からReducer2までは、シークフェーズのMapper-Reducer1-Reducer2処理中に、ベクトルが同じプライマリキーを持ち、値が異なるデータが同じreducerで処理されます。 その結果、データスキューが発生し、reduceタスクが予期せず終了する可能性がある。

ほとんどの場合、この問題は、次のいずれかの理由により、Proxima CEがMaxCompute Tunnelのインターフェイスを呼び出すことができないために発生します。

• ネットワークの問題: この場合、ダウンロードセッションを再作成します。

• クロスネットワークアクセスの問題: 設定されたTunnelエンドポイントが無効なため、MaxComputeテーブルの数を取得できません。 詳細については、「Tunnel Uploadコマンドを使用してデータをアップロードする場合、MaxComputeプロジェクトのクラシックネットワークのTunnelエンドポイントを設定しますが、プロジェクトはパブリックTunnelエンドポイントに接続されています。」をご参照ください。 なぜ?. この問題を解決するには、-tunnel_endpointスタートアップパラメーターをコードに追加して、有効なTunnelエンドポイントを指定し、コードを再実行します。

エラー例1およびエラー例2: ほとんどの場合、これらのエラーは、ビルドまたはシークフェーズでMapReduceタスクが入力テーブルの列からデータを読み取ることができないために発生します。 考えられる原因：

• 列が存在しません。

• 列の行の値はnullです。

• 列の行の値が無効です。 その結果、解析エラーが発生する。

ビルドフェーズでタスクが失敗した場合は、上記の問題がdocテーブルに存在するかどうかを確認します。 タスクがシークフェーズで失敗した場合は、前述の問題がクエリテーブルに存在するかどうかを確認します。 エラーメッセージに基づいて、ビルドまたはシークフェーズでタスクが失敗したかどうかを判断できます。

• Mapper-Reducerプロセスで生成されるMapReduceタスクは、ビルドフェーズで実行されます。 エラーの例2に示す出力は、実行ログに記録されます。

• Mapper-Reducer1リデューサー2プロセスで生成されるMRRタスクは、シークフェーズで実行されます。 エラーの例1に示す出力は、実行ログに記録されます。

エラー例3: ほとんどの場合、このエラーは、マッパタスクがシークフェーズでMaxComputeのボリュームとそのボリュームパーティションに関する情報を取得できない場合に発生します。 考えられる原因：

• 同じdocテーブルを使用する複数のタスクが同時に実行されます。 エラーの例3に示す出力は、実行ログに記録されます。 現在のバージョンのProxima CEの場合、インデックスを格納するボリュームパーティションは、docテーブルの名前とパーティション名に基づいています。 同じdocテーブルを使用する複数のタスクを同時に実行すると、タスクの同じボリューム内のインデックスファイルが上書きまたは削除される場合があります。 この場合、MaxComputeのボリュームの読み取りに失敗し、インデックスの読み込みに失敗する可能性があります。 タスクで使用されるdocテーブルの名前を変更して、タスクのdocテーブルの名前が異なることを確認できます。 これにより、各タスクが期待どおりに実行されます。

• 行と列のパラメーターが正しく設定されていません。 MaxComputeは、最大99,999個のリデューサーインスタンスをサポートしています。 -column_numパラメーターと -row_numパラメーターが大きすぎる値に設定されている場合、シークフェーズのMRRタスクのインスタンス数が上限を超えます。 インスタンス数は、column_numにrow_numを掛けたものです。 この場合、制御不可能なエラーが発生する可能性があり、シークフェーズの特定のリデューサインスタンスは、インデックスを格納する正しいボリュームパーティションを見つけることができません。 この問題を防ぐには、行パラメーターと列パラメーターに有効な値を指定します。 詳細については、「クラスターシャーディング」をご参照ください。

マッパタスクGeneratePkMapperは、有効な配列長を取得できません。 ほとんどの場合、マッパタスクの前に実行されるSQLタスクは、テーブルデータを読み取り、配列の長さを取得します。 この問題は、テーブルの読み取りに失敗したために発生します。

• タイムアウト: プロジェクトが属するクラスターのネットワークが不安定です。 この場合、タスクを複数回再試行するか、一定期間後にタスクを再実行してください。

• Tunnel例外: Proxima CEがテーブルを読み取ると、Proxima CEはTunnelコマンドを使用してテーブルレコードを取得します。 したがって、Tunnel例外もテーブルの読み取りに失敗します。 トンネルエラーの処理方法の詳細については、MaxComputeのTunnelエンドポイントへのアクセスが失敗した場合はどうすればよいですか。.

プロキシマCEがクラスターシャーディング中にインデックスを作成すると、プロキシマCEはグラフエンジンに基づいてデータをクラスター化します。 デフォルトでは、GraphJobは特定の数のワーカーノードを申請するために実行されます。 クラスターリソースが不足している場合、この問題が発生します。 次のコマンドを使用して、GraphJobを実行できるワーカーノードの数を制限できます。 これは、リソース要求を制限するのに役立ちます。 Proxima CEの起動コマンドの前に、次のパラメーター設定を追加します。

set odps.graph.worker.num=400; -- In this example, 400 is a sample value. You can specify the value based on the cluster resource configuration.

完全なコマンド:

set odps.graph.worker.num=400;
jar -resources kmeans_center_resource_cl,proxima-ce-aliyun-1.0.0.jar
-classpath http://schedule@{env}inside.cheetah.alibaba-inc.com/scheduler/res?id=251678818 com.alibaba.proxima2.ce com.alibaba.proxima2.ce.ProximaCERunner
-doc_table doc_table_pailitao
-doc_table_partition 20210707
-query_table query_table_pailitao
-query_table_partition 20210707
-output_table output_table_pailitao_cluster_2000w
-output_table_partition 20210707
-data_type float
-dimension 512
-oss_access_id xxx
-oss_access_key xxx
-oss_endpoint xxx
-oss_bucket xxx
-owner_id 123456
-vector_separator blank
-pk_type int64
-row_num 10
-column_num 10
-job_mode build:seek:recall
-topk 1,50,100,200
-sharding_mode cluster
-kmeans_resource_name kmeans_center_resource_cl
-kmeans_cluster_num 1000;