BigQuery のサーバーレスアーキテクチャでは、ストレージとコンピューティングが分離しているため、それぞれオンデマンドでスケールできる。
Avro形式はBigQueryにもSpark/Hadoopにも対応可能な共通フォーマット。 だが、HDFSはBigQueryからは直接アクセスできない。
Dry runはスキャン量の確認用、EXPLAINはBigQueryのクエリ実行計画（スキャン、フィルタ、JOINなどのステップ）の可視化。
[Analytics Hub]
Analytics Hub は、プロバイダー（提供者）とコンシューマー（利用者）を分離して、BigQuery データセットの共有を管理する GCP の公式サービスで、組織内でのデータ流通に最適です。
[clustering]
クラスタリングは、指定した列の値順にテーブル内データを物理的に並べます。
BigQuery のクラスタリングは、STRING / NUMERIC / DATE / TIMESTAMP など一部のデータ型にしか対応していません。
GEOGRAPHY 型はクラスタリングキーとして使えず、地理空間データの効率化には別の方法（例えば地域コードやID列をキーにする）が必要です。
[DataTransferService]
Google BigQuery の公式サービスで、以下に対応：
YouTube Channel Reports
YouTube Content Owner Reports
Google Ads, Campaign Manager, Google Analytics など
自動的にスケジュール転送されるため、ノーコードで簡潔にETLが実現可能。
BQ DTS は、Google SaaS (例: Google Ads)、他のクラウドストレージ (S3)、他の DWH (Teradata 等) から直接 BigQuery にデータをロードするのに特化したサービスである。オンプレミスのファイルシステムからオフサイトバックアップファイルを Cloud Storage 経由で BigQuery にロードするというシナリオでは、まず Cloud Storage への転送を行う Storage Transfer Service (または gsutil など) の方が直接的である。
[Flat-rate pricing]
Flat-rate pricingでは、専用スロットを購入でき、スロットを組織全体で共有しつつ、プロジェクトやフォルダ単位で優先順位や重み付けを設定できます（Reservation & Assignment）。これにより、スロット不足の問題を根本的に解決できます。
[Google スプレッドシートとの統合]
BigQuery は Google スプレッドシートとの統合が可能で、
クエリ結果を直接 Google Sheets に書き出し
共有設定を行えば、財務チームは慣れたスプレッドシートでそのまま分析が可能
[INFORMATION_SCHEMA.JOBS_BY_PROJECT]
このビューを使えば、各クエリのスキャン量や実行時間、ユーザーごとの実行状況を確認でき、原因特定に役立ちます。
Execution Details を使えば、クエリの各ステージごとの実行時間や処理量を可視化でき、どこがボトルネックになっているかを分析できます。
[partition]
PARTITION BY Date
OPTIONS (
partition_expiration_days=1445
)
パーティション有効期限（partition expiration） が切れると、
該当パーティション（例えば特定の日付や月のデータ全体）が丸ごと削除される。
パーティション: 大きく不要領域を切り落とす
クラスタリング: パーティション内の不要領域をさらに細かく切り落とす
日付でパーティショニング＋countryでクラスタリング
[quotas(クォータ)]
BigQuery の1日あたりの最大使用量を設定できる。
[Transfer Appliance + Dedicated/Partner Interconnect]
Transfer Applianceで既存データを搬入し、Dedicated Interconnectで高速・継続的にデータを取り込み可能。
[サービスアカウント]
「ユーザーごとに認証を行わせたくない」「データセットへの直接アクセス権も与えたくない」というような要件では、アプリケーションが代わりにBigQueryへアクセスする必要があり、その代表的な方法が サービスアカウント を使うことです。
[スロットとクエリモード]
Interactive Query（対話型）：即時実行されるがスロット使用量も即反映。スロットが足りないとクォータエラー。
Batch Query（バッチ）：最大3時間まで遅延可能。スロットが空いたときに実行されるため、低優先度クエリに最適。
[大規模データ更新]
大規模データ更新は DML（UPDATE）で処理するのではなく、新しいテーブルを使った MERGE または CREATE TABLE AS SELECT の形で処理するのが BigQuery の推奨パターン。
[ダッシュボードのレイテンシを最小化する最適解]
BI Engine：
インメモリキャッシュでクエリ高速化。
Materialized View：
事前に集計された結果を保存。
事前計算 + キャッシュ + 増分更新により、パフォーマンス大幅向上。
[フルマネージドCDC同期]
Oracle から BigQuery への フルマネージドCDC同期をしたいなら、Datastream + private connectivity がベストです。Google Cloud の公式ドキュメントでもこの構成が推奨されています。
[プロジェクトの追加方法]
Explorerの隣の「Add data」→「star a project by name」