Lookerベスト・プラクティス：LookML 要素別オススメ開発手法 #looker
Lookerではトピック毎のベストプラクティスを個別にドキュメントやナレッジベースとしてまとめています。当エントリではその中から、『LookML開発における"要素別のベスト・プラクティス"』についてご紹介したいと思います。
目次
命名規則
- 下記の「読み易さを考慮したフィールド名の設定」を参考。
- 集計関数、または一般的な用語を用いる形で「メジャー」項目に名前を付ける。
- 合計値：total_[FIELD]
- 件数：count_[FIELD]
- 平均値：avg_[FIELD]
- 名前の在り方を説明的にする。例えば「Orders Percent」(注文率)よりも「Orders Per Purchasing Customers」(顧客毎の注文数)の方がより明確です。
- Yes/Noを表すフィールドの場合はその状態を明確に表現。「返品」の場合であれば「Returned」よりも「Is Returned」です。
- Lookerはディメンション名の最後に各タイムフレームを名称として追加するため、ディメンショングループ名に"date"や"time"といった時制は含めないでください。created(作成)を例に取ると、Lookerでは「created_date」「created_time」というように「_date」や「_time」を付与するため、「created_date」のようなフィールド名は付けない...という形です。
プロジェクト組織
- 「接続」毎に1つのプロジェクト、という形を維持し、ビューを共有する場合は各プロジェクトに複数のモデルを保持するようにします。gitリポジトリと開発チームの間で、モデルとビューの両方を完全に分離する必要がある場合は、接続毎に複数のプロジェクトを用意します。
- モデル内のinclude:パラメータを確認し、不要な場合はモデルからビューを削除するか、ワイルドカードを使用するようにします。
- include
- 例えば、include: “user.view.lookml”またはinclude: “user.view”と記述することで、モデルに複数のユーザービュー(named user_order_facts, users, user_address...など)を含めることが出来ます。
- Markdown LookMLドキュメントを使って、それぞれのExploreに対しての質問に質問に応えられるような「ドキュメント」を作成しましょう。このドキュメントは各プロジェクト内で1つ以上作成出来ます。
モデル構築
- 高いレベルで、モデル全体を想定、設計しましょう。ユーザーが探索に用いるであろう主要なサブジェクト領域を想定し、それらに含まれるビューを定めます。通常であれば、最も詳細なレベルから「多対1」に結合することで、最高のクエリパフォーマンスが得られます。
- モデルファイル内で自動生成されたエクスプローラ(Explore)の中で無関係・不要な物がある場合は、対象のエクスプローラーをコメントアウト(#構文を使用)して、ディメンションテーブル開発時の混乱を減らすことが出来ます。必要に応じてコメントを解除することでいつでも再利用可能です。
- ユーザーが必要とする回答に簡単にアクセス出来るようにするために、可能な限りエクスプローラ(Explore)の数は少なくします。対象者毎に異なるモデルに分割することを検討してください。「最適なエクスプローラ(Explore)の数」は状況によって異なりますが、いずれにしても多数エクスプローラ(Explore)が存在しているとエンドユーザーの混乱の元となります。
- エンドユーザーが正しいエクスプローラ(Explore)を出来るだけ簡単に見つけられるように、複数のモデルをエクスプローラ(Explore)で整理します。
- 異なるモデルに対するアクセスフィルタフィールドを制限。LookMLを使い、1つのダッシュボードを複数のモデルで機能させます。(これは、ダッシュボード要素からモデルパラメータを削除する、ということを意味します)
エクスプローラ(Explore)設計
- フィールドピッカーでビューを表示する際にユーザーを混乱させないよう、エクスプローラ(Explore)における結合(join)を必要なものだけに制限しておきましょう。
- フィールドピッカーでディメンション、メジャー、及びフィルタの数を制限するため、各結合(join)またはエクスプローラ(Explore)レベルでfields:パラメータを使いましょう。
- description:を使い、それぞれのエクスプローラ(Explore)に「目的」と「対象者」を指定する短い説明文を追記しましょう。
- 必要な場合を除いて、1つのビュー(View)を多くのエクスプローラ(Explore)に結合させないでください。ビューの中に他のビューをスコープとするフィールドがあるとLookMLエラーが発生し、ビューを利用するエンドユーザーが混乱します。可能であればfields:パラメータを使ってこの制限を行ってください。これにより、幾つかのビュー拡張機能を使ってコアフィールドを繰り返し、特定のエクスプローラ(Explore)に固有のフィールドを追加する事が保証されます。
結合(Join)設計
- 読み易さとLookMLの柔軟性を高めるために、foreign_keyよりもsql_onを使うようにしましょう。ベースとなるビュー(View)を左に配置する形で結合(join)を記述して関係パラメータ(relationship parameter)と一致させることも、読み易さ向上に繋がります。
- 日付を参照するのでなければ、${}を使いましょう。日付を結合させる場合、結合述部でのcast/convert_tzを回避するために、raw sql(またはLooker 3.32以降で利用可能なtimeframe raw)を使用します。ただし、Lookerで宣言された連結主キーでの結合は避けてください。クエリを高速化させるために、テーブルのベースフィールドで結合するようにします。
- 正しい集約が生成されるように、必ずrelationship:パラメータを使って関係を定義してください。
- ハードコードされた複雑な結合述語をマップテーブル(PDT)に結合することで、高速な結合(join)を可能となります。
ビュー(View)設計
- ビュー(view)を作成する際は、エンドユーザーのことを考慮して命名し、親しみやすいデザインを心掛けてください。
- 正確性を確保するために、全てのビュー(view)で、「一意」を定義するフィールドにprimary_keyを宣言します。
- 利用者の混乱を避けるため、決して使われないことが分かっているディメンション(結合キーや結合ID、複合主キー、またはアプリケーション専用に設計された項目など)にはhidden:パラメータを使います。
- フィールドの内容を説明するために、description:パラメータを使います。一般的なデータベースの列名は、エンドユーザーにとって十分な説明とは言えません。
- description (for Fields)
- 例).description: ‘my great description’
- ビュー(view)内のメジャー項目のタイプ(types)を、一貫した方法でグルーピングします。これは文体的な手法ではありますが、他の人があなたの作成したモデル(Model)を読み解くのに役立ちます。
- 基本となるフィールド毎にグループ化(counts, sums, averages等)
- タイプごとの全てのメジャーのグループ化(counts together, sums together等)
- sets:パラメータを使って、フィールドのグループを整理します。これを使うことでエクスプローラ(Explore)からフィールドを簡単に削除出来、モデル(Model)のメンテナンス性が向上します。
- 不要な結合(例: user_count = count(distinct orders.user_id) )を回避するために、結合されたテーブルのメジャーの件数(count)をエクスプローラ(Explore)から外部キーのcount distinctに置き換えます。
- view_label 及び group_labelパラメータを使って、同じカテゴリに属する複数の結合ビューのディメンションとメジャーを統合します。
派生テーブル(PDT)の使用
- 誰かが最初にエクスプローラ(Explore)を使用する場合、またはスケジュールでデータを準備しておく必要がある場合は、persist_forでは無くsql_trigger_valueを選択します。
- sql_trigger_valueスケジュールの使用が、営業時間やレプリケーション(複製)プロセス、利用ピーク時間中にテーブルが構築されないように気を付けてください。稼働しているELTが完了する頃を見計らい、深夜または早朝にテーブルがトリガーされるように設定します。
- クエリのパフォーマンスを向上させるために、常にインデックス(indexes)、分散(distribution)、ソートキー(sortkeys)を定義します。
ダッシュボードの組織/設計
- フィールドにhtmlまたはlinksパラメータを使い、メジャーとディメンションからダッシュボード(または内部サイト)をリンクします。
- 『単一値の視覚化』は、高いレベルでのKPIを強調表示するのに効果的です。ダッシュボードの上部に配置することで上手く機能するでしょう。
まとめ
というわけで、Lookerにおける『LookML開発における"要素別のベスト・プラクティス"』のご紹介でした。
Lookerでは、LookMLを用いて作り上げる要素が数多く存在しています(というか殆ど全ての要素がコレですね)。既にここまでの歴史で、それら要素を作り上げる際の『コツ』がLookerの場合はノウハウとしてまとめられていますので、是非とも参考にしつつ上手く活用して行きたいものです。
![[レポート]AWSでデータメッシュアーキテクチャを構築する#ANT336 #reinvent](https://devio2023-media.developers.io/wp-content/uploads/2022/11/eyecatch_reinvent2022_session-report.png)
