このページでは、Cloud Data Fusion に関する問題を解決する方法について説明します。
バッチ パイプラインのトラブルシューティング
次のアドバイスはバッチ パイプラインに関するものです。
パイプライン エラー: テキスト ファイルがビジー状態
バッチ パイプラインを実行すると、次のエラーが発生してパイプラインが失敗します。
error=26, Text file busy
推奨事項
この問題を解決するには、パイプラインが失敗したときに自動的に再試行するトリガーを設定します。
- パイプラインを停止する。
- トリガーを作成する。この場合、実行するイベントを選択する際に [Fails] を選択します。詳細については、ダウンストリーム パイプラインで受信トリガーを作成するをご覧ください。
- パイプラインを開始する。
同時実行パイプラインが停止する
Cloud Data Fusion では、多数の同時バッチ パイプラインを実行すると、インスタンスに負荷がかかり、ジョブが Starting、Provisioning、Running 状態で停止する場合があります。その結果、ウェブ インターフェースや API 呼び出しでパイプラインを停止することはできなくなります。多数のパイプラインを同時に実行すると、ウェブ インターフェースが遅くなる、または応答しなくなる可能性があります。この問題は、バックエンドで HTTP ハンドラに対する複数の UI リクエストが原因で発生します。
推奨事項
この問題を解決するには、バージョン 6.6 以降で実行されているインスタンスで利用可能な Cloud Data Fusion フロー制御を使用して、新しいリクエストの数を制御します。
パイプラインの実行中に SSH 接続がタイムアウトする
バッチ パイプラインの実行時に、次のエラーが発生します。
`java.io.IOException: com.jcraft.jsch.JSchException:
java.net.ConnectException: Connection timed out (Connection timed out)`
推奨事項
このエラーを解決するには、次の問題を確認します。
- 欠落しているファイアウォール ルール（通常はポート 22）を確認します。新しいファイアウォール ルールを作成するには、Dataproc クラスタのネットワークの構成をご覧ください。
- Compute Engine 適用者が、Cloud Data Fusion インスタンスと Dataproc クラスタとの接続を許可していることを確認します。
レスポンス コード: 401エラー: 不明なエラーです。
バッチ パイプラインの実行時に、次のエラーが発生します。
`java.io.IOException: Failed to send message for program run program_run:
Response code: 401. Error: unknown error`
推奨事項
このエラーを解決するには、Cloud Data Fusion ランナーのロール（roles/datafusion.runner）を Dataproc で使用するサービス アカウントに付与する必要があります。
BigQuery プラグインを使用したパイプラインが Access Denied エラーで失敗する
BigQuery ジョブの実行時に、Access Denied エラーでパイプラインが失敗するという既知の問題があります。これは、次のプラグインを使用するパイプラインに影響します。
- BigQuery ソース
- BigQuery シンク
- BigQuery の複数テーブルシンク
- 変換プッシュダウン
ログのエラーの例（使用しているプラグインによって異なる場合があります）。
POST https://bigquery.googleapis.com/bigquery/v2/projects/PROJECT_ID/jobs
{
"code" : 403,
"errors" : [ {
"domain" : "global",
"message" : "Access Denied: Project xxxx: User does not have bigquery.jobs.create permission in project PROJECT_ID",
"reason" : "accessDenied"
} ],
"message" : "Access Denied: Project PROJECT_ID: User does not have bigquery.jobs.create permission in project PROJECT_ID.",
"status" : "PERMISSION_DENIED"
}
この例では、PROJECT_ID はプラグインで指定したプロジェクト ID です。プラグインで指定されたプロジェクトのサービス アカウントには、次のうち少なくとも 1 つを実行する権限がありません。
- BigQuery ジョブを実行する
- BigQuery データセットを読み取る
- 一時的なバケットを作成する
- BigQuery データセットを作成する
- BigQuery テーブルを作成する
推奨事項
この問題を解決するには、不足しているロールをプラグインで指定したプロジェクト（PROJECT_ID）に付与します。
BigQuery ジョブを実行するには、BigQuery ジョブユーザーのロール（
roles/bigquery.jobUser）を付与します。BigQuery データセットを読み取るには、BigQuery データ閲覧者のロール（
roles/bigquery.dataViewer）を付与します。一時バケットを作成するには、ストレージ管理者のロール（
roles/storage.admin）を付与します。BigQuery データセットまたはテーブルを作成するには、BigQuery データ編集者のロール（
roles/bigquery.dataEditor）を付与します。
詳細については、プラグインのトラブルシューティング ドキュメント（Google BigQuery マルチ テーブル シンクのトラブルシューティング）をご覧ください。
パイプラインがエラーしきい値で停止しない
エラーしきい値を 1 に設定しても、複数のエラー発生後にパイプラインが停止しないことがあります。
エラーしきい値は、処理されなかった障害に対してディレクティブから発生した例外を対象としています。ディレクティブがすでに emitError API を使用している場合、エラーしきい値はアクティブになりません。
推奨事項
特定のしきい値に達したときに失敗するパイプラインを設計するには、FAIL ディレクティブを使用します。
FAIL ディレクティブに渡された条件が満たされると、エラーしきい値に対してカウントされ、しきい値に達するとパイプラインが失敗します。
Oracle バッチソース プラグインが NUMBER を string に変換する
Oracle バッチソース バージョン 1.9.0、1.8.3 以前では、精度とスケールが未定義の Oracle の NUMBER データ型が CDAP の decimal(38,0) データ型にマッピングされます。
プラグイン バージョン 1.9.1、1.8.4、1.8.5 には下位互換性がありません。また、パイプラインのダウンストリーム ステージがソースの出力スキーマに依存している場合、その出力スキーマが変更されるため、以前のバージョンを使用するパイプラインは、バージョン 1.9.1、1.8.5、1.8.4 にアップグレードすると機能しない場合があります。バージョン 1.9.1、1.8.5、または 1.8 にアップグレードした後、以前のプラグイン バージョンで精度とスケールなしで定義された Oracle NUMBER データ型に対して定義された出力スキーマがある場合、Oracle バッチソース プラグインは Schema field '<field name>' is expected to
have type 'decimal with precision <precision> and scale <scale> but found
'string'. Change the data type of field <field name> to string. のスキーマ不一致エラーをスローします。
バージョン 1.9.1、1.8.5、1.8.4 は、精度とスケールなしで定義された Oracle NUMBER データ型の CDAP string データ型の出力スキーマで動作します。Oracle のソース出力スキーマに Oracle の NUMBER データ型が精度とスケールなしで定義されている場合、丸め誤差が発生する可能性があるため、古いバージョンの Oracle プラグインを使用することはおすすめしません。
特別なケースは、データベース名、スキーマ名、テーブル名にマクロを使用する場合や、出力スキーマを手動で指定していない場合です。スキーマは実行時に検出され、マッピングされます。古いバージョンの Oracle バッチソース プラグインは、Oracle の NUMBER データ型を精度とスケールなしで定義して CDAP decimal(38,0) データ型にマッピングします。バージョン 1.9.1、1.8.5、1.8.4 以降では、実行時にデータ型を string にマッピングします。
推奨事項
精度とスケールが定義されない Oracle NUMBER データ型を操作するときに発生する可能性のある精度の低下の問題を解決するには、パイプラインをアップグレードして Oracle バッチソース プラグインのバージョン 1.9.1、1.8.5、または 1.8.4 を使用します。
アップグレード後、精度とスケールなしで定義された Oracle の NUMBER データ型は、実行時に CDAP string データ型にマッピングされます。元の CDAP decimal データ型（精度とスケールなしでマッピングされた Oracle NUMBER データ型）を使用するダウンストリームのステージまたはシンクがある場合は、更新するか、文字列データを使用することを想定します。
丸め誤差によるデータ損失のリスクは理解しつつ、精度とスケールなしで定義された Oracle NUMBER データ型を CDAP decimal(38,0) データ型として使用する場合は、Hub から Oracle プラグイン バージョン 1.8.6（Cloud Data Fusion 6.7.3 の場合）または 1.9.2（Cloud Data Fusion 6.8.1 の場合）をデプロイし、代わりにそれらを使用するようにパイプラインを更新します。
詳細については、Oracle バッチソースのリファレンスをご覧ください。
エフェメラル Dataproc クラスタを削除する
Cloud Data Fusion がパイプライン実行のプロビジョニング中にエフェメラル Dataproc クラスタを作成すると、パイプライン実行の完了後にとクラスタが削除されます。まれに、クラスタの削除に失敗することがあります。
強く推奨: 適切なクラスタ管理のために、最新の Cloud Data Fusion バージョンにアップグレードします。
最大アイドル時間を設定する
この問題を解決するには、Max Idle Time オプションを構成します。これにより、パイプライン終了の明示的な呼び出しが失敗した場合でも、Dataproc は自動的にクラスタを削除できます。
Max Idle Time は、Cloud Data Fusion バージョン 6.4 以降で使用できます。
推奨: 6.6 より前のバージョンでは、Max Idle Time を手動で 30 分以上に設定します。
クラスタを手動で削除する
バージョンをアップグレードできない場合や、Max Idle Time オプションを構成できない場合は、古いクラスタを手動で削除します。
クラスタが作成された各プロジェクト ID を取得します。
パイプラインのランタイム引数で、Dataproc プロジェクト ID が実行用にカスタマイズされているかどうかを確認します。
Dataproc プロジェクト ID が明示的に指定されていない場合は、使用されているプロビジョナーを特定して、プロジェクト ID を確認します。
パイプラインのランタイム引数で、
system.profile.nameの値を確認します。
プロビジョナーの設定を開き、Dataproc プロジェクト ID が設定されているかどうかを確認します。設定が存在しない場合、またはフィールドが空の場合、Cloud Data Fusion インスタンスが実行されているプロジェクトを使用しています。
プロジェクトごとに、以下を行います。
Google Cloud コンソールでプロジェクトを開き、Dataproc の [クラスタ] ページに移動します。
クラスタを作成された日付の、古い日付から新しい日付で並べ替えます。
情報パネルが表示されていない場合は、[情報パネルを表示] をクリックして [ラベル] タブに移動します。
使用されていない各クラスタ（1 日以上経過しているなど）について、Cloud Data Fusion のバージョン ラベルがあるかどうかを確認します。これは、Cloud Data Fusion によって作成されたことを示します。
クラスタ名別のチェックボックスをオンにして、[削除] をクリックします。
Cloud Data Fusion インスタンスを作成できない
Cloud Data Fusion インスタンスの作成時に、次の問題が発生することがあります。
Read access to project PROJECT_NAME was denied.
推奨
この問題を解決するには、Cloud Data Fusion API を無効にしてから再度有効にします。 次に、インスタンスを作成します。
セカンダリ ワーカーを持つ Dataproc クラスタでパイプラインを実行すると、失敗する
Cloud Data Fusion バージョン 6.8 と 6.9 で、セカンダリ ワーカーが有効になっている Dataproc クラスタに対してパイプラインを実行すると、失敗します。
ERROR [provisioning-task-2:i.c.c.i.p.t.ProvisioningTask@161] - PROVISION task failed in REQUESTING_CREATE state for program run program_run:default.APP_NAME.UUID.workflow.DataPipelineWorkflow.RUN_ID due to
Caused by: io.grpc.StatusRuntimeException: CANCELLED: Failed to read message.
Caused by: com.google.protobuf.GeneratedMessageV3$Builder.parseUnknownField(Lcom/google/protobuf/CodedInputStream;Lcom/google/protobuf/ExtensionRegistryLite;I)Z.
推奨事項
この問題を解決するには、パッチ リビジョン 6.8.3.1、6.9.2.1 以降にアップグレードします。アップグレードできない場合は、次の方法でセカンダリ ワーカーノードを削除します。
エフェメラル Dataproc プロビジョナーを使用している場合は、次の手順でエラーを解決します。
- Cloud Data Fusion ウェブ インターフェースでパイプラインに移動します。
- パイプラインのランタイム引数で、
system.profile.properties.secondaryWorkerNumNodesを0に設定します。
- [保存] をクリックします。
- 名前空間を使用する場合は、名前空間内のセカンダリ ワーカーを無効にします。
- [システム管理者] > [名前空間] をクリックし、名前空間を選択します。
- [設定] > [編集] をクリックします。
system.profile.properties.secondaryWorkerNumNodesの値を0に設定します。
- [保存して閉じる] をクリックします。
既存の Dataproc プロビジョナーを使用している場合は、次の手順でエラーを解決します。
Google Cloud コンソールで、Dataproc の [クラスタ] ページに移動します。
クラスタを選択し、 [編集] をクリックします。
[セカンダリ ワーカーノード] フィールドに「
0」と入力します。
[保存] をクリックします。