Zenn
🐥

Google Cloud で提供されている『移行評価』で Amazon Redshift から BigQuery への移行をサポート

2024/08/27に公開
AWS
BigQuery
tech

はじめに

こんにちは、クラウドエース データソリューション部の源です。

クラウドエース データソリューション部 について

クラウドエースのITエンジニアリングを担う システム開発統括部 の中で、特にデータ基盤構築・分析基盤構築からデータ分析までを含む一貫したデータ課題の解決を専門とするのが データソリューション部 です。
弊社では、新たに仲間に加わってくださる方を募集しています。もし、ご興味があれば エントリー をお待ちしております。

今回は、Google Cloud で提供されている、Amazon Redshift からBigQuery への『移行評価』機能についてご紹介いたします。
詳細な手順や詳しい機能はドキュメントで確認可能なため、本記事では忙しい人向けに要約した内容をご紹介をいたします。
※内容及び画像は公式ドキュメントより引用しています。

移行評価について

既存のデータウェアハウスから別のデータウェアハウスに移行する場合、移行コストや必要な時間、スキーマ等様々な要因を考慮する必要があります。
データウェアハウスの移行を確実に成功させるためには早期の段階で移行戦略の計画を始める必要がありますが、移行評価をすることで有用な情報を得ることができます。
本記事では、Amazon Web Services の提供するデータウェアハウスである Amazon Redshift から Google Cloud の提供するデータウェアハウスである BigQuery へ移行する際の移行評価についてご紹介いたします。
この移行評価機能は一般提供されていますが、機能の一つである『集計された評価結果』は プレビュー になります。つまり、一般提供前のサービスであり、SLA または Google 補償の対象外、かつ通知なしに変更される場合があります。

移行評価の利点

BigQuery 移行評価は、既存のデータ ウェアハウスの BigQuery への移行プロセスを効率的に計画するのに役立ちます。
BigQuery 移行評価を利用すると以下が可能になります。

  • 移行後のコスト削減の可能性の確認
  • テーブルごとの予想移行時間や行数、サイズの確認
  • BigQuery のパーティショニングやクラスタリングに関する最適化提案の取得
  • 頻繁に使用されるテーブルや未使用テーブルに関する情報を基にした最適化提案の取得
  • 評価結果をレポートとして可視化

移行評価の手順

BigQuery 移行評価を準備して実行する手順の概要は次のとおりです。

  1. Cloud Storage バケットを作成
  2. dwh-migration-dumper ツールを使用して、データウェアハウスからメタデータとクエリログを抽出
  3. Cloud Storage バケットにメタデータとクエリログをアップロード
  4. 移行評価を実行
  5. Looker Studio レポートを確認
  6. 省略可: 評価結果をクエリして、詳細または具体的な評価情報を確認

1. Cloud Storage バケットを作成

移行評価を行う前にバケットを作成する必要があります。
ドキュメントを元にバケットを作成します。

2. データ ウェアハウスからメタデータとクエリログを抽出する

評価を実行するためには、メタデータとクエリログの両方が必要です。
評価の実行に必要なメタデータとクエリログを抽出するには、dwh-migration-dumper コマンドライン抽出ツール をダウンロードし、Amazon Redshift データウェアハウスからログとメタデータを 2 つの ZIP ファイルとして抽出します。

3. メタデータとクエリログを Cloud Storage にアップロードする

Amazon Redshift データウェアハウスからメタデータとクエリログを抽出したら、メタデータとクエリログを含む 1 つ以上の ZIP ファイルを Cloud Storage バケットにアップロードします。

4. 移行評価を実行

BigQuery 移行評価を実行すると、評価結果が BigQuery のテーブルに書き込まれます。

また、集約された評価結果のみを含むデータセットも作成されます。この集約されたデータセットにはクエリログが含まれないため、個人を特定できる情報やビジネス上の機密情報は表示されません。この集約されたデータセットを検索、検査、他のユーザーと安全に共有するには、移行評価の出力テーブルに対してクエリを実行する方法をご覧ください。この集約されたデータセットの作成機能は無効にすることも可能です。

5. Looker Studio レポートを確認

評価タスクが完了すると、結果の Looker Studio レポートを作成して共有できます。
Looker Studio レポートは、移行評価のためのフロントエンドダッシュボードです。
[Migration Highlights] ビューには、大きく分けて 3 つのセクションの概要が表示されます。

Migration_Highlights

  • [Existing System] パネルには、データベース、スキーマ、テーブルの数、および既存の Amazon Redshift システムの合計サイズに関する情報が表示されます。また、スキーマをサイズ別に一覧表示し、潜在的に最適ではないリソース使用率も示します。テーブルを削除、パーティショニング、クラスタリングするときにこの情報を使用できます。
  • [BigQuery Steady State] パネルに、BigQuery でデータが移行後にどのようになるかに関する情報（BigQuery 移行サービスを使用して自動的に変換できるクエリの数など）が表示されます。また、このセクションには、年間データ取り込み率に基づいてデータを BigQuery に保存するのにかかる費用と共に、テーブル、プロビジョニング、スペースの最適化に関する提案も表示されます。Amazon Redshift から BigQuery への移行に利用可能な移行サービスは複数あります。詳細はドキュメントGoogle Cloud への移行: 移行ツールをご覧ください。
  • [Migration Path] パネルには、移行処理自体に関する情報が表示されます。テーブルごとに、予想される移行時間、テーブル内の行数、サイズが表示されます。

特に [BigQuery Steady State] セクションは、ワークロード最適化を行うための指標が確認できます。

  • Clustering & Partitioning：パーティショニング、クラスタリングが役立つテーブルが表示されます。
  • Tables With No Usage：分析対象のログの期間中に BigQuery 移行評価で使用が検出されなかったテーブルが表示されます。使用量がないということは、移行中にそのテーブルを BigQuery に転送する必要がないか、BigQuery にデータを保存する費用を削減できることを示している場合があります。
  • Tables With No Writes：分析対象のログの期間中に BigQuery 移行評価で更新が検出されなかったテーブルが表示されます。書き込みがないことは、BigQuery でストレージコストを削減できる場所を示している可能性があります。具体的には、長期保存の検討が望ましいです。
  • BI Engine and Materialized Views：BigQuery のパフォーマンスを向上させるための最適化に関するその他の推奨事項が示されます。

評価の実行の概要

評価の実行の概要には、レポートの完全性、進行中の評価の進捗状況、処理されたファイルとエラーのステータスが含まれます。レポートの特定のセクションのデータが欠落している場合、この情報は [Assessment Modules] の表の [Report Completeness] インジケーターに表示されます。

Assessment_execution_summary

レポートを共有する

本章のレポート確認で用いた Looker Studio レポートは、他のユーザーに共有可能です。
基になるデータセットのアクセス権限に依存しているため、受取人に Looker Studio レポート自体へのアクセス権と評価結果を含む BigQuery データセットへのアクセス権の両方を与えることでレポートの共有が可能です。

6. 省略可: 評価結果をクエリして、詳細または具体的な評価情報を確認

BigQuery データセットの基となるデータを表示してクエリすることもできます。
次の例では、一意のクエリの総数、変換に失敗したクエリの数、変換に失敗した一意のクエリの割合を取得します。

  SELECT
    QueryCount.v AS QueryCount,
    ErrorCount.v as ErrorCount,
    (ErrorCount.v * 100) / QueryCount.v AS FailurePercentage
  FROM
  (
    SELECT
     COUNT(*) AS v
    FROM
      `your_project.your_dataset.TranslationErrors`
    WHERE Type = "ERROR"
  ) AS ErrorCount,
  (
    SELECT
      COUNT(DISTINCT(QueryHash)) AS v
    FROM
      `your_project.your_dataset.Queries`
  ) AS QueryCount;

まとめ

  • 既存のデータウェアハウスから別のデータウェアハウスに移行する場合、移行コストや必要な時間、スキーマなど様々な要因を考慮する必要があります。
  • 移行評価を行うことで、以下のことが可能になります。
    • 移行後のコスト削減の可能性の確認
    • テーブルごとの予想移行時間や行数、サイズの確認
    • BigQuery のパーティショニングやクラスタリングに関する最適化提案の取得
    • 頻繁に使用されるテーブルや未使用テーブルに関する情報を基にした最適化提案の取得
    • 評価結果をレポートとして可視化

Discussion