Lookerベスト・プラクティス:持続・保守可能なLookMLの作成術 #looker
Lookerではトピック毎のベストプラクティスを個別にドキュメントやナレッジベースとしてまとめています。当エントリではその中から、『持続・保守可能なLookMLの作成術』についてご紹介したいと思います。
目次
文字列置換演算子($)
全てのLookMLファイルで文字列置換演算子($)を使いましょう。LookMLモデルには、物理データモデル内のオブジェクトへの単一の参照ポイントのみが必要です。後続の定義でオブジェクトを参照する必要が出てきた場合は、既に定義されているLookMLオブジェクトを参照して使いましょう。
${TABLE}.field_nameの使用
- ${TABLE}.field_nameは、元になるデータベースの列から直接データを引っ張ってくる全てのベースディメンションに対して、元となるデータベーステーブルを参照するときに利用出来ます。スキーマまたはテーブル名が変更された場合、この値を使っていれば開発者はsql_table_nameというパラメータのスキーマ名またはテーブル名を更新することでその変更に追従し、コードに反映させることが出来ます。
${field_name}の使用
- ${field_name}は、LookML内で既に定義されているディメンションまたはメジャーを参照する場合に利用出来ます。列名が変更された場合、その変更はベースディメンションまたはメジャーのsqlパラメータでのみ更新する必要があります。その変更は列を参照する他の全てのフィールドに自動的に伝播します。
- 例えば、データベース列名がusersidからusers_idに変更された場合、Looker内で参照を変更する必要が出てきますが、${field_name}を使うことでその対応が1行だけで済むようになります。
実践例
複数のディメンションとメジャーが${TABLE}.field_nameで既存のLookMLフィールドを参照する場合、多くの変更が必要となります。
dimension: usersid { type: number sql: ${TABLE}.usersid ;; # Change here } measure: this_week_count { type: count_distinct sql: ${TABLE}.usersid ;; # Change here filters: { field: created_date value: "7 days" } } measure: this_month_count { type: count_distinct sql: ${TABLE}.usersid ;; # Change here filters: { field: created_date value: "1 month" } }
$ {field_name}参照を利用すると、変更は1箇所だけで済みます。
dimension: usersid { type: number sql: ${TABLE}.usersid ;; # Change here } measure: this_week_count { type: count_distinct sql: ${usersid} ;; #Using ${field_name} to reference the LookML field `usersid` filters: { field: created_date value: "7 days" } } measure: this_month_count { type: count_distinct sql: ${usersid} ;; #Using ${field_name} to reference the LookML field `usersid` filters: { field: created_date value: "1 month" } }
文字列置換演算子($)のその他の用途については、下記ドキュメントをご参照ください。
セット(Set)の利用
モデル(Model)内で再利用可能なフィールドの一覧を維持するために、セット(Set)パラメータを使いましょう。
繰り返されるフィールドのリストは、フィールドリストを更新したり、フィールド参照を変更したりできるモデル内の単一の場所を作成するために、fieldsパラメーターを介して、またはドリルフィールド内のセット(Set)に順番に組み込んでいく必要があります。セット(Set)の詳細については以下ドキュメントをご参照ください。
コードの繰り返しを避ける
LookMLオブジェクトを"ビルディングブロック"と考え、extendsパラメータを使ってコードを使わずに様々な方法でオブジェクトを結合する手法を検討しましょう。
"コードの再利用"に関する詳細情報は以下ドキュメントにも記載がありますのでご参考ください。
- Reusing Code with Extends
- extends (for Explores)
- extends (for Views)
- Using extensions to define joins - LookML / Modeling - Looker Community
複数の場所でコードの繰り返しを避けることにより、エクスプローラ(Explore)全体で一貫性を保持出来ます。これを達成する方法は以下にも紹介されていますので是非ご参考にしてください。
マップレイヤーや値形式などのアイテムを統合する
Lookerにおけるプロジェクトファイルのドキュメントに従って作成し、必要に応じてモデル全体に含めることの出来るmap_layers.lkmlというLookMLのファイルを使い、マップレイヤーを一元的に定義することが出来ます。
また、データファイルをLookMLプロジェクトにドラッグアンドドロップしてJSONファイルをリポジトリに直接追加し、モデル内で参照させることも可能です。
例えば、このマップレイヤーファイルは、include: "map_layers.base.lkml"という形で利用することでプロジェクトの任意のモデルに含めることが出来ます。
カスタム値形式をモデル内で一元的に設定するために、named_value_formatパラメータを使用してモデル内のカスタム形式を設定し、ディメンションとメジャーでvalue_format_nameパラメータを使用してそれらを参照します。
開発ガイドラインを作成する
LookMLモデルの開発とスケーリングを容易にするために、『開発ガイドライン』を定義しましょう。サンプル開発ガイドラインリストのウォークスルーについては、下記ドキュメントをご参照ください。
一般的なガイドラインには、以下のようなものが含まれます。
- LookMLを明確に整理。これにより一貫性が保たれ、操作が簡単になります。
- ビュー(view)とモデル(model)全体でコメントを利用。記述されたLookMLにコンテキストが追加されます。
- Markdownファイルを使用し、Looker内でドキュメントを作成。
まとめ
というわけで、Lookerにおける『持続・保守可能なLookMLの作成術』のご紹介でした。
Lookerでは基本的に『LookMLを使ってあらゆる要素を構築・設定する』流れとなりますので、こういったテクニックも非常に有用且つ必須なものとなります。別途参照されていた『開発ガイドライン』の策定も非常に有効・効果的な手段となりうるので別途その内容についてもご紹介していきたいと思います。