Netezza 移行のためのデータ移行、ETL、読み込み

  • [アーティクル]

この記事は、Netezza から Azure Synapse Analytics に移行する方法に関するガイダンスを提供する 7 つのパートから成るシリーズのパート 2 です。 この記事で注目するのは、ETL と読み込みの移行に関するベスト プラクティスです。

データ移行に関する考慮事項

Netezza からのデータ移行に関する最初の決定

Netezza データ ウェアハウスを移行するときには、基本的なデータ関連の質問をいくつかする必要があります。 次に例を示します。

  • 未使用のテーブル構造を移行する必要がありますか?

  • リスクとユーザーへの影響を最小限に抑えるために最適な移行方法は何ですか?

  • データ マートを移行するとき: 物理を維持しますか、仮想に移行しますか?

以降のセクションでは、Netezza からの移行のコンテキスト内で、これらの点について説明します。

使用されていないテーブルを移行しますか?

ヒント

レガシ システムでは、テーブルが時間の経過と共に冗長になることは珍しくありません。ほとんどの場合、これらを移行する必要はありません。

既存のシステムで使用されているテーブルのみを移行する方が合理的です。 アクティブでないテーブルは、移行するのではなく、アーカイブできます。これにより、将来必要に応じてデータを使用できます。 ドキュメントは最新ではない可能性があるため、使用中のテーブルを判別するには、ドキュメントではなくシステム メタデータとログ ファイルを使用することをお勧めします。

有効になっている場合は、Netezza クエリ履歴テーブルに、特定のテーブルが最後にアクセスされた時点を判別できる情報が含まれています。この情報を使用して、テーブルが移行の候補であるかどうかを判断できます。

以下に、特定の時間枠内に特定のテーブルが使用された状況を調べるクエリの例を示します。

SELECT FORMAT_TABLE_ACCESS (usage),
  hq.submittime
FROM "$v_hist_queries" hq
  INNER JOIN "$hist_table_access_3" hta USING
(NPSID, NPSINSTANCEID, OPID, SESSIONID)
WHERE hq.dbname = 'PROD'
AND hta.schemaname = 'ADMIN'
AND hta.tablename = 'TEST_1'
AND hq.SUBMITTIME > '01-01-2015'
AND hq.SUBMITTIME <= '08-06-2015'
AND
(
  instr(FORMAT_TABLE_ACCESS(usage),'ins') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'upd') > 0
  OR instr(FORMAT_TABLE_ACCESS(usage),'del') > 0
)
AND status=0;

| FORMAT_TABLE_ACCESS | SUBMITTIME
----------------------+---------------------------
ins                   | 2015-06-16 18:32:25.728042
ins                   | 2015-06-16 17:46:14.337105
ins                   | 2015-06-16 17:47:14.430995
(3 rows)

このクエリでは、ヘルパー関数 FORMAT_TABLE_ACCESS と、$v_hist_table_access_3 ビューの末尾にある数字を使用して、インストールされているクエリ履歴のバージョンを照合します。

リスクとユーザーへの影響を最小限に抑えるために最適な移行方法は何ですか?

企業でこの質問が頻繁に取り上げられるのは、企業はデータ ウェアハウス データ モデルへの変更の影響を軽減し、機敏性を向上させたいと考える場合が多いためです。 多くの場合、企業は ETL の移行中にデータをさらに最新化または変換する機会を見つけます。 このアプローチでは、複数の要因が同時に変化し、古いシステムと新しいシステムの結果を比較することが困難になるため、リスクがいっそう高くなります。 ここでデータ モデルを変更すると、他のシステムへのアップストリームまたはダウンストリームの ETL ジョブにも影響する可能性があります。 そのリスクのため、この規模での再設計はデータ ウェアハウス移行後に行うことをお勧めします。

データ モデルが移行全体の一部として意図的に変更される場合であっても、新しいプラットフォームで再エンジニアリングを行うのではなく、既存のモデルをそのまま Azure Synapse に移行するのがよい方法です。 このようにすると、既存の運用システムへの影響が最小限になる一方で、1 回限りの再エンジニアリング タスクに対しては Azure プラットフォームのパフォーマンスと柔軟なスケーラビリティによる利点があります。

Netezza からの移行時には、既存のデータ モデルが既にそのままで Azure Synapse への移行に適していることがよくあります。

ヒント

データ モデルに対する変更が将来計画されている場合でも、最初は既存のモデルをそのまま移行します。

物理データ マートを維持しますか、仮想データ マートに移行しますか?

ヒント

データ マートを仮想化すると、ストレージと処理のリソースを節約できます。

Netezza のレガシ データ ウェアハウス環境では、組織内の特定の部門またはビジネス機能に対して、パフォーマンスの優れたアド ホック セルフサービス クエリとレポート機能を提供するために構成されたいくつかのデータ マートを作成するのが一般的です。 そのためデータ マートは、通常、データ ウェアハウスのサブセットで構成されており、ユーザーが Microsoft Power BI、Tableau、MicroStrategy などのユーザーフレンドリなクエリ ツールを使用して短い応答時間で簡単にそれらのデータをクエリできる形式で、集計されたバージョンのデータが格納されています。 この形式は通常、ディメンション データ モデルです。 データ マートの使用方法の 1 つは、基になるウェアハウス データ モデルが異なる (データ コンテナーである、などの) 場合でも、使用可能な形式でデータを公開することです。

組織内の個々の部署に対して別々のデータ マートを使用すると、ユーザーに自分に関係する特定のデータ マートへのアクセスのみを許可し、機密データを排除、難読化、または匿名化することにより、堅牢なデータ セキュリティ体制を実装できます。

これらのデータ マートが物理テーブルとして実装されている場合は、それらを格納するための追加のストレージ リソースと、それらを定期的にビルドおよび更新するための追加の処理が必要になります。 また、マート内のデータは、最後の更新操作の時点での最新状態を保っているだけなので、変動の激しいデータ ダッシュボードには適さない可能性があります。

ヒント

Azure Synapse のパフォーマンスとスケーラビリティにより、パフォーマンスを犠牲にすることなく仮想化が可能になります。

Azure Synapse などの比較的低コストでスケーラブルな MPP アーキテクチャの出現と、そのようなアーキテクチャに固有のパフォーマンス特性により、マートを物理テーブルのセットとしてインスタンス化しなくても、データ マート機能を提供できる可能性があります。 これは、データ マートの効率的な仮想化を、メイン データ ウェアハウスに対する SQL ビューを介して行うか、Azure や Microsoft パートナーの仮想化製品のビューなどの機能を使用して仮想化レイヤーを介して行うことで実現されます。 この方法では、追加のストレージと集計処理の必要性が軽減されるか不要になるため、移行する必要のあるデータベース オブジェクトの総数が減少します。

このアプローチには、もう 1 つの潜在的な利点があります。 仮想化レイヤー内に集計と結合のロジックを実装し、仮想化されたビューを介して外部レポート ツールを表示することにより、これらのビューを作成するのに必要な処理がデータ ウェアハウスに "プッシュ ダウン" されます。データ ウェアハウスは、通常、大量のデータに対して結合、集計などの関連する操作を実行するのに最適な場所です。

物理データ マートよりも仮想データ マートの実装を選択する主な推進要因は、以下のとおりです。

  • 機敏性の向上: 仮想データ マートの方が、物理テーブルとその関連 ETL プロセスよりも変更しやすい。

  • 総保有コストの低下: 仮想化された実装では必要なデータ ストアとデータのコピー数が少なくなる。

  • 移行のための ETL ジョブを排除でき、仮想化環境のデータ ウェアハウス アーキテクチャが簡素化される。

  • パフォーマンス: これまでのところ物理データ マートの方がパフォーマンスは優れているとはいえ、仮想化製品にはその差を軽減するためのインテリジェントなキャッシュ手法が実装されるようになっている。

Netezza からのデータ移行

データを理解する

移行計画の一部は、移行する必要があるデータの量を詳しく理解することです。それが、移行方法に関する決定に影響を与える可能性があるためです。 システム メタデータを使用して、移行するテーブル内で "生データ" によって占有されている物理領域を判別します。 この文脈では、"生データ" とは、インデックスや圧縮などのオーバーヘッドを除く、テーブル内でデータ行によって使用されている領域のサイズを意味します。 これが特に当てはまるのは最大レベルのファクト テーブルです。これらのテーブルは、一般に、データの 95% 以上を構成しているためです。

データの代表的なサンプル (100 万行など) を、非圧縮のフラットな ASCII 区切りデータ ファイルに抽出することにより、特定のテーブルで移行されることになるデータの量について、正確な数字を取得できます。 次に、そのファイルのサイズを使用して、そのテーブルの行あたりの平均生データ サイズを取得します。 最後に、その平均サイズに、テーブル全体に含まれる行の総数を掛けて、そのテーブルの生データ サイズを求めます。 その生データ サイズを計画で使用します。

Netezza データ型マッピング

ヒント

準備フェーズの一環として、サポートされていないデータ型の影響を評価します。

ほとんどの Netezza データ型には、Azure Synapse に直接相当するものがあります。 次の表に、これらのデータ型と共に、それらをマッピングする際にお勧めする方法を示します。

Netezza のデータ型 Azure Synapse のデータ型
bigint bigint
BINARY VARYING(n) VARBINARY(n)
BOOLEAN BIT
BYTEINT TINYINT
CHARACTER VARYING(n) VARCHAR(n)
CHARACTER(n) CHAR(n)
DATE DATE(date)
DECIMAL(p,s) DECIMAL(p,s)
DOUBLE PRECISION FLOAT
FLOAT(n) FLOAT(n)
INTEGER INT
INTERVAL INTERVAL データ型は、現在 Azure Synapse Analytics では直接サポートされていませんが、DATEDIFF などのテンポラル関数を使用して計算できます。
MONEY MONEY
NATIONAL CHARACTER VARYING(n) NVARCHAR(n)
NATIONAL CHARACTER(n) NCHAR(n)
NUMERIC(p,s) NUMERIC(p,s)
real 実数
SMALLINT SMALLINT
ST_GEOMETRY(n) ST_GEOMETRY などの空間データ型は、現在 Azure Synapse Analytics ではサポートされていませんが、データは VARCHAR または VARBINARY として格納できます。
TIME TIME
TIME WITH TIME ZONE DATETIMEOFFSET
timestamp DATETIME

Netezza カタログ テーブルのメタデータを使用して、これらのデータ型のいずれかを移行する必要があるかどうかを判断し、移行計画でそれを考慮に入れます。 この種類のクエリで重要な Netezza のメタデータ ビューは以下のとおりです。

  • _V_USER: このユーザー ビューでは、Netezza システム内のユーザーに関する情報が提供されます。

  • _V_TABLE: このテーブル ビューには、Netezza パフォーマンス システムで作成されたテーブルの一覧が含まれています。

  • _V_RELATION_COLUMN: リレーション列のシステム カタログ ビューには、テーブルで使用できる列が含まれています。

  • _V_OBJECTS: このオブジェクト ビューでは、Netezza で使用できるテーブル、ビュー、関数などのさまざまなオブジェクトが一覧表示されます。

たとえば、次の Netezza SQL クエリでは、列と列の型が表示されます。

SELECT
tablename,
  attname AS COL_NAME,
  b.FORMAT_TYPE AS COL_TYPE,
  attnum AS COL_NUM
FROM _v_table a
  JOIN _v_relation_column b
  ON a.objid = b.objid
WHERE a.tablename = 'ATT_TEST'
AND a.schema = 'ADMIN'
ORDER BY attnum;

TABLENAME | COL_NAME    | COL_TYPE             | COL_NUM
----------+-------------+----------------------+--------
ATT_TEST  | COL_INT     | INTEGER              | 1
ATT_TEST  | COL_NUMERIC | NUMERIC(10,2)        | 2
ATT_TEST  | COL_VARCHAR | CHARACTER VARYING(5) | 3
ATT_TEST  | COL_DATE    | DATE                 | 4
(4 rows)

このクエリは、サポートされていないデータ型がもしあった場合はすべてのテーブルを検索するように変更できます。

Azure Data Factory を使用して、Netezza のレガシ環境からデータを移動できます。 詳細については、IBM Netezza コネクタに関する記事を参照してください。

前述したように、サードパーティ ベンダーが、データ型のマッピングなど、移行を自動化するためのツールとサービスを提供しています。 また、Netezza 環境で既に使用されている Informatica や Talend などのサード パーティー製 ETL ツールで、必要とされるすべてのデータ変換を実装できます。 次のセクションでは、既存のサードパーティ製 ETL プロセスの移行について説明します。

ETL 移行に関する考慮事項

Netezza ETL 移行に関する最初の決定

ヒント

前もって ETL 移行の方法を計画し、適切なところで Azure の機能を活用します。

Netezza のレガシ データ ウェアハウスでは、ETL/ELT 処理のために、nzsql や nzload などの Netezza ユーティリティ、または Informatica や Ab Initio などのサードパーティ製 ETL ツールを使用するカスタムビルド スクリプトを使用することがあります。 Netezza データ ウェアハウスでは、時間の経過と共に進化した、ETL と ELT を組み合わせた方法を使用している場合があります。 Azure Synapse への移行を計画するときには、関連するコストとリスクを最小限に抑えながら、必要な ETL/ELT 処理を新しい環境に実装するのに最適な方法を判断する必要があります。 ETL と ELT の処理の詳細については、ELT と ETL の設計方法の比較に関するページを参照してください。

以降のセクションでは、移行オプションについて説明し、さまざまなユース ケースに関する推奨事項を示します。 このフローチャートは、1 つの方法をまとめたものです。

移行オプションのフローチャートと推奨事項。

最初の手順では常に、移行する必要がある ETL/ELT プロセスのインベントリを作成します。 他の手順と同様に、標準の "組み込み" Azure 機能により、既存のプロセスの一部を移行する必要がなくなる場合があります。 計画目的では、実行する移行の規模を理解することが重要です。

前のフローチャートでは、決定 1 は、完全に Azure ネイティブの環境に移行するかどうかに関する高レベルの決定に関連しています。 完全に Azure ネイティブの環境に移行する場合は、Azure Data Factory のパイプラインとアクティビティまたは Azure Synapse Pipelines を使用して、ETL 処理を再エンジニアリングすることをお勧めします。 完全に Azure ネイティブの環境に移行しない場合は、既存のサードパーティの ETL ツールを既に使用中であるかどうかが、決定 2 です。

ヒント

既存のサードパーティ ツールへの投資を活用して、コストとリスクを軽減します。

サードパーティの ETL ツールが既に使用されていて、特にスキルに大きな投資が行われている場合や、複数の既存のワークフローとスケジュールがそのツールを使用している場合は、そのツールがターゲット環境として Azure Synapse を効率的にサポートできるかどうかが、決定 3 です。 最も効率的なデータ読み込みのためには、PolyBase や COPY INTO などの Azure 機能を活用できる "ネイティブ" コネクタがそのツールに含まれていれば理想的です。 PolyBase や COPY INTO などの外部プロセスを呼び出し、適切なパラメーターを渡す方法があります。 この場合は、Azure Synapse を新しいターゲット環境として、既存のスキルとワークフローを活用します。

既存のサードパーティの ETL ツールを持ち続ける場合は、(既存のオンプレミス ETL サーバーに対してではなく) Azure 環境内でそのツールを実行し、既存のワークフローの全体的オーケストレーションを Azure Data Factory に処理させるという利点が得られることがあります。 注目すべき利点の 1 つは、Azure からダウンロードし、処理してから、Azure に再びアップロードする必要があるデータが少なくなる点です。 そのため、決定 4 は、既存のツールをそのまま実行するか、Azure 環境に移行してコスト、パフォーマンス、スケーラビリティの利点を実現するかです。

既存の Netezza 固有のスクリプトを再エンジニアリングする

既存の Netezza ウェアハウス ETL/ELT 処理の一部またはすべてが、nzsql や nzload などの Netezza 固有のユーティリティを利用するカスタム スクリプトによって処理される場合は、これらのスクリプトを、新しい Azure Synapse 環境用に再コーディングする必要があります。 同様に、ETL プロセスが Netezza のストアド プロシージャを使用して実装された場合は、これらのプロセスも再コーディングする必要があります。

ヒント

移行する ETL タスクのインベントリには、スクリプトとストアド プロシージャが含まれている必要があります。

ETL プロセスの一部の要素は、たとえば、外部ファイルからステージング テーブルへの単純な一括データ読み込みにより、簡単に移行できます。 プロセスのそれらの部分は、たとえば nzload ではなく PolyBase を使用して自動化することさえできます。 任意の複雑な SQL やストアド プロシージャが含まれるプロセスの他の部分については、再エンジニアリングにかかる時間が長くなります。

Azure Synapse との互換性について Netezza SQL をテストする方法の 1 つは、Netezza のクエリ履歴から代表的な SQL ステートメントをいくつかキャプチャし、それらのクエリにプレフィックス EXPLAIN を付けてから、(Azure Synapse での同種同士の移行データ モデルを想定して) Azure Synapse でそれらの EXPLAIN EXPLAIN ステートメントを実行することです。 互換性のない SQL ではエラーが生成されるので、エラー情報によって、再コーディング タスクの規模を特定できます。

Microsoft パートナーは、Netezza の SQL とストアド プロシージャを Azure Synapse に移行するためのツールとサービスを提供しています。

サードパーティの ETL ツールを使用する

前のセクションで説明したように、多くの場合、既存のレガシ データ ウェアハウス システムには、サードパーティの ETL 製品によって事前にデータが取り込まれ、保守されます。 Azure Synapse を対象とする Microsoft データ統合パートナーの一覧については、データ統合パートナーに関するページを参照してください。

Netezza からのデータの読み込み

Netezza からデータを読み込むときに使用できる選択肢

ヒント

サードパーティ ツールを使用して移行プロセスの簡略化と自動化を行えば、リスクを軽減できます。

Netezza データ ウェアハウスからのデータ移行に関して言えば、データ読み込みに関連するいくつかの基本的な質問を解決する必要があります。 既存のオンプレミス Netezza 環境からクラウドの Azure Synapse にデータを物理的に移動する方法のほか、転送と読み込みを実行するために使用するツールを決定する必要があります。 以降のセクションで説明する次の質問を検討してください。

  • データをファイルに抽出しますか、ネットワーク接続を介して直接移動しますか?

  • プロセスのオーケストレーションは、ソース システムから行いますか、ターゲットの Azure 環境から行いますか?

  • プロセスの自動化と管理にはどのツールを使用しますか?

ファイルとネットワーク接続のどちらを介してデータを転送するか

ヒント

移行するデータの量と使用可能なネットワーク帯域幅を把握します。これらの要因が移行方法の決定に影響を与えるためです。

移行するデータベース テーブルが Azure Synapse 内に作成されたら、データを移動して、Netezza のレガシ システムからそれらのテーブルにデータを取り込み、新しい環境に入れることができます。 基本的な方法は 2 つあります。

  • ファイルの抽出: Netezza テーブルからフラット ファイルに、通常は CSV 形式でデータを抽出します。-o オプションを指定して nzsql を使用するか、CREATE EXTERNAL TABLE ステートメントを使用します。 データ スループットの観点からは外部テーブルが最も効率的であるため、可能な限りこれを使用します。 次の SQL 例では、外部テーブルを介して CSV ファイルを作成します。

    CREATE EXTERNAL TABLE '/data/export.csv' USING (delimiter ',')
AS SELECT col1, col2, expr1, expr2, col3, col1 || col2 FROM your table;

    Netezza のローカル ホストにマウントされるファイル システムにデータをエクスポートしようとしている場合は、外部テーブルを使用します。 JDBC、ODBC、または OLEDB がインストールされているリモート マシンにデータをエクスポートしようとしている場合は、"remotesource odbc" オプションが USING 句です。

    この方法では、抽出されたデータ ファイルの到着場所となる領域が必要です。 この領域は、ローカルの Netezza ソース データベース (十分なストレージが使用可能である場合) でも、リモートの Azure Blob Storage でもかまいません。 ファイルがローカルに書き込まれる場合はネットワークのオーバーヘッドが回避されるため、最適なパフォーマンスが実現します。

    ストレージとネットワーク転送の要件を最小限に抑えるには、gzip などのユーティリティを使用して、抽出されたデータ ファイルを圧縮することをお勧めします。

    抽出されたフラット ファイルは、(ターゲット Azure Synapse インスタンスと併置される) Azure Blob Storage に移動するか、PolyBase または COPY INTO を使用して Azure Synapse に直接読み込むことができます。 ローカルのオンプレミス ストレージから Azure クラウド環境にデータを物理的に移動する方法は、データの量と使用可能なネットワーク帯域幅によって異なります。

    Microsoft では、大量のデータを移動するさまざまなオプションを提供しています。たとえば、ネットワーク経由でファイルを Azure Storage に移動するための AzCopy、プライベート ネットワーク接続経由で一括データを移動するための Azure ExpressRoute、ファイルを物理ストレージ デバイス (このデバイスは読み込みのために Azure データ センターに輸送されます) に移動するための Azure Data Box があります。 詳細については、データ転送に関するページを参照してください。

  • ネットワーク経由での直接抽出と読み込み: データ抽出要求が、ターゲットの Azure 環境から、通常は SQL コマンドを介して Netezza のレガシ システムに送信され、データを抽出します。 結果は、ネットワーク経由で送信され、Azure Synapse に直接読み込まれます。データの到着場所を中間ファイルにする必要はありません。 このシナリオの制限要因は、通常、Netezza データベースと Azure 環境の間の、ネットワーク接続の帯域幅です。 データ量が非常に多い場合、この方法は実用的でないことがあります。

両方の方法を使用するハイブリッドな方法もあります。 たとえば、小さなディメンション テーブルと大きなファクト テーブルのサンプルであれば、ネットワーク直接抽出の方法を使用して、Azure Synapse にテスト環境をすばやく用意できます。 以前からのデータ量が多いファクト テーブルの場合は、Azure Data Box を使用して、ファイルの抽出と転送の方法を使用できます。

オーケストレーションは Netezza と Azure のどちらから行うか

Azure Synapse への移行時にお勧めできるのは、最も効率的なデータ読み込みのために、Azure Synapse Pipelines または Azure Data Factory と、PolyBase や COPY INTO などの関連ユーティリティを使用して、Azure 環境からのデータ抽出と読み込みのオーケストレーションを行う方法です。 この方法では、Azure の機能を活用して、再利用可能なデータ読み込みパイプラインを簡単に構築する方法が提供されます。

この方法の他の利点として、管理と読み込みのプロセスが Azure で実行されるためにデータ読み込みプロセス中の Netezza システムへの影響が軽減されることと、メタデータ駆動型のデータ読み込みパイプラインを使用するプロセス自動化機能が挙げられます。

どのツールを使用できるか

データの変換と移動は、どの ETL 製品にもある基本的な機能のタスクです。 既存の Netezza 環境で、これらの製品のいずれかを既に使用中の場合は、既存の ETL ツールを使用すると、Netezza から Azure Synapse へのデータ移行が簡略化される可能性があります。 この方法は、ETL ツールがターゲット環境として Azure Synapse をサポートしていることを前提としています。 Azure Synapse をサポートしているツールの詳細については、データ統合パートナーに関するページを参照してください。

ETL ツールを使用する予定の場合は、Azure クラウドのパフォーマンス、スケーラビリティ、コストの利点を享受して Netezza データ センターのリソースを解放するため、Azure 環境内でそのツールを実行することを検討してください。 もう 1 つの利点は、クラウド環境とオンプレミス環境の間のデータ移動が減少することです。

まとめ

まとめると、Netezza から Azure Synapse にデータと関連 ETL プロセスを移行する場合の推奨事項は、以下のとおりです。

  • 移行作業が確実に成功するように事前に計画します。

  • できるだけ早期に、移行するデータとプロセスの詳細なインベントリを作成します。

  • システム メタデータとログ ファイルを使用して、データとプロセスの使用状況を正確に理解します。 ドキュメントは最新ではない可能性があるため、頼らないでください。

  • 移行するデータの量と、オンプレミス データ センターと Azure クラウド環境の間のネットワーク帯域幅について把握します。

  • 標準の "組み込み" Azure 機能を活用して、移行ワークロードを最小限に抑えます。

  • Netezza 環境と Azure 環境の両方でのデータ抽出と読み込みのために最も効率的なツールを特定して理解します。 プロセスの各フェーズで適切なツールを使用します。

  • Azure Synapse Pipelines や Azure Data Factory などの Azure 機能を使用して、Netezza システムへの影響を最小限に抑えながら、移行プロセスのオーケストレーションと自動化を行います。

次のステップ

セキュリティ アクセス操作の詳細を確認するため、このシリーズの次の記事「Netezza 移行のセキュリティ、アクセス、操作」を参照してください。