Teradata 移行時の SQL の問題を最小化します

この記事は、Teradata から Azure Synapse Analytics に移行する方法についてガイダンスを提供する 7 つのパートから成るシリーズの第 5 部です。 この記事では、SQL の問題を最小限に抑えるためのベスト プラクティスに焦点を合わせています。

概要

Teradata 環境の特性

1984 年、Teradata は最初にデータベース製品をリリースしました。 大規模な並列処理 (MPP) 手法を導入し、その時点で利用できる既存のメインフレーム技術よりも大規模なデータ処理を効率的に実現しました。 それ以降、製品は進化し、大手金融機関、通信会社、小売企業の間で多くのインストールの実績があります。 当初の実装では、独自のハードウェアを使用し、メインフレーム (通常は IBM または IBM 互換プロセッサ) にチャネルが接続済みでした。

最近の発表では、ネットワーク接続やクラウド (Azure を含む) での Teradata テクノロジ スタックの利用が可能になりましたが、既存のインストールのほとんどはオンプレミスであるため、多くのユーザはTeradata データの一部またはすべてを Azure Synapse Analytics に移行して、最新のクラウド環境への移行によるメリットを得ようと検討しています。

Teradata のテクノロジをデータ ウェアハウスの実装によく使用し、SQL を使用して大きなデータに対する複雑な分析クエリをサポートします。 ディメンション データ モデル (星スキーマまたはスノーフレーク スキーマ) は、各部門のデータ マートの実装と同様、一般的なものです。

この SQL データ モデルとディメンション データ モデルの組み合わせにより、基本的な概念と SQL スキルを移行できるため、Azure Synapse への移行が簡単になります。 推奨されるアプローチは、既存のデータ モデルをそのまま移行して、リスクと所要時間を削減することです。 最終的にデータ モデルを変更する (たとえば、データ ボルト モデルに移行する) 場合は、最初にそのまま移行し、その後 Azure クラウド環境内で変更し、パフォーマンス、弾性スケーラビリティ、コスト面での利点を活用します。

SQL 言語は標準化されていますが、場合によっては、各ベンダが独自に拡張機能をを実装しています。 このドキュメントでは、従来の Teradata 環境からの移行中に発生する可能性のあるSQLの違いを明らかにし、回避策を示します。

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

オンプレミスの Teradata 環境からの移行を実行するときに、Azure 環境を活用します。 Azure は、手頃な価格のクラウド ストレージと弾性スケーラビリティを示し、Azure の VM 内に Teradata インスタンスを作成して、ターゲットのAzure Synapse 環境と併置することができます。

このアプローチでは、Teradata Parallel Data Transporter などの標準 Teradata ユーティリティ (または、Attunity Replicate などのサードパーティ製データ レプリケーション ツール) を使用して、VM インスタンスに移行される Teradata テーブルのサブセットを効率的に移動した後、Azure 環境内ですべての移行タスクを実行することができます。 この方法には、いくつかの利点があります。

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

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

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

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

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

Azure Data Factory を使用してメタデータに基づく移行を実装する

Azure 環境の機能を使用して移行プロセスの自動化と調整をすることは理にかなっています。 このアプローチにより、既存の Teradata 環境への影響も最小限に抑えられます (既に全容量に近い状態で実行されている可能性があります)。

Azure Data Factory は、データドリブン型のワークフローをクラウドに作成することでデータの移動と変換を制御し、自動化することができるクラウドベースのデータ統合サービスです。 Azure Data Factory を使えば、さまざまなデータ ストアのデータを取り込むことができるデータ主導型のワークフロー (パイプライン) を作成し、スケジューリングします。 Azure HDInsight Hadoop、Spark、 Azure Data Lake Analytics、Azure Machine Learning などのコンピューティング サービスを使用してデータ を処理し、変換できます。

移行するデータ テーブルとその場所をリストするメタデータを作成することで、Azure Data Factory の機能を使用して移行プロセスの一部を管理し、自動化します。 Azure Synapse Pipelines使用することもできます。

Teradata と Azure Synapse の SQL DDL の違い

SQL データ定義言語 (DDL)

ANSI SQL 標準では、 CREATE TABLE と CREATE VIEWなどの DDL コマンドの基本的な構文を定義します。 これらのコマンドは、Teradata と Azure Synapse の両方で使用しますが、インデックス作成、テーブルの分散、パーティション分割オプションなどの実装固有が持つ特徴の定義を可能にするよう拡張しています。

次のセクションでは、Azure Synapse への移行時に考慮する Teradata 固有のオプションについて説明します。

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

異なるテクノロジ間でテーブルを移行する場合、通常、生データとその記述メタデータのみが 2 つの環境間で物理的に移動されます。 インデックスやログ ファイルなど、ソース システムからその他のデータベース要素を直接移行することはありません。これは、これらの要素が必要ないか、新しいターゲット環境内で異なる方法で実装される可能性があるためです。 たとえば、Teradata のCREATE TABLE構文内にはMULTISETオプションに相当するものがありません。

ソース環境でパフォーマンスの最適化 (インデックスなど) を使用した場所を理解することが重要です。 これは、新しいターゲット環境でパフォーマンス最適化が追加可能な場所を示します。 たとえば、ソース Teradata 環境で一意でないセカンダリ インデックス (NUSI) が作成される場合、移行された Azure Synapse データベースで非クラスター化インデックスを作成する必要があることを示している可能性があります。 テーブル レプリケーションなど、他のネイティブ パフォーマンの最適化手法は、"同一条件で" インデックスを直接作成するよりも適している場合があります。

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

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

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

また、Azure 環境には、 時系列分析情報と呼ばれる大規模な時系列データに対する複雑な分析のための特定の特徴も含まれています。これは IoT データ分析アプリケーションを対象としており、このユース ケースに適している場合があります。

サポートされていない Teradata データ型

ほとんどの Teradata データ型には、Azure Synapse に直接対応するものがあります。 次の表に、Azure Synapse でサポートされていない Teradata データ型と、推奨されるマッピングを示します。 表で、Teradata の列の型はシステム カタログ内 (例: DBC.ColumnsV) に保存される型です。

Teradata カタログ テーブルのメタデータを使用して、これらのデータ型のいずれかを移行する必要があるかどうかを判断し、移行プランでそれに対処できるようにします。 たとえば、次のような SQL クエリを使用して、サポートされていないデータ型の出現を見つけ、注意を払う必要があります。

SELECT
ColumnType, CASE
WHEN ColumnType = '++' THEN 'TD_ANYTYPE' 
WHEN ColumnType = 'A1' THEN 'ARRAY' WHEN 
ColumnType = 'AN' THEN 'ARRAY' WHEN 
ColumnType = 'BO' THEN 'BLOB'
WHEN ColumnType = 'CO' THEN 'CLOB'
WHEN ColumnType = 'DH' THEN 'INTERVAL DAY TO HOUR' WHEN 
ColumnType = 'DM' THEN 'INTERVAL DAY TO MINUTE' WHEN 
ColumnType = 'DS' THEN 'INTERVAL DAY TO SECOND' WHEN
ColumnType = 'DT' THEN 'DATASET'
WHEN ColumnType = 'DY' THEN 'INTERVAL DAY'
WHEN ColumnType = 'HM' THEN 'INTERVAL HOUR TO MINUTE' WHEN
ColumnType = 'HR' THEN 'INTERVAL HOUR'
WHEN ColumnType = 'HS' THEN 'INTERVAL HOUR TO SECOND' WHEN
ColumnType = 'JN' THEN 'JSON'
WHEN ColumnType = 'MI' THEN 'INTERVAL MINUTE' WHEN 
ColumnType = 'MO' THEN 'INTERVAL MONTH'
WHEN ColumnType = 'MS' THEN 'INTERVAL MINUTE TO SECOND' WHEN
ColumnType = 'PD' THEN 'PERIOD(DATE)'
WHEN ColumnType = 'PM' THEN 'PERIOD (TIMESTAMP WITH TIME ZONE)'
WHEN ColumnType = 'PS' THEN 'PERIOD(TIMESTAMP)' WHEN 
ColumnType = 'PT' THEN 'PERIOD(TIME)'
WHEN ColumnType = 'PZ' THEN 'PERIOD (TIME WITH TIME ZONE)' WHEN
ColumnType = 'SC' THEN 'INTERVAL SECOND'
WHEN ColumnType = 'SZ' THEN 'TIMESTAMP WITH TIME ZONE' WHEN
ColumnType = 'XM' THEN 'XML'
WHEN ColumnType = 'YM' THEN 'INTERVAL YEAR TO MONTH' WHEN
ColumnType = 'YR' THEN 'INTERVAL YEAR'
END AS Data_Type,
COUNT (*) AS Data_Type_Count FROM
DBC.ColumnsV
WHERE DatabaseName IN ('UserDB1', 'UserDB2', 'UserDB3') -- select databases to be migrated
GROUP BY 1,2
ORDER BY 1;

前述のように、データ型のマッピングなど、移行を自動化するツールとサービスをオファーするサードパーティー ベンダが存在します。 Informatica や Talend などのサードパーティ製 ETL ツールが Teradata 環境で既に使用されている場合、これらのツールで必要なデータ変換を実装できます。

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

既存のTeradata CREATE TABLE および CREATE VIEW スクリプトを編集し、必要に応じて前述のようにデータ型を変更した同等の定義を作成します。 通常、これにはFALLBACKやMULTISETなどの Teradata 固有の不要な句の削除が含まれます。

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

この情報には DBC.ColumnsV などのカタログに対するビューからアクセスでき、Azure Synapse の同等のテーブルに対する同等の CREATE TABLE DDL ステートメントを生成します。

データ型のマッピングなど、移行を自動化するためのツールやサービスをオファーするMicrosoft パートナーがあります。 また、Informatica や Talend などのサードパーティー製 ETL ツールが Teradata 環境ですでに使用されている場合、そのツールで必要なデータ変換も実装できます。

Teradata と Azure Synapse の SQL DML の違い

SQL データ操作言語 (DML)

ANSI SQL 標準は、SELECT、INSERT、UPDATE、DELETEなどのDML コマンドの基本構文を定義します。 Teradata と Azure Synapse の両方でこれらのコマンドが使用されますが、場合によっては実装の違いがあります。

次のセクションでは、Azure Synapse への移行時に考慮する必要がある Teradata 固有の DML コマンドについて説明します。

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 序数で、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 では、文字比較では常に大文字と小文字は区別されます。

EXPLAIN を使用してレガシ SQL を検証

Azure Synapse との互換性のためにレガシ Teradata SQL をテストする方法の 1 つは、レガシ システム クエリ ログからいくつかの代表的な SQL ステートメントをキャプチャし、それらのクエリの前に EXPLAIN を付け、(同じテーブルと列名で Azure Synapse に移行された"いいね!" を付けるデータ モデルと仮定して) これらのEXPLAINステートメントを Azure Synapse に実行することです。 互換性なしの SQL はエラーを THROW します。この情報を使用して、再コード化タスクのスケールを決定します。 このアプローチでは、データを Azure 環境に読み込む必要はありません。これは、関連するテーブルとビューが作成された場合のみです。

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

Teradata などの成熟したレガシ データ ウェアハウス環境から移行するときは、単純なテーブルとビュー以外の要素を、新しいターゲット環境に移行することが必要になる場合がよくあります。 このようなものの例としては、関数、ストアド プロシージャ、トリガー、シーケンスがあります。

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

Teradata 環境で関数またはストアド プロシージャとして実装されている機能の代わりになるサービスが、Azure 環境に存在する場合があります。 この場合、通常は、Teradata の関数を再コード化するより、Azure の組み込み設備を使用する方が効率的です。

Microsoft パートナーは、移行を自動化できるツールとサービスをオファーします。

これらの各要素の詳細については、次のセクションを参照してください。

機能

ほとんどのデータベース製品と同様に、Teradata ではシステム関数と SQL 実装内のユーザー定義関数もサポートされています。 Azure Synapse などの別のデータベース プラットフォームに移行する場合、通常は共通のシステム関数を使用でき、変更なしに移行することができます。 システム関数によって、構文が若干異なることがありますが、この場合は必要な変更を自動化できます。 任意のユーザー定義関数など、同等のものが存在しないシステム関数は、ターゲット環境で使用可能な言語を用いて再コード化する必要がある場合があります。 Azure Synapse でユーザー定義関数を実装するには、一般的な Transact-SQL 言語が使用されます。

ストアド プロシージャ

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

Azure Synapse Analytics の専用 SQL プールでは、T-SQL を使用したストアド プロシージャもサポートされているため、ストアド プロシージャを移行する必要がある場合は、それに応じて再コード化します。

トリガー

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

シーケンス

Azure Synapse シーケンスは Teradata と同様の方法で処理され、ID を使用して代理キーにまたはマネージド ID を作成します。

Teradata から T-SQL へのマッピング

次の表は、Teradata から T-SQL へのAzure Synapse SQL データ型のマッピングに準拠しています。

まとめ

既存のレガシの Teradata の一般的なインストールは、Azure Synapse への移行を容易にする方法で実装されています。 これらは、大きなデータ ボリュームに対する分析クエリに SQL を使用し、何らかの形式のディメンション データ モデルです。 これらの要因により、Azure Synapse への移行に適した候補になります。

実際の SQL コードを移行するタスクを最小化するには、次の推奨事項をフォローします。

• 最終的な最終環境にデータ ヴォルトなどの異なるデータ モデルが組み込まれる場合でも、データ ウェアハウスの初期移行は、リスクと time を最小化するためにそのまま移行する必要があります。

• Consider using a Teradata instance in an Azure VM as a stepping stone as part of the migration process.移行プロセスの一環として、Azure VM 内の Teradata インスタンスを使用することを検討してください。

• Teradata SQL の実装と Azure Synapse の相違点を理解します

• 既存の Teradata 実装のメタデータとクエリ ログを使用して、相違点の影響を評価し、軽減するためのアプローチを計画します。

• 可能な限りプロセスを自動化して、移行のエラー、リスク、および time を最小化します。

• スペシャリストである Microsoft パートナー とサービスを使用して移行を合理化することを検討してください。

次のステップ

Microsoft とサード パーティのツールの詳細については、このシリーズの次の記事、「 Teradata データ ウェア ハウスを Azure Synapse Analytics に 移行するためのツール」を参照してください。