データポータルを BigQuery に接続すると、タイムアウト、SQL 構文の制限、割り当て制限、VPC Service Controls のエラーが発生することがあります。このガイドでは、BigQuery コネクタ全体に共通する問題について説明します。[解決手順] を開いて、問題を調査して解決します。
クエリと SQL の構文エラー
データポータルのカスタム SQL クエリには特定の制限があります。クエリがこれらの上限に違反すると、エラーが発生する可能性があります。
Field is ambiguous 結合エラー
カスタムクエリに重複する列名が含まれている場合、グラフに次のエラーが表示されます。
User Configuration Error: Field is ambiguous
原因: 結合されたテーブル（JOIN）で重複する列名を共有することはできません。たとえば、Criteria_ID フィールドで同一のスキーマを持つ 2 つのテーブルを結合すると、結果の仮想テーブルに重複する列（Criteria_ID、Parent_ID、Name）が含まれ、あいまいさエラーが発生します。
解決手順
AS キーワードまたは EXCEPT 句を使用して、すべての列名を一意にします。
オプション 1: エイリアスを使用して重複するフィールドの名前を明示的に変更する
SELECT * FROM ( SELECT Criteria_ID AS Criteria_ID_1, Parent_ID AS Parent_ID_1, Name AS NAME_1 FROM `project.dataset.table_1` ) AS table_1 LEFT JOIN ( SELECT Criteria_ID AS Criteria_ID_2, Parent_ID AS Parent_ID_2, Name AS NAME_2 FROM `project.dataset.table_2` ) AS table_2 ON table_1.Criteria_ID_1 = table_2.Criteria_ID_2;
オプション 2: EXCEPT を使用して特定のフィールドを除外して名前を変更する
残りのフィールドを保持しながら、少数のフィールドの名前を変更する必要がある場合は、EXCEPT を使用します。
SELECT * EXCEPT (city), city AS city_1 FROM `project.dataset.table_1`
カスタム SQL クエリの構文エラー（複数のステートメント）
カスタム SQL クエリに変数または複数のステートメント（DECLARE、SET）が含まれている場合、クエリは失敗します。
原因: データポータルは、外部の SELECT クエリ（SELECT * FROM (<your_custom_sql>)）内で SQL を実行します。そのため、クエリは単一の SELECT ステートメントである必要があります。
たとえば、次のクエリは、選択する前に変数を宣言しているため失敗します。
DECLARE cost_per_tb_in_dollar FLOAT64 DEFAULT 4.2;
SELECT total_bytes_billed / (1024 * 1024) * cost_per_tb_in_dollar / (1024 * 1024) FROM `billing_table`;
解決手順
共通テーブル式（CTE または WITH 句）を使用して、計算を 1 つの SELECT ステートメントに結合します。
WITH constants AS ( SELECT 4.2 AS cost_per_tb_in_dollar ) SELECT total_bytes_billed / (1024 * 1024) * c.cost_per_tb_in_dollar / (1024 * 1024) AS cost FROM `billing_table`, constants AS c;
パフォーマンスとクエリのタイムアウト
クエリの実行に 3 ～ 5 分以上かかると、データポータルは結果を受信する前にタイムアウトし、HTTP 504 Gateway timeout を返します。
HTTP 504 Gateway timeout または長時間実行クエリのエラー
データポータルのカスタムクエリや複雑なグラフ集計は、3 ～ 5 分後にタイムアウトし、HTTP 504 Gateway timeout エラーが返されることがあります。
解決手順
クエリが常にタイムアウトする場合は、次の最適化を使用します。
- BigQuery Storage Read API を有効にする: BigQuery Storage Read API を有効にして、データ スループットを向上させます。
- クエリを簡素化する: 不要な `JOIN` コマンドを削除し、より広い期間でデータをグループ化して、必要な列のみを選択します。
- BigQuery BI Engine を使用する: BigQuery BI Engine で容量を予約して、1 秒未満のパフォーマンスを実現します。
- データベース ビューを使用する: カスタム SQL を BigQuery ビューまたはマテリアライズド ビューとして保存し、データポータルをそのビューに直接接続します。
- レポート テーブルに事前集計する: BigQuery のスケジュールされたクエリを使用して、サマリー レコードを別のテーブルに書き込み、サマリー テーブルをクエリします。
割り当てとテーブルの制限事項
データセットに数千のテーブルが含まれている場合や、数百万のレコードが返される場合は、上限エラーが発生することがあります。
5,000 を超えるテーブルを含むデータセットの UI の応答性がフリーズする
データポータルのテーブル選択リストを使用して BigQuery データセットに接続しようとすると、ユーザー インターフェースがフリーズするか、応答しなくなります。
原因: コネクタは、データセットあたり最大 5,000 個のテーブルをサポートしています。データセットのテーブルまたはビューが 5,000 を超えると、テーブル選択リストがタイムアウトしてフリーズします。
解決手順
テーブルリストを読み込まずに接続するには、次のいずれかの方法を使用します。
- カスタムクエリを使用して接続する: [カスタムクエリ] を選択し、複雑でない `SELECT` ステートメントを作成します。
SELECT * FROM `your_project.your_dataset.your_table`
- BigQuery から直接接続する: BigQuery コンソールでテーブルを見つけ、[エクスポート] または [データを探索] をクリックして、[Looker Studio で開く] を選択します。
- データセットを分割または再編成する: レポート テーブルを、テーブル数が 5,000 未満の、より小さな専用のレポート データセットに移動します。
返される行数の上限は 200 万行
大規模なデータセットを可視化すると、グラフにデータ切り捨ての警告が表示されたり、200 万レコードを超える行が省略されたりすることがあります。
原因: コネクタは、グラフクエリごとに最大 200 万行を返します。クエリが 200 万レコードを超えると、グラフはデータを切り捨てて警告を表示します。
解決手順
データの切り捨てを回避するには:
- レポートレベルの日付フィルタを適用して、クエリの量を絞り込みます。
- パーティション フィルタを必要とする日付パーティション分割テーブル（`DATE`、`DATETIME`、`TIMESTAMP`）をクエリする（詳細）。
- データポータルで可視化する前に、BigQuery 内で高基数ディメンションをグループ化する。
MEDIAN と PERCENTILE の差異
BigQuery に接続されているグラフで正確な中央値（MEDIAN）またはパーセンタイル（PERCENTILE）を計算すると、他の SQL データベースまたは CSV エクスポートで実行される同じ計算とは出力が若干異なる場合があります。
原因: BigQuery クエリでは、MEDIAN と PERCENTILE は APPROX_QUANTILES 近似集計関数を使用します。これにより、ペタバイト規模のデータセットを迅速に処理できますが、近似結果は、CSV エクスポートや他の SQL データベースで実行される正確な計算とは若干異なる場合があります。
データ型と暗号化のエラー
サポートされていない列タイプと組織で適用される鍵暗号化ポリシーを処理する方法について説明します。
CONDITION_NOT_MET 暗号化エラー（CMEK）
データセットをクエリすると、グラフが失敗し、次のエラーが返されます。
User Configuration Error: CONDITION_NOT_MET
原因: データポータルがクエリジョブを実行すると、BigQuery はクエリ結果を課金対象プロジェクトの一時テーブルに書き込みます。課金プロジェクトの BigQuery に constraints/gcp.restrictNonCmekServices 組織ポリシーの制約が適用されている場合、BigQuery では、一時的なクエリ結果テーブルを含むすべての新しいテーブルに顧客管理の暗号鍵（CMEK）が必要です。コネクタはクエリジョブ リクエストで Cloud Key Management Service 鍵を渡さないため、プロジェクトのデフォルトの Cloud KMS 鍵が構成されていない限り、クエリは User Configuration Error: CONDITION_NOT_MET で失敗します。
解決手順
BigQuery が一時的なクエリ結果テーブルを自動的に暗号化するように、BigQuery でプロジェクトのデフォルトの Cloud KMS 鍵を構成します。
- 課金プロジェクトの BigQuery 暗号化サービス アカウントに、Cloud KMS 鍵に対する Cloud KMS CryptoKey 暗号化 / 復号（
roles/cloudkms.cryptoKeyEncrypterDecrypter）ロールを付与します。 - クエリを実行するデータセットのロケーションの課金プロジェクトで、プロジェクトのデフォルトの Cloud KMS 鍵（
region-LOCATION.default_kms_key_name）を設定します。次に例を示します。ALTER PROJECT PROJECT_ID SET OPTIONS ( `region-LOCATION.default_kms_key_name` = 'projects/KMS_PROJECT_ID/locations/LOCATION/keyRings/KEY_RING/cryptoKeys/KEY' );
または、組織管理者と連携して、課金プロジェクトを constraints/gcp.restrictNonCmekServices ポリシーから除外します。
TIME データ型はサポートされていません
TIME データ型の列（23:59:59 など）を含む BigQuery テーブルに接続すると、データポータルによってフィールドが TEXT に変換され、時間ベースの並べ替えや集計ができなくなります。
原因: データポータルは、BigQuery の TIME データ型（23:59:59 など）をネイティブにサポートしていません。コネクタは、取り込み時に TIME 列を TEXT 文字列に変換するため、時間ベースの並べ替えができなくなります。
解決手順
次のいずれかの回避策を使用して、`TIME` 列を DATETIME オブジェクトに変換します。
回避策 1: カスタム SQL クエリを使用する
SQL で `TIME` フィールドを基準日（`1970-01-01`）と直接結合します。
SELECT *, -- Combine a dummy date (1970-01-01) with your TIME field DATETIME(DATE "1970-01-01", your_time_field) AS time_as_datetime FROM `your_project.your_dataset.your_table`
- 結果: データポータルは、`time_as_datetime` を [日付と時刻] フィールドとして取り込みます。
- 書式設定: レポートグラフのプロパティで、フィールドの [**表示形式**] を [**時間**]、[**分**]、またはカスタム時刻形式（`h:mm:ss`）に変更して、時刻部分のみが表示されるようにします（詳細）。
回避策 2: データポータルで計算フィールドを作成する
SQL クエリを変更しない場合は、データソース内に計算フィールドを作成します。
PARSE_DATETIME("%H:%M:%S", CAST(your_time_field AS TEXT))
- 結果: `PARSE_DATETIME` 関数は、テキスト文字列を解析して **Date & Time** オブジェクトに変換します。このとき、カレンダーの日付はデフォルトで 1970 年 1 月 1 日になります（詳細）。
VPC Service Controls のエラー
サービス境界内で作業する際に、アクセス拒否エラーとバックグラウンド プロセスの制限をトラブルシューティングします。
Service Control Failure（VPN 以外でレポートを表示する場合）
組織の VPN または企業ネットワークの外部でレポートを表示すると、一部またはすべてのグラフで次のエラーが発生します。
Service Control Failure
原因: コネクタは、レポート閲覧者の IP アドレスを BigQuery に渡して、VPC Service Controls の IP ベースのアクセスレベルを確認します。レポートをコピーすると、コピー内の以前のカスタム SQL データソースまたは「ゴースト」カスタム SQL データソースが、サービス境界内で保護されている課金プロジェクトを参照する場合があります。これは、プライマリ データセットが境界外にある場合でも同様です。
解決手順
レポートで、境界にバインドされた非表示の課金プロジェクトを特定し、削除または再割り当てします。
- 影響を受けているレポートのコピーを作成して、安全にトラブルシューティングを行います。
- コピーのレポート エディタで、[リソース] > [追加済みのデータソースの管理] に移動します。
- レポートに添付されている埋め込みの **BigQuery** または **カスタム SQL** データソースをすべて確認します。
- 各カスタム SQL 接続を編集して、構成されている [**請求先プロジェクト**] を確認します。VPC Service Controls の境界で保護されている課金プロジェクトを指しているデータソースがある場合は、保護されていない課金プロジェクトを使用するように更新するか、使用されていないデータソースを削除します。
VPC Service Controls の背後で送信日時を設定したメール配信またはグラフアラートの失敗
VPC Service Controls で保護された BigQuery データセットに接続されているグラフで、自動化されたバックグラウンド機能（送信日時を設定したメール配信やグラフのアラートなど）が実行されると、送信日時を設定したメールはレポートのコンテンツや添付ファイルなしで配信されるか、アラートがトリガーされません（VPC Service Controls unexpected field in error map）。
原因: 自動化されたバックグラウンド機能（送信日時を設定したメール配信やグラフのアラートなど）は、エンドユーザーの IP アドレスなしでバックグラウンド タスクとして実行されるため、VPC Service Controls（VPC-SC）は、IP ベースのアクセスレベル（VPC Service Controls unexpected field in error map）を評価するときに、これらの機能をブロックします。
解決手順
VPC Service Controls の境界の背後で自動バックグラウンド機能を使用するには、サービス アカウントの認証情報を使用するようにデータソースを構成するか、ID ベースのアクセスレベルを作成します。
- 人間以外の専用の認証を構成するには、データポータルの Google Cloud サービス アカウントを設定するをご覧ください。
- 正確なアクセスレベルの要件については、VPC Service Controls の制限をご覧ください。