このトピックでは、小さなファイルの最適化とジョブ診断に関するよくある質問に対する回答を提供します。
MaxCompute用に小さなファイルが生成されるシナリオ 小さなファイルの問題を解決するにはどうすればよいですか?
シナリオ
MaxComputeは、ブロックストレージにApsara分散ファイルシステム (Pangu) を使用します。 ほとんどの場合、サイズがブロックサイズより小さいファイルは小さなファイルと見なされます。 デフォルトのブロックサイズは64 MBです。
以下のシナリオでは、小さなファイルが生成される可能性があります。
Reduceステージでは、多数の小さなファイルが生成されます。
小さなファイルは、トンネルベースのデータ収集中に生成されます。
ジョブ実行中に生成された一時ファイルやごみ箱に保持されている期限切れのファイルは、小さなファイルである可能性があります。 ファイルは次のタイプに分類されます。
TABLE_BACKUP: 特定の日数を超えてごみ箱に保持されるテーブル。
FUXI_JOB_TMP: ジョブの実行時に生成される一時ディレクトリ。
TMP_TABLE: ジョブの実行時に生成される一時テーブル。
INSTANCE: ジョブの実行中にメタデータテーブルに保持されるログ。
LIFECYCLE: ライフサイクルの終わりに達するテーブルまたはパーティション。
INSTANCEPROFILE: ジョブが送信および実行された後のプロファイル情報。
VOLUME_TMP: メタデータ情報を持たず、Apsara Distributed File System (Pangu) にマップされたディレクトリを持つデータ。
TEMPRESOURCE: ユーザー定義関数 (UDF) によって使用される1回限りの一時リソースファイル。
FAILOVER: システムフェイルオーバーが発生したときに保持される一時ファイル。
次のコマンドを実行して、テーブル内の小さなファイルの数を照会できます。
desc extended + Table name影響:
多数の小さなファイルには、次の影響があります。
マップインスタンスの起動は悪影響を受けます。 デフォルトでは、1つの小さなファイルが1つのインスタンスに対応します。 小さなファイルの数が多いと、リソースが無駄になり、全体的な実行パフォーマンスに悪影響を及ぼします。
多数の小さなファイルは、Apsara Distributed File System (Pangu) に高い負荷をかけ、ストレージスペースの効率的な使用に影響を与えます。 極端な場合、Apsara Distributed File System (Pangu) が利用できなくなることがあります。
解決策：
異なるシナリオで生成される小さなファイルを処理するために、異なるソリューションが提供される。
Reduceステージで生成される小さなファイル: ソーステーブルまたはパーティションでINSERT OVERWRITEステートメントを実行するか、新しいテーブルにデータを書き込み、ソーステーブルを削除します。
トンネルベースのデータ収集中に生成される小さなファイル:
Tunnel SDKを呼び出すときは、ファイルキャッシュが64 MBに達するたびにファイルをアップロードします。
MaxComputeクライアントを使用する場合は、小さなファイルを頻繁にアップロードしないでください。 大量のファイルが収集されている场合は, 同时にファイルをアップロードすることを推奨します。
パーティションテーブルにデータをインポートするときは、テーブル内のパーティションのライフサイクルを設定することをお勧めします。 このようにして、期限切れのデータを自動的にクリアできます。
ソーステーブルまたはパーティションでINSERT OVERWRITEステートメントを実行します。
次のコマンドを実行して、小さなファイルをマージします。
ALTER TABLE tablename [PARTITION] MERGE SMALLFILES;
同時挿入操作を実行するときにエラーが報告された場合はどうすればよいですか?
問題の説明
同時挿入操作が実行されると、次のエラーメッセージが返されます。
ODPS-0110999: Critical! Internal error happened in commit operation and rollback failed, possible breach of atomicity - Rename directory failed during DDLTask.考えられる原因
MaxComputeは同時実行制御をサポートしていません。 テーブルを修正するために、複数のジョブを同時に実行することができる。 この場合、METAモジュールに対する操作が行われたときに同時実行競合が発生する確率は低い。 その結果、エラーメッセージが返されます。 この問題は、ALTER操作とINSERT操作が同時に実行される場合にも発生します。
解決策
テーブルをパーティションテーブルに変更して、各SQL文がデータを個別のパーティションに挿入するようにすることをお勧めします。 これにより、テーブルに対して同時操作を実行できます。
ジョブの実行中にODPS-0130121エラーが報告された場合はどうすればよいですか?
問題の説明
ジョブが実行されると、次のエラーメッセージが返されます。
FAILED:ODPS-0130121:Invalid argument type - line 1:7 'testfunc':in function class考えられる原因
組み込み関数の入力パラメーターのデータ型が無効です。
解決策
入力パラメーターのデータ型が組み込み関数の入力パラメーターの要件を満たしていることを確認することを推奨します。
DataWorks Operation Centerでタスクのプロパティを表示すると、表示されるタスクのステータスは一時停止されます。 これはなぜですか。
プロジェクト設定に基づいてタスクが開始されているかどうかを確認します。
タスクが開始された場合は、タスクの祖先タスクが失敗したかどうかを確認します。
タスクが開始されていない場合は、ワーカーノードを右クリックしてノードが適切に実行されているかどうかを確認するか、タスクの名前を変更してスケジューリングプロパティを設定します。
DataWorks Data Integrationで操作を実行すると、常に右上隅にメッセージが表示され、Orderフィールドが削除されているかどうかを確認するように求められます。 これはなぜですか。
データベースの [注文] フィールドが削除されているかどうかを確認します。
キャッシュをクリアし、同期タスクを再構成または再作成してから、タスクのステータスを再度確認します。
odpscmd -fコマンドを実行してSQLファイルを実行すると、実行は失敗しますが、エラーメッセージは返されません。 どうすればよいですか。
タスクの実行時ログまたはエラーメッセージを取得して、問題の原因を特定します。
Shellを使用してodpscmd -fコマンドを実行し、Shellにログを出力します。 ログ情報は、コールがシェルで正常であることを示します。 crontabで呼び出しが行われると、エラーが報告され、ログは生成されません。
この問題に対処するには、タスク実行の出力をcrontabに記録します。 問題が発生した場合は、ログファイルからタスクログを取得します。 実行するコマンドは、odpscmd -f xxx.sql >> path/to/odpscmd.log 2>&1です。
DataWorksを使用すると、多数のデータ同期タスクが待機状態になります。 これはなぜですか。
同期タスクが共有スケジューリングリソースを使用しているときに待機状態にある場合は、バッチ同期タスクを最適化して同期速度を最大化します。
スケジューリングリソースを追加することもできます。 詳細については、「Data Integrationのカスタムリソースグループの作成と使用」をご参照ください。
シェルタスクを実行すると, スケジューリングリソース管理機能を使用して追加したサーバのいずれかが常に停止状態で表示されます。 再初期化後もサーバは停止状態のままである。 これはなぜですか。
クラウド製品相互接続ネットワークを使用する場合は、登録情報のマシン名がマシンの実名かどうかを確認してください。 ECSインスタンスで
hostnameコマンドを実行して、マシン名を取得します。 カスタム名はサポートされていません。仮想プライベートクラウド (VPC) が使用されている場合は、ECSホスト名が変更されているかどうかを確認します。 ECSホスト名はインスタンス名と同じではないことに注意してください。 ECSホスト名が変更されている場合は、ECSインスタンスで
cat /etc/hostsコマンドを実行して、バインディングが有効かどうかを確認します。