Teradata から BigQuery への移行: 概要
このドキュメントでは、Teradata から BigQuery に移行する理由、Teradata と BigQuery の機能の比較、BigQuery への移行を開始する手順の概要について説明します。
Teradata から BigQuery に移行する理由
Teradata は、大量のデータの管理と分析における初期のイノベーターでした。ただし、クラウド コンピューティングのニーズが進化するにつれて、データ分析に最新のソリューションが必要になる場合があります。
以前に Teradata を使用したことがある場合は、次の理由から BigQuery への移行を検討してください。
- レガシー プラットフォームの制約を克服する
- Teradata の従来のアーキテクチャでは、最新の分析のニーズ、特に無制限の同時実行と多様なワークロードに対する一貫して高いパフォーマンス要件を満たすことが難しいことがよくあります。BigQuery のサーバーレス アーキテクチャは、最小限の労力でこれらの要求を処理するように設計されています。
- クラウドネイティブ戦略を採用する
- 多くの組織が、オンプレミス インフラストラクチャからクラウドへの戦略的な移行を進めています。この変化により、運用上のオーバーヘッドを削減するために、Teradata などの従来のハードウェア バウンド ソリューションから、フルマネージドでスケーラブルなオンデマンド サービス（BigQuery など）への移行が必要になります。
- 最新のデータソースと分析を統合する
- 重要な企業データがクラウドベースのソースに依存する度合いが高まっています。BigQuery は Google Cloud エコシステムとネイティブに統合されており、これらのソースにシームレスにアクセスできます。また、Teradata のインフラストラクチャの制限を受けることなく、高度な分析、ML、リアルタイム データ処理を実現できます。
- 費用とスケーラビリティを最適化する
- Teradata には、複雑で費用のかかるスケーリング プロセスが伴うことがよくあります。BigQuery では、ストレージとコンピューティングの両方を個別に透過的かつ自動的にスケーリングできるため、手動での再構成が不要です。また、総所有費用の予測可能性が高まり、多くの場合、総所有費用が削減されます。
機能の比較
次の表に、Teradata の機能とコンセプトと、BigQuery の同等の機能を比較します。
| Teradata のコンセプト | 対応する BigQuery のツール | 説明 |
|---|---|---|
| Teradata（オンプレミス、クラウド、ハイブリッド） | BigQuery（統合 AI データ プラットフォーム）。BigQuery は、従来のデータ ウェアハウスと比較して、多くの追加機能を提供します。 | BigQuery は、 Google Cloud上のフルマネージドのクラウドネイティブ データ ウェアハウスです。Teradata は、オンプレミス、クラウド、ハイブリッドのオプションを提供しています。BigQuery はサーバーレスで、すべてのクラウドで BQ Omni として利用できます。 |
| Teradata ツール（Teradata Studio、BTEQ） | Google Cloud コンソール、BigQuery Studio、bq コマンドライン ツール | どちらも、データ ウェアハウスの管理と操作を行うためのインターフェースを提供します。BigQuery Studio はウェブベースで Google Cloud と統合されており、SQL、Python、Apache Spark を使用できます。 |
| データベース / スキーマ | データセット | Teradata では、BigQuery データセットと同様に、データベースとスキーマを使用してテーブルとビューを整理します。ただし、管理方法や使用方法は異なる場合があります。 |
| テーブル | テーブル | どちらのプラットフォームも、テーブルを使用してデータを行と列に格納します。 |
| ビュー | ビュー | ビューは両方のプラットフォームで同様に機能し、クエリに基づいて仮想テーブルを作成する方法を提供します。 |
| 主キー | 主キー（GoogleSQL では非適用） | BigQuery は、GoogleSQL で適用されていない主キーをサポートしています。これらは主にクエリの最適化に役立ちます。 |
| 外部キー | 外部キー（GoogleSQL では非適用） | BigQuery は、GoogleSQL で適用されていない外部キーをサポートしています。これらは主にクエリの最適化に役立ちます。 |
| インデックス | クラスタリング、検索インデックス、ベクトル インデックス（自動またはマネージド） | Teradata では、明示的なインデックス作成が可能です。 BigQuery でのクラスタリングをおすすめします。クラスタリングはデータベース インデックスと同等ではありませんが、ディスクに順序付けられたデータを保存する際に役立ちます。また、クラスタ化された列を述語として使用することでデータ取得を最適化できます。 BigQuery は、検索インデックスとベクトル インデックスをサポートしています。 |
| パーティショニング | パーティショニング | どちらのプラットフォームも、大規模なテーブルに対するクエリのパフォーマンスを向上させるため、テーブル パーティショニングをサポートしています。 BigQuery は、日付と整数によるパーティショニングのみをサポートしています。文字列の場合は、代わりにクラスタリングを使用します。 |
| リソース割り当て（ハードウェアとライセンスに基づく） | 予約（容量ベース）、オンデマンド料金（分析の料金） | BigQuery には柔軟な料金モデルが用意されています。予約では、自動スケーリングを使用して一貫したワークロードとアドホック ワークロードの費用を予測できます。一方、オンデマンド料金はクエリごとのバイトスキャン料金に重点を置いています。 |
| BTEQ、SQL Assistant、その他のクライアント ツール | BigQuery Studio、bq コマンドライン ツール、API | BigQuery には、ウェブベースのエディタ、コマンドライン ツール、プログラムによるアクセス用の API など、クエリを実行するためのさまざまなインターフェースが用意されています。 |
| クエリのロギング / 履歴 | クエリ履歴、INFORMATION_SCHEMA.JOBS |
BigQuery は実行されたクエリの履歴を保持しているため、過去のクエリを確認したり、パフォーマンスを分析したり、問題のトラブルシューティングを行うことができます。INFORMATION_SCHEMA.JOBS は、過去 6 か月間に送信されたすべてのジョブの履歴を保持します。 |
| セキュリティ機能（アクセス制御、暗号化） | セキュリティ機能（IAM、ACL、暗号化） | どちらも堅牢なセキュリティを提供します。BigQuery は、 Google Cloud IAM を使用してきめ細かいアクセス制御を行います。 |
| ネットワーク制御（ファイアウォール、VPN） | VPC Service Controls、プライベート Google アクセス | BigQuery は VPC Service Controls と統合して、特定のネットワークからの BigQuery リソースへのアクセスを制限します。プライベート Google アクセスを使用すると、パブリック IP を使用せずに BigQuery にアクセスできます。 |
| ユーザーとロールの管理 | Identity and Access Management（IAM） | BigQuery では、IAM を使用してきめ細かいアクセス制御を行います。ユーザーとサービス アカウントには、プロジェクト、データセット、テーブルの各レベルで特定の権限を付与できます。 |
| オブジェクトに対する権限付与とロール | データセットとテーブルのアクセス制御リスト（ACL） | BigQuery では、データセットとテーブルに ACL を定義し、きめ細かいレベルでアクセスを制御できます。 |
| 保存データと転送中データの暗号化 | 保存データと転送中のデータの暗号化、顧客管理の暗号鍵（CMEK）。鍵は外部の EKM システムにホスト可能。 | BigQuery はデフォルトでデータを暗号化します。独自の暗号鍵を管理して、制御を強化することもできます。 |
| データ ガバナンスとコンプライアンスの機能 | データ ガバナンス ポリシー、DLP（データ損失防止） | BigQuery は、データ セキュリティとコンプライアンスの遵守に役立つデータ ガバナンス ポリシーと DLP をサポートしています。 |
| Teradata ロード ユーティリティ（FastLoad、MultiLoad）、bteq | BigQuery Data Transfer Service、bq コマンドライン ツール、API | BigQuery には、さまざまなデータ読み込み方法が用意されています。Teradata には、専用の読み込みユーティリティがあります。BigQuery は、データの取り込みのスケーラビリティと速度を重視しています。 |
| Teradata エクスポート ユーティリティ（bteq） | bq コマンドライン ツール、API、Cloud Storage へのエクスポート | BigQuery では、さまざまな宛先にデータをエクスポートできます。Teradata には独自のエクスポート ツールがあります。BigQuery と Cloud Storage の統合は、大きなメリットです。 BigQuery Storage Read API を使用すると、外部コンピューティングでデータを一括で読み取ることができます。 |
| 外部テーブル | 外部テーブル | どちらも外部ストレージのデータのクエリをサポートしています。BigQuery は、Cloud Storage、Spanner、Bigtable、Cloud SQL、AWS S3、Azure Blob Storage、Google ドライブと統合されています。 |
| マテリアライズド ビュー | マテリアライズド ビュー | どちらもクエリ パフォーマンスのためにマテリアライズド ビューを提供しています。 BigQuery には、常に最新のデータを返すスマート チューニング マテリアライズド ビューが用意されています。また、クエリがベーステーブルを参照している場合でも、マテリアライズド ビューに対するクエリの自動書き換えも行われます。 |
| ユーザー定義関数（UDF） | ユーザー定義関数（UDF）（SQL、JavaScript） | BigQuery は、SQL と JavaScript の UDF をサポートしています。 |
| Teradata Scheduler、その他のスケジューリング ツール | スケジュールされたクエリ、Cloud Composer、Cloud Functions、BigQuery パイプライン | BigQuery は、 Google Cloud スケジューリング サービスやその他の外部スケジューリング ツールと統合されています。 |
| ビューポイント | モニタリング、ヘルスチェック、ジョブの探索、容量の管理を行うための BigQuery 管理。 | BigQuery には、運用の健全性とリソース使用率をモニタリングするためのペインなど、包括的な管理ツールボックスに基づく UI が用意されています。 |
| バックアップとリカバリ | データセットのクローン作成、タイムトラベルとフェイルセーフ、テーブルのスナップショットとクローン作成、リージョン ストレージとマルチリージョン ストレージ、クロスリージョン バックアップと復元。 | BigQuery には、データを復元するためのスナップショットとタイムトラベル機能が用意されています。タイムトラベルは、特定の期間内の履歴データにアクセスできる機能です。BigQuery には、データセットのクローニング、リージョン ストレージとマルチリージョン ストレージ、リージョン間のバックアップと復元オプションも用意されています。 |
| 地理空間関数 | 地理空間関数 | どちらのプラットフォームも、地理空間データと関数をサポートしています。 |
使ってみる
以降のセクションでは、Teradata から BigQuery への移行プロセスについて説明します。
移行評価を実行する
Teradata から BigQuery への移行では、まず BigQuery 移行評価ツールを実行して、データ ウェアハウスを Teradata から BigQuery に移行する実現可能性と潜在的なメリットを評価することをおすすめします。このツールは、現在の Teradata 環境を理解し、移行を成功させるために必要な作業を見積もるための構造化されたアプローチを提供します。
BigQuery 移行評価ツールを実行すると、次のセクションを含む評価レポートが生成されます。
- 既存のシステムに関するレポート: データベース、スキーマ、テーブルの数、合計サイズ（TB 単位）など、既存の Teradata システムと使用状況のスナップショット。また、スキーマをサイズ別にリストし、潜在的に最適ではないリソース使用率（書き込みがまったくない、または読み取りがほとんどないテーブル）を示します。
- BigQuery の安定状態での変換の提案: 移行後の BigQuery システムがどのようになるかを提示します。これには BigQuery のワークロードの最適化（と無駄の回避）に関する提案が含まれます。
- 移行計画: 移行作業自体に関する情報を提供します。たとえば、既存のシステムから BigQuery の定常状態への移行などです。このセクションには、自動的に変換されたクエリの数と、各テーブルを BigQuery に移行する予想時間が含まれています。
移行評価の結果について詳しくは、Looker Studio レポートを確認するをご覧ください。
Teradata からスキーマとデータを移行する
移行評価の結果を確認したら、移行用に BigQuery を準備し、データ転送ジョブを設定して、Teradata の移行を開始できます。
Teradata の移行プロセスの詳細については、Teradata からスキーマとデータを移行するをご覧ください。
移行を検証する
Teradata データを BigQuery に移行したら、Data Validation Tool（DVT）を実行して、新しく移行した BigQuery データに対してデータ検証を行います。DVT は、テーブルレベルから行レベルまで、さまざまな関数を検証して、移行したデータが意図したとおりに機能することを確認します。DVT の詳細については、EDW 移行用データ検証ツールの紹介をご覧ください。
DVT には、DVT の公開 GitHub リポジトリからアクセスできます。
次のステップ
- Teradata から BigQuery へのテスト移行を試みる。