LookML の基礎の補足

このページでは、LookMLのより一般的なパターンについて説明します。

フィールド（およびUIの名前）へのラベル付け

Looker は、通常のフォントのビュー名と太字のフィールドの短縮名を組み合わせることで、LookML のフィールド名を UI に表示される文字列に変換します。たとえば、[Orders] ビューの [Amount] というフィールドは、UI では Orders [Amount] と表示されます。太字にし、ビュー名は大文字で表記し（ORDERS Amount）、ディスカッションをわかりやすくするために。

フィールド名をテーブルの列名と異なる名前にする場合は、フィールド名を変更して sql: リンクを宣言します。次の例では、列 cntrl_twr が配置されたテーブル airports があります。Lookerは以下の宣言を生成します。

view: airports {
  dimension: cntrl_twr {        # full name: airports.cntrl_twr
    type: yesno                 # default name: AIRPORT Cntrl Twr (Yes/No)
    sql: ${TABLE}.cntrl_twr ;;  # the sql expression for this field
  }
}

cntrl_twr ディメンションの名前を人が読める形式に変更します。

view: airports {
  dimension: has_control_tower {  # full name: airports.has_control_tower
    type: yesno                   # aliased name: AIRPORTS Has Control Tower (Yes/No)
    sql: ${TABLE}.cntrl_twr ;;    # the sql expression for this field
  }
}

ディメンションによるカウントのフィルタリング

ディメンションでグループ化し、エンティティをカウントするのはとても簡単です。[Users Country] でグループ化すると、[ORDERS Count] で国別の注文を確認できます。しかし、多くの場合、なんらかのディメンション値でフィルタリングしたカウントを作成すると便利です。 たとえば、新しいメジャーとしてフランスからの注文数を作成できます。

view: users {
  dimension: country {}
}
view: orders {
  dimension: id {
    primary_key: yes
    sql: ${TABLE}.id ;;
  }
  measure: count {
    type: count
    drill_fields: [detail]
  }
  measure: france_count {
    type: count   # COUNT(CASE WHEN users.country = 'France' THEN 1 ELSE NULL END)
    filters: [users.country: "France"]
  }
}

フィルタでは任意の式を使用できます。 EU諸国のユーザーを数えるフィールドが必要な場合には、以下のようなものを使用できます。

measure: eu_count {
  type: count   # COUNT(CASE WHEN users.countrycode IN 'UK','FR','ES' THEN 1 ELSE NULL END)
  drill_fields: [detail]
  filters: [users.countrycode: "UK,FR,ES"]
}

数式でフィルタする場合は、二重引用符で囲みます。

measure: total_orders_above_100_dollars {
  type: sum   # SUM(CASE WHEN order.value > 100 THEN order.value ELSE NULL END)
  sql: ${order.value} ;;
  drill_fields: [detail]
  filters: [order.value: ">100"]
}

パーセント

重要業績評価指標の多くは、"返品率"、"販売につながったメールの割合"、またはその他の"YであるXの割合"というようなパーセント形式で表現されます。これをLookMLで表現するには、2つの条件のカウントを作成し、この2つのフィールド間のパーセントを計算するための3番目のフィールドを作成します。

dimension: returned {
  type: yesno
}
measure: count {   # total count of items
  type: count_distinct
  sql: ${TABLE}.id ;;
  drill_fields: [detail]
}
measure: returned_count {   # count of returned items
  type: count_distinct
  sql: ${TABLE}.id ;;
  drill_fields: [detail]
  filters: [returned: "Yes"]
}
measure: percent_returned {
  type: number
  sql: 100.0 * ${returned_count} / NULLIF(${count}, 0) ;;
  value_format: "0.00"
}

パーセントを計算する場合には、次の形式を使用してください。 Postgresではカウントは整数であり、整数間の割り算も整数となります。 100.0との掛け算により、最初のカウントが浮動小数点数に変換されるため、残りの式も浮動データに変換されます。 ゼロ除算エラーを回避するため、NULLIF(value, 0) はゼロの値を null に変換し、結果を null にしてエラーを回避します。

100.0 * ${returned_count} / NULLIF(${count}, 0)

セットを使用した詳細のドリルダウン

Lookerの最もパワフルな機能の1つに、データをドリルダウンして、カウントまたはその他のメジャーを構成する基となるエンティティを参照できる機能があります。

LookerのUI上でメジャーをクリックすると、そのメジャーを構成する一連のデータをローカライズする新しいクエリが作成されます。 テーブル内の行のディメンションごとの値がすべて現在のフィルタに追加されます。

詳細を表示するために、Looker にはメジャーの値がクリックされたときに表示する指定のドリル フィールドが必要となります。モデルを生成すると、通常、ジェネレータがユーザー用に最初のドリルフィールドを複数作成します。さらに、ユーザー自身もドリルフィールドを追加できます。 たとえば、ユーザーの州ごとに先週の注文数を測定しているとします。Lookerのクエリは以下のように表示されます。

USERS State	ORDERS Count
カリフォルニア	24
Texas	5
Colorado	4
フロリダ	4
Illinois	4

たとえば、カリフォルニア州の行で 24 をクリックした場合に予測される動作は、カリフォルニア州からの 24 件の注文が表示されるということです。

Looker は「ユーザー状態: カリフォルニア州」というフィルタを追加しますが、どの項目を順番に表示するかはわかりません。セットを使用して、モデルでそれらのフィールドを宣言する必要があります。

LookML では、セットとはフィールド（ディメンション、メジャー、フィルタ）の名前のリストを指します。セットは、Lookerに以下のフィールドを通知するのに使用されます。

• カウントまたは他のメジャーにドリルダウンするときに、どのフィールドを表示するか
• ビューを結合する場合にどのフィールドをインポートするか
• どのフィールドがExploreでインデックス化されるか

同じセットをモデル内のさまざまな箇所で使用できるので、Lookerにはセットを作成するいくつかの方法があります。

リテラルセット

最もシンプルなセットの形式はリテラルセットです。 リテラルセットは、セットを配列として宣言するだけで作成できます。 リテラルセットの宣言には、'[]'を使用します。

以下の例の場合、

view: customers {
  dimension: id {
    primary_key: yes
  }
  measure: count {
    type: count
  }
  dimension: city {}
  dimension: state {}
  dimension: name {}
}

表示するフィールドは、id、name、city です。

メジャーでは、リテラル配列を宣言するだけです。

measure: count {
  type: count
  drill_fields: [id, name, city]
}

1回だけ使用するセットについては、リテラル宣言をすることで、シンプルで理解しやすくなります。

名前付きセット

CUSTOMERS Count と CUSTOMERS In California Count の 2 つのカウントがあるとします。これらのカウントのいずれかにドリルダウンし、フィールド id、name、city を表示します。フィールドをリテラルに宣言すると、以下のようになります。

view: customers {
  measure: count {
    type: count
    drill_fields: [id, name, city]
  }
  measure: in_california_count {
    type: count
    filters: [state: "California"]
  }
}

新しいフィールド（フィールド customers.state など）を追加する場合は、両方のリストを編集する必要があります。その代わりに、LookMLは、1箇所で維持し、複数の箇所で使用できる名前付きセットを作成する方法を提供します。

次のコードは、セット customers.detail を作成し、両方のカウントを同じフィールド セットにポイントしています。

view: customers {
  set: detail {
    fields: [id, name, city]      # creates named set customers.detail
  }

  measure: count {
    type: count
    drill_fields: [detail*]       # show fields in the set "customers.detail"
  }
  measure: in_california_count {
    type: count
    filters: [state: "California"]
  }
}

LookMLセットはパワフルです。

• セットの宣言は追加式です。セットを複数の場所で宣言すると、Looker はすべてのロケーションでセットに対して宣言されたすべてのフィールドを含めます。
• 他のセットにセットを埋め込むには、他のセット名に続けてアスタリスクを入力します（例: setname*）。
• -fieldname のように、フィールド名の前にハイフンを付けると、セットから要素を削除することもできます。

詳細なセットのリファレンスを読む

ドリルビジュアリゼーションのカスタマイズ

Looker 管理者が ビジュアル ドリル Labs 機能を有効にしている場合は、必ずしもドリル ビジュアリゼーションがデータテーブルのデフォルトとは限りません。この場合は、link パラメータのドキュメント ページとより強力なデータドリルのヘルプセンター記事に示されているように、link パラメータで Liquid 変数を使用して表示するビジュアリゼーションをカスタマイズできます。

新しいダッシュボードでは、ビジュアル ドリル Labs 機能を有効化することなく、link パラメータを使用したドリルダウンがサポートされています。

結果セットのフィルタリング

LookMLに用意されている一連のフィルタ操作をフィールドやExploreに適用して、結果セットをフィルタリングしてからユーザーに返すことができます。

Explore での always_filter

always_filter を使用して、Explore 内で実行されるクエリに常に一連のフィルタを適用します。フィルタはLookerのUIに表示されます。ユーザーはデフォルトのフィルタ値を変更できますが、フィルタを削除することはできません。 一般的に、これらのフィルタは、通常は除外するデータの削除に使用します。たとえば、[注文] の Explore で、完了した注文または保留中の注文のみを確認する必要があるとします。この場合には、以下を追加できます。

explore: orders {
  view_name: order
    filters: [status: "complete,pending"]
  }
}

その他のステータス値を持つ注文を確認するには、UI で [注文ステータス] を [%] に設定します。

Explore での sql_always_where

ユーザーが変更できないクエリ制限を適用する場合は、sql_always_where を使用できます。ユーザーが実行するクエリ以外にも、ダッシュボード、スケジュール化されたLook、そのExploreに依存する組み込まれた情報などに適用されます。 sql_always_where 条件は、ユーザーが作成するクエリの基盤となる SQL を確認しない限り、ユーザーには表示されません。

以下の例では、ユーザーが2012年1月1日より前の注文を見ることができないように制限しています。

# Using Looker references
explore: order {
  sql_always_where: ${created_date} >= '2012-01-01' ;;
}

# Using raw SQL
explore: order {
  sql_always_where: DATE(created_time) >= '2012-01-01' ;;
}

Explore での conditionally_filter

非常に大規模なテーブルでクエリを実行する場合には、クエリに制限がないと、データベースの負荷が過大になるため、なんらかの配慮が必要です。 LookML には、conditionally_filter の形式でこれに対処する方法が用意されています。

unless セクションにリストされているフィールドのいずれかにユーザーがフィルタを追加していない限り、conditionally_filter パラメータを使用してクエリにフィルタを適用します。

次の例では、ユーザーが created_date、shipped_time、shipped_date、orders.id、または customer.name のうち 1 つ以上のフィールドに対してフィルタを適用している場合、ユーザーのクエリは変更されません。ユーザーがこれらのいずれのフィールドにもフィルタを適用しなかった場合、Looker は orders.created_time に 1 日間のフィルタを自動的に追加します。

  filters: [orders.created_time: "1 day"]
  unless: [created_date, shipped_time, shipped_date, orders.id, customer.name]
}