Netezza 移行の設計とパフォーマンス
この記事は、Netezza から Azure Synapse Analytics に移行する方法に関するガイダンスを提供する 7 つのパートから成るシリーズのパート 1 です。 この記事での焦点は、設計とパフォーマンスのベスト プラクティスです。
概要
IBM のサポート終了により、Netezza データ ウェアハウス システムの多くの既存ユーザーは、最新のクラウド環境で提供されるイノベーションを活用しようとしています。 サービスとしてのインフラストラクチャ (IaaS) とサービスとしてのプラットフォーム (PaaS) クラウド環境を使用すると、インフラストラクチャのメンテナンスやプラットフォーム開発などのタスクをクラウド プロバイダーに委任できます。
ヒント
Azure 環境には、データベースだけでなく、包括的な一連の機能とツールが用意されています。
Netezza と Azure Synapse Analytics は両方とも、極度に大規模なデータ量に対して高いクエリ パフォーマンスを実現するために、超並列処理 (MPP) 手法を使用する SQL データベースですが、アプローチには基本的な違いがいくつかあります。
多くの場合、レガシ Netezza システムは、独自のハードウェアを使用してオンプレミスにインストールされます。一方、Azure Synapse は Azure のストレージとコンピューティング リソースを使用したクラウドベースです。
Netezza 構成のアップグレードは、物理ハードウェアの追加や、長時間かかる可能性のあるデータベースの再構成またはダンプと再読み込みを伴う大きなタスクです。 ストレージとコンピューティング リソースは Azure 環境では分離されていて、エラスティック スケーリング機能があるため、これらのリソースは、独立してスケーリング (アップまたはダウン) できます。
必要に応じて Azure Synapse を一時停止したりそのサイズを変更したりして、リソースの使用率とコストを削減できます。
Microsoft Azure は、グローバルに使用できる、高度なセキュリティで保護されたスケーラブルなクラウド環境であり、Azure Synapse とサポート ツールおよび機能のエコシステムが組み込まれています。 次の図は、Azure Synapse エコシステムをまとめたものです。
Azure Synapse では、MPP や頻繁に使用されるデータの複数のレベルの自動キャッシュなどの手法を使用して、最高のリレーショナル データベース パフォーマンスを実現しています。 これらの手法の結果は、独立したベンチマークで確認できます。たとえば、GigaOm によって最近実施されたものでは、Azure Synapse が他の一般的なクラウド データ ウェアハウス オファリングと比較されています。 Azure Synapse 環境に移行するお客様には、次のような多くの利点があります。
パフォーマンスと費用対効果の向上。
機敏性の向上と価値実現までの時間の短縮。
より高速なサーバーのデプロイとアプリケーション開発。
実際の使用量に対してのみ課金される柔軟なスケーラビリティ。
セキュリティ/コンプライアンスの向上。
ストレージとディザスター リカバリーのコスト削減。
全体的な TCO の削減、コスト管理の向上、運用支出 (OPEX) の合理化。
このような利点を最大限に活用するには、新規または既存のデータとアプリケーションを Azure Synapse プラットフォームに移行します。 多くの組織で、移行には、Netezza などのレガシ オンプレミス プラットフォームから Azure Synapse への既存のデータ ウェアハウスの移動が含まれます。 おおまかに、移行プロセスには次の手順が含まれます。
準備 🡆
スコープ (移行する対象) を定義する。
移行のためのデータとプロセスのインベントリを作成する。
データ モデルの変更を定義する (ある場合)。
ソース データ抽出メカニズムを定義する。
使用する適切な Azure およびサードパーティのツールと機能を特定する。
新しいプラットフォームのスタッフ トレーニングを早期に実施する。
Azure のターゲット プラットフォームをセットアップする。
移行 🡆
小規模で簡単なものから始める。
可能な限り、処理を自動化します。
Azure の組み込みツールと機能を活用して移行の労力を減らす。
テーブルとビューのメタデータを移行する。
維持する履歴データを移行する。
ストアド プロシージャとビジネス プロセスを移行またはリファクタリングする。
ETL/ELT の段階的読み込みプロセスを移行またはリファクタリングする。
移行後
プロセスのすべてのステージを監視してドキュメント化する。
今後の移行のため、得られた経験を利用してテンプレートを作成する。
必要な場合、(新しいプラットフォームのパフォーマンスとスケーラビリティを使用して) データ モデルを再エンジニアリングする。
アプリケーションとクエリ ツールをテストする。
クエリ パフォーマンスのベンチマークと最適化を行う。
この記事では、データ ウェアハウスを既存の Netezza 環境から Azure Synapse に移行するときのパフォーマンス最適化に関する一般的な情報とガイドラインを示します。 パフォーマンスの最適化の目的は、スキーマの移行後に Azure Synapse で同等以上のデータ ウェアハウスのパフォーマンスを実現することです。
設計上の考慮事項
移行のスコープ
Netezza 環境から移行する準備をしているときに、次の移行の選択肢を検討してください。
初期移行のワークロードを選択する
レガシ Netezza 環境は通常、時間の経過とともに進化して、複数の主題領域と混合ワークロードを含むようになります。 移行プロジェクトをどこから開始するのかを決定するときに、次の作業が可能になる領域を選択します。
新しい環境の利点を迅速に提供することで、Azure Synapse への移行の実現可能性が証明される。
社内の技術スタッフが、他の領域を移行するときに使用するプロセスとツールに関する経験を得ることができる。
さらに移行を行うために、ソース Netezza 環境と既に配置済みの現在のツールおよびプロセスに固有のテンプレートを作成する。
Netezza 環境からの初期移行の適切な候補とは、上記の項目をサポートし、次を満たすものです。
オンライン トランザクション処理 (OLTP) ワークロードではなく、BI/Analytics ワークロードを実装する。
スターやスノーフレークのスキーマなどの、最小限の変更で移行できるデータ モデルが使用されている。
ヒント
移行する必要があるオブジェクトのインベントリを作成し、移行プロセスを文書化してください。
初期移行で移行されるデータの量は、Azure Synapse 環境の機能と利点を示すために十分な大きさに、ただし、価値をすばやく示すために大きすぎないようにする必要があります。 1 から 10 テラバイトの範囲のサイズが一般的です。
最初の移行プロジェクトでは、リスク、労力、移行時間を最小限に抑えて、Azure クラウド環境の利点をすばやく確認できるようにします。 リフトアンドシフトと段階的移行のどちらのアプローチでも、初期移行の範囲はデータ マートのみに制限され、ETL 移行や履歴データ移行などのより広範な移行の側面には対応しません。 ただし、移行されたデータ マート レイヤーにデータと必要なビルド プロセスがバックフィルされたら、プロジェクトの後のフェーズでこれらの側面に対処できます。
リフト アンド シフト移行と段階的アプローチ
一般に、計画された移行の目的と範囲に関係なく、2 種類の移行があります。リフト アンド シフトそのままと、変更を組み込む段階的なアプローチです。
リフト アンド シフト
リフト アンド シフト移行では、既存のデータ モデル (スター スキーマなど) は、そのまま新しい Azure Synapse プラットフォームに移行されます。 このアプローチでは、Azure クラウド環境への移動の利点を実現するために必要な作業を減らして、リスクと移行時間を最小限に抑えます。 リフトアンドシフト移行は、次のシナリオに適しています。
- 移行する単一のデータ マートを持つ既存の Netezza 環境がある場合、または
- 適切に設計されたスターまたはスノーフレークのスキーマに既に含まれているデータを含む既存の Netezza 環境がある場合、または
- 最新のクラウド環境に移動するための時間とコストが切迫している場合
ヒント
リフト アンド シフトは、後続のフェーズでデータ モデルへの変更が実装される場合でも、適切な開始点です。
変更を組み込む段階的なアプローチ
レガシ データ ウェアハウスが長期間にわたって進化している場合、必要なパフォーマンス レベルを維持するために再エンジニアリングが必要なことがあります。 モノのインターネット (IoT) ストリームなどの新しいデータをサポートするために、再エンジニアリングが必要になる場合もあります。 再エンジニアリング プロセスの一環として、スケーラブルなクラウド環境のメリットを利用するために、Azure Synapse に移行します。 移行には、基になるデータ モデルの変更 (Inmon モデルからデータ コンテナーへの移動など) が含まれることもあります。
Microsoft は、既存のデータ モデルをそのまま Azure に移動してから、Azure 環境のパフォーマンスと柔軟性を生かして、再エンジニアリングの変更を適用することをお勧めします。 そうすることで、既存のソース システムに影響を与えることなく、Azure の機能を使用して変更を加えることができます。
Azure Data Factory を使用してメタデータに基づく移行を実装する
Azure 環境の機能を使用することで、移行プロセスを自動化し、調整できます。 このアプローチにより、既存の Netezza 環境 (既に能力いっぱいに近い状態で実行されている場合があります) のパフォーマンスへの影響が最小限に抑えられます。
Azure Data Factory は、クラウドベースのデータ統合サービスであり、データの移動と変換を調整および自動化するデータ主導型ワークフローのクラウドでの作成をサポートします。 Data Factory を使用して、さまざまなデータ ストアからデータを取り込むデータ ドリブン ワークフロー (パイプライン) を作成し、スケジュールを設定できます。 Data Factory は、Azure HDInsight Hadoop、Spark、Azure Data Lake Analytics、Azure Machine Learning などのコンピューティング サービスを使ってデータを処理し、変換できます。
Data Factory 機能を使用した移行プロセスの管理を計画するときは、移行するすべてのデータ テーブルとその場所を一覧表示するメタデータを作成します。
Netezza と Azure Synapse の設計の違い
前述のように、Netezza と Azure Synapse Analytics のデータベースのアプローチにはいくつかの基本的な違いがあり、これらの違いについては次に説明します。
複数のデータベースに対して、1 つのデータベースとスキーマ
Netezza 環境には、多くの場合、複数の個別のデータベースが含まれています。 たとえば、データ インジェストとステージングのテーブル、コア ウェアハウス テーブル、データ マート (セマンティック レイヤーとも呼ばれることもあります) に対して個別のデータベースが存在する可能性があります。 ETL または ELT パイプライン プロセスにより、データベースをまたがる結合が実装され、個別のデータベース間でデータが移動されます。
一方、Azure Synapse 環境には 1 つのデータベースがあり、スキーマを使用して、論理的に分離されたグループにテーブルが分割されます。 Netezza 環境から移行される個別のデータベースを模倣するために、ターゲットの Azure Synapse データベース内で一連のスキーマを使用することをお勧めします。 Netezza 環境で既にスキーマが使用されている場合は、Netezza の既存のテーブルとビューを新しい環境に移動するときに、新しい名前付け規則を使用することが必要な場合があります。 たとえば、元の個別のデータベース名を維持するために、Netezza の既存のスキーマとテーブルの名前を連結して Azure Synapse の新しいテーブル名にしてから、新しい環境でスキーマ名を使用することが考えられます。 スキーマ統合の名前にドットがある場合は、Spark Azure Synapse で問題が発生する可能性があります。 基になるテーブルに SQL ビューを使用して論理構造を維持することもできますが、このアプローチには潜在的な欠点がいくつかあります。
Azure Synapse のビューは読み取り専用であるため、データの更新は、基になるベース テーブルで行われる必要があります。
1 つ以上のビューのレイヤーが既に存在していて、さらにビューのレイヤーを追加すると、入れ子になったビューのトラブルシューティングが困難なため、パフォーマンスとサポート可能性に影響を与える可能性があります。
ヒント
Azure Synapse 内で複数のデータベースを 1 つのデータベースに統合し、スキーマ名を使用して、テーブルを論理的に分離します。
テーブルに関する考慮事項
異なる環境間でテーブルを移行するとき、通常は生データと、それを記述するメタデータのみが物理的に移行されます。 インデックスなどの、ソース システムの他のデータベース要素は、通常は移行されません。新しい環境ではこれらが不要であるか、実装方法が異なる可能性があるためです。
インデックスなどの、ソース環境でのパフォーマンスの最適化は、新しい環境でパフォーマンスの最適化を追加することが検討される場所を示します。 たとえば、ソース Netezza 環境のクエリが頻繁にゾーン マップを使用する場合、Azure Synapse 内に非クラスター化インデックスを作成する必要があることを示している可能性があります。 テーブル レプリケーションなどの、他のネイティブ パフォーマンスの最適化手法が、同一条件でインデックスをそのまま作成するよりも適している場合があります。
ヒント
既存のインデックスは、移行後のウェアハウスでのインデックス作成の候補を示します。
サポートされていない Netezza データベース オブジェクトの種類
Netezza 固有の機能はしばしば、Azure Synapse の機能に置き換えることができます。 ただし、一部の Netezza データベース オブジェクトは、Azure Synapse で直接サポートされていません。 サポートされていない Netezza データベース オブジェクトの次の一覧で、Azure Synapse で同等の機能を実現する方法について説明します。
ゾーン マップ: Netezza では、次の列の種類に対してゾーン マップが自動的に作成され、維持されます。また、これらはクエリ時に、スキャンされるデータ量を制限するために使用されます。
INTEGER長さが 8 バイト以下の列。DATE、TIME、TIMESTAMPなどのテンポラル列。- 具体化されたビューの一部であり、
ORDER BY句で示されている場合、CHAR列。
どの列にゾーン マップがあるかを調べるには、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 にマッピングするお勧めの方法を示します。
| 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 |
ヒント
移行準備段階で、サポートされていないデータ型の数と種類を評価してください。
サードパーティ ベンダーから、データ型のマッピングなどの、移行を自動化するツールとサービスが提供されています。 サードパーティの ETL ツールが既に Netezza 環境で使用されている場合は、そのツールを使用して、必要なデータ変換を実装します。
SQL DML 構文の相違点
Netezza SQL と Azure Synapse T-SQL には、SQL DML 構文の違いがあります。 これらの違いについては、「Netezza 移行の SQL 問題を最小限に抑える」で詳しく説明します。
STRPOS:Netezza のSTRPOS関数からは、文字列内の substring の位置が返されます。 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 のような成熟した環境からデータ ウェアハウスを移行するときは、単純なテーブルやビュー以外の要素を移行することがおそらく必要になります。 Azure 環境内のツールが関数、ストアド プロシージャ、シーケンスの機能を置き換えることができるかどうかを確認します。これは、通常、組み込みの Azure ツールを使用する方が、それらの要素を Azure Synapse 用に再コーディングするよりも効率的であるためです。
準備段階の一環として、移行する必要があるオブジェクトのインベントリを作成し、それらを処理する方法を定義して、移行計画に適切なリソースを割り当てます。
データ統合パートナーから、関数、ストアド プロシージャ、シーケンスの移行を自動化できるツールとサービスが提供されています。
以降のセクションでは、関数、ストアド プロシージャ、シーケンスの移行についてさらに説明します。
関数
ほとんどのデータベース製品と同様に、Netezza では SQL 実装内で、システムとユーザー定義の関数がサポートされています。 レガシ データベース プラットフォームを Azure Synapse に移行するときに、一般的なシステム機能は通常変更なしで移行できます。 一部のシステム関数では、構文が若干異なることがありますが、必要な変更は自動化できます。
Azure Synapse に同等のものがない Netezza システム関数または任意のユーザー定義関数については、ターゲット環境言語を使用してそれらの関数を再コーディングします。 Netezza ユーザー定義関数は、nzlua または C++ 言語でコーディングされます。 Azure Synapse では、Transact-SQL 言語を使用して、ユーザー定義関数を実装します。
ストアド プロシージャ
ほとんどの最新のデータベース製品では、データベース内にプロシージャを格納できます。 Netezza は、この目的で Postgres PL/pgSQL をベースにした NZPLSQL 言語を提供しています。 ストアド プロシージャには通常、SQL ステートメントと手続き型のロジックの両方が含まれていて、データや状態を返すことができます。
Azure Synapse では T-SQL を使用したストアド プロシージャがサポートされているため、移行されたストアド プロシージャをその言語で再コーディングする必要があります。
シーケンス
Netezza では、シーケンスとは、CREATE SEQUENCE を使用して作成される名前付きデータベース オブジェクトです。 シーケンスは、NEXT VALUE FOR メソッド経由で一意の数値を提供します。 主キーに対する代理キーの値として、生成された一意の数値を使用できます。
Azure Synapse は CREATE SEQUENCE を実装しませんが、IDENTITY 列または系列内の次のシーケンス番号を生成する SQL コードを使用してシーケンスを実装できます。
Netezza 環境からのメタデータとデータの抽出
データ定義言語 (DDL) の生成
ANSI SQL 標準では、データ定義言語 (DDL) コマンドの基本的な構文が定義されています。 一部の DDL コマンド (CREATE TABLE、CREATE VIEW など) は、Netezza と Azure Synapse の両方に共通ですが、実装固有の機能を提供するように拡張されています。
既存の Netezza の CREATE TABLE と CREATE VIEW スクリプトを編集して、Azure Synapse の同等の定義を実現できます。 これを行うには、変更されたデータ型を使用し、Netezza 固有の句 (ORGANIZE ON など) を削除または変更することが必要になる場合があります。
Netezza 環境内では、システム カタログ テーブルが現在のテーブルとビューの定義を指定します。 ユーザーが保守するドキュメントとは異なり、システム カタログ情報は常に完全であり、現在のテーブル定義と同期されます。 nz_ddl_table などのユーティリティを使用すると、システム カタログ情報にアクセスして、Azure Synapse で同等のテーブルを作成する CREATE TABLE DDL ステートメントを生成できます。
同様の結果を得るために、システム カタログ情報を処理するサードパーティの移行および ETL のツールを使用することもできます。
Netezza からのデータの抽出
nzsql や nzunload などの標準の Netezza ユーティリティを使用するか、外部テーブル経由で、Netezza テーブルから CSV ファイルなどのフラット区切りファイルに生テーブル データを抽出できます。 次に、gzip を使用してフラット区切りファイルを圧縮し、AzCopy や Azure Data Box などの Azure データトランスポート ツールを使用して圧縮ファイルを Azure Blob Storage にアップロードできます。
テーブル データを可能な限り効率的に抽出します。 外部テーブルのアプローチが最も高速な抽出方法であるため、これを使用します。 複数の抽出を並列で実行し、データ抽出のスループットを最大にします。 次の SQL ステートメントは、外部テーブルの抽出を実行します。
CREATE EXTERNAL TABLE '/tmp/export_tab1.csv' USING (DELIM ',') AS SELECT * from <TABLENAME>;
十分なネットワーク帯域幅を使用できる場合、オンプレミスの Netezza システムから Azure Synapse テーブルまたは Azure Blob Data Storage に直接データを抽出できます。 これを行うには、Data Factory プロセスまたはサードパーティのデータ移行や ETL の製品を使用します。
ヒント
最も効率的なデータ抽出には、Netezza 外部テーブルを使用します。
抽出されたデータ ファイルには、CSV、Optimized Row Columnar (ORC)、または Parquet 形式の区切りテキストが含まれている必要があります。
Netezza 環境からデータと ETL を移行する詳細については、「Netezza 移行のためのデータ移行、ETL、読み込み」を参照してください。
Netezza 移行のパフォーマンスに関する推奨事項
パフォーマンスの最適化の目標は、Azure Synapse への移行後のデータ ウェアハウスのパフォーマンスのを同等以上にすることです。
パフォーマンス チューニング アプローチの概念の類似点
Netezza データベースのパフォーマンス チューニングの概念の多くは、Azure Synapse データベースにあてはまります。 次に例を示します。
データ分布を使用して、同じ処理ノードに結合するデータを併置します。
特定の列に対して最小のデータ型を使用して、ストレージ領域を節約し、クエリ処理を高速化します。
結合する列のデータ型が同じになるようにして、結合処理を最適化し、データ変換の必要性を削減します。
オプティマイザーで最適な実行プランを生成するのに役立つように、統計を常に最新にしておきます。
組み込みのデータベース機能を使用してパフォーマンスを監視し、リソースが効率的に使用されるようにします。
ヒント
移行の開始時に、Azure Synapse のチューニング オプションの学習を優先してください。
パフォーマンス チューニング アプローチの相違点
このセクションでは、Netezza と Azure Synapse のパフォーマンス チューニングの詳細な実装の違いについて説明します。
データ分散オプション
パフォーマンスのために、Azure Synapse はマルチノード アーキテクチャを使用して設計されていて、並列処理を使用します。 テーブルのパフォーマンスを最適化するために、Azure Synapse では DISTRIBUTION を、Netezza では DISTRIBUTE ON を使用して、CREATE TABLE ステートメントでデータ分散オプションを定義できます。
Netezza とは異なり、Azure Synapse では、小さなテーブルのレプリケーションを使用して、小さなテーブルと大きなテーブルの間のローカル結合がサポートされます。 たとえば、スター スキーマ モデル内の小さなディメンション テーブルと大きなファクト テーブルを考えてみましょう。 Azure Synapse では、小さなディメンション テーブルをすべてのノードにレプリケートして、大きなテーブルの結合キーの値に一致するローカルで使用可能なディメンション行を確保できます。 ディメンション テーブルのレプリケーションのオーバーヘッドは、小さなディメンション テーブルでは比較的低くなります。 大きなディメンション テーブルの場合は、ハッシュ分散アプローチの方が適しています。 データ分散オプションの詳細については、レプリケート テーブルを使用するための設計ガイダンスと分散テーブルを設計するためのガイダンスを参照してください。
データのインデックス作成
Azure Synapse では、Netezza のシステム管理ゾーン マップとは操作と使用方法が異なる、ユーザーが定義できるいくつかのインデックス作成オプションがサポートされています。 Azure Synapse ではの異なるインデックス作成オプションの詳細については、専用 SQL プール テーブルのインデックス作成に関するページを参照してください。
移行元 Netezza 環境内の既存のシステム管理ゾーン マップでは、データの使用方法と、Azure Synapse 環境内でインデックスを作成するための候補列を実用的に示します。
データのパーティション分割
エンタープライズ データ ウェアハウスには、ファクト テーブルに数十億行が含まれる場合があります。 パーティション分割でこれらのテーブルを別々の部分に分割し、処理されるデータ量を減らすと、これらの保守とクエリのパフォーマンスが最適化されます。 Azure Synapse では、CREATE TABLE ステートメントは、テーブルのパーティション分割指定を定義します。
パーティション分割に使用できるフィールドは、テーブルごとに 1 つのみです。 多くのクエリは日付または日付範囲でフィルター処理されるため、多くの場合、このフィールドは日付フィールドになります。 CREATE TABLE AS ( CTAS) ステートメントを使用して、新しい分散のテーブルを再作成することにより、初期読み込み後にテーブルのパーティション分割を変更できます。 Azure Synapse でのパーティション分割の詳細については、「専用 SQL プールでのテーブルのパーティション分割」を参照してください。
データ テーブルの統計
ETL/ELT ジョブに統計ステップを組み込むことで、データ テーブルの統計が最新になるようにする必要があります。
データ読み込み用の PolyBase または COPY INTO
PolyBase では、並列読み込みストリームを使用して大量のデータをデータ ウェアハウスに効率的に読み込むことができます。 詳細については、PolyBase データ読み込み戦略に関する記事を参照してください。
COPY INTO でも、高スループットのデータ インジェストと、さらに次の処理がサポートされます。
フォルダーとサブフォルダー内のすべてのファイルからのデータ取得。
同じストレージ アカウント内の複数の場所からのデータ取得。 コンマ区切りのパスを使用して、複数の場所を指定できます。
Azure Data Lake Storage (ADLS) と Azure Blob Storage。
CSV、PARQUET、ORC の各ファイル形式。
ワークロードの管理
混合ワークロードを実行すると、ビジー状態のシステムでリソースの問題が発生する可能性があります。 正常なワークロード管理スキームでは、リソースが効果的に管理され、リソースが確実に効率よく利用され、投資収益率 (ROI) が最大化されます。 ワークロードの分類、ワークロードの重要度、ワークロードの分離により、ワークロードでのシステム リソースの利用方法をより詳細に制御できます。
ワークロード管理ガイドでは、ワークロードの分析、ワークロードの重要度の管理と監視の手法、およびリソース クラスのワークロード グループへの変換手順について説明しています。 Azure portal と DMV に対する T-SQL クエリを使用してワークロードを監視し、該当するリソースが効率的に利用されるようにします。
次のステップ
Netezza 移行の ETL と読み込みについては、このシリーズの次の記事「Netezza 移行のためのデータ移行、ETL、読み込み」を参照してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示