Standard、Premium、または Enterprise サブスクリプションを使用して、データ レイクにデータをランディングします
データを次のターゲットにランディングするために、 [データ レイクにデータをランディング] タスクを設定できます。
Amazon S3
Amazon S3 への接続の構成については、「 Amazon S3」を参照してください。
Azure Data Lake Storage
Azure Data Lake Storage への接続の構成については、「Azure Data Lake Storage」を参照してください。
Google Cloud Storage
Google Cloud Storage への接続の構成については、「Google Cloud Storage」を参照してください。
データ ソースへの接続の設定については、「 データソースへの接続の設定」を参照してください。
データ レイクのランディング タスクを設定するには:
[データ統合] > [プロジェクト] で、 [プロジェクトを作成] をクリックします。
[新しいプロジェクト] ダイアログで、次の操作を実行します。
プロジェクトの [名前] を入力します。
- プロジェクトを作成する [スペース] を選択します。
- 必要に応じて [説明] を入力します。
- [ユースケース] として [レプリケーション] を選択します。
- 必要に応じて、何も構成せずに空のプロジェクトを作成する場合は、 [開く] チェック ボックスをオフにします。
[作成] をクリックします。
次のいずれかが発生します。
- [新しいプロジェクト] ダイアログの [開く] チェック ボックスがオンになっている場合 (既定)、プロジェクトが開きます。
- [新しいプロジェクト] ダイアログの [開く] チェック ボックスがオフの場合、プロジェクトはプロジェクトのリストに追加されます。プロジェクトの
メニューから [開く] を選択すると、後でプロジェクトを開くことができます。
プロジェクトが開いたら、 [データレイクにデータをランディング] をクリックします。
[データレイクにデータをランディング] ウィザードが開きます。
[基本設定] タブで、データ レイク ランディング タスクの名前と説明を指定します。[次へ] をクリックします。
情報メモスラッシュ (/) またはバックスラッシュ (\) 文字を含む名前はサポートされていません。[ソース接続を選択] タブで、ソース データへの接続を選択します。必要に応じて、 [アクション] 列のメニューから [編集] を選択して、接続設定を編集できます。
ソース データに接続されていない場合は、タブの右上にある [接続を作成] をクリックして、最初にデータ接続を作成する必要があります。
左側のフィルターを使用して、接続のリストをフィルタリングできます。接続は、ソース タイプ、ゲートウェイ、スペース、所有者でフィルタリングできます。接続リストの上にある [すべてのフィルター] ボタンには、現在のフィルターの数が表示されます。このボタンを使用して、左側の [フィルター] パネルを閉じたり開いたりできます。現在アクティブなフィルターは、使用可能な接続のリストの上にも表示されます。
右側のドロップダウン リストから [最終更新日]、 [最終作成日]、または [アルファベット順] を選択してリストを並べ替えることもできます。ソート順を変更するには、リストの右側にある矢印をクリックします。
データ ソース接続を選択した後、必要に応じて、タブの右上にある [接続をテスト] をクリックし (推奨)、[次へ] をクリックします。
[データセットを選択] タブで、データ レイク ランディング タスクに含めるテーブルやビューを選択します。データベースからのデータの選択 で説明されているように、ワイルドカードを使用して選択ルールを作成することもできます。
情報メモスラッシュ (/) またはバックスラッシュ (\) 文字を含むスキーマ名またはテーブル名はサポートされていません。[ターゲット接続を選択] タブで、使用可能な接続のリストからターゲットを選択し、 [次へ] をクリックします。機能的には、このタブは前述の [ソース接続を選択] タブと同じです。
[設定] タブで、必要に応じて次の設定を変更し、[次へ] をクリックします。
更新方法:
変更データキャプチャ (CDC): データ レイクのランディング タスクは、フル ロードから開始されます (その間、選択されたすべてのテーブルがランディングされます)。ランディング データは、CDC (変更データ キャプチャ) テクノロジーを使用して最新の状態に保たれます。
情報メモDDL 操作の CDC (変更データ キャプチャ) はサポートされていません。Data Movement gateway を使用する場合、変更はソースからほぼリアルタイムでキャプチャされます。Data Movement gateway を使用せずに作業する場合、変更はスケジューラーの設定に従ってキャプチャされます。詳細は、Data Movement gateway を使用しない場合のタスクのスケジュール設定をご覧ください。
- リロード: 選択したソーステーブルからターゲットプラットフォームへのデータのフル ロードを実行し、必要に応じてターゲット テーブルを作成します。フル ロードはタスクの開始時に自動的に実行されますが、必要に応じて手動で実行することや、定期的に実行するようにスケジュールすることもできます。
[変更データキャプチャ (CDC)] を選択し、データに CDC またはビューをサポートしていないテーブルも含まれている場合、2 つのデータ パイプラインが作成されます。CDC をサポートするすべてのテーブルを含む 1 つのパイプラインと、 [リロード] を使用する他のすべてのテーブルとビューを含む別のパイプライン。
使用するフォルダ:
ファイルを書き込むバケット フォルダーに応じて、次のいずれかを選択します。
- 既定のフォルダー: 既定のフォルダー形式は <your-project-name>/<your-task-name> です。
- ルート フォルダー: ファイルはバケットに直接書き込まれます。
フォルダー: フォルダー名を入力します。フォルダーが存在しない場合は、データ レイクのランディング タスク中に作成されます。
情報メモ フォルダー名に特殊文字 (@、#、! など) を含めることはできません。
[概要] タブに、データ パイプラインのビジュアルが表示されます。[<名前> タスクを開く]、または [Do nothing] (何もしない) を選択します。次に、 [作成] をクリックします。
選択に応じて、タスクが開かれるか、プロジェクトのリストが表示されます。
タスクを開くことを選択した場合、 [データセット] タブには、選択したデータ アセット テーブルの構造とメタデータが表示されます。これには、明示的にリストされたすべてのテーブルと、選択ルールに一致するテーブルが含まれます。
データ ソースからさらにテーブルを追加する場合は、 [ソース データの選択] をクリックします。
必要に応じて、クラウド ストレージ ターゲットの設定 の説明に従ってタスク設定を変更します。
データセットの変換を実行し、データをフィルタリングし、列を追加できます。
詳細については、「データセットの管理」を参照してください。
必要な変換を追加したら、[データセットの検証] をクリックしてデータセットを検証できます。検証に失敗した場合は、先に進む前にエラーを修正してください。
詳細については、「データセットの検証と調整」を参照してください。
準備ができたら、 [準備] をクリックしてランディング タスクをカタログ化し、実行の準備をします。
データ タスクの準備が完了したら、 [実行] をクリックします。
これで、データ レイクのランディング タスクが開始されます。モニター ビューで進行状況を監視できます。詳細については、「個々のデータ タスクの監視」を参照してください。
データセットのロードの優先度の設定
各データセットにロード優先度を割り当てることで、データ タスクでのデータセットのロード順を制御できます。この機能は、大きなデータセットの前に小さなデータセットをロードする場合などに便利です。
[ロードの優先度] をクリックします。
各データセットのロードの優先度を選択します。
既定のロードの優先度は [標準] です。データセットは次の優先順位でロードされます。
最高
より高く
高
標準
低
より低く
最低
同じ優先度のデータセットは順不同でロードされます。
[OK] をクリックします。
メタデータの更新
タスクのメタデータを更新して、タスクの [設計] ビューのソースのメタデータの変更に合わせることができます。Metadata Manager を使用する SaaS アプリケーションの場合、データ タスクでメタデータを更新する前に、Metadata Manager を更新する必要があります。
次のいずれかを実行できます:
[...] をクリックし、 [メタデータを更新] をクリックして、タスク内のすべてのデータセットのメタデータを更新します。
[データセット] 内のデータセットで [...] をクリックし、 [メタデータを更新] をクリックして、単一のデータセットのメタデータを更新します。
画面の下部にある [メタデータを更新] でメタデータの更新のステータスを確認できます。
にカーソルを合わせると、メタデータが最後に更新された日時を確認できます。変更を適用するには、データ タスクを準備します。
データ タスクを準備し、変更を適用すると、変更は [メタデータを更新] から削除されます。
変更をプロパゲートするには、このタスクを使用するストレージ タスクを準備する必要があります。
列が削除されると、ストレージから履歴データが失われないように、Null 値を使用した変換が追加されます。
メタデータの更新に関する制限
同じ時間スロットで、それ以前に削除された列を含む名前変更は、同じデータ型とデータ長である場合、削除された列の名前変更に変換されます。
前: a b c d
後: a c1 d
この例では、b が削除され、c の名前が c1 に変更され、b と c のデータ型とデータ長は同じになります。
これは、b から c1 への名前変更と c の削除として識別されます。
最後の列が削除され、その前の列の名前が変更された場合でも、最後の列の名前変更は認識されません。
前: a b c d
後: a b c1
この例では、d が削除され、c の名前が c1 に変更されました。
これは、c と d の削除と c1 の追加として識別されます。
新しい列は最後に追加されると想定されます。途中に次の列と同じデータ型の列が追加されると、削除と名前変更として解釈される可能性があります。
スキーマの進化
スキーマの進化により、複数のデータ ソースに対する構造的な変更を簡単に検出し、それらの変更がタスクにどのように適用されるかを制御できます。スキーマの進化を使用すると、ソース データ スキーマに対して実行された DDL 変更を検出できます。一部の変更を自動的に適用することもできます。
変更タイプごとに、タスク設定の [スキーマの進化] セクションで変更を処理する方法を選択できます。変更を適用、変更を無視、テーブルを一時停止、またはタスクの処理を停止できます。
変更タイプごとに、DDL 変更を処理するために使用するアクションを設定できます。すべての変更タイプで、一部のアクションは使用できません。
ターゲットに適用
変更を自動的に適用します。
無視
変更を無視します。
テーブルを一時停止
テーブルを一時停止します。[モニター] では、テーブルがエラーとして表示されます。
タスクを停止
タスクの処理を停止します。これは、すべてのスキーマ変更を手動で処理する場合に便利です。これにより、スケジュールも停止され、スケジュール済みの実行は行われなくなります。
次の変更がサポートされています。
列を追加
列名を変更
列のデータ型を変更
選択パターンに一致するテーブルを追加する
[選択ルール] を使用してパターンに一致するデータセットを追加した場合、パターンを満たす新しいテーブルが検出され、追加されます。
タスク設定の詳細については、「スキーマの進化」を参照してください。
スキーマの進化によって処理される変更に関する通知を受け取ることもできます。詳細については、「動作変更時の通知の設定」を参照してください。
スキーマの進化に関する制限
スキーマの進化には次の制限が適用されます。
スキーマの進化は、更新方法として CDC を使用する場合にのみサポートされます。
スキーマの進化の設定を変更した場合は、再度タスクを準備する必要があります。
テーブルの名前を変更すると、スキーマの進化はサポートされません。この場合、タスクを準備する前にメタデータを更新する必要があります。
タスクを設計している場合は、スキーマの進化の変更を受け取るためにブラウザを更新する必要があります。変更があった場合に通知を受け取るように設定できます。
ランディング タスクでは、列のドロップはサポートされていません。列をドロップして追加すると、テーブル エラーが発生します。
ランディング タスクでは、テーブルのドロップ操作を実行してもテーブルはドロップされません。テーブルをドロップしてからテーブルを追加しても、古いテーブルが切り捨てられるだけで、新しいテーブルは追加されません。
ターゲット データベースのサポートによっては、すべてのターゲットで列の長さを変更できない場合があります。
列名が変更されると、その列を使用して定義された明示的な変換は列名に基づいているため反映されません。
メタデータの更新に対する制限は、スキーマの進化にも適用されます。
DDL の変更をキャプチャする場合、次の制限が適用されます。
ソース データベースで一連の操作が高速に実行されると (例: DDL > DML > DDL)、Qlik Talend Data Integration はログを間違った順序で解析し、データが欠落したり、予期しない動作が発生したりする可能性があります。このような事態が発生する可能性を最小限に抑えるベストプラクティスとして、次の操作を実行する前に、変更がターゲットに適用されるまで待機してください。
たとえば、変更キャプチャ中に、ソース テーブルの名前が立て続けに複数回変更されると (2 回目の操作で元の名前に戻される)、ターゲット データベースにテーブルが既に存在するというエラーが発生する可能性があります。
- タスクで使用されるテーブルの名前を変更してからタスクを停止すると、タスクの再開後に Qlik Talend Data Integration はそのテーブルに加えられた変更をキャプチャしません。
タスクが停止している間にソース テーブルの名前を変更することはサポートされていません。
- テーブルのプライマリ キー列の再割り当てはサポートされていません (したがって、DDL 履歴コントロール テーブルには書き込まれません)。
- タスクが停止している間に列のデータ型が変更され、(同じ) 列の名前が変更されると、タスクが再開されたときに DDL の変更が DDL 履歴コントロール テーブルに「列をドロップ」として表示され、その後「列を追加」として表示されます。待機時間が長引いた場合にも、同じ動作が起こる可能性があることに注意してください。
- タスクが停止している間にソースで実行された CREATE TABLE 操作は、タスクが再開されるとターゲットに適用されますが、DDL 履歴コントロール テーブルに DDL として記録されません。
メタデータの変更に関連する操作 (ALTER TABLE、再編成、クラスター化インデックスの再構築など) は、次のいずれかの方法で実行された場合、予期しない動作を引き起こす可能性があります。
フル ロード時
-または-
[プロセスの変更開始] のタイムスタンプと現在の時刻 (つまり、ユーザーが [詳細な実行オプション] ダイアログで [OK] をクリックした時点) の間。
例:
次の場合:
指定された [プロセスの変更開始] 時刻は午前 10:00 です。
および:
午前 10 時 10 分に、 [年齢] という列が [従業員] テーブルに追加されました。
および:
ユーザーは午前 10 時 15 分に [詳細な実行オプション] ダイアログで [OK] をクリックします。
その結果:
10:00 から 10:10 の間に発生した変更により、CDC エラーが発生する可能性があります。
情報メモ上記のいずれの場合でも、データがターゲットに適切に 移動済み されるように、影響を受けるテーブルをリロードする必要があります。
- DDL ステートメント
ALTER TABLE ADD/MODIFY <column> <data_type> DEFAULT <>は、既定値をターゲットにレプリケートせず、新しい列または変更された列は NULL に設定されます。列を追加または変更した DDL が過去に実行された場合でも、発生する可能性があることに注意してください。新しい列または変更された列が NULL 可能である場合、ソース エンドポイントは DDL 自体をログに記録する前にすべてのテーブル行を更新します。その結果、Qlik Talend Data Integration は変更をキャプチャしますが、ターゲットは更新しません。新しい列または変更された列が NULL に設定されているため、ターゲット テーブルにプライマリ キーまたは一意のインデックスがない場合、後続の更新では「影響を受ける行は 0 行です」というメッセージが生成されます。 TIMESTAMP および DATE 精度列への変更はキャプチャされません。
データ レイクにデータをランディングする際の制限と考慮事項
変換には次の制限があります。
- 右から左に記述する言語の列では、変換はサポートされません。
名前に特殊文字 (例: #、\、/、-) が含まれる列では変換を実行できません。
- LOB/CLOB データ型でサポートされている唯一の変換は、ターゲット上の列をドロップすることです。
- 変換を使用して列の名前を変更し、同じ名前の新しい列を追加することはサポートされていません。
移動された列では、直接変更または変換ルールを使用して Null 可能性を変更することはサポートされていません。ただし、タスクで作成された新しい列は、既定で Null 可能です。