Netezza 移行の SQL 問題を最小限に抑える

  • [アーティクル]

この記事は、Netezza から Azure Synapse Analytics に移行する方法に関するガイダンスを提供する 7 つのパートから成るシリーズのパート 5 です。 この記事では、SQL の問題を最小限に抑えるためのベスト プラクティスに焦点を合わせています。

概要

Netezza 環境の特性

ヒント

Netezza は、2000 年代初頭に「データ ウェアハウス アプライアンス」 コンセプトの先駆者となりました。

2003 年、Netezza は最初にデータ ウェアハウス アプライアンス製品をリリースしました。 これにより、エントリのコストが削減され、超並列処理 (MPP) 手法の使いやすさが向上し、既存のメインフレームやその他の MPP テクノロジよりも大規模にデータ処理を効率的に行えるようになりました。 それ以降、製品は進化し、大手金融機関、通信会社、小売企業の間で多くのインストールの実績があります。 当初の実装では、フィールド プログラマブル ゲート アレイ(FPGA) を含む独自のハードウェアが使用され、TCP/IPを介したODBCまたはJDBCネットワーク接続経由でアクセスできるようになりました。

ほとんど既存の Netezza インストールはオンプレミスであるため、多くのユーザーは、最新のクラウド環境への移行の利点を得るために、一部またはすべての Netezza データを Azure Synapse Analytics に移行することを検討しています。

ヒント

既存の Netezza インストール済み環境の多くは、ディメンション データ モデルを使用するデータ ウェアハウスです。

Netezza のテクノロジをデータ ウェアハウスの実装によく使用し、SQL を使用して大きなデータに対する複雑な分析クエリをサポートします。 ディメンション データ モデル (スター スキーマまたはスノーフレーク スキーマ) は、各部門のデータ マートの実装と同様、一般的なものです。

この SQL データ モデルとディメンション データ モデルの組み合わせにより、基本的な概念と SQL スキルを移行できるため、Azure Synapse への移行が簡単になります。 推奨されるアプローチは、既存のデータ モデルをそのまま移行して、リスクと所要時間を削減することです。 最終的にデータ モデルを変更する (たとえば、データ ボルト モデルに移行する) 場合は、最初にそのまま移行し、その後 Azure クラウド環境内で変更し、パフォーマンス、弾性スケーラビリティ、コスト面での利点を活用します。

SQL 言語は標準化されていますが、場合によっては、各ベンダが独自に拡張機能を実装しています。 このドキュメントでは、従来の Netezza 環境からの移行中に発生する可能性のある SQL の違いを明らかにし、回避策を示します。

Azure Data Factory を使用してメタデータに基づく移行を実装する

ヒント

Azure Data Factory 機能を使用して移行プロセスを自動化します。

Azure 環境の機能を使用して移行プロセスの自動化と調整をすることは理にかなっています。 このアプローチにより、既存の Netezza 環境への影響も最小限に抑えられます (既に全容量に近い状態で実行されている可能性があります)。

Azure Data Factory は、データドリブン型のワークフローをクラウドに作成することでデータの移動と変換を制御し、自動化することができるクラウドベースのデータ統合サービスです。 Azure Data Factory を使えば、さまざまなデータ ストアのデータを取り込むことができるデータ主導型のワークフロー (パイプライン) を作成し、スケジューリングします。 Azure HDInsight Hadoop、Spark、 Azure Data Lake Analytics、Azure Machine Learning などのコンピューティング サービスを使用してデータ を処理し、変換できます。

移行するデータ テーブルとその場所をリストするメタデータを作成することで、Azure Data Factory の機能を使用して移行プロセスの一部を管理し、自動化します。 Azure Synapse Pipelines使用することもできます。

Netezza と Azure Synapse の SQL DDL の違い

SQL データ定義言語 (DDL)

ヒント

SQL DDL コマンドCREATE TABLEとCREATE VIEWは、標準のコア要素を持ちますが、実装固有のオプションの定義にも使用します。

ANSI SQL 標準では、 CREATE TABLE と CREATE VIEWなどの DDL コマンドの基本的な構文を定義します。 これらのコマンドは、Netezza と Azure Synapse の両方で使用しますが、インデックス作成、テーブルの分散、パーティション分割オプションなどの実装固有が持つ特徴の定義を可能にするよう拡張しています。

次のセクションでは、Azure Synapse への移行時に考慮する Netezza 固有のオプションについて説明します。

テーブルに関する考慮事項

ヒント

既存のインデックスを使用して、移行後のウェアハウスでインデックス作成の候補を示します。

異なるテクノロジ間でテーブルを移行する場合、通常、生データとその記述メタデータのみが 2 つの環境間で物理的に移動されます。 インデックスやログ ファイルなど、ソース システムからその他のデータベース要素を直接移行することはありません。これは、これらの要素が必要ないか、新しいターゲット環境内で異なる方法で実装される可能性があるためです。 たとえば、Netezza の CREATE TABLE 構文内の TEMPORARY オプションは、Azure Synapse でテーブル名の先頭に "#" 文字を付けることと同じです。

ソース環境で、パフォーマンスの最適化 (インデックスなど) を使用した場所を理解することが重要です。 これは、新しいターゲット環境でパフォーマンス最適化が追加可能な場所を示します。 たとえば、ゾーン マップがソース Netezza 環境で作成された場合は、移行された Azure Synapse データベースに非クラスター化インデックスを作成する必要があることを示している可能性があります。 テーブル レプリケーションなど、他のネイティブ パフォーマンスの最適化手法は、"同一条件で" インデックスを直接作成するよりも適している場合があります。

サポートされていない Netezza データベース オブジェクトの種類

ヒント

Netezza 固有の機能は、Azure Synapse の機能に置き換えることができます。

Netezza は、Azure Synapse で直接サポートされていないデータベース オブジェクトをいくつか実装していますが、新しい環境内で同じ機能を実現する方法があります。

  • ゾーン マップ: Netezza では、一部の列の種類に対してゾーン マップが自動的に作成され、維持されます。また、これらはクエリ時に、スキャンされるデータ量を制限するために使用されます。 ゾーンマップは、次の列の種類に対して作成されます。

    • INTEGER 長さが 8 バイト以下の列。
    • テンポラル列。 たとえば、DATE、TIME、TIMESTAMP などです。
    • CHAR 列 (これらが具体化されたビューの一部であり、ORDER BY 句で示されている場合)。

    どの列にゾーン マップがあるかを調べるには、NZ Toolkit の一部である nz_zonemap ユーティリティーを使用します。 Azure Synapse にはゾーン マップは含まれていませんが、他のユーザー定義のインデックスの種類やパーティション分割を使用して、同様の結果を得ることができます。

  • クラスター化されたベース テーブル (CBT): Netezza では、大量のレコードを含むファクト テーブルに対しては、CBT が使用されます。 このような大きなテーブルをスキャンするには、関連するレコードを取得するためにフル テーブル スキャンが必要になる可能性があるため、多くの処理時間が必要になります。 制限の厳しい CBT でレコードを編成すると、Netezza はレコードを同じエクステントまたは近くのエクステントにグループ化できます。 また、このプロセスは、スキャンするデータ量を減らすことで、パフォーマンスを向上させるゾーン マップも作成します。

    Azure Synapse では、パーティション分割や他のインデックスの使用することで同様の効果を実現できます。

  • 具体化されたビュー: Netezza は、具体化されたビューをサポートしており、クエリで定期的に使用される列が少ない場合に、多くの列を持つ大きなテーブルに 1 つ以上の具体化されたビューを作成することが推奨されています。 ベース テーブルのデータが更新されると、システムは具体化されたビューを自動的に維持します。

    Azure Synapse は、Netezza と同じ機能を持つ具体化されたビューをサポートしています。

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 では直接サポートされていませんが、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 ではサポートされていませんが、データは VARCHAR または VARBINARY として保存できます。
TIME TIME
TIME WITH TIME ZONE DATETIMEOFFSET
timestamp DATETIME

データ定義言語 (DDL) の生成

ヒント

既存の Netezza メタデータを使用して、Azure Synapse の CREATE TABLE と CREATE VIEW の DDL の生成を自動化します。

既存の Netezzaa CREATE TABLE と CREATE VIEW スクリプトを編集し、必要に応じて前述のようにデータ型を変更した同等の定義を作成します。 通常は、不要な Netezza 固有の句 (ORGANIZE ON など) をすべて削除または変更する必要があります。

ただし、既存の Netezza 環境内のテーブルおよびビューの現在の定義を指定するすべての情報は、システム カタログ テーブル内で保持されます。 これは、最新の状態で完了していることが保証されているため、この情報ソースが最適です。 ユーザーが整備したドキュメントは、現在のテーブル定義と同期していない可能性があることに注意してください。

nz_ddl_table などのユーティリティーを使用してこの情報にアクセスし、CREATE TABLE DDL ステートメントを生成します。 Azure Synapse 同等のテーブルについて、これらのステートメントを編集します。

ヒント

サードパーティー製のツールやサービスを使用すると、データ マッピング タスクを自動化できます。

データ型のマッピングなど、移行を自動化するためのツールやサービスをオファーする Microsoft パートナーがあります。 また、Informatica や Talend などのサードパーティの ETL ツールが既に Netezza 環境で使用されている場合は、必要なデータ変換を実装できます。

Netezza と Azure Synapse の SQL DML の違い

SQL データ操作言語 (DML)

ヒント

SQL DML コマンド SELECT、INSERT、UPDATE は、標準のコア要素を持ちますが、さまざまな構文オプションを実装することもできます。

ANSI SQL 標準は、SELECT、INSERT、UPDATE、DELETEなどの DML コマンドの基本構文を定義します。 Netezza と Azure Synapse の両方でこれらのコマンドが使用されますが、場合によっては実装の違いがあります。

次のセクションでは、Azure Synapse への移行時に考慮する必要がある Netezza 固有の DML コマンドについて説明します。

SQL DML 構文の相違点

移行時、Netezza SQL と Azure Synapse では、SQL データ操作言語 (DML) 構文にこれらの違いがあることに注意してください。

  • STRPOS: Netezza の STRPOS 関数からは、文字列内の部分文字列の位置が返されます。 Azure Synapse で同等の関数は CHARINDEX ですが、引数の順序が逆になっています。 たとえば、Netezza での SELECT STRPOS('abcdef','def')... は、Azure Synapse での SELECT CHARINDEX('def','abcdef')... と同じです。

  • AGE: Netezza は、タイム スタンプや日付などで 2 つのテンポラル値間の間隔を指定するAGE演算子をサポートしています。 たとえば、「 SELECT AGE('23-03-1956','01-01-2019') FROM... 」のように入力します。 Azure Synapse では、DATEDIFF間隔を指定します。 たとえば、「 SELECT DATEDIFF(day, '1956-03-26','2019-01-01') FROM... 」のように入力します。 日付表現の順序に注意する必要があります。

  • NOW():Azure Synapse での CURRENT_TIMESTAMP を表すために、Netezza では NOW() が使用されます。

関数、ストアド プロシージャ、シーケンス

ヒント

準備フェーズの一環として、移行されるデータ以外のオブジェクトの数と型を評価します。

Netezza などの成熟したレガシ データ ウェアハウス環境から移行するときは、単純なテーブルとビュー以外の要素を、新しいターゲット環境に移行することが必要になる場合がよくあります。 このようなものの例としては、関数、ストアド プロシージャ、シーケンスがあります。

準備フェーズの一環として、移行する必要があるオブジェクトのインベントリを作成し、それらを処理する方法を定義します。 次に、プロジェクト計画でリソースの適切な割り当てをします。

Netezza 環境で関数またはストアド プロシージャとして実装されている機能の代わりになるサービスが、Azure 環境に存在する場合があります。 この場合多くは、Netezza 関数をコーディングし直すよりも、組み込みの Azure ファシリティを使用する方が効率的です。

ヒント

サードパーティーの製品やサービスによって、データ以外の要素の移行を自動化します。

Microsoft パートナーは、データ型のマッピングなど、移行を自動化できるツールとサービスを提供しています。 また、IBM Netezza 環境で既に使用されている Informatica や Talend などのサード パーティーの ETL ツールでも、必要なデータ変換を実装できます。

これらの各要素の詳細については、次のセクションを参照してください。

関数

ほとんどのデータベース製品と同様に、Netezza ではシステム関数と SQL 実装内のユーザー定義関数もサポートされています。 Azure Synapse などの別のデータベース プラットフォームに移行する場合、通常は共通のシステム関数を使用でき、変更なしに移行することができます。 システム関数によって、構文が若干異なることがありますが、この場合は必要な変更を自動化できます。 任意のユーザー定義関数など、同等のものが存在しないシステム関数は、ターゲット環境で使用可能な言語を用いて再コード化する必要がある場合があります。 Azure Synapse でユーザー定義関数を実装するには、一般的な Transact-SQL 言語が使用されます。 Netezza ユーザー定義関数は、nzlua または C++ 言語でコーディングされます。

ストアド プロシージャ

最新のデータベース製品では、データベース内にプロシージャを格納できます。 Netezza は Postgres PL/pgSQL をベースにした NZPLSQL 言語を提供しています。 ストアド プロシージャには、通常、SQL ステートメントといくつかの手続き型のロジックが含まれており、データや状態を返すことができます。

Azure Synapse Analytics では、T-SQL を使用したストアド プロシージャもサポートされているため、ストアド プロシージャを移行する必要がある場合は、それに応じてストアド プロシージャを再コーディングします。

シーケンス

Netezza では、シーケンスは CREATE SEQUENCE によって作成された名前付きデータベースオブジェクトであり、NEXT VALUE FOR メソッドによって一意の値を指定できます。 これらを使用して、主キー値に対する代理キー値として使用する一意の数値を生成します。

Azure Synapse では、CREATE SEQUENCE はありません。 シーケンスは、ID を使用して代理キーまたはマネージド ID を作成するか、連続する次のシーケンス番号を作成するために SQL コードを使用して処理されます。

EXPLAIN を使用して、従来の SQL を検証

ヒント

既存のシステム クエリ ログから実際のクエリを使用して、潜在的な移行の問題を見つけます。

従来のクエリ履歴ログからいくつかの代表的な SQL ステートメントをキャプチャして、Azure Synapse との互換性について従来の Netezza SQL を評価します。 次に、これらのクエリに EXPLAIN というプレフィックスを付け、同じテーブル名と列名を持つ Azure Synapse の "同一条件で" 移行されたデータ モデルを想定して、Azure Synapse でこれらの EXPLAIN ステートメントを実行します。 互換性のない SQL はエラーを返します。 この情報を使用して、再コーディング タスクのスケールを決定します。 このアプローチでは、Azure 環境にデータを読み込む必要はなく、関連するテーブルとビューが作成されていることのみが必要です。

IBM Netezza から T-SQL へのマッピング

Azure Synapse SQL データ型マッピングに準拠した IBM Netezza から T-SQL へのマッピングを次の表に示します。

IBM Netezza のデータ型 Azure Synapse SQL のデータ型
array サポートされていません
bigint bigint
binary large object [(n[K|M|G])] nvarchar [(n|max)]
 blob [(n[K|M|G])] nvarchar [(n|max)]
 byte [(n)] binary [(n)]|varbinary(max)
 byteint smallint
 char varying [(n)] varchar [(n|max)]
character varying [(n)] varchar [(n|max)]
 char [(n)] char [(n)]|varchar(max)
character [(n)] char [(n)]|varchar(max)
 character large object [(n[K|M|G])] varchar [(n|max)
 clob [(n[K|M|G])] varchar [(n|max)
 dataset サポートされていません 
 date date
 dec [(p[,s])] decimal [(p[,s])]
 decimal [(p[,s])] decimal [(p[,s])]
 double precision float(53)
 float [(n)] float [(n)]
 graphic [(n)] nchar [(n)]| varchar(max)
 interval サポートされていません 
 json [(n)] nvarchar [(n|max)]
 long varchar nvarchar(max)
 long vargraphic nvarchar(max)
 mbb サポートされていません 
 mbr サポートされていません 
 number [((p|*)[,s])] numeric [(p[,s])]
 numeric [(p [,s])]  numeric [(p[,s])]
 period サポートされていません 
 real  real
 smallint smallint
 st_geometry サポートされていません 
 time time
 time with time zone datetimeoffset
 timestamp  datetime2
 timestamp with time zone datetimeoffset
 varbyte varbinary [(n|max)]
 varchar [(n)]  varchar [(n)]
 vargraphic [(n)] nvarchar [(n|max)]
 varray サポートされていません 
 xml サポートされていません 
 xmltype サポートされていません 

まとめ

一般的な既存のレガシ Netezza インストールは、Azure Synapse への移行を容易にする方法で実装されています。 これらは、大きなデータ ボリュームに対する分析クエリに SQL を使用し、何らかの形式のディメンション データ モデルです。 これらの要因により、Azure Synapse への移行に適した候補になります。

実際の SQL コードを移行するタスクを最小化するには、次の推奨事項をフォローします。

  • 最終的な最終環境にデータ ヴォルトなどの異なるデータ モデルが組み込まれる場合でも、データ ウェアハウスの初期移行は、リスクと時間を最小化するためにそのまま移行する必要があります。

  • Netezza SQL 実装と Azure Synapse の相違点を理解します。

  • 既存の Netezza 実装のメタデータと照会ログを使用して、相違の影響を評価し、軽減するためのアプローチを計画します。

  • 可能な限りプロセスを自動化して、エラー、リスク、移行にかかる時間を最小限に抑えます。

  • スペシャリストである Microsoft パートナー とサービスを使用して移行を合理化することを検討してください。

次のステップ

Microsoft とサード パーティのツールの詳細については、このシリーズの次の記事 Azure Synapse Analytics への Netezza データ ウェアハウス移行用ツール」 を参照してください。