メインフレームからクラウドへのデータ移行が容易に

※この投稿は米国時間 2022 年 7 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

IBM のメインフレームは 1950 年代に登場し、多くの組織で今日でも重要な役割を担っています。近年、メインフレームを利用している多くの企業が、クラウドへの移行を進めています。妥当性の維持、メインフレーム専門家の減少、クラウド ソリューションによるコスト削減がその要因です。

メインフレームからの移行で直面する主な課題の一つは、クラウドへのデータ移行です。移行に役立つツールとして、Google が bigquery-zos-mainframe コネクタをオープンソース化しているため、この作業を非常に簡単に行えます。

BigQuery および Cloud Storage 用メインフレーム コネクタとは？

メインフレーム コネクタを使用すると、Google Cloud ユーザーがデータを Cloud Storage にアップロードし、ジョブ制御言語（JCL）で定義されたメインフレームベースのバッチジョブから、BigQuery ジョブを送信できます。内蔵されたシェル インタプリタと、JVM ベースで実装された gsutil および bq コマンドライン ユーティリティによって、ELT パイプライン全体を z/OS から完全に管理できます。

このツールはメインフレーム上のデータを Cloud Storage および BigQuery に移動します。またデータセットを直接 ORC（BigQuery がサポートする形式）にコード変換します。さらに、ユーザーが JCL から BigQuery ジョブを実行できるので、Google Cloud の非常に強力なサービスをメインフレーム ジョブで利用できます。

このコネクタは、コピーブックで容易に表現可能な 2 進整数、パック 10 進数、EBCDIC 文字フィールドを含む、IBM DB2 EXPORT で作成されたフラット ファイルでテストされています。VSAM ファイルをお持ちのお客様は、IDCAMS REPRO を使用してフラット ファイルにエクスポートしてから、このツールを使用してアップロードできます。この ORC へのコード変換にはコピーブックが必要で、すべてのレコードが同じレイアウトになっている必要があります。可変レイアウトの場合はコード変換できませんが、データセットの単純な 2 進コピーをアップロードすることはできます。

bigquery-zos-mainframe コネクタの使用

メインフレーム コネクタの標準的フローには次のステップがあります。

1. メインフレーム データセットの読み取り

2. データセットの ORC へのコード変換

3. Cloud Storage への ORC のアップロード

4. 外部テーブルとしての登録

5. MERGE DML ステートメントの実行による、ターゲット テーブルへの新しい増分データの読み込み

読み込み後にデータセットの変更が不要な場合は、外部テーブルに読み込むよりも、ネイティブ テーブルに読み込むほうがうまくいきます。

ステップ 2 では、DB2 エクスポートがメインフレームの順次データセットに書き込まれ、コネクタがデータセットのコピーブックを使用して ORC にコード変換することに注意してください。

次の簡単な例は、メインフレーム上のデータを読み取り、それを ORC 形式にデータ変換し、その ORC ファイルを Cloud Storage にコピーして、BigQuery ネイティブ テーブルに読み込み、そのテーブルに対する SQL を実行する様子を示しています。

1. 確認とコンパイル:

2. target/scala-2.13 で作成したアセンブリ jar を、メインフレームの UNIX ファイルシステム上のパスにアップロードします。

3. PROCLIB として使用するすべてのメインフレーム パーティション分割データセットに、BQSH JCL プロシージャをインストールします。プロシージャを編集し、アセンブリ jar のアップロード先の UNIX ファイルシステム パスになるよう、Java クラスパスを更新します。プロシージャの編集では、サイト固有の環境変数も設定できます。

4. ジョブの作成

ステップ 1:

このステップでは INFILE DD からデータセットを読み取り、COPYBOOK DD からレコード レイアウトを読み取ります。入力データセットは、IBM DB2 または VSAM ファイルからエクスポートされたフラット ファイルです。入力データセットから読み取られたレコードと、データ量から決定されたパーティション数が、gs://bucket/my_table.orc にある ORC ファイルに書き込まれます。

ステップ 2:

このステップでは、my_table.orc から MY_DATASET.MY_TABLE に ORC ファイル パーティションを読み込む、BigQuery load ジョブを送信します。このパスは前のステップで書き込まれています。

ステップ 3:

このステップでは、QUERY DD（LRECL が 80 のフォーマット FB ファイル）から SQL DML read を実行する、BigQuery Query ジョブを送信します。通常、クエリは MERGE または SELECT INTO DML ステートメントであり、BigQuery テーブルが変換されます。注: コネクタはジョブ指標をログに記録しますが、クエリ結果はファイルに書き込みません。

メインフレーム外での実行による MIPS の削減

大量の転送を伴う本番環境レベルの読み込みをスケジュール設定する際は、プロセッサの使用率が問題になることがあります。メインフレーム コネクタは JVM プロセス内で実行されるため、デフォルトで zIIP プロセッサを使用する必要がありますが、容量が不足すると、汎用プロセッサまで使用されることがあります。z/OS レコードのコード変換と ORC ファイル パーティションの書き込みには、少なくない量の処理が必要なため、メインフレーム コネクタにはクラウド サーバーでのコンピューティング負荷の高いオペレーションの処理用に設計された gRPC サーバーが含まれます。そのため z/OS で実行されるプロセスに求められるのは、Cloud Storage へのデータセットのアップロードと、RPC 呼び出しを行うことだけです。ローカル実行とリモート実行の切り替えは、環境変数を変更するだけで行えます。この機能の詳細についてはこちらをご覧ください。

^謝辞

^{ツールのテスト、デバッグ、メンテナンス、拡張を行ってくれた、以下のメンバーに感謝します。Timothy Manuel、Catherine Im、Madhavi Kancharla、Suresh Balakrishnan、Viktor Fedinchuk、Pavlo Kravets}