この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
Lookerでは対象のデータベーステーブルを解析し、「ビュー」という構造体として設定ファイルを生成します。中身はテーブル内のカラム情報を解析したものとなるのですが、その過程・挙動について気になったところがありましたのでエントリとしてまとめました。確認してみて初めて腑に落ちた部分でもありましたので、Lookerをご利用の方、使い始めた方々のご参考になれば幸いです。
目次
- LookerML自動生成時のビューに於ける『ディメンション』と『メジャー』生成で個人的に感じた疑問点(Question)
- LookerML自動生成時のビューに於ける『ディメンション』と『メジャー』生成に於ける挙動と対処方法(Answer)
- まとめ
LookerML自動生成時のビューに於ける『ディメンション』と『メジャー』生成で個人的に感じた疑問点(Question)
所定の操作に従って接続対象データベースを指定し、LookML Projectを作成すると、Lookerはシステム内部でデータベース接続を元に対象テーブルを割り出し、対象テーブル毎に定義ファイルを自動生成します。
生成されたテーブルの設定ファイル例が以下となります。Developers.IOのブログ投稿データを管理するテーブルです。(※生成済みのファイルに対し、label:属性及びカラム名を付与しています)
生成された項目は、「メジャー」として認識されているのは73-77行目で定義されているcountのみ。その他の項目は全て「ディメンション」として定義されています。
t_blogposts
view: t_blogposts {
sql_table_name: cmdevio.t_blogposts ;;
dimension: author_id {
label: "著者ID"
type: string
sql: ${TABLE}.author_id ;;
}
dimension: facebook {
label: "ポイント:Facebook"
type: number
sql: ${TABLE}.facebook ;;
}
dimension: hatena {
label: "ポイント:はてブ"
type: number
sql: ${TABLE}.hatena ;;
}
dimension_group: post {
label: "投稿日時"
type: time
timeframes: [
raw,
time,
date,
week,
month,
quarter,
year
]
sql: ${TABLE}.post_date ;;
}
dimension: post_id {
label: "投稿ID"
type: number
sql: ${TABLE}.post_id ;;
}
dimension: social {
label: "ポイント:SNS総数"
type: number
sql: ${TABLE}.social ;;
}
dimension: title {
label: "ブログタイトル"
type: string
sql: ${TABLE}.title ;;
}
dimension: twitter {
label: "ポイント:Twitter"
type: number
sql: ${TABLE}.twitter ;;
}
dimension: url {
label: "ブログURL"
type: string
sql: ${TABLE}.url ;;
}
dimension: view {
label: "ポイント:PV"
type: number
sql: ${TABLE}.view ;;
}
measure: count {
type: count
label: "投稿本数"
drill_fields: []
}
}ここで気になるのは、以下の様なポイントです。
Q1.
なぜ、投稿件数(count)だけメジャーとして定義されているのか？
Q2.
その他数値として認識して欲しかったものは以下の項目群なのだが、それらは全て「ディメンション」として認識されている。(type: numberと定義されているのでデータの在り方としては数値っぽいが、なぜディメンションとなっているのだろう？
- dimension: facebook(label: "ポイント:Facebook")
- dimension: hatena(label: "ポイント:はてブ")
- dimension: social(label: "ポイント:SNS総数")
- dimension: twitter(label: "ポイント:Twitter")
- dimension: view(label: "ポイント:PV")
Q3.
個人的には「投稿件数(count)の合計」や「SNSポイント(social)の合計や平均」等を数値情報として利用したいが、この初期状態から何か上手いこと展開してくれるものなのだろうか？それとも必要なものは都度自分で作成しなければならない？
LookerML自動生成時のビューに於ける『ディメンション』と『メジャー』生成に於ける挙動と対処方法(Answer)
上記疑問点に対し、Lookerのドキュメントやサポートに問い合わせる等して判明した内容は以下となります。
A1&A2
そういう仕様・挙動になっている。
...まぁ回答としては身も蓋も無い感じではありますがw 内部挙動的にはそういう形になっているようです。
下記ドキュメントの「ディメンションとメジャーのフィールド」の項には、以下の様な記述があります。
ディメンションとメジャーの「作成条件」については下記引用文太字箇所で確認出来ました。Looker内部ではこの条件に基づき、レコード件数に相当するcountのみをメジャーとして判断・生成し、その他の項目は全てディメンションとして初期状態で作成するという挙動となっているようです。
ビューには、フィールド、主にディメンションとメジャーが含まれます。これらは、Lookerクエリの基本的な構成要素となります。
Lookerでは、ディメンションはグループ化可能なフィールドであり、クエリ結果をフィルタリングするために使用できます。以下のものになる可能性があります。
基になるテーブルの列に直接関連する属性
ファクト、または数値
単一の行の他のフィールドの値に基づいて計算された派生値
例えば、製品のビューのディメンションには、製品名、製品モデル、製品の色、製品価格、製造年月日、消費期限日などが含まれます。メジャーは、COUNT、SUM、AVG、MIN、MAXなどのSQL集計関数を使用するフィールドです。他のメジャー値の値に基づいて計算されたフィールドもメジャーです。メジャーを使用して、グループ化された値をフィルタリングできます。例えば、売上のビューのメジャーには、売上アイテム数（カウント）、売上総額（合計）、平均売り値（平均）が含まれます。
フィールドの動作と予期される値は、string、number、timeなど、宣言されたタイプによって異なります。メジャーでは、タイプにはsumやpercent_of_previousなどの集計関数があります。詳細については、ディメンションのタイプおよびメジャーのタイプを参照してください。
A3."必要な"メジャー項目は要件・状況に応じてフィールド定義を追加しなければならない。
なんでこの部分に対してこういう言及を行い、Q&Aとして挙げたのかと言うと、個人的にTableauをこれまで慣れ親しんでいたので、「Tableauではこうなってたけど、Lookerではどういう風になっているんだろう？」と思ったのがその理由です。Tableauでは以下の様にデータ型が数値の場合は数値項目(メジャー)として判定され、要素としても数値項目として利用出来るようになっています。この部分は両者挙動に違いがあるのですね。
で、3つ目の問いに関する答えが上記見出しの内容となります。そうなんです。Lookerでは「そういうメジャーが欲しい」場合、「そういう挙動を持つメジャーとフィールドとして新設しなければならない」のです。これはディメンションも同様で、「無ければ作る」必要があります。
作成する際に参考となる「作成出来るタイプ」については下記ドキュメントでディメンション、メジャーそれぞれに解説が為されています。
当エントリでは「メジャー項目」に焦点を当てていたので、ヘルプを参考にして以下の様なフィールド定義を追加してみました。
元からあった投稿本数(count)については、こちらの意図した通り数値情報として機能しました。著者別でまとめた際も合計値として集約されています。
件数をsumでまとめた「合計(投稿本数)」なるメジャーも作ってみました。がしかし、この使い方(メジャー項目で他のメジャーを参照する)はLookerではエラーになるようです。
maxを用いた、所定の期間における「1エントリにおける最もSNSポイントをゲットしたエントリの数字」を出してみました。これもちゃんと動いてそう。(うん、っていうかSNSポイントで1000超えってすごいね...)
averageを使った1エントリ毎の平均値も著者別に出してみました。こちらは小数点の出し方に若干の癖があるようなのですが、一応それっぽい値は出ています。(詳細についてはまたエントリを改める形で...)
まとめ
という訳で、Lookerにおけるフィールド毎のディメンション／メジャーの生成条件、及びメジャー項目の新規作成方法(の触りだけ)のご紹介でした。
途中言及したように「TableauではこうだけどLookerだとどうなってるんだろう？」という形で当エントリを書く流れとなったのですが、Lookerの"お作法"が判明したので結果的に良かったです。「明示的にフィールドを定義する」「その定義は不プロジェクトでソースコード管理され、共有出来るようになる」という流れで考えるとこれはこれで望ましい形なのかな、とも思いました。ディメンション及びメジャーについては、実際にどういう型定義が出来るのかについて一通り触ってみたいと思います。
24
