[IDMC]IDMCのレプリケーション機能”CDIR”でデータをGoogleBigQueryに投入する勘所メモ

## はじめに
Informatica Intelligent Data Management Cloud(IDMC/旧称IICS)でのちょっとしたTipsを纏めていきます。日々の活動の中で検証した結果記録であり、忘れやすい自分のためのメモですが、少しでも皆様のお役に立てればと思い公開していきます。記述方法など試行錯誤しており随時更新するかもしれません。

## CDIRでGoogleBigQueryにデータを投入する(ターゲット)際の設定例
CDIR Cloud Data Ingestion and Replication でデータをGoogle Big Queryに投入する際の設定例を纏めます。残念ながらマニュアルを見ても分からない点が多いため、、ここで纏めておきます。皆様のお役に立ってくれることを願います。

:::note info
この記事は以前記載したこの記事 
[[IDMC]IDMCのレプリケーション機能”CDIR”でMarketoのデータをリアルタイムで簡単レプリケーション(差分も)](https://qiita.com/asekine-infajp/items/518113b4f997131e0d1f)
の派生記事とさせて頂いてます。記事ではターゲットをSnowflakeにしていましたが、今回ターゲットをGoogleBigQueryにする場合の設定を書いてみました。
前提となる上記記事も併せて参照ください。
:::

## Cloud Data Ingestion and Replication Applicationでタスクを設定する
- ステップ1：”定義”
- ステップ2：”ソース” 
ソース(Marketo)の設定までは、既に記載している記事を参照ください。

- ステップ3：”ターゲット”
事前に、今回利用するGoogle Big Query V2コネクタは事前に設定しておきました。
特にCDIR用に特別に必要な設定はありません。CDI等で利用するのと同じコネクタを利用出来ます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/1e739100-8eb4-bf0a-0bf5-7e0cca271038.png)

その1：上段部
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/639f2c63-c984-638c-0126-bce20ce44394.png)
接続：事前に設定済みのGoogle Big Query V2コネクタ設定を選択
スキーマ：①Google Big Queryにおけるスキーマを選択。このスキーマ内に新規テーブルを作成してデータをレプリケーションします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/6e8be568-e96c-b9e9-c134-b8a2983f23d8.png)

バケット：②Google Cloud Storageのバケット名。バケットがない場合は事前に作成しておく必要が有る様子。
タスクターゲットディレクトリ：②のバケット配下のディレクトリ。頭にスラッシュ(/)が必要な点に注意。ステージング処理に使う一時領域みたいな物。ディレクトリは事前に作成しておかなくてもOK。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/acd5c01c-f86d-6ac8-85c9-a03aefdcdeb9.png)

その2：下段部
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/065d5b40-104f-c7c1-c4a9-b095df55b807.png)
(オプション)最終レプリケート時刻を追加：ターゲット側にデータがレプリケートされた時刻を記録する新規列を追加します。差分連携時のデータ判断に利用出来たり便利なのでチェックしておきます。

- ステップ4：”スケジュール及びランタイムオプション”
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/715493f4-a79c-e1f3-75b2-56e03c0c0dd7.png)
今回は手動で起動する予定でありスケジュール設定しない為、デフォルトのままでOK。このまま「保存」します。

- 最終ステップ：デプロイ
実行出来るようにデプロイを実施します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/be32b35f-6b3b-de02-71e6-4ae4171271c6.png)
デプロイをクリックするとデプロイ処理が実施されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/39722fcb-27ef-bb90-3a53-f0cc9ae6c385.png)

## Cloud Data Ingestion and Replication Applicationタスクを実行(起動)する
デプロイが完了したらタスクを実行しましょう。
実行・監視はオペレーションインサイトから行います。

オペレーションインサイト に移動し、左側メニューから”データ取り込みおよびレプリケーション”をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/dd6537d9-4252-4553-2577-80ac3bdba24d.png)
すべてのジョブ タブをクリックすると、先ほどデプロイしたアプリケーション取込タスクがデプロイされています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/29003f02-2841-f33b-84c3-c68d7738d872.png)

一番右端のメニューから”実行”をクリックすれば実行が開始されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/5e9091f7-c405-e97a-7c3d-a8e17c11efea.png)

ジョブ名のリンクをクリックし、タスクサマリ画面へ移動しましょう。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/931c5356-ff65-2f8e-cbee-ff412b26a0dc.png)

キューへ格納 -> 開始 -> 実行中 と変化していきます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/985f98a7-727f-baa3-ea30-7983fd573d96.png)

画面下部では、現在どのような処理で何件レプリケーションされたかが表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/bc7392fe-2be0-9472-a161-0bed268ddff3.png)

以上で設定から実行まで、慣れれば10分もかからず実施可能となります。
Google Big Queryでは、バケット名やディレクトリ名の記述方法を間違わないようにご注意ください。間違うと、実行して動き出しますが、データが投入できずエラーとなります。

### 補足：BigQury側で確認
ちゃんとデータがレプリケーションされています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2985453/e338e28a-b3e8-ee7e-aa0f-d2aca0c7e277.png)

### マニュアルに記載の無い注意点：
Google Biq Queryのデータのロケーションとステージング領域として使うGoogle Cloud Storageのbucketのロケーションは同一となるように設定しないといけません。たとえばGoogle Big Queryのデータのロケーションが[US]であれば、利用するGoogle Cloud Storageのbucketも[US]"マルチリージョン"にする必要があります。もし不一致があると実行した際にデータが投入できずエラーが発生します。自分の場合オペレーションインサイトからダウンロード出来る実行ログ(Job_log_xxx_xxxxxxxxx.txt)の中に以下のような出力があったため、気がつきました。

:::note alert 
"message": "Cannot read and write in different locations: source: us-east1, destination: US"
:::

ステップ3：”ターゲット”で設定するバケットで利用するbucketがus-east1リージョンだったため、US マルチリージョンのbuketを作成して利用するように設定し直したところエラーを回避出来ました。

## まとめ
IDMCは単なるETLツールでは無く、上記のようなWizard形式による簡単レプリケーションも実装できます。簡単ですが以上です。

###### 検索用
Informatica / IDMC / Intelligent Data Management Cloud / IICS / Data Integration / CDI / CMI / CDIR / Mass Ingestion / CDQ / CDP / Profiling / CDGC / CDMP / CLAIRE / AI / SecureAgent / ランタイム / マスインジェスチョン / マルケト / Marketo / Snowflake