DataStage-aaS Anywhereでジョブ作成/実行してみた
投稿者：泉 亮太郎
こんにちは！
NI+C DataOpsチームの泉です。
本Techブログは2023年11月16日にIBMより新しくリリースされたDataStage-aaS Anywhere（以降、DataStage Anywhereとします）の連載第2回目となり、ジョブの作成/実行した結果をまとめております。
なお、第1回目”DataStage-aaS Anywhereを導入してみた”はこちらで紹介しておりますので、併せてご参照下さい。
■DataStage-aaS Anywhereの利点
IBM Cloud上で提供される既存のDataStage as a Service（DataStage SaaS）の場合はpx-runtime（実行エンジン）がクラウド上にあるため、実データのやりとりはクラウドを経由して送受信することになります。
しかし、DataStage Anywhereの場合はpx-runtime（実行エンジン）を任意のロケーション（オンプレミス、AWSやGCP等の自社クラウド環境）に導入し動かすことができるという特徴があります。その為、実データをDataStage（コントロールブレーン）と送受信することはないため、セキュリティを確保することができます。実データはクラウドを経由することなくデータ源とデータ連携先間で送受信するといった使い方ができるようになります。
以下にDataStage SaaSとDataStage AnywhereでGoogle Cloud Storage（以下、GCSとします）のデータをBigQueryにロードする場合のデータ処理の流れを載せております。データ処理の流れからも分かるようにDataStage SaaSの場合は実データをGCP、BQ→IBM Cloud間で送受信することになります。一方で、DataStage Anywhereの場合はGCP、BQ→IBM Cloud間は実データを送受信することはないため、利用用途や扱うデータの特性に応じて使い分けることが可能です。
♦DataStage SaaSの場合
♦DataStage-aaS Anywhereの場合
次作業からは実際にDataStage Anywhereを使用してジョブを作成/実行してみます。
■ジョブの作成/実行
今回データソースにはGCSに格納している2つのcsvファイル、出力先にはBigQueryのテーブルを使用します。
使用するcsvファイルのデータ内容は以下の通りとなります。
♦Student.csv
| student_id | student_name | sex |
| 1 | 山田 太郎 | 男性 |
| 2 | 田中花子 | 女性 |
| 3 | 佐藤 健太 | 男性 |
♦Cource.csv
| student_id | cource_name |
| 1 | 数学 |
| 1 | 物理 |
| 2 | 化学 |
| 3 | 国語 |
| 3 | 日本史 |
出力先のテーブル情報は以下の通りとなります。
♦Student_Cource_List
| フィールド名 | タイプ | モード |
| student_id | string | nullable |
| student_name | string | nullable |
| sex | string | nullable |
| cource_name | string | nullable |
作成するジョブの処理概要・処理フロー図は以下の通りとなります。
※px-runtime（実行エンジン）は弊社が社内環境として使用しているGCP上のGoogle Compute Engineに導入しております。
＜処理概要＞
①GCSからStudent.csvとCource.csvを抽出
②Joinステージを使用してstudent_idをキーにStudent.csvとCource.csvを結合
③Transformerステージを使用してStudent_nameカラムに含まれる全角の空白を削除
④加工したデータをBigQueryのStudent_Cource_Listテーブルに格納
＜処理フロー図＞
それではジョブを作成していきます。
１．資産画面右上にある新規資産をクリックします。
２．DataStageを選択します。
３．DataStageフローの名前を指定(nic_test）して、右下の作成をクリックします。
４．DataStageフロー作成画面の上部にある設定をクリックします。
５．実行メニュー画面のランタイムで導入したpx-runtime（実行エンジン）を指定し、右下の保存をクリックします。
６．DataStageジョブフロー作成画面の左側にあるコンポーネント一覧からGoogle Cloud Storage・Google BigQuery・
Joinステージ・Transformerステージを選択し、中央にドラック＆ドロップします。
また、各コンポーネントの名前を分かりやすいように変更しておきます。
７．Google Cloud Storageをクリックし、データソースの設定を行います。
設定が必要な項目は以下の通りとなります。
※今回は事前に接続情報のパラメータを作成して設定時に使用しております。
本TechBlogではパラメータの作成方法は割愛させていただきますが、興味のある方はIBMのDataStage でのパラメーター・
セットの作成と使用をご参照ください。
＜設定が必要な項目＞
①プロジェクトID
②資格情報（JSON形式のサービスアカウントキー）
③バケット名
④ファイル名
８．Joinステージをクリックし、結合キーにstudent_idを指定します。
９．Transformerステージをクリックし、student_nameカラムに対して空白を削除する関数を指定します。
１０．Google BigQueryの設定を行います。
設定が必要な項目は以下の通りとなります。
＜設定が必要な項目＞
①資格情報（JSON形式のサービスアカウントキー）
②プロジェクトID
③データセット名
④表名
１１．各コンポーネントの設定が完了しましたので保存して実行をクリックします。
ジョブが正常に実行された場合”正常に実行されました”と表示されます。
ジョブが正常に実行されたことが確認できましたので、実際にBigQuery側でデータが格納されていることも確認してみます。
問題なくStudent_Cource_Listテーブルにデータが格納されていますね。
動作する実行エンジンが異なるため、作成したジョブをIBM Cloud上のSaaSで動かすか、任意のロケーションで動かすかという違いはありますが、DataStage SaaSと同じ手順・画面でジョブの作成/実行ができます。
■まとめ
今回はDataStage Anywhereを使用して実際にジョブを作成/実行してみました。
Datastage Anywhereの使用感はDataStage SaaSと比較して変わりはありませんが、DataStage Anywhereの場合は任意のロケーションでジョブの実行がされるため、社内で保持しているデータをクラウド側と送受信することはなくセキュリティを担保することができます。
自身の感想にはなりますが、実際にジョブ作成/実行してみて以下の状況で悩まれているお客様にとってDataStage Anywhereは最適なツールであると改めて感じました。
・オンプレ上にETLツールを導入していてクラウドシフトしたいと考えているが、一方で社内データはオンプレ上に存在している
ためクラウド側と実データのやり取りを行いたくないお客様
クラウドへの移行を考えている場合はDataStage Anywhereをご検討の一つに入れてみてはいかがでしょうか。
■Tips
♦px-runtime（実行エンジン）の導入に失敗した件
px-runtime（実行エンジン）を複数導入するケースや、一度インストールしたpx-runtimeを導入し直すといったようなケースにおいて注意点があります。 px-runtimeの導入時において下記画像のpx-runtime（実行エンジン）名を入力する際、既に導入済みのpx-runtime名と同名にしてしまうとジョブ作成後のコンパイル時にエラーが発生します。複数px-runtime（実行エンジン）を導入するケースやpx-runtimeを導入しなおすケースでは違う名前で導入するようにしてください。
こちらの導入手順のブログとあわせてご確認ください。
$ ./dsengine.sh start -n "px-runtime" -a "$IBMCLOUD_APIKEY" -e "$ENCRYPTION_KEY" -i "$ENCRYPTION_IV" -p "$IBMCLOUD_CONTAINER_REGISTRY_APIKEY" --project-id "$PROJECT_ID
