このドキュメントでは、変更データ キャプチャ（CDC）を使用して、さまざまなデータソースを BigQuery と統合するいくつかの手法について説明します。このドキュメントでは、各手法におけるデータの整合性、使いやすさ、費用のトレードオフの分析について説明します。これにより、既存のソリューションについて理解し、CDC によってレプリケートされたデータを消費する手法を学習して、手法のコスト パフォーマンスの分析を行うことが可能になります。
このドキュメントは、データ アーキテクト、データ エンジニア、ビジネス アナリストを対象に、BigQuery にレプリケートされたデータにアクセスするための最適な手法を開発できるようにすることを目的としています。このドキュメントは、BigQuery、SQL、コマンドライン ツールを十分に理解していることを前提としています。
CDC データ レプリケーションの概要
CDC のデータソースとして MySQL、Oracle、SAP などのデータベースが最もよく使われています。ただし、主キーで識別されるデータ要素がキャプチャされ、変更された場合は、どのようなシステムもデータソースと見なされます。システムがトランザクション ログなどの組み込みの CDC プロセスを備えていない場合、変更情報を得るには、増分バッチリーダーをデプロイします。
このドキュメントでは、次の条件を満たす CDC プロセスについて説明します。
- データ レプリケーションにより、各テーブルの変更が個別にキャプチャされる。
- すべてのテーブルに主キーまたは複合主キーがある。
- すべての CDC イベントには単調に増加する変更 ID（通常はトランザクション ID やタイムスタンプなど）が割り当てられる。
- すべての CDC イベントが、変更された行の状態を含んでいる。
次の図は、CDC を使用してデータソースを BigQuery にレプリケートする汎用アーキテクチャを示しています。
上図では、メインテーブルとデルタテーブルがソース データ テーブルごとに BigQuery に作成されます。メインテーブルには、ソーステーブルのすべての列に加え、最新の変更 ID 値の列が 1 列含まれます。最新の変更 ID 値は、レコードの主キーで識別されるエンティティのバージョン ID と見なし、それを使用して最新バージョンを検索できます。
デルタテーブルには、ソーステーブルのすべての列、オペレーション タイプ列（更新、挿入、削除のいずれか）、および変更 ID の値が含まれます。
CDC を使用して BigQuery にデータをレプリケートする全体的なプロセスは、次のとおりです。
- ソーステーブルの初期データダンプが抽出されます。
- 抽出されたデータは、必要に応じて変換され、対応するメインテーブルに読み込まれます。テーブルに、最終更新タイムスタンプなど、変更 ID として使用できる列がない場合、変更 ID はその列のデータ型の最小値に設定されます。これにより、後続の処理が、最初のデータダンプの後に更新されたメインテーブル レコードを識別できます。
- 最初のデータダンプの後に変化した行は、CDC のキャプチャ プロセスでキャプチャされます。
- 必要に応じて、CDC 処理レイヤによって追加のデータ変換が実行されます。たとえば、CDC 処理レイヤは、BigQuery で使用するタイムスタンプの再フォーマット、列の垂直分割、列の削除など行います。
- データは、マイクロバッチ読み込みまたはストリーミング挿入を使用して、BigQuery の対応するデルタテーブルに挿入されます。
データが BigQuery に挿入される前に追加の変換が行われると、列の数とタイプがソーステーブルと異なるデータになる場合があります。ただし、メインテーブルとデルタテーブルには、同じ一連の列が存在します。
デルタテーブルには、初期の読み込み以降の特定のテーブルに対するすべての変更イベントが含まれます。すべての変更イベントを利用可能にすることは、トレンド、テーブルが特定の時点を表すエンティティの状態、変更頻度の特定に役立ちます。
特定の主キーによって表されるエンティティの現在の状態を取得するには、メインテーブルとデルタテーブルをクエリして、最新の変更 ID を持つレコードを取得します。このクエリは、メインテーブルとデルタテーブルの結合を実行し、特定の主キーの最新のエントリを見つけるために両方のテーブル全体を完全にスキャンする必要があるため、コストが高くなる場合があります。主キーに基づいてテーブル内のクラスタリングまたはパーティショニングを行うことで、テーブル全体のスキャンを実行せずに済みますが、常に可能なわけではありません。
テーブルをパーティショニングまたはクラスタ化できない場合、次の方法でエンティティの現在のステータスを取得できます。このドキュメントでは、これらの一般的な手法について比較を行います。
- 即時整合性アプローチ: クエリを使用して、レプリケートされたデータの現在の状態を反映します。即時整合性は、メインテーブルとデルタテーブルを結合するクエリを行い、各主キーに対応する最新の行を選択します。
- コスト最適化アプローチ: データが利用可能になるまでに多少の遅れが生じますが、高速で低コストのクエリが実行されます。データはメインテーブルに定期的にマージできます。
- ハイブリッド型アプローチ: 要件と予算に応じて、即時整合性アプローチまたはコスト最適化アプローチを使用します。
このドキュメントでは、これらの手法に加え、パフォーマンスを向上させる他の方法についても説明します。
始める前に
このドキュメントでは、bq コマンドライン ツールと SQL ステートメントを使用して、BigQuery データの表示やクエリを行う方法を説明します。テーブルのレイアウトとクエリの例は、このドキュメントの後半で説明します。サンプルデータで試してみる場合は、次の手順を行います。
- プロジェクトを選択するか、プロジェクトを作成して、プロジェクトで課金を有効にします。
- プロジェクトを作成すると、BigQuery が自動的に有効になります。
- 既存のプロジェクトを選択した場合は、BigQuery API を有効にします。
- Google Cloud Console で Cloud Shell を開きます。
テキスト エディタで BigQuery 構成ファイルの
~/.bigqueryrcを開き、ファイル内の任意の場所に次の行を追加します。[query] --use_legacy_sql=false [mk] --use_legacy_sql=falseBigQuery 環境を設定するスクリプトを含む GitHub リポジトリのクローンを作成します。
git clone https://github.com/GoogleCloudPlatform/bq-mirroring-cdc.gitデータセット、メインテーブル、デルタテーブルを作成します。
cd bq-mirroring-cdc/tutorial chmod +x *.sh ./create-tables.sh
試用後に料金が発生しないようにするには、プロジェクトをシャットダウンするか、データセットを削除します。
BigQuery データを準備する
BigQuery に CDC データをレプリケーションする方法を比較するため、後で説明する単純なサンプル テーブルのようなサンプルデータを含むメインテーブルとデルタテーブルのペアを使用します。
このドキュメントの説明よりも高度な設定を行うには、CDC BigQuery 統合デモを使用できます。このデモでは、テーブルを設定するプロセスを自動化します。また、レプリケーション プロセスをモニタリングするスクリプトも使用します。デモを実行する場合は、始める前にセクションで作成した GitHub リポジトリのクローンのルートにある README ファイルを参照してください。
サンプルデータでは、単純なデータモデル（システムによって生成されたセッション ID とオプションのユーザー名を含むウェブ セッション）を使用しています。セッションを開始すると、ユーザー名は null になります。ユーザーがログインすると、ユーザー名が挿入されます。
BigQuery 環境のスクリプトからメインテーブルにデータを読み込むには、次のようにコマンドを実行します。
bq load cdc_tutorial.session_main init.csv
メインテーブルのコンテンツを取得するには、次のようにクエリを実行します。
bq query "select * from cdc_tutorial.session_main limit 1000"
出力は次のようになります。
+-----+----------+-----------+ | id | username | change_id | +-----+----------+-----------+ | 100 | NULL | 1 | | 101 | Sam | 2 | | 102 | Jamie | 3 | +-----+----------+-----------+
次に、CDC 変更の最初のバッチをデルタテーブルに読み込みます。デルタテーブルに対する CDC 変更の最初のバッチを BigQuery 環境のスクリプトから読み込むには、次のようにコマンドを実行します。
bq load cdc_tutorial.session_delta first-batch.csv
デルタテーブルのコンテンツを取得するには、次のようにクエリを実行します。
bq query "select * from cdc_tutorial.session_delta limit 1000"
出力は次のようになります。
+-----+----------+-----------+-------------+ | id | username | change_id | change_type | +-----+----------+-----------+-------------+ | 100 | Cory | 4 | U | | 101 | Sam | 5 | D | | 103 | NULL | 6 | I | | 104 | Jamie | 7 | I | +-----+----------+-----------+-------------+
この出力で、change_id の値はテーブル行変更の一意の ID です。change_type 列の値には次の意味があります。
U: 更新オペレーションD: 削除オペレーションI: 挿入オペレーション
メインテーブルには、セッション 100、101、102 に関する情報が含まれます。デルタテーブルに含まれる変更点は、次のとおりです。
- セッション 100 がユーザー名「Cory」で更新されている。
- セッション 101 が削除されている。
- 103 と 104 の新規セッションが作成されている。
ソースシステムにおけるセッションの現在の状態は次のようになります。
+-----+----------+ | id | username | +-----+----------+ | 100 | Cory | | 102 | Jamie | | 103 | NULL | | 104 | Jamie | +-----+----------+
現在の状態はテーブルとして表示されますが、このテーブルが具体化された形式で存在するわけではありません。このテーブルは、メインテーブルとデルタテーブルを組み合わせたものです。
クエリでデータを取得する
セッションの全体的な状態を判断する手法はいくつかあります。以降のセクションでは、それぞれの手法の利点と欠点について説明します。
即時整合性アプローチ
即時のデータ整合性が第一の目標で、ソースデータが頻繁に変更される場合は、1 回のクエリでメインテーブルとデルタテーブルを結合し、最新の行（最新のタイムスタンプか最大の値を持つ行）を選択できます。
メインテーブルとデルタテーブルを結合して最新の行を見つける BigQuery ビューを作成するには、次のように bq ツールのコマンドを実行します。
bq mk --view \
"SELECT * EXCEPT(change_type, row_num)
FROM (
SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY change_id DESC) AS row_num
FROM (
SELECT * EXCEPT(change_type), change_type
FROM \`$(gcloud config get-value project).cdc_tutorial.session_delta\` UNION ALL
SELECT *, 'I'
FROM \`$(gcloud config get-value project).cdc_tutorial.session_main\`))
WHERE
row_num = 1
AND change_type <> 'D'" \
cdc_tutorial.session_latest_v
前の BigQuery ビューの SQL ステートメントは次の処理を行います。
- 最も内側の
UNION ALLは、メインテーブルとデルタテーブルの両方から次のように行を生成します。SELECT * EXCEPT(change_type), change_type FROM session_deltaは、change_type列をリストの最終列にします。SELECT *, 'I' FROM session_mainは、挿入行として使えるようにメインテーブルの行を選択します。*演算子は、例を単純にするために使用しています。追加の列がある場合や、列の順序が異なる場合は、この省略形を明示的な列リストに置き換えます。
SELECT *, ROW_NUMBER() OVER (PARTITION BY id ORDER BY change_id DESC) AS row_numは BigQuery のウィンドウ関数を使用して、同じid値を持つ行をPARTITION BYでグループ化し、そのグループそれぞれに 1 から始まる連続する行番号を割り当てます。行は、そのグループ内でchange_idの降順に並べられます。change_idは増加することが保証されているため、最新の変更は、row_num列の値が 1 になります。WHERE row_num = 1 AND change_type <> 'D'は、各グループの最新行のみを選択します。これは BigQuery でよく使用される重複除去の方法です。また、変更タイプが delete の場合は結果から行を削除します。- 一番上の
SELECT * EXCEPT(change_type, row_num)は、処理のために加えられた余分な列を削除しますが、それ以外の意味はありません。
上の例では、最も大きい change_id 値を参照すると、元の挿入または最新の更新が選択されるため、挿入と更新の変更タイプは使用していません。この場合、各行にはすべての列の完全なデータが含まれています。
ビューを作成すると、ビューに対してクエリを実行できます。最新の変更を取得するには、次のようにクエリを実行します。
bq query 'select * from cdc_tutorial.session_latest_v order by id limit 10'
出力は次のようになります。
+-----+----------+-----------+ | id | username | change_id | +-----+----------+-----------+ | 100 | Cory | 4 | | 102 | Jamie | 3 | | 103 | NULL | 6 | | 104 | Jamie | 7 | +-----+----------+-----------+
データ操作言語（DML）ステートメントを使用してデルタテーブルのデータを更新すると、ビューに対するクエリの実行で、デルタテーブルのデータがすぐに表示されます。データをストリーミングで更新した場合は、ほぼすぐに表示されます。
コスト最適化アプローチ
即時整合性アプローチは単純ですが、BigQuery はビューを実装するためにすべての履歴レコードを読み取り、主キーで並べ替え、そのクエリ内の他のオペレーションを処理する必要があるため、効率的ではありません。即時整合性アプローチでは、セッション状態を頻繁にクエリするとパフォーマンスが低下し、BigQuery でデータの保存と処理のコストが増える可能性があります。
コストを最小限に抑えるには、デルタテーブルの変更をメインテーブルにマージし、デルタテーブルからマージした行を定期的に削除します。マージと削除には追加の費用がかかりますが、メインテーブルを頻繁にクエリする場合は、デルタテーブルのキーの最新レコードを絶えず検索するよりも費用ははるかに低くなります。
デルタテーブルのデータをメインテーブルにマージするには、MERGE ステートメントを次のように実行します。
bq query \
'MERGE `cdc_tutorial.session_main` m
USING
(
SELECT * EXCEPT(row_num)
FROM (
SELECT *, ROW_NUMBER() OVER(PARTITION BY delta.id ORDER BY delta.change_id DESC) AS row_num
FROM `cdc_tutorial.session_delta` delta )
WHERE row_num = 1) d
ON m.id = d.id
WHEN NOT MATCHED
AND change_type IN ("I", "U") THEN
INSERT (id, username, change_id)
VALUES (d.id, d.username, d.change_id)
WHEN MATCHED
AND d.change_type = "D" THEN
DELETE
WHEN MATCHED
AND d.change_type = "U"
AND (m.change_id < d.change_id) THEN
UPDATE
SET username = d.username, change_id = d.change_id'
上の MERGE ステートメントは 4 行とメインテーブルに作用し、セッションの現在状態を保持します。このビューのメインテーブルをクエリするには、次のようにクエリを実行します。
bq query 'select * from cdc_tutorial.session_main order by id limit 10'
出力は次のようになります。
+-----+----------+-----------+ | id | username | change_id | +-----+----------+-----------+ | 100 | Cory | 4 | | 102 | Jamie | 3 | | 103 | NULL | 6 | | 104 | Jamie | 7 | +-----+----------+-----------+
メインテーブルのデータには、最新のセッションの状態が反映されます。
データを頻繁かつ整合性を取りながらマージする最適な方法は、MERGE ステートメントを使用し、複数の INSERT、UPDATE、DELETE ステートメントを 1 つのアトミック オペレーションに組み合わせることです。上の MERGE ステートメントの意味は次のとおりです。
session_mainテーブルは、USING句（この場合はサブクエリ）で指定されたデータソースとマージされます。- サブクエリは、即時整合性アプローチのビューと同じ手法を使用し、同じ
id値を持つレコード グループ内の最新の行（ROW_NUMBER() OVER(PARTITION BY id ORDER BY change_id DESC) row_numとWHERE row_num = 1の組み合わせ）を選択します。 - マージは、両テーブルの
id列（主キー）で行われます。 WHEN NOT MATCHED句は、レコードが一致するかどうかをチェックします。一致しない場合、その最新レコードが挿入されたものか、更新されたものかを確認し、どちらかの場合はレコードを挿入します。- レコードが一致して変更タイプが削除の場合、レコードはメインテーブルから削除されます。
- レコードが一致して変更タイプが更新の場合、デルタテーブルの
change_id値がメインレコードのchange_id値より大きければ、データは更新され、change_id値が最新になります。
上の MERGE ステートメントは、次の変更のどの組み合わせでも正しく機能します。
- 同じ主キーに対する複数行の更新。最新の更新のみが適用されます。
メインテーブルで一致しない更新。メインテーブルにレコードがない場合、新しいレコードが挿入されます。
この手法では、メインテーブルの抽出が省略され、デルタテーブルから開始します。メインテーブルのデータは自動的に挿入されます。
未処理のデルタバッチに行を挿入して更新します。最新の更新行が使用され、新しいレコードがメインテーブルに挿入されます。
未処理のバッチに行を挿入して削除します。レコードは挿入されません。
上の MERGE ステートメントは、複数回実行してもメインテーブルと同じ状態になります。副作用はありません。デルタテーブルに新しい行がない場合、MERGE ステートメントを再実行すると、出力は次のようになります。
Number of affected rows: 0
MERGE ステートメントを定期的に実行することで、マージを行うたびにメインテーブルが最新の状態になります。メインテーブルのデータの鮮度はマージの頻度によって異なります。MERGE ステートメントを自動的に実行する方法については、前にダウンロードしたデモの README ファイルで「Scheduling merges」セクションをご覧ください。
ハイブリッド アプローチ
即時整合性アプローチとコスト最適化アプローチは組み合わせて使用できます。session_latest_v ビューと session_main テーブルに対してクエリを実行すると、同じ結果が返されます。使用する手法は、要件と予算に応じて選択できます。高コストでほぼ即時の整合性を選択するか、低コストだが古いデータの可能性があるものを選択するかの違いです。以降のセクションでは、各手法とそれに代わる候補を比較する方法について説明します。
各手法の比較
このセクションでは、各ソリューションのコスト パフォーマンスと、許容できるデータのレイテンシおよびマージの実行コストのバランスを検討して各手法を比較する方法について説明します。
クエリのコスト
各ソリューションのコスト パフォーマンスを評価するため、次の例では CDC BigQuery 統合デモで生成された約 500,000 セッションの分析を示します。デモのセッション モデルは、このドキュメントで導入した前述のモデルよりもやや複雑で、別のデータセットにデプロイされますが、コンセプトは同じです。
クエリのコストは、単純な集計を行うクエリを使用して比較できます。次のクエリの例では、デルタデータとメインテーブルを組み合わせたビューに対する即時整合性アプローチを検査します。
SELECT status, count(*) FROM `cdc_demo.session_latest_v`
GROUP BY status ORDER BY status
クエリの結果、コストは次のとおりです。
Slot time consumed: 15.115 sec, Bytes shuffled 80.66 MB
次の例のクエリでは、メインテーブルに対するコスト最適化アプローチを調べます。
SELECT status, count(*) FROM `cdc_demo.session_main`
GROUP BY status ORDER BY status
クエリの結果、次のように低いコストになります。
Slot time consumed: 1.118 sec, Bytes shuffled 609 B
同じクエリを複数回実行した場合、スロット時間の使用量は変わる可能性がありますが、平均値はかなり安定します。Bytes shuffled 値は、異なる実行間で一致しています。
パフォーマンスのテスト結果は、クエリの種類とテーブル レイアウトによって異なります。前のデモでは、データ クラスタリングやパーティショニングを使用していません。
データ レイテンシ
コスト最適化アプローチを使用する場合、データ レイテンシは次の項目の合計になります。
- データ レプリケーション トリガーの遅延。これは、元のイベントの中でデータが保持されてから、レプリケーション システムがレプリケーション プロセスをトリガーするまでの時間です。
- BigQuery にデータを挿入する時間（レプリケーション ソリューションによって異なります）。
- BigQuery のストリーミング バッファデータがデルタテーブルに入るまでの時間。ストリーミング挿入の場合、通常は数秒です。
- マージの実行から次のマージを実行するまでの間隔。
- マージの実行時間。
即時整合性アプローチを使用する場合、データ レイテンシは次の項目の合計です。
- データ レプリケーション トリガーの遅延。
- BigQuery にデータを挿入する時間。
- BigQuery のストリーミング バッファデータがデルタテーブルに挿入されるまでの時間。
マージの実行間隔は、マージの実行にかかるコストとデータに必要な整合性とのトレードオフに応じて構成できます。必要に応じて、営業時間中は頻繁にマージを実行し、営業時間外は 1 時間ごとにマージするなど、より複雑な方法を使用できます。
考慮すべき代替手段
即時整合性アプローチとコスト最適化アプローチは、さまざまなデータソースを BigQuery と統合するための最も一般的な CDC の選択肢です。このセクションでは、よりシンプルで低コストのデータ統合の選択肢について説明します。
信頼できる唯一の情報源としてのデルタテーブル
デルタテーブルに変更履歴全体が含まれている場合、デルタテーブルに対してのみビューを作成でき、メインテーブルは使用できません。信頼できる唯一の情報源としてデルタテーブルを使用する例としてはイベント データベースがあります。この手法を使用すると、パフォーマンスを少し犠牲にするだけで、即時整合性を低コストで実現できます。レコード数が少なく、ディメンション テーブルの変更頻度が非常に低い場合は、この手法を検討してください。
CDC なしの全データダンプ
テーブルが扱いやすいサイズ（たとえば 1 GB 未満）の場合、次の手順で簡単に完全なデータのダンプを実行できます。
- 最初のデータダンプを一意の名前を持つテーブルにインポートします。
- 新しいテーブルのみを参照するビューを作成します。
- 基になるテーブルではなくビューに対してクエリを実行します。
- データダンプを別のテーブルにインポートします。
- 新たにアップロードされたデータを参照するようにビューを再作成します。
- 必要に応じて、元のテーブルを削除します。
- 上の手順を定期的に繰り返して、インポート、再作成、削除を行います。
メインテーブルに変更履歴を保存する
コスト最適化アプローチでは、変更履歴は保持されず、最新の変更で前のデータが上書きされます。履歴を残す必要がある場合は、変更の配列を使用して履歴を保持できます。これによって、最大行数上限は超えないように注意する必要があります。メインテーブルの変更履歴を保持する場合、1 回の MERGE オペレーションでデルタテーブルの複数の行をメインテーブルの 1 つの行に統合できるため、マージ DML はより複雑になります。
フェデレーション データソースを使用する
BigQuery 以外のデータソースにレプリケートして、連携クエリを使用してそのデータソースを公開できる場合もあります。BigQuery はさまざまな外部データソースをサポートしています。たとえば、MySQL データベースからスター型のようなスキーマを複製する場合は、ネイティブの MySQL レプリケーションを使用して、変更頻度が非常に低いディメンションを読み取り専用バージョンの MySQL に複製できます。この方法では、頻繁に変更されるファクト テーブルのみを BigQuery に複製します。フェデレーション データソースを使用する場合は、フェデレーション ソースのクエリに関するいくつかの制限を考慮してください。
パフォーマンスをさらに改善する
このセクションでは、テーブルのクラスタリングとパーティショニング、マージされたデータのプルーニングによって、さらにパフォーマンスを改善する方法について説明します。
BigQuery テーブルのクラスタリングとパーティショニング
データセットが頻繁にクエリされる場合は、テーブル全体の使用状況を分析し、クラスタリングとパーティショニングを行ってテーブルの設計を調整します。メインテーブルとデルタテーブルの片方または両方を主キーでクラスタリングすると、他の方法に比べてパフォーマンスが向上する可能性があります。パフォーマンスを検証するには、少なくとも 10 GB のデータセットでクエリをテストします。
マージされたデータのプルーニング
デルタテーブルは時間の経過とともに増加します。また、各マージ リクエストでは、最終結果に不要な多くの行を読み取ることによりリソースが無駄に消費されます。デルタテーブルのデータのみを使用して最新の状態を算定する場合、マージされたレコードをプルーニングすると、マージのコストを削減できます。また、BigQuery に保存されるデータ量を減らすことで全体のコストも削減できます。
マージされたデータは、次の方法でプルーニングできます。
- 定期的にメインテーブルで
change_idの最大値をクエリし、その最大値未満のchange_id値を持つ差分レコードをすべて削除します。デルタテーブルにストリーミング挿入する場合、挿入した内容が一定期間削除されないことがあります。 - デルタテーブルの取り込みベースのパーティショニングを使用し、毎日 1 回実行されるスクリプトを使用して、すでに処理されたパーティションを削除します。より細かい BigQuery のパーティショニングが利用可能になると、パージの頻度を増やせます。実装の詳細については、前にダウンロードしたデモの
READMEファイルの「Purging processed data」セクションをご覧ください。
まとめ
適切なアプローチを選択するには（複数選択を含む）、解決するユースケースを考慮する必要があります。既存のデータベース移行技術を使用することにより、データ レプリケーションのニーズを解決できる場合があります。たとえば、リアルタイム データのユースケースを解決し、残りのデータアクセス パターンをコスト最適化する必要がある場合など、複雑なニーズがある場合は、他のプロダクトやオープンソースのソリューションに基づいてカスタム データベース移行の頻度を設定する必要があるかもしれません。このドキュメントで説明した手法とテクニックは、このようなソリューションの実装を成功させるのに役立ちます。
次のステップ
- データ パイプラインの移行を確認する。
- Google Cloud でクラウドネイティブ データ ウェアハウスのための ETL アーキテクチャを設計すると Dataflow を使用してリレーショナル データベースから BigQuery に ETL を実行するを確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センター をご覧ください。