この記事は、Netezza から Azure Synapse Analytics に移行する方法に関するガイダンスを提供する 7 部構成のシリーズのパート 5 です。 この記事では、SQL の問題を最小限に抑えるためのベスト プラクティスに焦点を合わせています。
概要
Netezza 環境の特性
ヒント
Netezza は、2000 年代初頭に "データ ウェアハウス アプライアンス" の概念を開拓しました。
2003 年、Netezza は最初にデータ ウェアハウス アプライアンス製品をリリースしました。 これにより、エントリのコストが削減され、超並列処理 (MPP) 手法の使いやすさが向上し、既存のメインフレームやその他の MPP テクノロジよりも大規模なデータ処理を効率的に行えるようになっています。 それ以降、製品は進化し、大手金融機関、通信会社、小売企業の間で多くのインストールの実績があります。 元の実装では、フィールド プログラミング可能なゲート アレイ (または FPGA) を含む独自のハードウェアが使用され、ODBC または TCP/IP 経由の 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 のTEMPORARY構文内のCREATE TABLE オプションは、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 | ビット |
| BYTEINT | タイニーイント (TINYINT) |
| 可変文字列(n) | VARCHAR(n) |
| CHARACTER(n) | CHAR(n) |
| DATE | DATE(日付) |
| DECIMAL(p,s) | DECIMAL(p,s) |
| 倍精度 | FLOAT |
| FLOAT(n) | FLOAT(n) |
| INTEGER | INT |
| INTERVAL | INTERVAL データ型は現在、Azure Synapse では直接サポートされていませんが、DATEDIFF などのテンポラル関数を使用して計算できます。 |
| お金 | お金 |
| NATIONAL CHARACTER VARYING(n) | NVARCHAR(n) |
| NATIONAL CHARACTER(n) | NCHAR(n) |
| NUMERIC(p,s) | NUMERIC(p,s) |
| real | real |
| SMALLINT | SMALLINT |
| ST_GEOMETRY(n) | ST_GEOMETRYなどの空間データ型は現在 Azure Synapse ではサポートされていませんが、データは VARCHAR または VARBINARY として格納できます。 |
| TIME | TIME |
| タイム ゾーンを使用した時刻 | DATETIMEOFFSET |
| TIMESTAMP | 日時 |
データ定義言語 (DDL) の生成
ヒント
既存の Netezza メタデータを使用して、Azure Synapse の CREATE TABLE と CREATE VIEW DDL の生成を自動化します。
既存の Netezza CREATE TABLE と CREATE VIEW スクリプトを編集して、必要に応じて前述のように、変更されたデータ型を含む同等の定義を作成します。 通常、これには、 ORGANIZE ONなどの追加の Netezza 固有の句を削除または変更する必要があります。
ただし、既存の 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 では、AGE演算子をサポートして、タイムスタンプや日付などの 2 つの一時的な値の間隔を指定します。 たとえば、「SELECT AGE('23-03-1956','01-01-2019') FROM...」のように入力します。 Azure Synapse では、DATEDIFFは間隔を与えます。 たとえば、「SELECT DATEDIFF(day, '1956-03-26','2019-01-01') FROM...」のように入力します。 日付表現の順序に注意してください。NOW(): Netezza では、NOW()を使用して Azure Synapse のCURRENT_TIMESTAMPを表します。
関数、ストアド プロシージャ、およびシーケンス
ヒント
準備フェーズの一環として、移行されるデータ以外のオブジェクトの数と型を評価します。
Netezza などの成熟したレガシ データ ウェアハウス環境から移行する場合、多くの場合、新しいターゲット環境に移行する必要がある単純なテーブルやビュー以外の要素があります。 この例には、関数、ストアド プロシージャ、シーケンスなどがあります。
準備フェーズの一環として、移行する必要があるオブジェクトのインベントリを作成し、それらを処理する方法を定義します。 次に、プロジェクト計画でリソースの適切な割り当てを割り当てます。
Azure 環境には、Netezza 環境の関数またはストアド プロシージャとして実装された機能を置き換える機能が存在する場合があります。 この場合、多くの場合、Netezza 関数を再コーディングするのではなく、組み込みの Azure 機能を使用する方が効率的です。
ヒント
サードパーティーの製品やサービスによって、データ以外の要素の移行を自動化します。
Microsoft パートナー は、データ型のマッピングなど、移行を自動化できるツールとサービスを提供しています。 また、IBM Netezza 環境で既に使用されている Informatica や Talend などのサードパーティの ETL ツールでは、必要なデータ変換を実装できます。
これらの各要素の詳細については、次のセクションを参照してください。
Functions
ほとんどのデータベース製品と同様に、Netezza は SQL 実装内のシステム関数とユーザー定義関数をサポートします。 Azure Synapse などの別のデータベース プラットフォームに移行する場合、通常は共通のシステム関数を使用でき、変更なしに移行することができます。 システム関数によって、構文が若干異なることがありますが、この場合は必要な変更を自動化できます。 任意のユーザー定義関数など、同等のものが存在しないシステム関数は、ターゲット環境で使用可能な言語を用いて再コード化する必要がある場合があります。 Azure Synapse でユーザー定義関数を実装するには、一般的な Transact-SQL 言語が使用されます。 Netezza ユーザー定義関数は、nzlua または C++ 言語でコーディングされています。
ストアド プロシージャ
最新のデータベース製品では、データベース内にプロシージャを格納することができます。 Netezza には、Postgres PL/pgSQL に基づく NZPLSQL 言語が用意されています。 ストアド プロシージャには、通常、SQL ステートメントといくつかの手続き型のロジックが含まれており、データや状態を返します。
Azure Synapse Analytics では T-SQL を使用したストアド プロシージャもサポートされているため、ストアド プロシージャを移行する必要がある場合は、それに応じてそれらを再コーディングします。
Sequences
Netezza では、シーケンスは、CREATE SEQUENCE メソッドを使用して一意の値を提供できるNEXT VALUE FORを使用して作成された名前付きデータベース オブジェクトです。 これらを使用して、主キー値の代理キー値として使用する一意の数値を生成します。
Azure Synapse では、 CREATE SEQUENCEはありません。 シーケンスは 、IDENTITY を 使用して処理され、SQL コードを使用して代理キーまたは マネージド ID を 作成し、系列内に次のシーケンス番号を作成します。
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 のデータ型 |
|---|---|
| 配列 | サポートされていません |
| bigint | bigint |
| バイナリ ラージ オブジェクト [(n[K|M|G])] | nvarchar [(n|max)] |
| ブロブ [(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) |
| 文字 [(n)] | char [(n)]|varchar(max) |
| character large object [(n[K|M|G])] | varchar [(n|max) |
| clob [(n[K|M|G])] | varchar [(n|max) |
| データセット | サポートされていません |
| date | date |
| dec [(p[,s])] | decimal [(p[,s])] |
| 小数点 [(p[,s])] | decimal [(p[,s])] |
| double precision | float(53) |
| float [(n)] | float [(n)] |
| グラフィック [(n)] | nchar [(n)]|varchar(max) |
| interval | サポートされていません |
| json [(n)] | nvarchar [(n|max)] |
| long varchar | nvarchar(max) |
| long vargraphic | nvarchar(max) |
| mbb | サポートされていません |
| mbr | サポートされていません |
| number [((p|*)[,s])] | 数値型 [(p[,s])] |
| numeric [(p [,s])] | 数字型 [(p[,s])] |
| 期間 | サポートされていません |
| real | real |
| smallint | smallint |
| st_geometry | サポートされていません |
| time | time |
| time with time zone | 日付時刻のオフセット |
| timestamp | datetime2 |
| タイム ゾーンを含むタイムスタンプ | デイトタイムオフセット |
| varbyte | varbinary [(n|max)] |
| varchar [(n)] | varchar [(n)] |
| vargraphic [(n)] | nvarchar [(n|max)] |
| varray | サポートされていません |
| Xml | サポートされていません |
| xmltype | サポートされていません |
まとめ
従来の従来の Netezza の一般的なインストールは、Azure Synapse への移行を容易にする方法で実装されます。 これらは、大きなデータ ボリュームに対する分析クエリに SQL を使用し、何らかの形式のディメンション データ モデルです。 これらの要因により、Azure Synapse への移行に適した候補になります。
実際の SQL コードを移行するタスクを最小限に抑えるには、次の推奨事項に従います。
最終的な最終環境にデータ ヴォルトなどの異なるデータ モデルが組み込まれる場合でも、データ ウェアハウスの初期移行は、リスクと time を最小化するためにそのまま移行する必要があります。
Netezza SQL の実装と Azure Synapse の違いについて説明します。
既存の Netezza 実装のメタデータとクエリ ログを使用して、相違点の影響を評価し、軽減するアプローチを計画します。
可能な限りプロセスを自動化して、移行のエラー、リスク、および time を最小化します。
スペシャリストである Microsoft パートナーとサービスを使用して移行を合理化することを検討してください。
次のステップ
Microsoft およびサード パーティ製ツールの詳細については、このシリーズの次の記事「 Tools for Netezza data warehouse migration to Azure Synapse Analytics」を参照してください。