Netezza に関する Azure Synapse Analytics ソリューションと移行Azure Synapse Analytics solutions and migration for Netezza

IBM による Netezza のサポートが終了するため、現在 Netezza データ ウェアハウス システムを使用している多くの組織では、Azure のようなより新しい環境で革新的なクラウド、サービスとしてのインフラストラクチャ、サービスとしてのプラットフォームを利用することが検討されています。As IBM support for Netezza ends, many organizations that currently use Netezza data warehouse systems are looking to take advantage of innovative cloud, infrastructure as a service, and platform as a service offerings in newer environments like Azure. 多くの組織は、インフラストラクチャのメンテナンスやプラットフォームの開発といった、コストのかかるタスクをクラウド プロバイダーに移行するための手順を実行する準備ができています。Many organizations are ready to take the step of shifting expensive tasks like infrastructure maintenance and platform development to a cloud provider.

Azure Synapse Analytics は、エンタープライズ データ ウェアハウスとビッグ データ分析が統合された制限のない分析サービスです。Azure Synapse Analytics is a limitless analytics service that brings together enterprise data warehousing and big data analytics. サーバーレスのオンデマンド リソースまたはプロビジョニング済みのリソースを使用しながら、各自の条件で自由にデータのクエリを大規模に実行できます。It gives you the freedom to query data on your terms at scale by using either serverless on-demand or provisioned resources. 従来の Netezza システムを Azure Synapse に移行するときに計画する内容について説明します。Learn what to plan for as you migrate a legacy Netezza system to Azure Synapse.

Netezza と Azure Synapse は、いずれも大量のデータに対する高いクエリ パフォーマンスを実現するために、超並列処理手法を使用するように設計された SQL データベースであるという点で似ています。Netezza and Azure Synapse are similar in that each is a SQL database that's designed to use massively parallel processing techniques to achieve high query performance on large data volumes. しかし、2 つのプラットフォームは大事な点で違いがあります。But the two platforms are different in key aspects:

  • 従来の Netezza システムはオンプレミスにインストールされ、独自のハードウェアが使用されます。Legacy Netezza systems are installed on-premises, and they use proprietary hardware. Azure Synapse はクラウドベースであり、Azure のコンピューティングおよびストレージのリソースが使用されます。Azure Synapse is cloud-based and uses Azure compute and storage resources.
  • Netezza 構成のアップグレードは、追加の物理ハードウェアや、長時間かかる可能性のあるデータベースの再構成またはダンプと再読み込みを伴う大きなタスクです。Upgrading a Netezza configuration is a major task that involves extra physical hardware and a potentially lengthy database reconfiguration or dump and reload. Azure Synapse では、ストレージ リソースとコンピューティング リソースは分かれています。In Azure Synapse, storage and compute resources are separate. Azure の柔軟なスケーラビリティを使用して、個別にスケールアップまたはスケールダウンすることができます。You can use the elastic scalability of Azure to independently scale up or down.
  • サポートする物理システムがないので、必要に応じて Azure Synapse を一時停止したりそのサイズを変更したりして、リソースの使用率とコストを削減することができます。Without a physical system to support, you can pause or resize Azure Synapse as needed to reduce resource utilization and cost. Azure では、サポート ツールと機能のエコシステムに Azure Synapse が組み込まれている、グローバルに使用できる、高度なセキュリティで保護されたスケーラブルなクラウド環境にアクセスできます。In Azure, you have access to a globally available, highly secure, and scalable cloud environment that includes Azure Synapse in an ecosystem of supporting tools and capabilities.

この記事では、Azure Synapse で移行した Netezza データ ウェアハウスおよびデータ マートについて同等以上のパフォーマンスを得るために、ビューを使用してスキーマを移行する方法について説明します。In this article, we look at schema migration, with a view to obtaining equivalent or increased performance of your migrated Netezza data warehouse and data marts on Azure Synapse. 既存の Netezza 環境からの移行に特に適用される考慮事項について検討します。We consider concerns that apply specifically to migrating from an existing Netezza environment.

大まかに言えば、移行プロセスには次の表に示す手順が含まれています。At a high level, the migration process includes the steps that are listed in the following table:

準備Preparation 移行Migration 移行後Post-migration
  • 範囲を定義する: 何を移行するか?Define scope: what do we want to migrate?
  • 移行するデータとプロセスのインベントリを作成する。Build an inventory of data and processes to migrate.
  • データ モデルの変更を定義する。Define any data model changes.
  • 使用する最適な Azure およびサードパーティのツールと機能を特定する。Identify the best Azure and third-party tools and features to use.
  • 新しいプラットフォームのスタッフ トレーニングを早期に実施する。Train staff early on the new platform.
  • Azure のターゲット プラットフォームをセットアップする。Set up the Azure target platform.
  • 小規模で簡単なものから始める。Start small and simple.
  • 可能であれば自動化する。Automate where possible.
  • Azure の組み込みツールと機能を使用して移行作業を減らす。Use Azure built-in tools and features to reduce the migration effort.
  • テーブルとビューのメタデータを移行する。Migrate metadata for tables and views.
  • 関連する履歴データを移行する。Migrate relevant historical data.
  • ストアド プロシージャとビジネス プロセスを移行またはリファクタリングする。Migrate or refactor stored procedures and business processes.
  • ETL または ELT の段階的読み込みプロセスを移行またはリファクタリングする。Migrate or refactor ETL or ELT incremental load processes.
  • 移行プロセスのすべてのステージを監視してドキュメント化する。Monitor and document all stages of the migration process.
  • 今後の移行のため、得られた経験を利用してテンプレートを作成する。Use experience gained to build a template for future migrations.
  • 必要な場合、新しいプラットフォームのパフォーマンスとスケーラビリティを使用して、データ モデルを再エンジニアリングする。Reengineer the data model if necessary by using the new platform's performance and scalability.
  • アプリケーションとクエリ ツールをテストする。Test applications and query tools.
  • クエリ パフォーマンスのベンチマークと最適化を行う。Benchmark and optimize query performance.

従来の Netezza 環境から Azure Synapse に移行するときは、Netezza のドキュメントで説明されている比較的一般的な情報に加えて、いくつかの特定の要因について検討する必要があります。When you migrate from a legacy Netezza environment to Azure Synapse, you must consider some specific factors, in addition to the more general subjects described in the Netezza documentation.

初期移行ワークロードInitial migration workload

従来の Netezza 環境は、通常、複数の主題領域と混合ワークロードを含むように、時間の経過と共に進化しています。Legacy Netezza environments typically evolve over time to encompass multiple subject areas and mixed workloads. 最初の移行プロジェクトをどこから始めるか決定するときは、次のような領域を選択することをお勧めします。When you are deciding where to start on an initial migration project, it makes sense to choose an area that:

  • 新しい環境の利点を迅速に提供することで、Azure Synapse への移行の実現可能性が証明される。Proves the viability of migrating to Azure Synapse by quickly delivering the benefits of the new environment.
  • 社内のテクニカル スタッフが、他の領域の移行に使用できるように、新しいプロセスやツールに関する経験を得られる。Allows in-house technical staff to gain experience with new processes and tools so that they can use them to migrate other areas.
  • 移行元 Netezza 環境からの追加の移行で使用する、現在のツールとプロセスに基づくテンプレートが作成される。Creates a template based on the current tools and processes to use in additional migration from the source Netezza environment.

これらの目標が満たされる Netezza 環境からの初期移行に適した候補は、通常、OLTP ワークロードではなく、Power BI や分析のワークロードが実装されている部分です。A good candidate for an initial migration from a Netezza environment that would support these objectives typically is one that implements a Power BI/analytics workload rather than an OLTP workload. そのようなワークロードでは、スター スキーマやスノーフレーク スキーマなど、最小限の変更で移行できるデータ モデルが使用されている必要があります。The workload should have a data model that can be migrated with minimal modifications, such as a star or snowflake schema.

サイズに関しては、最初の演習で移行するデータ量が、短い時間で価値を示すことにより、Azure Synapse 環境の機能と利点を示すのに十分な大きさであることが重要です。For size, it's important that the data volume you migrate in the initial exercise is large enough to demonstrate the capabilities and benefits of the Azure Synapse environment with a short time to demonstrate value. 通常、そのような要件を満たすサイズは、1 テラバイト (TB) から 10 TB の範囲です。The size that typically meets the requirements is in the range of 1 terabyte (TB) to 10 TB.

リスクと実装時間を最小限に抑える初期移行プロジェクトのアプローチは、データ マートへの移行の範囲を制限することです。An approach for the initial migration project that minimizes risk and implementation time is to confine the scope of the migration to data marts. このアプローチは、移行の範囲が明確に制限され、通常は短いタイムスケール内で実現できるため、出発点として適しています。This approach is a good starting point because it clearly limits the scope of the migration and typically can be achieved on a short timescale. データ マートの初期移行だけでは、ETL や履歴データの移行方法といった、より広範な問題に対処することはできません。An initial migration of data marts only doesn't address broader concerns like how to migrate ETL and historical data. これらの領域については後のフェーズで対処し、移行したデータ マート レイヤーを、それらを構築するために必要なデータとプロセスでバックフィルする必要があります。You must address these areas in later phases and backfill the migrated data mart layer with the data and processes that are required to build them.

リフト アンド シフト方式と段階的方式の比較Lift-and-shift approach vs. phased approach

移行に対して選択した原動力や範囲とは関係なく、次の 2 種類の一般的な移行のどちらかを選択できます。Regardless of the drivers and scope that you choose for your migration, you can choose from two general types of migration:

  • リフトアンドシフト方式: この方式では、既存のデータ モデル (スター スキーマなど) は、そのまま新しい Azure Synapse プラットフォームに移行されます。Lift-and-shift approach: In this approach, the existing data model, such as a star schema, is migrated unchanged to the new Azure Synapse platform. このシナリオで重視されるのは、Azure クラウド環境への移行の利点を実現するために必要な作業を減らすことで、リスクを最小限に抑え、移行にかかる時間を短縮することです。In this scenario, the emphasis is on minimizing risk and the time it takes to migrate by reducing the work that has to be done to achieve the benefits of moving to the Azure cloud environment.

    この方式は、1 つのデータ マートが移行される既存の Teradata 環境で、データが既に適切に設計されたスター スキーマやスノーフレーク スキーマになっている場合に適しています。This approach is a good fit for existing Teradata environments in which a single data mart is to be migrated, and if the data is already in a well-designed star or snowflake schema. この方式は、より最新のクラウド環境への移行に対して時間とコストの制約がある場合にも適しています。This approach is a good choice also if you have time and cost pressures to move to a more modern cloud environment.

  • 変更を伴う段階的方式: レガシ ウェアハウスが時間の経過と共に進化してきた場合は、必要なパフォーマンスを維持したり、IoT ストリームなどの新しいデータ ソースをサポートしたりするために、データ ウェアハウスのリエンジニアリングが必要になることがあります。Phased approach that incorporates modifications: When a legacy warehouse has evolved over time, you might need to reengineer the data warehouse to maintain the required performance or to support new data sources like IoT streams. リエンジニアリング プロセスの一環として、スケーラブルなクラウド環境のよく知られている利点を得るために Azure Synapse に移行することを検討する場合があります。Migrating to Azure Synapse for the well-known benefits of a scalable cloud environment might be considered part of the reengineering process. このプロセスには、基になるデータ モデルの変更 (Inmon モデルから Azure Data Vault への移行など) が含まれる場合があります。This process might include changing the underlying data model, such as moving from an Inmon model to Azure Data Vault.

    最初に既存のデータ モデルをそのまま Azure に移行する方式をお勧めします。The approach we recommend is to initially move the existing data model as-is to Azure. その後、Azure サービスのパフォーマンスと柔軟性を利用して、既存の移行元システムに影響を与えずにリエンジニアの変更を適用します。Then, take advantage of the performance and flexibility of Azure services to apply the reengineering changes without affecting the existing source system.

メタデータの移行Metadata migration

Azure 環境の機能を使用することで、移行プロセスを自動化し、調整することは理にかなっています。It makes sense to automate and orchestrate the migration process by using the capabilities of the Azure environment. この方式では、既に容量の上限に近い状態で実行されている可能性がある、既存の Netezza 環境への影響も最小限に抑えられます。This approach minimizes the effect on the existing Netezza environment, which might already be running close to full capacity.

Azure Data Factory は、クラウドベースのデータ統合サービスです。Azure Data Factory is a cloud-based data integration service. Data Factory を使用すると、クラウドにデータ ドリブン ワークフローを作成して、データ移動とデータ変換を調整および自動化できます。You can use Data Factory to create data-driven workflows in the cloud to orchestrate and automate data movement and data transformation. Data Factory パイプラインでは、さまざまなデータ ストアからデータを取り込んだ後、Apache Hadoop や Apache Spark 用の Azure HDInsight、Azure Data Lake Analytics、Azure Machine Learning などのコンピューティング サービスを使用して、データの処理と変換を行うことができます。Data Factory pipelines can ingest data from disparate datastores, and then process and transform the data by using compute services like Azure HDInsight for Apache Hadoop and Apache Spark, Azure Data Lake Analytics, and Azure Machine Learning. 最初に、移行するデータ テーブルとその場所をリストするメタデータを作成してから、Data Factory の機能を使用して移行プロセスを管理します。You start by creating metadata to list the data tables you want to migrate, with their locations, and then use Data Factory capabilities to manage the migration process.

Netezza と Azure Synapse の設計の違いDesign differences between Netezza and Azure Synapse

従来の Netezza 環境から Azure Synapse への移行を計画するときは、2 つのプラットフォームの設計の違いを考慮することが重要です。As you plan your migration from a legacy Netezza environment to Azure Synapse, it's important to consider the design differences between the two platforms.

複数のデータベースに対して、1 つのデータベースとスキーマMultiple databases vs. a single database and schemas

Netezza 環境では、環境全体の異なる部分に対して複数の異なるデータベースが存在することがあります。In a Netezza environment, you might have multiple, separate databases for different parts of the overall environment. たとえば、データ インジェストおよびステージング テーブルのデータベース、コア ウェアハウス テーブルのデータベース、データ マート (" セマンティック レイヤー " とも呼ばれる) のデータベースが個別に存在する場合があります。For example, you might have a separate database for data ingestion and staging tables, a database for core warehouse tables, and another database for data marts, sometimes called a semantic layer . Azure Synapse で ETL および ELT パイプラインとして個別のデータベースを処理するには、データベース間結合を実装し、異なるデータベース間でデータを移動する必要があります。Processing separate databases as ETL/ELT pipelines in Azure Synapse might require implementing cross-database joins and moving data between the separate databases.

Azure Synapse 環境にあるデータベースは 1 つです。The Azure Synapse environment has a single database. スキーマは、テーブルを論理的に分かれたグループに分割するために使用されます。Schemas are used to separate tables into logically separate groups. 移行先の Azure Synapse で一連のスキーマを使用して、Netezza から移行する個別のデータベースを模倣することをお勧めします。We recommend that you use a series of schemas in the target Azure Synapse to mimic any separate databases that you migrate from Netezza. Netezza 環境でスキーマを使用している場合は、Netezza の既存のテーブルとビューを新しい環境に移動するために、新しい名前付け規則を使用することが必要な場合があります。If you use schemas in the Netezza environment, you might need to use a new naming convention to move the existing Netezza tables and views to the new environment. たとえば、Netezza の既存のスキーマ名とテーブル名を連結して Azure Synapse の新しいテーブル名にしてから、新しい環境でスキーマ名を使用して、元の個別のデータベース名を維持するような場合があります。For example, you might concatenate the existing Netezza schema and table names into the new Azure Synapse table name, and then use schema names in the new environment to maintain the original separate database names.

もう 1 つの方法は、基になるテーブルに対して SQL ビューを使用して、論理構造を維持することです。Another option is to use SQL views over the underlying tables to maintain the logical structures. SQL ビューを使用すると、次のような欠点が生じる可能性があります。There are some potential downsides to using SQL views:

  • Azure Synapse のビューは読み取り専用であるため、データに対する更新は、基になるベース テーブルで行う必要があります。Views in Azure Synapse are read-only, so you must make any updates to the data on the underlying base tables.
  • ビューのレイヤーが既に存在する場合、別のビューのレイヤーを追加すると、パフォーマンスが低下する可能性があります。If layers of views already exist, adding another layer of views might affect performance.

テーブルTables

異なるテクノロジ間でテーブルを移行するときは、生データとそれを記述するメタデータだけを、2 つの環境間で物理的に移動します。When you migrate tables between different technologies, you physically move only raw data and the metadata that describes it between the two environments. インデックスのようなデータベース要素は、新しい環境では必要なかったり、異なる方法で実装されたりする場合があるため、移行元システムからは移行しません。You don't migrate database elements like indexes from the source system because they might not be needed or they might be implemented differently in the new environment.

ただし、インデックスなどのパフォーマンス最適化が移行元環境のどこで使用されていたかを把握しておくことは、新しい環境でパフォーマンスを最適化できる場所を示すのに役立ちます。However, understanding where performance optimizations like indexes have been used in the source environment can be a helpful indication of where you might optimize performance in the new environment. たとえば、移行元の Netezza 環境のクエリでゾーン マップが頻繁に使用されている場合は、移行先の Azure Synapse 環境で非クラスター化インデックスを作成すると有益である、またはテーブル レプリケーションのような他のネイティブなパフォーマンス最適化手法を使用する方が、既存のものと同じインデックスを作成するより適している、という結論になる可能性があります。For example, if queries in the source Netezza environment frequently use zone maps, you might conclude that it would be advantageous to create a nonclustered index in the migrated Azure Synapse environment, or that using other native performance optimization techniques like table replication might be preferable to creating a like-for-like index.

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

Netezza では、Azure Synapse で直接サポートされていない、いくつかのデータベース オブジェクトが実装されています。Netezza implements some database objects that aren't directly supported in Azure Synapse. ただし、Azure Synapse には、次の一覧で説明するように、新しい環境で同じ機能を実現するために使用できる方法が用意されています。However, Azure Synapse offers methods that you can use to achieve the same functionality in the new environment, as described in the following list:

  • ゾーン マップ: Netezza では、一部の列の型に対して、ゾーン マップが自動的に作成されて維持されます。Zone maps: In Netezza, zone maps are automatically created and maintained for some column types. ゾーン マップは、スキャンされるデータの量を制限するために、次の列の型に対するクエリ時に使用されます。Zone maps are used at query time on the following column types to restrict the amount of data to be scanned:

    • 長さが 8 バイト以下の INTEGERINTEGER columns that are a length of 8 bytes or less
    • DATETIMETIMESTAMP を含むテンポラル列Temporal columns, including DATE, TIME, and TIMESTAMP
    • CHAR 列 (それらが具体化されたビューの一部であり、ORDER BY 句に含まれる場合)CHAR columns, if they are part of a materialized view and included in the ORDER BY clause

    nz_zonemap ユーティリティを使用して、ゾーン マップがある列を確認できます。You can find out which columns have zone maps by using the nz_zonemap utility. このユーティリティは、NZ ツールキットの一部です。The utility is part of the NZ Toolkit.

    Azure Synapse ではゾーン マップは使用されていませんが、ユーザー定義のインデックスの種類またはパーティション分割を使用することで、同様の結果を実現できます。Azure Synapse doesn't use zone maps, but you can achieve similar results by using user-defined index types or partitioning.

  • クラスター化されたベース テーブル (CBT): Netezza で最もよく使用される CBT は、大量のレコードが含まれるファクト テーブルです。Clustered base tables (CBTs): In Netezza, the most common CBT is the fact table, which has billions of records. このような大きなテーブルをスキャンするには、関連するレコードを取得するためにフル テーブル スキャンが必要になる可能性があるため、長い処理時間が必要になります。Scanning such a huge table requires a long processing time because a full table scan might be needed to get relevant records. 制限付きの CBT でレコードを整理すると、Netezza で同じエクステントまたは近くにあるエクステントのレコードをグループ化できます。By organizing records in restrictive CBTs, Netezza can group records in the same or nearby extents. また、このプロセスでは、スキャンするデータの量を減らすことで、パフォーマンスを向上させるゾーン マップも作成されます。The process also creates zone maps that improve performance by reducing the amount of data to scan.

    Azure Synapse では、パーティション分割または他のインデックスの種類を使用して、同様の結果を得ることができます。In Azure Synapse, you can achieve a similar result through partitioning or by using other index types.

  • 具体化されたビュー: Netezza では、多数の列があり、そのうちの数列だけがクエリでよく使用される大きなテーブルより、1 つ以上の具体化されたビューを作成することが推奨されます。Materialized views: Netezza recommends that users create one or more materialized view over large tables that have many columns, and in which only a few columns are regularly used in queries. 具体化されたビューは、ベース テーブルのデータが更新されるとシステムで自動的に維持されます。Materialized views are automatically maintained by the system when data in the base table is updated.

    現在、Azure Synapse では、Netezza と同じ機能を持つ具体化されたビューのプレビュー サポートが提供されています。Currently, Microsoft offers preview support for materialized views, with the same functionality as Netezza, in Azure Synapse.

  • データ型のマッピング: ほとんどの Netezza データ型には、Azure Synapse に直接相当するものがあります。Data type mapping: Most Netezza data types have a direct equivalent in Azure Synapse. 次の表では、データ型と、データ型をマップする推奨される方法を示します。The following table shows the data types and the recommended approaches for mapping the data types.

    一部のサードパーティ ベンダーからは、データ型のマッピングなどの移行タスクを自動化できるツールとサービスが提供されています。Some third-party vendors offer tools and services that can automate migration tasks, including data type mapping. Informatica や Talend などのサードパーティの ETL ツールが Netezza 環境で既に使用されている場合は、そのツールを使用して、必要なデータ変換を実装できます。If a third-party ETL tool like Informatica or Talend is already used in the Netezza environment, you can use the tool to implement any data transformations that are required.

  • SQL データ操作言語 (DML) の構文: Netezza SQL と Azure Synapse の間で、SQL DML 構文のいくつかの違いに注意する必要があります。SQL Data Manipulation Language (DML) syntax: You should be aware of a few differences in SQL DML syntax between Netezza SQL and Azure Synapse.

    いくつかの主要な関数とその違いを次に示します。Here are some key functions and how they are different:

    • STRPOS:Netezza の STRPOS 関数からは、文字列内の部分文字列の位置が返されます。STRPOS: In Netezza, the STRPOS function returns the position of a substring within a string. Azure Synapse でそれと同等のものは CHARINDEX 関数ですが、引数の順序は逆になります。The equivalent in Azure Synapse is the CHARINDEX function, and the order of the arguments is reversed.

      Netezza の場合:In Netezza:

      SELECT STRPOS('abcdef', 'def') ...

      Azure Synapse では次のコードに置き換えられます。Is replaced with the following code in Azure Synapse:

      SELECT CHARINDEX('def', 'abcdef') ...

    • AGE:Netezza では、2 つのテンポラル値 (タイムスタンプ、日付など) の間隔を得るために、AGE 演算子がサポートされています。AGE: Netezza supports the AGE operator to give the interval between two temporal values (for example, timestamps and dates). 次に例を示します。For example:

      SELECT AGE ('23-03-1956', '01-01-2019') FROM ...

      Azure Synapse では、DATEDIFF を使用して同じ結果を実現できます (日付表現の順序に注意してください)。You can achieve the same result in Azure Synapse by using DATEDIFF (note the date representation sequence):

      SELECT DATEDIFF(day, '1956-03-23', '2019-01-01') FROM ...

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

関数、ストアド プロシージャ、シーケンスFunctions, stored procedures, and sequences

Netezza のような成熟したレガシ環境からデータ ウェアハウスを移行するときは、単純なテーブルやビュー以外の要素を新しいターゲット環境に移行することが必要になることがよくあります。When you migrate a data warehouse from a mature legacy environment like Netezza, you often need to migrate elements other than simple tables and views to the new target environment. Azure Synapse への移行が必要になる可能性がある Netezza のテーブル以外の要素の例としては、関数、ストアド プロシージャ、シーケンスなどがあります。Examples of non-table elements in Netezza that you might need to migrate to Azure Synapse are functions, stored procedures, and sequences. 移行の準備フェーズでは、移行するオブジェクトのインベントリを作成する必要があります。During the preparation phase of the migration, you should create an inventory of objects to migrate. プロジェクト計画で、すべてのオブジェクトを処理する方法を定義し、移行のための適切なリソースを割り当てます。In the project plan, define the method of handling all objects and allocate the appropriate resources for their migration.

Netezza 環境で関数またはストアド プロシージャとして実装されている機能の代わりになるサービスが、Azure 環境で見つかる場合があります。You might find services in the Azure environment that replace the functionality implemented as functions or stored procedures in the Netezza environment. 通常、Netezza の関数をコーディングし直すのではなく、Azure の組み込み機能を使用する方が効率的です。Usually, it's more efficient to use the built-in Azure capabilities instead of recoding the Netezza functions.

また、サードパーティのベンダーから、Netezza からの関数、ストアド プロシージャ、シーケンスの移行を自動化できるツールとサービスが提供されています。Also, third-party vendors offer tools and services that can automate the migration of functions, stored procedures, and sequences from Netezza. たとえば、Qlik (旧称 Attunity) や WhereScape などです。Examples include Qlik (formerly Attunity) and WhereScape.

関数、ストアド プロシージャ、シーケンスの移行に関する追加情報を次に示します。Here's some additional information about migrating functions, stored procedures, and sequences:

  • 関数: ほとんどのデータベース製品と同様に、Netezza では SQL の実装でのシステム関数とユーザー定義関数がサポートされています。Functions: Like most database products, Netezza supports system functions and user-defined functions in a SQL implementation. 一般的なシステム関数は、Azure Synapse などの別のデータベース プラットフォームに移行されると、一般に新しい環境で使用でき、変更なしに移行できます。When common system functions are migrated to another database platform like Azure Synapse, they generally are available in the new environment and can be migrated without change. 新しい環境でシステム関数の構文が若干異なる場合は、通常、必要な変更を自動化できます。If system functions have slightly different syntax in the new environment, you usually can automate the required changes.

    新しい環境に同等のものがない任意のユーザー定義関数とシステム関数については、再コーディングが必要になる場合があります。You might need to recode arbitrary user-defined functions and system functions that have no equivalent in the new environment. 新しい環境で使用できる言語を使用します。Use the languages that are available in the new environment. Netezza のユーザー定義関数は、nzLua または C++ を使用してコーディングされています。Netezza user-defined functions are coded by using nzLua or C++. Azure Synapse でユーザー定義関数を実装するには、一般的な Transact-SQL 言語が使用されます。Azure Synapse uses the popular Transact-SQL language to implement user-defined functions.

  • ストアド プロシージャ: ほとんどの最新のデータベース製品では、データベースにプロシージャを保存できます。Stored procedures: In most modern database products, you can store procedures n the database. ストアド プロシージャには、通常、SQL ステートメントといくつかの手続き型ロジックが含まれています。A stored procedure typically contains SQL statements and some procedural logic. また、データや状態が返される場合もあります。It might also return data or a status.

    Netezza では、ストアド プロシージャ用に、PL/pgSQL に基づく NZPLSQL 言語が用意されています。Netezza provides the NZPLSQL language, based on PL/pgSQL, for stored procedures. Azure Synapse では、T-SQL を使用してストアド プロシージャがサポートされます。Azure Synapse supports stored procedures by using T-SQL. ストアド プロシージャを Azure Synapse に移行する場合は、T-SQL を使用してそれらをコーディングし直す必要があります。If you migrate stored procedures to Azure Synapse, you must recode them by using T-SQL.

  • シーケンス: Netezza でのシーケンスは、CREATE SEQUENCE ステートメントを使用して作成される名前付きデータベース オブジェクトです。Sequences: In Netezza, a sequence is a named database object that's created via a CREATE SEQUENCE statement. オブジェクトを使用すると、NEXT() メソッドを介して一意の値を提供できます。Objects can provide the unique value via the NEXT() method. 値を使用して、主キー値に対する代理キー値となる一意の数値を生成できます。You can use values to generate unique numbers as surrogate key values for primary key values.

    Azure Synapse では、CREATE SEQUENCE はサポートされていません。Azure Synapse doesn't support CREATE SEQUENCE. Azure Synapse のシーケンスは、ID 列を使用することで、または SQL コードを使用して系列の次のシーケンス番号を作成することで、処理されます。In Azure Synapse, sequences are handled by using identity columns or SQL code to create the next sequence number in a series.

メタデータとデータの抽出Metadata and data extraction

Netezza 環境からメタデータとデータを抽出する方法を計画する場合は、次の情報を考慮します。Consider the following information when you plan how to extract metadata and data from the Netezza environment:

  • データ定義言語 (DDL) の生成: 前に説明したように、Netezza の既存の CREATE TABLE および CREATE VIEW スクリプトを編集し、必要に応じてデータ型を変更して、同等の定義を作成することができます。Data Definition Language (DDL) generation: It's possible to edit existing Netezza CREATE TABLE and CREATE VIEW scripts to create the equivalent definitions, with modified data types if necessary, as described earlier. 通常、このタスクでは、ORGANIZE ON のように Netezza に固有の句を削除または変更する必要があります。This task usually involves removing or modifying any clauses that are specific to Netezza, like ORGANIZE ON.

    Netezza では、現在のテーブルとビューの定義を指定する情報が、システム カタログ テーブルに保持されます。In Netezza, the information that specifies the current table and view definitions is maintained in system catalog tables. システム カタログ テーブルは、最新で完全な状態である可能性があるため、情報の最適なソースです。System catalog tables are the best source of the information because the tables likely are up to date and complete. ユーザーが管理するドキュメントは、現在のテーブル定義と同期されていない可能性があります。User-maintained documentation might not be in sync with current table definitions.

nz_ddl_table のようなユーティリティを使用することで、Netezza のシステム カタログ テーブルにアクセスできます。You can access system catalog tables in Netezza by using a utility like nz_ddl_table. テーブルを使用して CREATE TABLE DDL ステートメントを生成し、それを Azure Synapse の同等のテーブル用に編集できます。You can use the tables to generate CREATE TABLE DDL statements, which you can then edit for the equivalent tables in Azure Synapse. サードパーティの移行および ETL ツールでも、カタログ情報を使用して同じ結果が得られます。Third-party migration and ETL tools also use the catalog information to achieve the same results.

  • データの抽出: nzsql や nzsql などの標準的な Netezza ユーティリティと外部テーブルを使用して、既存の Netezza テーブルからフラットな区切りファイルに移行するための生データを抽出できます。Data extraction: You can extract raw data to migrate from an existing Netezza table into a flat, delimited file by using standard Netezza utilities like nzsql and nzunload, and by using external tables. gzip を使用してファイルを圧縮した後、AzCopy または Azure Data Box などの Azure データ転送サービスを使用して、Azure Blob Storage にファイルをアップロードします。Compress the files by using gzip, and then use AzCopy or an Azure data transport service like Azure Data Box to upload the files to Azure Blob storage.

    移行の演習では、できるだけ効率的にデータを抽出することが重要です。During a migration exercise, it's important to extract data as efficiently as possible. Netezza に対して推奨される方法は、最も高速な方法でもある外部テーブルを使用することです。The recommended approach for Netezza is to use external tables, which also is the fastest method. 複数の抽出を並列に実行し、データ抽出のスループットを最大にできます。You can complete multiple extracts in parallel to maximize the throughput for data extraction.

外部テーブルの抽出の簡単な例を次に示します。Here's a simple example of an external table extract:

CREATE EXTERNAL TABLE '/tmp/export_tab1.CSV' USING (DELIM ',') AS SELECT * from <TABLE-NAME>;

十分なネットワーク帯域幅が存在する場合は、Data Factory プロセスか、サードパーティのデータ移行または ETL 製品を使用して、オンプレミスの Netezza システムから Azure Synapse テーブルまたは Azure データ ストレージにデータを直接抽出できます。If you have sufficient network bandwidth, you can extract data directly from an on-premises Netezza system into Azure Synapse tables or into Azure data storage by using Data Factory processes or third-party data migration or ETL products.

抽出されたデータに対して推奨されるデータ形式は、区切りテキスト ファイル (" コンマ区切り値 " とも呼ばれます)、Optimized Row Columnar、または Parquet ファイルです。Recommended data formats for extracted data are delimited text files (also called comma-separated values ), optimized row columnar files, or Parquet files.

Netezza 環境からデータと ETL を移行するプロセスの詳細については、データ移行 ETL と読み込みに関する Netezza のドキュメントを参照してください。For more detailed information about the process of migrating data and ETL from a Netezza environment, see the Netezza documentation about data migration ETL and load.

パフォーマンス チューニングに関する推奨事項Performance-tuning recommendations

Netezza 環境から Azure Synapse に移動する場合、パフォーマンス チューニングの概念の多くは Netezza のものと似ています。When you move to Azure Synapse from a Netezza environment, many of the performance-tuning concepts you use will be familiar.

たとえば、次の概念はどちらの環境でも同じです。For example, these concepts are the same for both environments:

  • データ分散では、同じ処理ノードにデータが結合されて配置されます。Data distribution colocates data to be joined onto the same processing node.
  • 特定の列に対して最小のデータ型を使用すると、ストレージ領域が節約され、クエリ処理が高速化されます。Using the smallest data type for a specific column saves storage space and accelerates query processing.
  • 結合される列のデータ型を同一にしておくと、データを一致させるために変換する必要性が減るため、結合処理が最適化されます。Ensuring that data types of columns to be joined are identical optimizes join processing by reducing the need to transform data for matching.
  • 統計が最新であることを確認しておくと、オプティマイザーで最適な実行プランを生成するのに役立ちます。Ensuring that statistics are up to date helps the optimizer produce the best execution plan.

最適化に関しては、プラットフォーム間にいくつかの違いがあります。There are some differences between platforms when it comes to optimization. パフォーマンス チューニングに関する推奨事項の次の一覧では、Netezza と Azure Synapse での下位レベルの実装の相違点と、移行に対する代替手段が強調して示されています。In the following list of performance-tuning recommendations, lower-level implementation differences between Netezza and Azure Synapse, and alternatives for your migration, are highlighted:

  • データ分散オプション: Netezza と Azure Synapse の両方で、CREATE TABLE ステートメントを使用して、分散の定義を指定できます。Data distribution options: In both Netezza and Azure Synapse, you can use a CREATE TABLE statement to specify a distribution definition. Netezza では DISTRIBUTE ON を使用し、Azure Synapse では DISTRIBUTION = を使用します。Use DISTRIBUTE ON for Netezza and DISTRIBUTION = for Azure Synapse.

    Azure Synapse は、小さいテーブルと大きいテーブル結合でローカル結合を実現するための追加の方法が提供されています。これは、スター スキーマ モデルで " ディメンション テーブルとファクト テーブルの結合 " と呼ばれることがよくあります。Azure Synapse provides an additional way to achieve local joins for small table/large table joins, often called a dimension table/fact table join in a star schema model. この方法では、小さいディメンション テーブルがすべてのノードにレプリケートされることにより、大きいテーブルの結合キーのすべての値に対して、一致するディメンション行をローカル環境で使用できるようになります。The approach is to replicate the smaller dimension table across all nodes, thereby ensuring that any value of the join key for the larger table will have a matching dimension row that's locally available. ディメンション テーブルが大きくない場合、テーブルをレプリケートする場合のオーバーヘッドは比較的低くなります。The overhead of replicating the dimension table is relatively low if the tables are not large. この場合、前に説明したハッシュ分散アプローチを使用することが推奨されます。In this case, using the hash distribution approach described earlier is preferable.

  • データのインデックス作成: Azure Synapse には、ユーザー定義が可能なさまざまなインデックス作成オプションが用意されていますが、オプションは Netezza のシステム管理ゾーン マップとは操作および使用方法が異なります。Data indexing: Azure Synapse provides various user-definable indexing options, but the options are different in operation and usage than system-managed zone maps in Netezza. Azure Synapse でのインデックス作成オプションの詳細については、Azure Synapse SQL プールでのインデックス テーブルに関するページを参照してください。To learn about the indexing options in Azure Synapse, see Index tables in an Azure Synapse SQL pool.

    移行元 Netezza 環境内の既存のシステム管理ゾーン マップでは、データがどのように使用されているかをわかりやすく示すことができ、Azure Synapse 環境内でインデックスを作成するための候補列も示すことができます。Existing system-managed zone maps in the source Netezza environment can provide a useful indication of how data is used and provide an indication of candidate columns for indexing in the Azure Synapse environment.

  • データのパーティション分割: エンタープライズ データ ウェアハウスでは、ファクト テーブルに数 10 億行のデータが含まれる場合があります。Data partitioning: In an enterprise data warehouse, fact tables might contain many billions of rows of data. パーティション分割は、これらのテーブルでのメンテナンスとクエリを最適化するための手段です。Partitioning is a way to optimize maintenance and querying in these tables. テーブルを個別のパーツに分割すると、一度に処理されるデータの量が少なくなります。Splitting the tables into separate parts reduces the amount of data processed at one time. テーブルのパーティション分割は、CREATE TABLE ステートメントで定義されます。Partitioning for a table is defined in the CREATE TABLE statement.

    パーティション分割に使用できるフィールドは、テーブルごとに 1 つだけです。Only one field per table can be used for partitioning. 多くのクエリが日付または日付範囲によってフィルター処理されるため、頻繁にパーティション分割に使用されるフィールドは日付フィールドです。The field that's used for partitioning frequently is a date field because many queries are filtered by date or by a date range. テーブルのパーティション分割は、初期読み込みの後で変更できます。You can change the partitioning of a table after initial load. テーブルのパーティション分割を変更するには、CREATE TABLE AS SELECT ステートメントを使用する新しい分散でテーブルを再作成します。To change a table's partitioning, re-create the table with a new distribution that uses the CREATE TABLE AS SELECT statement. Azure Synapse でのパーティション分割の詳細については、Azure Synapse SQL プールでのテーブルのパーティション分割に関するページを参照してください。For a detailed description of partitioning in Azure Synapse, see Partition tables in an Azure Synapse SQL pool.

  • データの読み込み用の PolyBase: PolyBase は、大量のデータをウェアハウスに読み込むために使用する最も効率的な方法です。PolyBase for data loading: PolyBase is the most efficient method to use to load large amounts of data into a warehouse. PolyBase を使用して、並列ストリームでデータを読み込むことができます。You can use PolyBase to load data in parallel streams.

  • ワークロード管理用のリソース クラス: Azure Synapse では、リソース クラスを使用してワークロードが管理されます。Resource classes for workload management: Azure Synapse uses resource classes to manage workloads. 一般に、大きなリソース クラスを使用すると、個々のクエリのパフォーマンスが向上します。In general, large resource classes provide better individual query performance. リソース クラスを小さくすると、より高いレベルのコンカレンシーが得られます。Smaller resource classes give you higher levels of concurrency. 動的管理ビューを使用して使用率を監視し、適切なリソースが効率的に使用されるようにすることができます。You can use dynamic management views to monitor utilization to help ensure that the appropriate resources are used efficiently.

次の手順Next steps

Netezza 移行の実装の詳細については、オンプレミスの移行プランについて Microsoft アカウント担当者にお問い合わせください。For more information about implementing a Netezza migration, talk with your Microsoft account representative about on-premises migration offers.