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

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

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

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

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

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

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

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

リソースの使用量

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

たとえば BigQuery では、このタイプのクエリは BigQuery でドライラン クエリを実行するようなものです。BigQuery の場合、LIMIT 0 クエリはデータをスキャンしないため、SQL バリデータが実行するクエリに対して料金は発生しません。

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

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

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

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

• 次の例に示すように、ディメンションの LookML 定義の tags パラメータに ci: ignore ステートメントを追加できます。

  dimension: addresses {
    sql: ${TABLE}.addresses ;;
    tags: ["ci: ignore"]
  }
  

• 次の例に示すように、ディメンションの LookML の sql フィールドにコメント -- ci: ignore を追加できます。

  dimension: addresses {
    sql:
      -- ci: ignore
      ${TABLE}.addresses ;;
  }
  

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

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

• クエリを実行する Explore
• 除外する Explore
• Fail fast
• 非表示を無視する
• クエリの同時実行数
• 増分検証

クエリするデータ探索

デフォルトでは、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 で定義されている [ユーザー] 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 バリデータに Explore を指定する方法の詳細については、クエリする Explore セクションをご覧ください。

フェイル ファスト

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

検証を高速化するには、[Fail fast] オプションを有効にして、SQL 検証ツールで Explore の初期クエリ（すべてのディメンションが一度に含まれるクエリ）のみを実行するようにします。そのクエリがエラーを返すと、SQL 検証ツールは CI 実行結果にそのエラーを表示し、検証対象の次の Explore に進みます。

Fail fast を有効にすると、通常、検証はより迅速に完了します。ただし、SQL Validator の結果には、複数のディメンションにエラーがあっても、各 Explore の最初のエラーのみが表示されます。つまり、最初のエラーを修正した後、SQL バリデータを再度実行すると、追加のエラーが表示される可能性があります。

非表示を無視する

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

クエリの同時実行数

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

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

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

増分検証

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

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

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

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

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

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