Warning

注: 以下の翻訳の正確性は検証されていません。AIPを利用して英語版の原文から機械的に翻訳されたものです。

Data Connection FAQ

以下は、Data Connectionに関するよくある質問です。

一般的な情報については、Data Connectionのドキュメンテーションをご覧ください。


スケジュールされたビルドが実行されない

ビルドが指定された時間に実行されるはずだったが、実行されなかった。

以下のステップを実行してトラブルシューティングを行います:

  1. このデータセットとブランチに別の同期が実行中ですか? 同じデータセットとブランチで同時に2つの同期を実行することはできないので、他のジョブが同時に実行されていないことを確認してください。

  2. スケジュールが一時停止していませんか? このデータセットのスケジュール概要ページで、このスケジュールが一時停止していないことを確認してください。 このページには、同期の Schedulerで編集 ビューまたは Dataset Previewの スケジュール管理 オプションからアクセスできます。

  3. この同期のエージェントが無効化されていませんでしたか? この同期のソースに関連付けられたエージェントに移動し、エージェントが無効になっていないことを確認してください。

トップに戻る


SNAPSHOT トランザクションを実行した際にデータセットに重複行が発生した

同期が実行されたが、重複行が発生した。

  1. 新しい同期を作成する際には、Snapshot の代わりに APPEND タイプの同期を実行するよう選択します。
  2. 増分設定を宣言する際に、last_upd_in_appl_ts がユニークで常に増加する列である場合、その列を設定し、その列の他のすべての値よりも小さい値を選択します。
  3. これ以降、追加のアクションは必要ないはずです。Data Connectionは同期した最新の値を追跡し、新しい行だけを取り込みます。 新しいとは、前の値よりも大きいことを意味し、新しいタイムスタンプは古いタイムスタンプよりも大きいです。

トップに戻る


増分ロードの実行時間情報

増分同期を実行した際にどの値が使用されたのか?

以下のステップを実行してトラブルシューティングを行います:

  1. データセットに移動します。
  2. 画面上部近くで History を選択します。
  3. 画面の左側で関心のあるトランザクションを選択します。
  4. Build を表示します。
  5. Transaction を表示します。
  6. 画面下部に向かって Custom Metadata のセクションを展開します。
  7. incrementalMetadata のブロックを確認し、正確性を確認します。

トップに戻る


データベースとデータセットの間で列のタイプが一致していない

同期後のデータセットに表示されるものとは異なるタイプが私のタイプです。

以下のステップを実行してトラブルシューティングを行います:

  1. 列が TIMESTAMP の場合、結果として Foundry でのタイプが LONG であるか確認します。 LONG の場合、多くのデータベース作成者が提供するドライバーの副作用で、タイプを最も安全な表現に戻すため、選択したデータ準備ツールを使用してタイプを TIMESTAMP に解析する必要があります(Code Repositories、Preparation、または別のアプリケーション)。
  2. 列が DECIMAL で、元のデータベースと比較して精度が異なる場合、データベース自体のクエリで数値を特定の精度とスケールにキャストすることをお勧めします。または、クエリで列を VARCHAR にキャストし、Foundry で再キャストします。

トップに戻る


実行中のクエリのステータス

クエリが実行を開始した後、そのステータスを確認するにはどうすればよいですか?

以下のステップを実行してトラブルシューティングを行います:

  1. Job tracker アプリケーションを開き、実行中の同期を選択します。
  2. 同期の最も詳細なステータスがここに表示されます。
  3. 可能であれば、ソースデータベースでのクエリの動作を確認します。

トップに戻る


スキーマの不一致で同期が失敗する

ファイルやJDBCテーブルのスキーマが増分 APPEND トランザクション間で変更されると、データセットはスキーマの不一致のクレームで失敗を開始します。 Data ConnectionはJDBC抽出のためのスキーマを推測し、ファイルベースの抽出のための既存のスキーマを伝播します。この場合、スキーマが同じであればスキーマ推測を再度適用する必要があります。スキーマが APPEND トランザクション間で実際に変更されている場合、新しいスキーマには新しいデータセットが必要です。

以下のステップを実行してトラブルシューティングを行います:

ファイルベース

  1. ファイルがXLSXまたはCSVの表形式のデータである場合、同期したデータセットでスキーマを再推測することが可能であるかもしれません。 このスキーマが以前のものと一致していれば、データセットは追加された行を問題なく追加します。

  2. スキーマを推測した後でもまだスキーマエラーが発生する場合(Dataset Previewまたは別のアプリケーションで)、この新しいファイルは、基本的に異なるテーブルビューを表すため、新しいデータセットに同期する必要があります。

  3. 新しいスキーマでデータセットがすでに追加されていた場合、このトランザクションを元に戻すためにPalantirサポートに連絡することをおすすめします。 また、現在のデータセットへのファイルの同期は、同期概要ページに移動し、この同期に関連するスケジュールを一時停止することで一時停止する必要があります。

  4. 新しいスキーマの後続のファイルは、元のデータセットとは異なるデータセットに同期する必要があるため、元の同期から情報をコピーして新しい同期に入れ、ターゲットデータセットを異なるものに置き換えることをおすすめします(データセット名に新しいバージョンを注釈付きで)。

  5. また、Foundry の既存のデータを破損させる可能性のある未来のスキーマ不一致エラーを防ぐため、元の同期を削除するのが最善かもしれません。

JDBC

  1. スキーマがある時点で変更され、その新しい形に永続化することを予期している場合、最初のテーブルをスキーマバージョンを示すデータセットに格納するのが最善です。(例えば account_transactions_v1.0)。
  2. 同期が実行される前に元のテーブルのスキーマが変更された場合:
    • 同期のスケジュールを一時停止します(存在する場合)
  3. 同期が実行された後に元のテーブルのスキーマが変更された場合:
    • 同期のスケジュールを一時停止します(存在する場合)
    • ターゲットデータセットをおそらく破損させたこのトランザクションを元に戻すために、Palantirサポートに連絡します
  4. 同期が一時停止した状態で、新しいスキーマに移行する準備が整ったら、まず新しいスキーマを新しいデータセットに格納する必要があります:
    • 同期を新しい同期にクローンし、ターゲットデータセットを新しいものに置き換えます(例えば account_transactions_v1.1)。 この新しいデータセットは、元のデータセットと結合することができ、全データセットを含むことができます。
    • 使用ケースに必要な場合、新しい同期の動作が正しいことを確認した後、元の同期を削除することができます。 これにより、古いデータセットに破損したデータを着陸する可能性がなくなり、以前のローディング設定の透明性が低下するコストで確保されます。

トップに戻る


BootvisorのステータスがUnknown

私のBootvisorが Unknown の状態になってしまい、停止も開始もできません。

以下のステップを実行する前に、Palantirサポートに連絡して設定を確認してください。以下のステップを実行すると、このエージェントでの同期が一時的に実行できなくなります。ソースの複数のエージェントを確保するか、メンテナンスウィンドウ中にこれらのステップを実行してダウンタイムを防ぎます。

  1. エージェント上の同期を一時停止します。
  2. 現在実行中のすべての同期が完了するのを待ちます。
  3. エージェントを停止します(このステップはエージェントの現在の状態によっては失敗する場合があります)。
  4. エージェントマシンにSSHでログインします。
  5. Data Connectionに関連するすべてのJVMプロセスを kill します。
  6. ./service/bin/init.sh start でBootvisorを開始します。
  7. Data Connectionでエージェントを開始し、エージェントが paused 状態でないことを確認します。

トップに戻る