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

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

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. 従来の Teradata システムを Azure Synapse に移行するときに計画する内容について説明します。Learn what to plan for as you migrate a legacy Teradata system to Azure Synapse.

Teradata と Azure Synapse は、両者とも、大量のデータで高いクエリ パフォーマンスを実現するために超並列処理手法を使用するように設計された SQL データベースであるという点で類似していますが、基本的な違いがいくつかあります。Although Teradata and Azure Synapse are similar in that they're both SQL databases that are designed to use massively parallel processing techniques to achieve high query performance on large data volumes, they have some basic differences:

  • 従来の Teradata システムはオンプレミスにインストールされ、専用のハードウェアが使用されます。Legacy Teradata systems are installed on-premises, and they use proprietary hardware. Azure Synapse はクラウドベースであり、Azure のストレージ リソースとコンピューティング リソースが使用されます。Azure Synapse is cloud-based and uses Azure storage and compute resources.
  • Teradata 構成のアップグレードは、追加の物理ハードウェアや、長時間かかる可能性のあるデータベースの再構成またはダンプと再読み込みを伴う大きなタスクです。Upgrading a Teradata configuration is a major task that involves extra physical hardware and a potentially lengthy database reconfiguration or dump and reload. Azure Synapse では、ストレージ リソースとコンピューティング リソースが分離されるため、Azure の柔軟なスケーラビリティを利用して、個別にスケールアップやスケールダウンを簡単に行うことができます。In Azure Synapse, storage and compute resources are separate, so you can easily scale up or down independently by using the elastic scalability of Azure.
  • サポートする物理システムがないので、必要に応じて 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 で移行した Teradata データ ウェアハウスおよびデータ マートについて同等以上のパフォーマンスを得ることを目的として、スキーマの移行について説明します。In this article, we look at schema migration, with an objective of obtaining equivalent or increased performance of your migrated Teradata data warehouse and data marts on Azure Synapse. 既存の Teradata 環境からの移行に特に適用される考慮事項について検討します。We consider concerns that apply specifically to migrating from an existing Teradata 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/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.

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

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

通常、従来の Teradata 環境は、時間の経過と共に進化して、複数のサブジェクト領域や混合ワークロードが含まれるようになります。Legacy Teradata environments typically evolve over time to encompass multiple subject areas and mixed workloads. 最初の移行プロジェクトをどこから開始するのかを決定する場合、次のような領域を選択することをお勧めします。When you're 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.
  • 移行元の Teradata 環境からの追加の移行で使用するために、現在のツールとプロセスに基づいたテンプレートが作成される。Creates a template based on the current tools and processes to use in additional migration from the source Teradata environment.

これらの目標を支援する Teradata 環境からの初期移行に適した候補は、通常、OLTP ワークロードではなく、Power BI や分析のワークロードが実装されている部分です。A good candidate for an initial migration from a Teradata environment that would support these objectives usually 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 TBs.

リスクと実装時間を最小限に抑える初期移行プロジェクトのアプローチは、データ マートへの移行の範囲を制限することです。An approach for the initial migration project that minimizes risk and implementation time is to confine the scope of the migration to data marts. Teradata の好例としては、Teradata データ ウェアハウスの OLAP データベース部分が挙げられます。In Teradata, a good example is the OLAP database part of a Teradata data warehouse. このアプローチは、移行の範囲が限定され、多くの場合、短いタイムスケール内で実現できるため、出発点として適しています。This approach is a good starting point because it limits the scope of the migration, and it often can be achieved on a short timescale.

データ マートの初期移行の範囲だけでは、ETL や履歴データの移行方法など、より広範な問題に対処することはできません。An initial migration scope 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 you choose for your migration, you can choose from two general types of migrations:

  • リフト アンド シフト方式: この方式では、既存のデータ モデル (スター スキーマなど) は、そのまま新しい 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 クラウド環境への移行の利点を実現するために必要な作業を減らして、リスクを最小限に抑え、移行にかかる時間を短縮することです。The emphasis is on minimizing risk and the time it takes to migrate by reducing the work that's required to achieve the benefits of moving to the Azure cloud environment.

    この方式は、単一のデータ マートが移行される既存の 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: If your 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 データ コンテナーへの移行など) が含まれる場合があります。This process might include changing the underlying data model, such as moving from an Inmon model to an 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.

移行をサポートするための仮想マシン コロケーションVirtual machine colocation to support migration

オンプレミスの Teradata 環境から移行するオプションのアプローチでは、Azure の安価なクラウド ストレージと柔軟なスケーラビリティを利用します。An optional approach to migrate from an on-premises Teradata environment takes advantage of inexpensive cloud storage and elastic scalability in Azure. 最初に、ターゲットの Azure Synapse 環境と併置された Azure 仮想マシンに Teradata インスタンスを作成します。First, you create a Teradata instance on an Azure virtual machine that's colocated with the target Azure Synapse environment. 次に、Teradata Parallel Transporter などの標準の Teradata ユーティリティ、または Qlik Replicate (旧称 Attunity) などのサードパーティのデータ レプリケーション ツールを使用して、VM インスタンスに移行する Teradata テーブルのサブセットを効率的に移動します。Then, you use a standard Teradata utility like Teradata Parallel Transporter or a third-party data replication tool like Qlik Replicate (formerly by Attunity) to efficiently move the subset of Teradata tables that you're migrating to the VM instance. すべての移行タスクは、Azure 環境で実行されます。All migration tasks take place in the Azure environment.

この方法には、いくつかの利点があります。This approach has several benefits:

  • データの初期レプリケーション後、ソース システムは他の移行タスクの影響を受けません。After the initial replication of data, the source system isn't affected by other migration tasks.
  • 使い慣れた Teradata のインターフェイス、ツール、ユーティリティを、Azure 環境内で利用できます。Familiar Teradata interfaces, tools, and utilities are available in the Azure environment.
  • Azure 環境に移行した後、オンプレミスのソース システムとクラウド ターゲット システムの間で利用可能なネットワーク帯域幅に関する問題が発生する可能性はありません。After the migration shifts to the Azure environment, you don't have any potential issues with network bandwidth availability between the on-premises source system and the cloud target system.
  • Azure Data Factory などのツールを使用すると、Teradata Parallel Transporter などのユーティリティを効率的に呼び出して、データをすばやく簡単に移行できます。Tools like Azure Data Factory efficiently call utilities like Teradata Parallel Transporter to migrate data quickly and easily.
  • 移行プロセスは、Azure 環境内で完全に調整および制御されます。The migration process is orchestrated and controlled entirely from within the Azure environment.

メタデータの移行Metadata migration

Azure 環境の機能を使用することで、移行プロセスを自動化し、調整することは理にかなっています。It makes sense to automate and orchestrate the migration process by using the capabilities of the Azure environment. この方式により、既に容量の上限に近い状態で実行されている可能性がある、既存の Teradata 環境への影響も最小限に抑えられます。This approach minimizes impact on the existing Teradata 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 パイプラインは、さまざまなデータストアからデータを取り込むことができます。Data Factory pipelines can ingest data from disparate datastores. その後、それらにより Azure HDInsight for Apache Hadoop、Apache Spark、Azure Data Lake Analytics、Azure Machine Learning などのコンピューティング サービスを使ってデータが処理され、変換されます。Then, they 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.

まず、移行するデータ テーブルとその場所を一覧するメタデータを作成します。Start by creating metadata that lists the data tables you want to migrate, with their locations. 次に、Data Factory の機能を使用して、移行プロセスを管理します。Then, use Data Factory capabilities to manage the migration process.

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

従来の Teradata 環境から Azure Synapse への移行を計画する場合、この 2 つのプラットフォームの設計の違いを考慮することが重要です。As you plan your migration from a legacy Teradata 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

Teradata 環境では、環境全体の異なる部分に対して複数の異なるデータベースが存在することがあります。In a Teradata 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 で一連のスキーマを使用して、Teradata から移行する個別のデータベースを模倣することをお勧めします。We recommend that you use a series of schemas in Azure Synapse to mimic any separate databases you migrate from Teradata.

Teradata 環境でスキーマを使用する場合、Teradata の既存のテーブルとビューを新しい環境に移動するために、新しい名前付け規則を使用することが必要になる可能性があります。If you use schemas in the Teradata environment, you might need to use a new naming convention to move the existing Teradata tables and views to the new environment. たとえば、Teradata の既存のスキーマ名とテーブル名を連結して Azure Synapse の新しいテーブル名にしてから、新しい環境でスキーマ名を使用して、元の個別のデータベース名を維持することができます。For example, you might concatenate the existing Teradata 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 their 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.


異なるテクノロジ間でテーブルを移行するときは、生データとそれを記述するメタデータだけを、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. たとえば、一意でないセカンダリ インデックスが移行元の Teradata 環境で作成された場合、移行先の Azure Synapse 環境で非クラスター化インデックスを作成すると有益である、またはテーブル レプリケーションなどの他のネイティブなパフォーマンス最適化手法を使用する方が、既存のものと同じインデックスを作成するより適切であるという結論に達することがあります。For example, if a non-unique secondary index was created in the source Teradata environment, 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.

高可用性データベースHigh availability database

Teradata では、FALLBACK オプションを使用して、ノード間でのデータ レプリケーションがサポートされます。Teradata supports data replication across nodes via the FALLBACK option. ノードに物理的に存在するテーブル行は、システム内の別のノードにレプリケートされます。Table rows that reside physically on a node are replicated to another node within the system. このアプローチによって、ノードで障害が発生してもデータが消失しないことが保証され、フェールオーバー シナリオの基礎が提供されます。This approach guarantees that data isn't lost if a node fails, and it provides the basis for failover scenarios.

Azure SQL Database 内の高可用性アーキテクチャの目的は、データベースが 99.99% の時間稼働することを保証することにあります。The goal of the high-availability architecture in Azure SQL Database is to guarantee that your database is up and running 99.99% of the time. メンテナンス操作および停止がワークロードにどのように影響するかを考慮する必要はありません。You don't need to consider how maintenance operations and outages might affect your workload. Azure により、パッチ適用、バックアップ、Windows および SQL のアップグレードなどの重要なサービス タスクに加えて、基本となるハードウェア、ソフトウェア、またはネットワークのエラーなどの予定外のイベントが自動的に処理されます。Azure automatically handles critical servicing tasks like patching, backups, and Windows and SQL upgrades, and unplanned events like underlying hardware, software, or network failures.

これらのスナップショットは、Azure Synapse で復元ポイントを作成するサービスの組み込み機能です。Snapshots are a built-in feature of the service that creates restore points in Azure Synapse. スナップショットを使用すると、Azure Synapse でデータ ストレージを自動的にバックアップできます。Snapshots provide automatic backup for data storage in Azure Synapse. この機能を有効にする必要はありません。You don't have to enable the capability. 自動復元ポイントは、回復の SLA を保持するためにサービスで使用されるため、現時点では、ユーザーが個々に削除することはできません。Currently, individual users can't delete automatic restore points that the service uses to maintain SLAs for recovery.

Azure Synapse によって、1 日を通してデータ ウェアハウスのスナップショットが取得されます。Azure Synapse takes snapshots of the data warehouse throughout the day. 作成された復元ポイントは、7 日間使用できます。The restore points that it creates are available for seven days. この保有期間は変更できません。The retention period can't be changed. Azure Synapse により、8 時間の回復ポイントの目標がサポートされています。Azure Synapse supports an eight-hour recovery point objective. プライマリ リージョンのデータ ウェアハウスを、過去 7 日間に作成されたいずれかのスナップショットから復元することができます。You can restore your data warehouse in the primary region from any of the snapshots taken in the past seven days. 組織がさらに細かいバックアップを必要とする場合は、他のユーザー定義オプションを使用できます。Other user-defined options are available if your organization needs more granular backups.

サポートされていない Teradata テーブル型Unsupported Teradata table types

Teradata には、時系列とテンポラル データに対する特殊なテーブル型のサポートが含まれています。Teradata includes support for special table types for time series and temporal data. これらのテーブル型に対する構文と一部の関数は、Azure Synapse により直接サポートされていませんが、データを、必要なデータ型を含む標準テーブルに移行し、日付/時刻列でインデックス作成またはパーティション分割することができます。Azure Synapse doesn't directly support the syntax and some of the functions for these table types, but you can migrate the data into a standard table that has the required data types and indexing or partitioning on the date/time column.

Teradata には、クエリの書き換えによってテンポラル クエリ内にフィルターを追加し、該当する日付範囲を制限すると、テンポラル クエリ機能が実装されます。Teradata implements temporal query functionality by using query rewriting to add filters to a temporal query to limit the applicable date range. 移行元の Teradata 環境でテンポラル クエリを使用している場合、それを移行するには、関連するテンポラル クエリにフィルターを追加する必要があります。If you use temporal queries in the source Teradata environment and you want to migrate it, you must add filters to the relevant temporal queries.

Azure 環境には、Azure Time Series Insights を使用して大規模な時系列データの複雑な分析を行うための機能も含まれています。The Azure environment also includes features for complex analytics on time series data at scale through Azure Time Series Insights. Time Series Insights は、IoT データ分析アプリケーション向けに設計されており、そのユース ケースにより適している可能性があります。Time Series Insights is designed for IoT data analysis applications, and it might be more appropriate for that use case. 詳細については、「Azure Time Series Insights」を参照してください。For more information, see Azure Time Series Insights.

Teradata データ型のマッピングTeradata data type mapping

Teradata の一部のデータ型は、Azure Synapse で直接サポートされていません。Some Teradata data types aren't directly supported in Azure Synapse. 次の表は、これらのデータ型とそれらの推奨される処理方法を示します。The following table shows these data types and the recommended approach for handling them. この表で、Teradata の列の型は、システム カタログ (たとえば、DBC.ColumnsV 内) に格納される型です。In the table, the Teradata column type is the type that's stored in the system catalog (for example, in DBC.ColumnsV).

Teradata カタログ テーブルのメタデータを使用して、これらのデータ型のいずれかを移行する必要があるかどうかを判断し、移行プランで、リソースのサポートを計画します。Use the metadata from the Teradata catalog tables to determine whether any of these data types should be migrated, and then plan for supporting resources in your migration plan. たとえば、次のセクションで示すような SQL クエリを使用して、解決が必要なサポートされていないデータ型の使用を検出できます。For example, you can use a SQL query like the one in the next section to find any occurrences of unsupported data types that you need to address.

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

SQL データ操作言語 (DML) の構文の違いSQL Data Manipulation Language (DML) syntax differences

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

  • QUALIFY:Teradata では、QUALIFY 演算子がサポートされています。QUALIFY: Teradata supports the QUALIFY operator.

    次に例を示します。For example:

    SELECT col1 FROM tab1 WHERE col1='XYZ'

    サードパーティのツールとサービスを使用すると、データ マッピング タスクを自動化できます。Third-party tools and services can automate data-mapping tasks:


    Azure Synapse では、次の構文を使用して同じ結果を得ることができます。In Azure Synapse, you can achieve the same result by using the following syntax:

    SELECT * FROM (SELECT col1, ROW_NUMBER() OVER (PARTITION by col1 ORDER BY col1) rn FROM tab1 WHERE c1='XYZ' ) WHERE rn = 1;

  • 日付の算術演算子: Azure Synapse には、DATEADDDATEDIFF などの演算子があり、これらをDATE または DATETIME で使用することができます。Date arithmetic: Azure Synapse has operators like DATEADD and DATEDIFF, which you can use on DATE or DATETIME.

    Teradata によって、次のような日付の直接減算がサポートされています。Teradata supports direct subtraction on dates:


    • LIKE ANY の構文LIKE ANY syntax



      Azure Synapse の構文で相当するものは次のとおりです。The equivalent in Azure Synapse syntax is:


  • システム設定によって、既定では、Teradata の文字比較で大文字と小文字が区別されない場合があります。Depending on system settings, character comparisons in Teradata might not be case-specific by default. Azure Synapse の場合、これらの比較では常に大文字と小文字が区別されます。In Azure Synapse, these comparisons are always case-specific.

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

Teradata のような成熟したレガシ環境からデータ ウェアハウスを移行する場合、単純なテーブルやビュー以外の要素を新しいターゲット環境に移行することがしばしば必要になります。When you migrate a data warehouse from a mature legacy environment like Teradata, often you need to migrate elements other than simple tables and views to the new target environment. Teradata で Azure Synapse への移行が必要になる可能性があるテーブル以外の要素の例としては、関数、ストアド プロシージャ、シーケンスなどがあります。Examples of non-table elements in Teradata that you might need to migrate to Azure Synapse are functions, stored procedures, triggers, 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 to migrate them.

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

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

  • 関数: ほとんどのデータベース製品と同様に、Teradata によって SQL の実装でのシステム関数とユーザー定義関数がサポートされています。Functions: Like most database products, Teradata 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're usually 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. 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.

    Teradata には、ストアド プロシージャを作成するためのストアド プロシージャ言語が用意されています。Teradata provides Stored Procedure Language to create 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.

  • トリガー: Azure Synapse でトリガーを作成することはできませんが、Data Factory でトリガーを実装することができます。Triggers: You can't create triggers in Azure Synapse, but you can implement triggers in Data Factory.

  • シーケンス: Azure Synapse シーケンスは、Teradata と同様の方法で処理されます。Sequences: Azure Synapse sequences are handled similarly to how they are handled in Teradata. 系列内の次のシーケンス番号を作成するには、IDENTITY 列または SQL コードを使用します。Use IDENTITY columns or SQL code to create the next sequence number in a series.

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

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

  • データ定義言語 (DDL) の生成: 前述のとおり、Teradata の既存の CREATE TABLE および CREATE VIEW スクリプトを編集して、同等の定義を作成することができ、必要に応じて、データ型を変更します。Data Definition Language (DDL) generation: As described earlier, it's possible to edit existing Teradata CREATE TABLE and CREATE VIEW scripts to create the equivalent definitions, with modified data types, if necessary. このシナリオでは、通常、余分な Teradata 固有の句 (たとえば、FALLBACK) を削除する必要があります。In this scenario, you usually must remove extra Teradata-specific clauses (for example, FALLBACK).

    現在のテーブルとビューの定義を指定する情報が、システム カタログ テーブルに保持されます。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.

    この情報にアクセスするには、DBC.ColumnsV などのカタログに関するビューを使用します。You can access the information by using views on the catalog, such as DBC.ColumnsV. また、ビューを使用して、Azure Synapse の同等のテーブルに対する同等の CREATE TABLE データ記述言語 (DDL) ステートメントを生成することもできます。You also can use views to generate the equivalent CREATE TABLE Data Definition Language (DDL) statements for the equivalent tables in Azure Synapse.

    サードパーティの移行および ETL ツールでも、カタログ情報を使用して同じ結果が得られます。Third-party migration and ETL tools also use the catalog information to achieve the same result.

  • データの抽出Data extraction

    BTEQFASTEXPORT などの標準的な Teradata ユーティリティを使用して、既存の Teradata テーブルから生データを移行します。Migrate the raw data from existing Teradata tables by using standard Teradata utilities like BTEQ and FASTEXPORT. 移行の演習では、通常、可能な限り効率的にデータを抽出することが重要です。In a migration exercise, it's generally important to extract the data as efficiently as possible. Teradata の最近のバージョンで推奨される方法は、Teradata Parallel Transporter を使用することです。これは、複数の並列 FASTEXPORT ストリームを使用して最高のスループットを実現するユーティリティです。The approach we recommend for recent versions of Teradata is to use Teradata Parallel Transporter, a utility that uses multiple parallel FASTEXPORT streams to achieve the best throughput.

    Teradata Parallel Transporter は、Data Factory から直接呼び出すことができます。You can call Teradata Parallel Transporter directly from Data Factory. 前述のとおり、Teradata インスタンスがオンプレミスである場合でも、Azure 環境内の VM にコピーされる場合でも、データ移行プロセスを管理するための方法としてこれをお勧めしています。We recommend this approach for managing the data migration process, whether the Teradata instance is on-premises or copied to a VM in the Azure environment, as described earlier.

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

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

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

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

  • データ分散オプション: Azure では、個々のテーブルについて、データの分散方法を設定できます。Data distribution options: In Azure, you can set the data distribution methods for individual tables. この機能の目的は、クエリの実行時に、処理ノード間を移動するデータ量を削減することにあります。The purpose of the functionality is to reduce the amount of data that moves between processing nodes when a query is executed.

    大きなテーブル同士の結合の場合、一方または両方 (理想的には両方) のテーブルの結合列にハッシュを分散すると、結合するデータ行が同じ処理ノードに既に併置されているので、結合処理をローカルで確実に実行するのに役立ちます。For large table/large table joins, hash distributing in one or both (ideally, both) tables on the join columns helps ensure that join processing can be performed locally because the data rows to be joined are already colocated on the same processing node.

    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). 小さいディメンション テーブルがすべてのノードにレプリケートされると、大きいテーブルの結合キーのすべての値に対して、一致するディメンション行をローカル環境で確実に使用できるようになります。You replicate the smaller table across all nodes, thereby ensuring that any value of the join key for the larger table has a matching dimension row that's locally available. ディメンション テーブルが大きくない場合、テーブルをレプリケートする場合のオーバーヘッドは比較的低くなります。The overhead of replicating the dimension table is relatively low if the tables aren't large. この場合、前に説明したハッシュ分散アプローチを使用することが推奨されます。In this case, using the hash distribution approach described earlier is preferable.

  • データのインデックス作成: Azure Synapse により、さまざまなインデックス作成オプションが提供されますが、これらのオプションの動作と使用は Teradata のインデックス作成オプションとは異なります。Data indexing: Azure Synapse provides various indexing options, but the options are different in operation and usage from indexing options in Teradata. Azure Synapse でのインデックス作成オプションについては、Azure Synapse プールでのテーブルの設計に関するページを参照してください。To learn about the indexing options in Azure Synapse, see Design tables in an Azure Synapse pool.

    移行元の Teradata 環境内の既存のインデックスによって、データの使用方法をわかりやすく示すことができ、Azure Synapse 環境内でインデックスを作成するための候補列も示すことができます。Existing indexes in the source Teradata 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.

  • データ テーブルの統計: ETL/ELT ジョブに COLLECT STATISTICS ステップを追加するか、テーブルの自動統計収集を有効にすると、データ テーブルの統計が最新であることを保証できます。Data table statistics: You can ensure that statistics about data tables are up to date by adding a COLLECT STATISTICS step in ETL/ELT jobs or by enabling automatic statistics collection on the table.

  • データ読み込み用の 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

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