Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

継続的インテグレーション SQL バリデータ

継続的インテグレーション（CI）SQL バリデータは、Explore のディメンションがデータベースに対して正しく実行されることを検証します。これを行うために、SQL バリデータは LookML プロジェクトの Explore で一連のクエリを実行します。

デフォルトでは、SQL バリデータは次のタスクを実行します。

プロジェクト内の各 Explore について、SQL バリデータは Explore 内のすべてのディメンションを含む Explore クエリを実行します。
Looker が Explore クエリのエラーを返すと、SQL Validator は Explore のディメンションごとに個別の Explore クエリを実行します。

SQL バリデータで、すべての Explore のすべてのディメンションをテストしないようにするには、必要に応じて次のいずれかを行います。

特定の Explore のみをクエリするように SQL Validator を構成します。
特定の Explore を除外するように SQL Validator を構成します。
hidden: yes で定義された LookML ディメンションを無視するように SQL Validator を構成します。
ディメンションの LookML に ci: ignore コメントまたはタグを追加して、SQL Validator が Explore クエリにディメンションを含めないようにします。

CI スイートを作成または編集するときに構成できるオプションの詳細については、このページの SQL Validator のオプションセクションをご覧ください。SQL Validator の実行については、継続的インテグレーションスイートの実行のドキュメントページをご覧ください。

実行結果ページでは、SQL バリデータが各 SQL エラーをディメンションと Explore 別に分類して表示します。問題のある LookML へのリンクと、デバッグ用の [ここから探索] リンクも表示されます。

SQL Validator の検出結果を示す継続的インテグレーションの結果ページ

リソースの使用量

SQL Validator は、Looker 内とデータウェアハウス内で消費するリソースが最小限になるように設計されています。すべての SQL Validator クエリには、LIMIT 0 句と WHERE 1=2 句が含まれています。これらの句は、データウェアハウスのクエリプランナーに、データを処理するのではなく、SQL の有効性を確認するように指示します。

たとえば、BigQuery では、このタイプのクエリは BigQuery でドライランクエリを実行するのと同様です。BigQuery の場合、LIMIT 0 クエリはデータをスキャンしないため、SQL Validator が実行するクエリに対して課金されることはありません。

SQL 検証からディメンションを除外する

パラメータに依存するディメンションなど、特定のディメンションを SQL 検証から除外したい場合があります。これは、検証中にパラメータの値が null になり、常に SQL エラーが発生するためです。

sql パラメータを持たないディメンション（type: distance、type: location、type: duration のディメンションなど）を除外することもできます。

SQL 検証からディメンションを除外するには、次の 2 つの方法のいずれかでディメンションの LookML を変更します。

次の例に示すように、ディメンションの LookML 定義の tags パラメータに ci: ignore ステートメントを追加できます。
```
dimension: addresses {
  sql: ${TABLE}.addresses ;;
  tags: ["ci: ignore"]
}
```
次の例に示すように、ディメンションの LookML の sql フィールドにコメント -- ci: ignore を追加できます。
```
dimension: addresses {
  sql:
    -- ci: ignore
    ${TABLE}.addresses ;;
}
```

継続的インテグレーションと OAuth データベース接続

LookML プロジェクトで OAuth 用に構成されたデータベース接続を使用している場合、自動 CI サービスアカウントユーザーは、データベースの認証に必要なインタラクティブな OAuth フローを完了できません。これにより、SQL Validator が OAuth log in required エラーで失敗します。

継続的インテグレーション SQL バリデータを使用するには、次のいずれかの回避策を実装します。

サービスアカウントを使用するようにデータベース接続を構成する: データベース接続の [認証] 設定を変更して、OAuth ではなくサービスアカウント（アプリケーションのデフォルト認証情報など）を使用するようにします。
CI に OAuth 以外のモデルを使用する: OAuth 以外のデータベース接続を使用する新しい LookML モデルを作成し、他のモデルをインポートします。Looker CI ユーザーがこの新しいモデルにアクセスできることを確認します。

SQL バリデータのオプション

継続的インテグレーションスイートを作成または編集するときに、SQL Validator の実行方法を構成するいくつかのオプションを指定できます。これらのオプションについては、このページの次のセクションで説明します。

クエリを実行する Explore
除外する Explore
フェイルファスト
非表示を無視する
クエリの同時実行数
増分検証

クエリする Explore

デフォルトでは、SQL バリデータは LookML プロジェクト内のすべてのモデルと Explore に対して SQL 検証を実行します。

[クエリする Explore] フィールドを使用して、SQL 検証に含める Explore とモデルを指定できます。

Explore は model_name/explore_name の形式で指定できます。

次の点にご注意ください。

model_name には、.model.lkml 拡張子なしのモデルファイルの名前を使用します。たとえば、thelook.model.lkml で定義されたモデルを指定するには、「thelook」と入力します。
explore_name には、explore LookML パラメータの explore_name を使用します。たとえば、LookML プロジェクトで explore: users として定義されている Explore を指定するには、users と入力します。
カンマ区切りのリストを作成して、複数の Explore を指定できます。
model_name または explore_name でワイルドカード * を使用できます。

次に例を示します。

ファイル thelook.model.lkml で explore: users を使用して定義されている Users Explore のみを指定するには、次のように入力します。
```
thelook/users
```
thelook.model.lkml ファイルで users と orders という名前の Explore を指定するには、次のように入力します。
```
thelook/users, thelook/orders
```
thelook.model.lkml 内のすべての Explore を指定するには、次のように入力します。
```
thelook/*
```
プロジェクト内のすべてのモデルで users という名前のすべての Explore を指定するには、次のように入力します。
```
*/users
```

除外する Explore

デフォルトでは、SQL バリデータは LookML プロジェクト内のすべてのモデルと Explore に対して SQL 検証を実行します。

[除外する Explore] フィールドを使用して、SQL 検証から除外する Explore とモデルを指定できます。

Explore は model_name/explore_name の形式で指定できます。

SQL Validator の Explore を指定する方法については、クエリする Explore セクションをご覧ください。

フェイルファスト

デフォルトでは、SQL Validator は Explore ごとに 1 つのクエリを実行し、クエリ内のすべてのディメンションを対象とします。その Explore クエリが失敗すると、SQL Validator は Explore 内の各ディメンションに対して個別に Explore クエリを実行します。

検証を高速化するには、[フェイルファスト] オプションを有効にします。これにより、SQL Validator は Explore の初期クエリ（すべてのディメンションを一度に含むクエリ）のみを実行します。そのクエリがエラーを返した場合、SQL Validator は CI 実行結果にそのエラーを表示し、検証対象の次の Explore に移動します。

[フェイルファスト] を有効にすると、通常は検証がより速く完了します。ただし、複数のディメンションにエラーがある場合でも、SQL Validator の結果には各 Explore の最初のエラーのみが表示されます。つまり、最初のエラーを修正した後、SQL バリデータを次に実行すると、別のエラーが表示されることがあります。

非表示を無視する

Looker デベロッパーが hidden: yes で定義した LookML ディメンションを SQL バリデータで無視する場合は、[非表示を無視] フィールドを有効にします。SQL Validator は、検証中にこれらのディメンションを Explore クエリから除外します。

クエリの同時実行数

デフォルトでは、Looker インスタンスの過負荷を回避するため、SQL Validator は一度に 10 個以下のクエリを実行します。[クエリの同時実行数] フィールドを使用して、SQL Validator が同時に実行できるクエリの最大数を指定できます。

[クエリの同時実行] フィールドの最大値は、データベース接続の [この接続に関する同時実行クエリの最大数] の設定に制限されます。

SQL 検証の実行中に Looker インスタンスの速度が低下していることに気付いた場合は、この値を減らすことができます。

増分検証

増分検証は、特定の開発ブランチに固有のエラー（本番環境にまだ存在しないエラー）を見つける方法です。増分検証は、開発者がプロジェクト内の既存のエラーに気を取られることなく、担当するエラーを見つけて修正するのに役立ちます。また、特に多くの Explore を含む LookML プロジェクトでは、検証を高速化することもできます。

増分検証の場合、SQL Validator は、開発バージョン（ベース参照）と本番環境バージョン（ターゲット参照）の間で変更された Explore クエリのみを実行します。SQL バリデータは、製品版自体にエラーがある場合でも、開発版に固有のエラーのみを返します。

バリデータの結果では、検証対象のブランチまたは commit でコンパイルされた SQL に変更がなかったためにスキップされた各 Explore が SQL バリデータによって示されます。増分検証の結果の例については、増分検証の結果を表示するをご覧ください。

SQL Validator の増分検証を有効にするには、継続的インテグレーションスイートを作成または編集するときに、[SQL Validator] セクションの [増分エラーのみ] チェックボックスをオンにします。

増分検証については、次の点に注意してください。

（本番環境ブランチでの手動実行などで）SQL Validator が本番環境ブランチ自体を検証する場合、増分検証の設定は適用されません。本番環境ブランチを検証するときは、SQL Validator が完全な検証を実行します。
フェイルファスト モードは、増分検証の実行ではサポートされていません。これは、プロジェクトの開発ブランチに固有の増分エラーを公開するために、個々のディメンションクエリが必要になるためです。