Teradata の移行の設計とパフォーマンス

  • [アーティクル]

この記事は、Teradata から Azure Synapse Analytics に移行する方法に関するガイダンスを提供する 7 つのパートから成るシリーズのパート 1 です。 この記事での焦点は、設計とパフォーマンスのベスト プラクティスです。

概要

Teradata データ ウェアハウス システムの多くの既存ユーザーは、最新のクラウド環境で提供されるイノベーションを活用しようとしています。 サービスとしてのインフラストラクチャ (IaaS) とサービスとしてのプラットフォーム (PaaS) クラウド環境を使用すると、インフラストラクチャのメンテナンスやプラットフォーム開発などのタスクをクラウド プロバイダーに委任できます。

ヒント

Azure 環境には、データベースだけでなく、包括的な一連の機能とツールが用意されています。

Teradata と Azure Synapse Analytics は両者とも非常に大規模なデータ量に対して高いクエリ パフォーマンスを実現するために、超並列処理 (MPP) 手法を使用する SQL データベースですが、アプローチには基本的な違いがいくつかあります。

  • 多くの場合、レガシ Teradata システムは、独自のハードウェアを使用してオンプレミスにインストールされます。一方、Azure Synapse は Azure Storage とコンピューティング リソースを使用したクラウドベースです。

  • ストレージとコンピューティング リソースは Azure 環境では分離されていて、エラスティック スケーリング機能があるため、これらのリソースは、独立してスケーリング (アップまたはダウン) できます。

  • 必要に応じて Azure Synapse を一時停止したりそのサイズを変更したりして、リソースの使用率とコストを削減できます。

  • Teradata の構成のアップグレードは、物理ハードウェアの追加や、長時間かかる可能性のあるデータベースの再構成やリロードを伴う大きなタスクです。

Microsoft Azure は、グローバルに使用できる、高度なセキュリティで保護されたスケーラブルなクラウド環境であり、Azure Synapse とサポート ツールおよび機能のエコシステムが組み込まれています。 次の図は、Azure Synapse エコシステムをまとめたものです。

Chart showing the Azure Synapse ecosystem of supporting tools and capabilities.

Azure Synapse では、MPP や頻繁に使用されるデータの複数のレベルの自動キャッシュなどの手法を使用して、最高のリレーショナル データベース パフォーマンスを実現しています。 これらの手法の結果は、独立したベンチマークで確認できます。たとえば、GigaOm によって最近実施されたものでは、Azure Synapse が他の一般的なクラウド データ ウェアハウス オファリングと比較されています。 Azure Synapse 環境に移行するお客様には、次のような多くの利点があります。

  • パフォーマンスと費用対効果の向上。

  • 機敏性の向上と価値実現までの時間の短縮。

  • より高速なサーバーのデプロイとアプリケーション開発。

  • 実際の使用量に対してのみ課金される柔軟なスケーラビリティ。

  • セキュリティ/コンプライアンスの向上。

  • ストレージとディザスター リカバリーのコスト削減。

  • 全体的な TCO の削減、コスト管理の向上、運用支出 (OPEX) の合理化。

このような利点を最大限に活用するには、新規または既存のデータとアプリケーションを Azure Synapse プラットフォームに移行します。 多くの組織で、移行には、Teradata などのレガシ オンプレミス プラットフォームから Azure Synapse への既存のデータ ウェアハウスの移動が含まれます。 おおまかに、移行プロセスには次の手順が含まれます。

    準備 🡆

  • スコープ (移行する対象) を定義する。

  • 移行のためのデータとプロセスのインベントリを作成する。

  • データ モデルの変更を定義する (ある場合)。

  • ソース データ抽出メカニズムを定義する。

  • 使用する適切な Azure およびサードパーティのツールと機能を特定する。

  • 新しいプラットフォームのスタッフ トレーニングを早期に実施する。

  • Azure のターゲット プラットフォームをセットアップする。

    移行 🡆

  • 小規模で簡単なものから始める。

  • 可能な限り、処理を自動化します。

  • Azure の組み込みツールと機能を活用して移行の労力を減らす。

  • テーブルとビューのメタデータを移行する。

  • 維持する履歴データを移行する。

  • ストアド プロシージャとビジネス プロセスを移行またはリファクタリングする。

  • ETL/ELT の段階的読み込みプロセスを移行またはリファクタリングする。

    移行後

  • プロセスのすべてのステージを監視してドキュメント化する。

  • 今後の移行のため、得られた経験を利用してテンプレートを作成する。

  • 必要な場合、(新しいプラットフォームのパフォーマンスとスケーラビリティを使用して) データ モデルを再エンジニアリングする。

  • アプリケーションとクエリ ツールをテストする。

  • クエリ パフォーマンスのベンチマークと最適化を行う。

この記事では、データ ウェアハウスを既存の Netezza 環境から Azure Synapse に移行するときのパフォーマンス最適化に関する一般的な情報とガイドラインを示します。 パフォーマンスの最適化の目的は、スキーマの移行後に Azure Synapse で同等以上のデータ ウェアハウスのパフォーマンスを実現することです。

設計上の考慮事項

移行のスコープ

Teradata 環境から移行する準備をしているときに、次の移行の選択肢を検討してください。

初期移行のワークロードを選択する

通常、レガシ Teradata 環境は、複数の主題領域と混合ワークロードを含むように、時間の経過と共に進化しています。 移行プロジェクトをどこから開始するのかを決定するときに、次の作業が可能になる領域を選択します。

  • 新しい環境の利点を迅速に提供することで、Azure Synapse への移行の実現可能性が証明される。

  • 社内の技術スタッフが、他の領域を移行するときに使用するプロセスとツールに関する経験を得ることができる。

  • 移行をさらに行うために、ソース Teradata 環境と既に配置済みの現在のツールおよびプロセスに固有のテンプレートを作成する。

Teradata 環境からの初期移行の適切な候補とは、上記の項目をサポートし、次を満たすものです。

  • オンライン トランザクション処理 (OLTP) ワークロードではなく、BI/Analytics ワークロードを実装する。

  • スターやスノーフレークのスキーマなどの、最小限の変更で移行できるデータ モデルが使用されている。

ヒント

移行する必要があるオブジェクトのインベントリを作成し、移行プロセスを文書化してください。

初期移行で移行されるデータの量は、Azure Synapse 環境の機能と利点を示すために十分な大きさに、ただし、価値をすばやく示すために大きすぎないようにする必要があります。 1 から 10 テラバイトの範囲のサイズが一般的です。

初期移行プロジェクトでは、リスク、労力、移行時間を最小限に抑えて Azure クラウド環境の利点をすばやく確認できるようにし、Teradata ウェアハウスの OLAP DB 部分などのデータ マートのみに移行の範囲を限定します。 リフトアンドシフトと段階的移行のどちらのアプローチでも、初期移行の範囲はデータ マートのみに制限され、ETL 移行や履歴データ移行などのより広範な移行の側面には対応しません。 ただし、移行されたデータ マート レイヤーにデータと必要なビルド プロセスがバックフィルされたら、プロジェクトの後のフェーズでこれらの側面に対処できます。

リフト アンド シフト移行と段階的アプローチ

一般に、計画された移行の目的と範囲に関係なく、2 種類の移行があります。リフト アンド シフトそのままと、変更を組み込む段階的なアプローチです。

リフト アンド シフト

リフト アンド シフト移行では、既存のデータ モデル (スター スキーマなど) は、そのまま新しい Azure Synapse プラットフォームに移行されます。 このアプローチでは、Azure クラウド環境への移動の利点を実現するために必要な作業を減らして、リスクと移行時間を最小限に抑えます。 リフト アンド シフト移行は、次のシナリオに適しています。

  • 移行する単一のデータ マートを持つ既存の Teradata 環境がある場合、または
  • 適切に設計されたスターまたはスノーフレークのスキーマに既に含まれているデータを含む既存の Teradata 環境がある場合、または
  • 最新のクラウド環境に移動するための時間とコストが切迫している場合。

ヒント

リフト アンド シフトは、後続のフェーズでデータ モデルへの変更が実装される場合でも、適切な開始点です。

変更を組み込む段階的なアプローチ

レガシ データ ウェアハウスが長期間にわたって進化している場合、必要なパフォーマンス レベルを維持するために再エンジニアリングが必要なことがあります。 モノのインターネット (IoT) ストリームなどの新しいデータをサポートするために、再エンジニアリングが必要になる場合もあります。 再エンジニアリング プロセスの一環として、スケーラブルなクラウド環境のメリットを利用するために、Azure Synapse に移行します。 移行には、基になるデータ モデルの変更 (Inmon モデルからデータ コンテナーへの移動など) が含まれることもあります。

Microsoft は、(必要に応じて、Azure で VM Teradata インスタンスを使用して) 既存のデータ モデルをそのまま Azure に移動してから、Azure 環境のパフォーマンスと柔軟性を生かして、再エンジニアリングの変更を適用することをお勧めします。 そうすることで、既存のソース システムに影響を与えることなく、Azure の機能を使用して変更を加えることができます。

移行の一環としての VM Teradata インスタンスの使用

オンプレミスの Teradata 環境から移行する場合は、Azure のクラウド ストレージと柔軟なスケーラビリティを活用して、VM 内に Teradata インスタンスを作成できます。 この方法では、Teradata インスタンスをターゲット Azure Synapse 環境と併置します。 Teradata Parallel Data Transporter などの標準 Teradata ユーティリティを使用して、VM インスタンスに移行される必要がある Teradata テーブルのサブセットを効率的に移動できます。 その後、Azure 環境内で以降のすべての移行タスクを実行できます。 この方法には、いくつかの利点があります。

  • データの初期レプリケーションの後、ソース システムは移行タスクの影響を受けません。

  • 使い慣れた Teradata のインターフェイス、ツール、ユーティリティを、Azure 環境内で利用できます。

  • Azure 環境では、オンプレミスのソース システムとクラウド ターゲット システムの間で利用可能なネットワーク帯域幅に関する問題が発生する可能性はありません。

  • Azure Data Factory などのツールを使用すると、Teradata Parallel Transporter などのユーティリティを呼び出して、データを効率的かつ迅速に移行できます。

  • 移行プロセスは、Azure 環境内で完全に調整および制御できます。

ヒント

Azure VM を使用して一時的な Teradata インスタンスを作成し、移行を高速化し、ソース システムへの影響を最小限に抑えます。

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 機能を使用した移行プロセスの管理を計画するときは、移行するすべてのデータ テーブルとその場所を一覧表示するメタデータを作成します。

Teradata と Azure Synapse の設計の違い

前述のように、Teradata と Azure Synapse Analytics のデータベースのアプローチにはいくつかの基本的な違いがあり、これらの違いについては次に説明します。

複数のデータベースに対して、1 つのデータベースとスキーマ

Teradata 環境には、多くの場合、複数の個別のデータベースが含まれています。 たとえば、データ インジェストとステージングのテーブル、コア ウェアハウス テーブル、データ マート (セマンティック レイヤーとも呼ばれることもあります) に対して個別のデータベースが存在する可能性があります。 ETL または ELT パイプライン プロセスにより、データベースをまたがる結合が実装され、個別のデータベース間でデータが移動されます。

一方、Azure Synapse 環境には 1 つのデータベースがあり、スキーマを使用して、論理的に分離されたグループにテーブルが分割されます。 Teradata 環境から移行される個別のデータベースを模倣するために、ターゲットの Azure Synapse データベース内で一連のスキーマを使用することをお勧めします。 Teradata 環境で既にスキーマが使用されている場合は、Teradata の既存のテーブルとビューを新しい環境に移動するときに、新しい名前付け規則を使用することが必要な場合があります。 たとえば、元の個別のデータベース名を維持するために、Teradata の既存のスキーマとテーブルの名前を連結して Azure Synapse の新しいテーブル名にしてから、新しい環境でスキーマ名を使用することが考えられます。 スキーマ統合の名前にドットがある場合は、Spark Azure Synapse で問題が発生する可能性があります。 基になるテーブルに SQL ビューを使用して論理構造を維持することもできますが、このアプローチには潜在的な欠点がいくつかあります。

  • Azure Synapse のビューは読み取り専用であるため、データの更新は、基になるベース テーブルで行われる必要があります。

  • 1 つ以上のビューのレイヤーが既に存在していて、さらにビューのレイヤーを追加すると、入れ子になったビューのトラブルシューティングが困難なため、パフォーマンスとサポート可能性に影響を与える可能性があります。

ヒント

Azure Synapse 内で複数のデータベースを 1 つのデータベースに統合し、スキーマ名を使用して、テーブルを論理的に分離します。

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

異なる環境間でテーブルを移行するとき、通常は生データと、それを記述するメタデータのみが物理的に移行されます。 インデックスなどの、ソース システムの他のデータベース要素は、通常は移行されません。新しい環境ではこれらが不要であるか、実装方法が異なる可能性があるためです。 インデックスなどの、ソース環境でのパフォーマンスの最適化は、新しい環境でパフォーマンスの最適化を追加することが検討される箇所を示します。 たとえば、ソース Teradata 環境内のテーブルに一意でないセカンダリ インデックス (NUSI) がある場合、クラスター化されていないインデックスを Azure Synapse 内に作成する必要があることが示唆されています。 テーブル レプリケーションなどの、他のネイティブ パフォーマンスの最適化手法が、同一条件でインデックスをそのまま作成するよりも適している場合があります。

ヒント

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

データベースの高可用性

Teradata では、FALLBACK オプションによりノード間でのデータ レプリケーションがサポートされており、特定のノードに物理的に存在するテーブル行が、システム内の別のノードにレプリケートされます。 この方法では、ノード障害が発生した場合にデータが失われないことが保証され、フェールオーバー シナリオの基礎が提供されます。

Azure Synapse Analytics での高可用性アーキテクチャの目的は、メンテナンス操作や障害の影響を心配せずに、データベースの稼働および実行の時間が 99.9% 以上になるように保証することです。 SLA の詳細については、「Azure Synapse Analytics の SLA」を参照してください。 Azure では、パッチ適用、バックアップ、Windows および SQL のアップグレードなどの重要なサービス タスクが自動的に処理されます。 また、基本となるハードウェア、ソフトウェア、またはネットワークの障害などの計画外のイベントも自動的に処理されます。

Azure Synapse のデータ ストレージは、スナップショットを使用して自動的にバックアップされます。 これらのスナップショットは、復元ポイントを作成するサービスの組み込み機能です。 この機能を有効にする必要はありません。 現時点では、回復のサービス レベル アグリーメント (SLA) を維持するためにサービスで使用される自動復元ポイントをユーザーが削除することはできません。

Azure Synapse Dedicated SQL プールでは、1 日を通してデータ ウェアハウスのスナップショットが取得され、7 日間利用できる復元ポイントが作成されます。 この保持期間は変更できません。 Azure Synapse では、8 時間の回復ポイントの目標 (RPO) がサポートされています。 プライマリ リージョンのデータ ウェアハウスを、過去 7 日間に作成されたいずれかのスナップショットから復元することができます。 より小さい単位でのバックアップが必要な場合は、他のユーザー定義オプションを使用できます。

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

Teradata では、時系列とテンポラル データに対する特殊なテーブル型をサポートします。 これらのテーブル型の構文および一部の関数は、Azure Synapse で直接サポートされていません。 ただし、適切なデータ型にマップし、日付/時刻列についてインデックス作成またはパーティション分割することで、Azure Synapse の標準テーブルにデータを移行できます。

ヒント

Azure Synapse 内の Standard テーブルでは、移行された Teradata 時系列テーブルとテンポラル データをサポートできます。

Teradata では、クエリの書き換えを使用してテンポラル クエリ内にフィルターを追加し、該当する日付範囲を制限することにより、テンポラル クエリ機能が実装されます。 ソース Teradata 環境からこの機能を移行する予定の場合は、関連するテンポラル クエリにさらにフィルター処理を追加します。

Azure 環境では、大規模な時系列データに対する複雑な分析のための Time Series Insights がサポートされています。 この機能は、IoT データ分析アプリケーションを対象としています。

SQL DML 構文の相違点

Teradata SQL と Azure Synapse T-SQL では、SQL データ操作言語 (DML) の構文の違いがあります。

  • QUALIFY:Teradata では、QUALIFY 演算子がサポートされています。 次に例を示します。

    SELECT col1
FROM tab1
WHERE col1='XYZ'
QUALIFY ROW_NUMBER () OVER (PARTITION by
col1 ORDER BY col1) = 1;

    同等の Azure Synapse の構文は次のとおりです。

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

  • 日付の算術演算子。Azure Synapse には、DATEADD や DATEDIFF などの演算子があり、DATE や DATETIME のフィールドで使用できます。 Teradata では、SELECT DATE1 - DATE2 FROM... のような日付の直接減算がサポートされています

  • GROUP BY: GROUP BY 序数で、T-SQL 列名を明示的に指定します。

  • LIKE ANY: Teradata では、次のような LIKE ANY 構文をサポートしています。

    SELECT * FROM CUSTOMER
WHERE POSTCODE LIKE ANY
('CV1%', 'CV2%', 'CV3%');

    Azure Synapse の構文で相当するものは次のとおりです。

    SELECT * FROM CUSTOMER
WHERE
(POSTCODE LIKE 'CV1%') OR (POSTCODE LIKE 'CV2%') OR (POSTCODE LIKE 'CV3%');

  • システム設定によっては、Teradata の文字比較で、既定では大文字と小文字は区別されない場合があります。 Azure Synapse では、文字比較では常に大文字と小文字は区別されます。

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

Teradata のような成熟した環境からデータ ウェアハウスを移行するときは、単純なテーブルやビュー以外の要素を移行することがおそらく必要になります。 このようなものの例としては、関数、ストアド プロシージャ、トリガー、シーケンスがあります。 Azure 環境内のツールが関数、ストアド プロシージャ、シーケンスの機能を置き換えることができるかどうかを確認します。これは、通常、組み込みの Azure ツールを使用する方が、それらの要素を Azure Synapse 用に再コーディングするよりも効率的であるためです。

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

データ統合パートナーから、関数、ストアド プロシージャ、シーケンスの移行を自動化できるツールとサービスが提供されています。

以降のセクションでは、関数、ストアド プロシージャ、シーケンスの移行についてさらに説明します。

関数

ほとんどのデータベース製品と同様に、Teradata では SQL 実装内で、システムとユーザー定義の関数がサポートされています。 レガシ データベース プラットフォームを Azure Synapse に移行するときに、一般的なシステム機能は通常変更なしで移行できます。 一部のシステム関数では、構文が若干異なることがありますが、必要な変更は自動化できます。

Azure Synapse に同等のものがない Teradata システム関数または任意のユーザー定義関数については、ターゲット環境言語を使用してそれらの関数を再コーディングします。 Azure Synapse では、Transact-SQL 言語を使用して、ユーザー定義関数を実装します。

ストアド プロシージャ

ほとんどの最新のデータベース製品では、データベース内にプロシージャを格納できます。 Teradata では、この目的に SPL 言語が提供されています。 ストアド プロシージャには通常、SQL ステートメントと手続き型のロジックの両方が含まれていて、データまたは状態が返されます。

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

トリガー

Azure Synapse ではトリガーの作成はサポートされていませんが、トリガーの作成は Azure Data Factory を使用して実装できます。

シーケンス

Azure Synapse は Teradata と同様の方法でシーケンスを処理します。ユーザーは、IDENTITY 列または系列内の次のシーケンス番号を生成する SQL コードを使用してシーケンスを実装できます。 シーケンスは、主キーの代理キー値として使用できる一意の数値を提供します。

Teradata 環境からのメタデータとデータの抽出

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

ANSI SQL 標準では、データ定義言語 (DDL) コマンドの基本的な構文を定義しています。 DDL コマンドの中には、CREATE TABLE や CREATE VIEW など、Teradata と Azure Synapse の両方に共通するものがありますが、インデックス作成、テーブルの分散、パーティション分割オプションなどの実装固有の機能も用意されています。

既存の Teradata の CREATE TABLE と CREATE VIEW スクリプトを編集して、Azure Synapse の同等の定義を実現できます。 これを行うには、変更されたデータ型を使用し、Teradata 固有の句 (FALLBACK など) を削除または変更することが必要になる場合があります。

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

Teradata 環境内では、システム カタログ テーブルが現在のテーブルとビューの定義を指定します。 ユーザーが保守するドキュメントとは異なり、システム カタログ情報は常に完全であり、現在のテーブル定義と同期されます。 DBC.ColumnsV などのカタログのビューを使用すると、システム カタログ情報にアクセスして、Azure Synapse で同等のテーブルを作成する CREATE TABLE DDL ステートメントを生成できます。

ヒント

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

同様の結果を得るために、システム カタログ情報を処理するサードパーティの移行および ETL のツールを使用することもできます。

Teradata からのデータの抽出

Basic Teradata Query (BTEQ)、Teradata FastExport、Teradata Parallel Transporter (TPT) などの標準 Teradata ユーティリティを使用して、Teradata テーブルから生のテーブル データをフラット区切りファイル (CSV ファイルなど) に抽出できます。 TPT を使用して、テーブル データを可能な限り効率的に抽出します。 TPT は、複数の並列 FastExport ストリームを使用して最適なスループットを実現します。

ヒント

最も効率的なデータ抽出には Teradata Parallel Transporter を使用します。

Azure Data Factory から TPT を直接呼び出します。 これは、Teradata オンプレミス インスタンスと、Azure 環境内の VM 内で実行される Teradata インスタンスのデータ移行に推奨される方法です。

抽出されたデータ ファイルには、CSV、Optimized Row Columnar (ORC)、または Parquet 形式の区切りテキストが含まれている必要があります。

Teradata 環境からのデータと ETL の移行の詳細については、「Teradata 移行のためのデータ移行、ETL、読み込み」を参照してください。

Teradata の移行に関するパフォーマンスの推奨事項

パフォーマンスの最適化の目標は、Azure Synapse への移行後のデータ ウェアハウスのパフォーマンスを同等以上にすることです。

ヒント

移行の開始時に、Azure Synapse のチューニング オプションの学習を優先してください。

パフォーマンス チューニング アプローチの相違点

このセクションでは、Teradata と Azure Synapse のパフォーマンス チューニングの詳細な実装の違いについて説明します。

データ分散オプション

パフォーマンスのために、Azure Synapse はマルチノード アーキテクチャを使用して設計されていて、並列処理を使用します。 Azure Synapse で個別のテーブルのパフォーマンスを最適化するために、DISTRIBUTION ステートメントを使用して、CREATE TABLE ステートメントでデータ分散オプションを定義できます。 たとえば、ハッシュ分散テーブルを指定できます。これは、決定論的なハッシュ関数を使用してコンピューティング ノード間でテーブル行を分散します。 その目的は、クエリの実行時に、処理ノード間で移動されるデータの量を減らすことです。

大きなテーブル同士の結合では、一方または両方 (理想的には両方) のテーブルの結合列にハッシュを分散します。これは、均等な分散を確保するのに役立つ幅広い値を持ちます。 結合されるデータ行が同じ処理ノードに併置されているので、結合処理をローカルに実行します。

Azure Synapse では、小さなテーブルのレプリケーションを使用して、小さなテーブルと大きなテーブルの間のローカル結合もサポートされます。 たとえば、スター スキーマ モデル内の小さなディメンション テーブルと大きなファクト テーブルを考えてみましょう。 Azure Synapse では、小さなディメンション テーブルをすべてのノードにレプリケートして、大きなテーブルの結合キーの値に一致するローカルで使用可能なディメンション行を確保できます。 ディメンション テーブルのレプリケーションのオーバーヘッドは、小さなディメンション テーブルでは比較的低くなります。 大きなディメンション テーブルの場合は、ハッシュ分散アプローチの方が適しています。 データ分散オプションの詳細については、レプリケート テーブルを使用するための設計ガイダンスと分散テーブルを設計するためのガイダンスを参照してください。

データのインデックス作成

Azure Synapse では、ユーザーが定義可能な複数のインデックス作成オプションがサポートされていますが、これらは Teradata で実装されているインデックス作成オプションとは異なります。 Azure Synapse の異なるインデックス作成オプションの詳細については、専用 SQL プール テーブルのインデックス作成に関するページを参照してください。

ソース Teradata 環境内の既存のインデックスは、データの使用方法と、Azure Synapse 環境内でインデックスを作成するための候補列を実用的に示します。

データのパーティション分割

エンタープライズ データ ウェアハウスには、ファクト テーブルに数十億行が含まれる場合があります。 パーティション分割でこれらのテーブルを別々の部分に分割し、処理されるデータ量を減らすと、これらの保守とクエリのパフォーマンスが最適化されます。 Azure Synapse では、CREATE TABLE ステートメントは、テーブルのパーティション分割指定を定義します。 非常に大きなテーブルのみをパーティション分割し、各パーティションに少なくとも 6,000 万行が含まれるようにします。

パーティション分割に使用できるフィールドは、テーブルごとに 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 クエリを使用してワークロードを監視し、該当するリソースが効率的に利用されるようにします。

次の手順

Teradata 移行の ETL と読み込みについては、このシリーズの次の記事「Teradata 移行のためのデータ移行、ETL、読み込み」を参照してください。