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 steady state 変換の提案: 移行後の 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 へのテスト移行を試みます。