Snowflake から BigQuery への移行 - 概要
このドキュメントでは、Snowflake から BigQuery へのデータ移行の概要について説明します。
BigQuery への移行をサポートするため、 Trusted Cloud by S3NS はデータ ウェアハウスを BigQuery に移行するための包括的なソリューションとして BigQuery Migration Service を提供しています。移行サービスには、評価と計画、SQL 変換、データ転送、データ検証など、移行の各フェーズをサポートする機能が用意されています。詳細については、BigQuery Migration Service の概要をご覧ください。
機能の比較
以降のセクションでは、BigQuery と Snowflake の主な違いと類似点を説明し、BigQuery 固有の機能をいくつか紹介します。
用語
次の表は、Snowflake の用語とそれに対応する BigQuery の用語を示しています。
Snowflake | BigQuery |
---|---|
データベース | データセット |
スキーマ | スキーマ |
表示 | 表示 |
安全なビュー | 承認済みビュー |
仮想ウェアハウス | 予約 |
マテリアライズド ビュー | マテリアライズド ビュー |
マイクロ パーティション | パーティショニング |
クラスタリング | クラスタリング |
セキュリティが強化されたユーザー定義関数(UDF) | 認可済みの UDF |
BigQuery アーキテクチャ
BigQuery は、スケーラビリティの高いアーキテクチャを備えた分析データ ウェアハウスです。BigQuery はストレージとコンピューティングを分離しているため、これらのコンポーネントをオンデマンドで個別にスケーリングできます。BigQuery のアーキテクチャの詳細については、BigQuery の概要をご覧ください。データ移行プロセスに関連する BigQuery の主な機能は次のとおりです。
BigQuery はマネージド テーブルを使用し、サードパーティ データの転送に柔軟なオプションを提供します。これには、Parquet、Avro、ORC、CSV などのポータブル形式で Cloud Storage から直接取り込むことも含まれます。
- BigQuery は Apache Iceberg テーブルもサポートしています。Iceberg は、データレイクハウスの機能を BigQuery にもたらすオープン テーブル形式で、スキーマの進化、タイムトラベル、ACID トランザクションを提供します。これにより、Iceberg を使用する他のシステムとのシームレスな統合が可能になり、データに対する柔軟性と制御性が向上します。
BigQuery では、テーブルを作成するときに明示的なパーティショニングとクラスタリングを定義できます。これにより、データ編成をきめ細かく制御できるため、クエリのパフォーマンスを最適化し、戦略的なパーティショニングとクラスタリングによってコストを削減し、特定の分析ニーズに合わせてデータ レイアウトを調整できます。
- パーティションとクラスタの Recommender を使用して、プロジェクトのワークロードに基づいてパーティショニングとクラスタリングの構成を BigQuery に提案させることもできます。
BigQuery はコンピューティング リソースを自動的に処理します。仮想マシンのプロビジョニングや管理を行う必要はありません。
- 予測可能なワークロードの場合、BigQuery では予約を利用できます。これにより、コンピューティング容量を事前に低コストで予約できます。これは、必要なリソース量が予測可能な一貫したワークロードにメリットがあります。
- 移行中に Snowflake の使用パターンを分析してコンピューティング要件を把握し、BigQuery で最も費用対効果の高いアプローチ(オンデマンド料金か予約の使用か)を判断します。
BigQuery ユーザー インターフェース
BigQuery インターフェースは Trusted Cloud コンソールに組み込まれています。
BigQuery には、bq コマンドライン ツールという Python ベースのコマンドライン ツールもあります。
BigQuery のセキュリティ機能
Snowflake から BigQuery に移行する場合は、Trusted Cloud by S3NS が Snowflake とどのように異なるセキュリティ処理を行うかを考慮してください。
BigQuery のセキュリティは、 Trusted Cloud by S3NSの Identity and Access Management(IAM)と本質的に関連しています。IAM 権限は、リソースで許可されるオペレーションを定義し、 Trusted Cloud by S3NS レベルで適用されます。これにより、セキュリティ管理に対する一元化された一貫性のあるアプローチが実現します。 Trusted Cloud by S3NSの主なセキュリティ機能は次のとおりです。
- 統合セキュリティ: BigQuery は Trusted Cloud by S3NSのセキュリティ機能を活用します。これには、堅牢でシームレスなセキュリティ統合のためのきめ細かいアクセス制御を行う IAM が含まれます。
- リソースレベルのセキュリティ: IAM はリソースレベルのアクセス制御に重点を置き、さまざまな BigQuery リソースとサービスに対する権限をユーザーとグループに付与します。このアプローチにより、アクセス権を効果的に管理し、ユーザーがタスクを実行するために必要な権限のみを持つようにすることができます。
- ネットワーク セキュリティ: BigQuery は、Virtual Private Cloud やプライベート接続など、 Trusted Cloud by S3NSの堅牢なネットワーク セキュリティ機能を活用しています。
Snowflake から BigQuery に移行する場合は、次のセキュリティ関連の移行要件を考慮してください。
- IAM 構成: 既存の Snowflake アクセス制御ポリシーに合わせて、BigQuery で IAM ロールと権限を構成する必要があります。これには、Snowflake のロールを適切な BigQuery IAM のロールと権限にマッピングすることが含まれます。
- きめ細かいアクセス制御: Snowflake で行レベルまたは列レベルのセキュリティを使用している場合は、承認済みビューまたはポリシータグを使用して、BigQuery で同等の制御を実装する必要があります。
- ビューと UDF の移行: ビューと UDF を移行するときに、関連するセキュリティ制御が BigQuery の承認済みビューと承認済み UDF に適切に変換されていることを確認します。
暗号化
BigQuery は、保存データと転送中データをデフォルトで暗号化します。暗号鍵をより細かく制御する必要がある場合は、BigQuery は Cloud Key Management Service で顧客管理の暗号鍵をサポートしています。列レベルの暗号化を使用することもできます。
BigQuery への移行中および移行後にデータ セキュリティを維持するには、次の点を考慮してください。
- 鍵管理: 顧客管理の鍵が必要な場合は、Cloud Key Management Service で鍵管理戦略を確立し、それらの鍵を使用するように BigQuery を構成します。
- データのマスキング/トークン化: 機密データが関係する場合は、データを保護するためにデータのマスキングまたはトークン化が必要かどうかを評価します。
- 行レベルのセキュリティ: 承認済みビュー、行レベルのセキュリティ フィルタ、またはその他の適切な方法を使用して、行レベルのセキュリティを実装します。
- 脆弱性スキャンとペネトレーション テスト: 定期的に脆弱性スキャンとペネトレーション テストを実施して、BigQuery 環境のセキュリティ体制を確認します。
ロール
ロールは、保護可能なオブジェクトに対する権限の付与や取り消しができるエンティティです。
IAM では、権限はロールにグループ化されています。IAM には次の 3 種類のロールがあります。
- 基本ロール: オーナー、編集者、閲覧者のロールが含まれます。Trusted Cloud コンソール、Identity and Access Management API、または
gcloud CLI
を使用して、これらのロールをプロジェクトまたはサービスのリソースレベルで適用できます。一般に、セキュリティを最も強固にするために、事前定義されたロールを使用して最小権限の原則に従うことをおすすめします。 - 事前定義ロール: プロダクト(BigQuery など)内の機能に対するよりきめ細かなアクセス権を提供します。これは、一般的なユースケースとアクセス制御パターンに対応することを目的としています。
- カスタムロール: ユーザー指定の権限で構成されます。
アクセス制御
Snowflake を使用すると、ロールを別のロールに付与して、ロールの階層を作成できます。IAM はロール階層をサポートしませんが、リソース階層を実装しています。IAM 階層には、組織レベル、フォルダレベル、プロジェクト レベル、リソースレベルが含まれます。IAM ロールは階層の任意のレベルで設定でき、リソースは親リソースのポリシーをすべて継承します。
BigQuery は、テーブルレベルのアクセス制御をサポートしています。テーブルレベルの権限により、テーブルまたはビューにアクセスできるユーザー、グループ、サービス アカウントが決まります。ユーザーに完全なデータセットへのアクセス権を与えることなく、特定のテーブルまたはビューへのアクセス権を付与できます。
よりきめ細かなアクセスを行うには、列レベルのアクセス制御または行レベルのセキュリティを使用します。このタイプの制御では、ポリシータグまたはタイプベースのデータ分類を使用して、機密性の高い列に対してきめ細かいアクセス制御を行います。
承認済みビューを作成して、基になるテーブルに対する読み取りアクセス権のないユーザーでもビューに対してクエリを実行できるように、きめ細かいアクセス制御を行うことができます。
他の Snowflake 機能を移行する
BigQuery への移行を計画する際は、次の Snowflake の機能を考慮してください。場合によっては、 Trusted Cloud の他のサービスを使用して移行を完了できます。
タイムトラベル: BigQuery では、タイムトラベルを使用して過去 7 日以内の任意の時点のデータにアクセスできます。7 日を超えるデータを使用する必要がある場合は、定期的にスケジュール設定されたスナップショットのエクスポートを検討してください。
ストリーム: BigQuery は Datastream で変更データ キャプチャ(CDC)をサポートします。Debezium などの CDC ソフトウェアを使用して、Dataflow で BigQuery にレコードを書き込むこともできます。BigQuery を使用して CDC パイプラインを手動で設計する方法の詳細については、データ ウェアハウスの BigQuery への移行: 変更データ キャプチャ(CDC)をご覧ください。
タスク: BigQuery では、クエリとストリームのスケジュール設定、または Datastream を使用したクエリへのストリーム統合が可能です。
外部関数: BigQuery は、Cloud Run functions を介した外部関数呼び出しをサポートしています。SQL UDF などのユーザー定義関数(UDF)を使用することもできますが、これらの関数は BigQuery 内で実行されます。
使ってみる
以降のセクションでは、Snowflake から BigQuery への移行プロセスについて説明します。
移行評価を実行する
Snowflake から BigQuery への移行では、まず BigQuery 移行評価ツールを実行して、データ ウェアハウスを Snowflake から BigQuery に移行する実現可能性と潜在的なメリットを評価することをおすすめします。このツールは、現在の Snowflake 環境を把握し、移行を成功させるために必要な作業を見積もるための構造化されたアプローチを提供します。
BigQuery 移行評価ツールを実行すると、次のセクションを含む評価レポートが生成されます。
- 既存のシステム レポート: データベース、スキーマ、テーブルの数、合計サイズ(TB 単位)など、既存の Snowflake システムと使用状況のスナップショット。また、スキーマをサイズ別に一覧表示し、書き込みがないか、読み取りがほとんどないテーブルなど、最適ではない可能性があるリソース使用率を示します。
- BigQuery steady state 変換の提案: 移行後の BigQuery でシステムがどのように表示されるかを示します。これには、BigQuery でのワークロードの最適化と無駄の回避に関する提案が含まれます。
- 移行計画: 移行作業自体に関する情報を提供します。たとえば、既存のシステムから BigQuery の定常状態への移行などです。このセクションには、自動的に変換されたクエリの数と、各テーブルを BigQuery に移行する予想時間が含まれています。
移行評価の結果について詳しくは、Looker Studio レポートを確認するをご覧ください。
Snowflake から BigQuery への移行パイプラインを設定する
移行評価の結果を確認したら、移行パイプラインを設定して Snowflake 移行を開始できます。詳細については、Snowflake から BigQuery への移行 - 概要をご覧ください。
移行を検証する
Snowflake データを BigQuery に移行したら、Data Validation Tool(DVT)を実行して、新しく移行した BigQuery データに対してデータ検証を行います。DVT は、テーブルレベルから行レベルまで、さまざまな機能を検証して、移行したデータが意図したとおりに動作することを確認します。