G-gen の杉村です。Google Cloud (旧称 GCP) 認定資格である Looker LookML Developer 試験 は、他の Google Cloud 認定試験とは一線を画し、かつては Google Cloud とは別プロダクトであった Looker の開発者向け認定資格です。
本投稿では試験の合格に役立つ情報を記載します。

※ 当試験は 2022/04/01 をもって廃止となりました。しかしながら当記事は Looker の製品知識の取得に役立ててもらう意味を込めて、公開のままとさせていただきます。

はじめに
フィルタとアクセス制御
- フィルタを強制する
- アクセス制御
Dimension & Measure
- フィールドタイプ
- 持続可能な LookML
Explore / View
Derived Table (派生テーブル)
ユーザーの利便性向上
開発と Git
トラブルシューティング
ベストプラクティス
その他
- 日本語版試験と英語版試験
- 受験環境

はじめに

本投稿の想定読者

本投稿は以下のような方向けです。

Looker LookML Developer 試験を受けるために勉強をしており出題傾向を知りたい
Looker の基本的な知識は習得済み、もしくはある程度実務で使ったことがある
近日中に試験を受けようと思っているので、最後の勉強をしている

Looker LookML Developer 試験の難易度

当試験の難易度としては、中程度だと言えます。
Looker を通常業務で用いており、 LookML を日常的に扱っている人にとっては、当記事を参考にポイントを押さえた追加学習を行うことで十分合格できます。
ただし LookML の初心者であったり、 Looker をあまり扱った経験のない人にとっては、まずはトレーニング等で基本を押さえてからでないと当試験の合格は難しいでしょう。

推奨の勉強法

Google (Looker チーム) の実施している公式トレーニングなどを受けて、基礎的なスキルを習得する (ここが最も重要であり取っ掛かりになります)
試験ガイドを読み出題範囲を理解する
当記事を読み、出題傾向を理解する
理解を深めたいパラメータについては公式ドキュメントを読んだり、インターネット検索して各社の公開する技術ブログを読む。実際に Looker 環境で使ってみることも重要
最後にまた、当記事で復習する

なお当試験は 2022 年 1 月現在、 英語でのみ提供 されています。
他の Google Cloud 試験と比べても 1 問の問題文が長い傾向があるため、英語ドキュメントを読むことに慣れていないと、まず問題文を理解することに脳のリソースを使ってしまうことになりかねません。 Looker ドキュメントは普段から英語で読む ように癖づけましょう。

また試験時間は 100 分であり、先述の通り問題文が長いため、他の Google Cloud 試験に比べて時間的余裕がありません。
筆者も、当試験の受験時点で 4 つの Google Cloud 試験を合格済みでしたが、もっとも時間的に焦りを感じた試験となりました。
時間配分は、普段以上に気をつける必要がありそうです。

出題傾向

当記事ではこれ以降、どのような試験問題が出るか、出題傾向を解説していきます。わからない言葉や知らない用語があれば、公式ドキュメントなどを辿り、十分知識をつけてください。そのように勉強すれば、試験に合格できるのに加え、実践的な知識となるでしょう。

フィルタとアクセス制御

フィルタを強制する

ソースデータベースから取得するデータを適切に絞ることは、とても重要です。
BigQuery を始め、多くのカラムナ (列志向) のデータウェアハウス製品では、適切なクエリを書かなければ テーブルにフルスキャンがかかってしまう 可能性があります。
これは不要な負荷をデータベースにかけることになるだけでなく、製品によってはスキャン量に応じた課金となるため、コスト的なデメリットもあります。

Looker では以下のようなパラメータが用意されており、 LookML の工夫次第でユーザーが不用意に巨大なクエリを投げてしまうことを防ぐことができます。

※ (凡例) [利用箇所] パラメータ名

[Explore] sql_always_where
[Explore] always_filter
[Explore] conditionally_filter

これらのパラメータについては、サブパラメータの書き方も含めてしっかり押さえておく必要があります。
ただドキュメントを眺めるのではなく「実業務ではどういうときにこのパラメータを使うのか？」「似たパラメータ名だが、違いは何なのか？」を理解すると良いでしょう。

アクセス制御

Looker のユーザーには User Attribute という属性を持たせることができます。例えば department という Attribute を持たせ、ユーザーごとに executive, sales, store-manager のように役職・部署名を持たせます。
Looker ではこの User Attribute ごとに、見せるデータを変えることができます。
Explore ごと、 Join/View ごと、フィールドごとに見せ方を変えることができますし、行単位で制御することも可能です。

以下のパラメータを用います。

[Explore] access_filter
[Model] access_grant
[Explore / Join / View / Field] required_access_grants

これらのパラメータについても、やはりサブパラメータの書き方も含めてしっかり押さえておく必要があります。
繰り返しになりますが「実業務ではどういうときにこのパラメータを使うのか？」「似たパラメータ名だが、違いは何なのか？」を考えつつ勉強します。

access_filter は User Attribute の値をもとに行をフィルタします。強制的に SQL の WHERE 句が追加されます。
access_grant と required_access_grants はセットです。 User Attribute の値に応じて Explore / Join / View / Field の閲覧を許可するかどうかを設定できます。

Dimension & Measure

フィールドタイプ

Dimension や Measure の各タイプやその特徴を押さえておきます。
Measure では sum や number といった頻繁に使われるタイプはもちろん、 sum_distinct や percent_of_total など、様々なタイプの用法、サブパラメータも押さえておきましょう。

持続可能な LookML

持続可能な LookML (運用を崩壊させず、継続でき、かつスケールできるような LookML の書き方) に関する問題は多く出てきます。

例えばフィールドを set でまとめて Explore 側の fields パラメータで指定できるようにしておく、であったり、万一フィールド名を変えたときのために alias を使ったり、などというテクニックです。

これは後述するベストプラクティスにも記載があります。
Extends の利用などもこれに含まれるでしょう。

Explore / View

Explore の各パラメータを把握しておきます。

特に重要になるのが、 View 同士の結合に関する知識です。
Looker では対称集計 (Symmetric Aggregates) が可能であり、これを適切に働かせるには join において relationship パラメータを適切に設定する必要があります。

なお対称集計に関連して Explore には symmetric_aggregates というパラメータがありますが通常は省略され、デフォルトは yes です。

そもそも対称集計とは何か、そしてそれが集計結果にどう影響を及ぼすのか、についてまずはキャッチアップしましょう。

Derived Table (派生テーブル)

試験にあたり Looker の Derived Table (派生テーブル) 機能を使いこなせるようになっている必要があります。

Looker における View を一般的なデータベース用語における「テーブル」に見立てると、 Derived Table は「ビュー」に当たります。
日単位→月単位のように粒度を変えたり、 Measure を Dimension 化したり、複雑なロジックを事前に入れ込んだりするために用います。

Derived Table の種類は "Persistent / Temporary" の軸と "Native / SQL" の軸があり、都合 4 種類あるといえます。

試験では、特に Persistent Derived Table (PDT) の扱いが注目されます。
そもそも、 PDT を使いたいときはどんなときなのかを把握しましょう。
一般的なデータベース用語における「ビュー」が Temporary Derived Table だとすると、 Persistent Derived Table は「マテリアライズド・ビュー」に当たります。
指定したデータベースに物理テーブルとしてデータを事前に永続化するので、パフォーマンスの向上が見込めます。

また PDT はデータベースに物理テーブルとして永続化されるので、リフレッシュのタイミングの指定方法が重要です。
datagroup の使い方をしっかり説明できるようにしておきましょう。
「 sql_trigger と max_cache_age の違いや使い方」「ソーステーブルの ETL プロセスと PDT リフレッシュのタイミングを合わせるにはどうするか」などの理解は必須です。

sql_trigger の書き方はドキュメントの「 Examples 」が参考になります。
またキャッシュ周りは似たようなパラメータが多いのでドキュメント Persistence strategies を読んでおきましょう。

ユーザーの利便性向上

LookML Developer 試験は開発者向けの試験ですが、ユーザー目線を意識させる問題が多いです。
どのように実装すれば利用者にとって嬉しいか、を考えさせます。

以下のようなベストプラクティスを覚えておきましょう。

必要最小限のフィールドだけが見えるようにする
- 不要なフィールドは Explore/Join の fields パラメータで除外
- 見せる必要のないフィールドは hidden パラメータで隠す
似たフィールドは group_label パラメータでグルーピングする
- group_label は explore にもある
分かりやすい名前を付けるため view_label パラメータを使う
- view_label は explore / view / join にもある

開発と Git

Looker は Git と統合できます。
GitHub などの外部レポジトリを用いるのが推奨です。

Bare Git repository と呼ばれる Looker サーバに配置するレポジトリのみを利用するモードもあり、これを利用すれば外部の Git を用意しなくてよいのですが、これだと開発者は Looker のブラウザベース IDE からローカルレポジトリのみを編集するような形になり、推奨されていません。

外部レポジトリを使う場合 HTTPS と SSH の 2 通りの接続方法が利用できますが、認証方法に違いがあるため、ドキュメントをそれぞれ確認しておきましょう。

例えば HTTPS 接続にした場合でも Single account HTTPS authentication と Multiple account HTTPS authentication の 2 種類があり、前者だと Git ログインに使われる認証情報を一つだけ設定する、など違いがあります。

トラブルシューティング

試験ガイドにあるように Content Validator で何ができるのかはよく確認しておきましょう。
壊れた参照などを検知する機能に加え、これを修正する機能も備わっています。

また LookML を開発していると様々なエラーメッセージに直面します。
Looker error catalog というドキュメントには、エラーメッセージと考えられる原因がまとめられています。
この一覧はチェックしておきましょう。もちろん、すべて覚える必要などありませんが [IDE] のマークが付いているメッセージは要確認です。

ベストプラクティス

公式の Looker Help Center に掲載されている、以下のベストプラクティスは読んでおきましょう。
試験問題だけでなく、業務に直結する知見が得られるかもしれません。

その他

日本語版試験と英語版試験

Google Cloud 認定資格の試験を申込みする際は KRYTERION の Webassessor の Web サイトでアカウントを作成して申し込みます。
しかし、アカウント作成時に言語を 日本語 として作成すると、日本語版の Google Cloud 認定資格しか申し込むことができません。

英語版しか提供されていない Looker 試験を申し込むには 2022 年 2 月現在、 言語を英語とした新しいアカウントを作成 する必要があります。
Webassessor のログイン画面が以下のように日本語表記の場合、英語版に切り替えてから新しいアカウントを作成し、そのアカウントで申し込みます。