本記事は、Use Refinements to add Period over Period functionality to existing explores の翻訳になります。
この例では、よくご要望としていただく 期間比較 (Period Over Period) 機能を Refinements を使用して実装する方法をご紹介しております。
| 一般的なRefinements利用の背景 | 期間比較(Period over Period)の背景 |
|---|---|
refinementsを利用することで、主要なロジックと機能を実現するロジックをそれぞれ完全に分離することができ、しかも同時に対象となる元オブジェクトに対して機能を追加することができます。例えば、ここでご紹介するパターンを使って、元のコアオブジェクトには手を入れずに、既存のExploreの日付フィールドにPoP機能をシームレスに追加することができます。 これについての詳細はこちらの the lookml refinements doc page をご覧いただくか、Fabioの記事をご覧ください。（訳註：Fabioの記事には翻訳記事がございます） |
PoPはよくご要望として上がる機能で、いくつかのやり方があります。例えばこちら (Flexible Period-over-period Analysis) やこちら(An Explore filter based approach) の記事でも他のやり方がご紹介されています。 本記事でご紹介する方法は実装がシンプルで、またExploreに変更が入ったとしても特別なメンテナンスが不要です。ユーザーにとっては過度な複雑さを避けた柔軟な方法となります。 |
期間比較 (Period Over Period) の見た目はどのようになりますか？
ユーザーは新しく作成したディメンションをピボットすることができ、また期間の長さと表示する数を選択することができます。
パラメータの入力例など他の2つの例をご覧になる場合はこちらをExpandしてください。
このアプローチの利点
いくつかあるPoPのバリエーションのほとんど全てをカバーできます：
- 複数の期間を選択できる
- 期間の単位（年／期／月など）を選択できる
- 異なる日付フィールドに基づくPoPなど、複数のバリエーションにも対応可能（同じExplore内でも可）
さらにこの方法には次の利点があります：
- 新しいExploreを作ったり、多くの新しいフィールドを作成する必要がなく、既存のExploreおよびreportの上にレイヤーとして追加することができます。既存のドリルなどに影響を及ぼしません。
- 非常にシンプルかつメンテナンスが容易で、スケールしやすくなります。新しいフィールドが追加される場合でも、派生テーブルのSQLを変更する必要がありませんし、PoPが動作するメジャーは再定義する必要がありません。
- ユーザーは直感的に操作できます。
- Lookerで自動生成される日付関数シンタックスを使用するため、他の方法で必要になる可能性のあるデータベース依存の構文変更を回避できるはずです。
Period Over Periodアプローチのコンセプトの説明
まず前提として、ユーザーが比較したい期間のサイズ（単位）と期間がわかっていると仮定します。その上で、以下の操作を行います：
- （コンセプトとしては）オリジナルのデータセットの複製を作ります。それぞれの期間に対して一つずつ必要です。
- 複製したデータを、期間と単位でオフセットします（ずらします）。
結果：それぞれの「前の」期間のデータが、現在の期間のデータに対して正しくマップされます。
これらのステップが完了すると、Explore上の他のすべての要素も問題なく動作し、PoPが適用された場合でも正常に動作します。なぜなら、ファンアウト（訳註：テーブルのJOINによって行が増えてしまう現象）する期間は自然と対応するピボット列に含まれるようになるため、結果セットはいずれにしても全く影響を受けないからです。他の項目は以前と同様にグループ化され、計算されます。
このステップを図示すると以下のようなイメージになります：
SQLまたはクエリーベースでのステップは以下のようになります：
- pop_support ビューをJOINします
- それぞれ選択された期間に対して1行、複製が有効になります
- Refinementされた日付フィールド＝元の日付フィールド_date + ( [pop_support.number_periods_ago] * [選択された期間の長さ] )
-
日付フィールドの**${EXTENDED}**キーワード（元のSQL）に日付オフセット関数をラップすることで実現されます。
実際の実装ステップ
準備）新しいファイルにPoP Support LookMLのコードをペーストしてください。
注）これは任意の数のPoP対応フィールドで再利用できる汎用コードです。
Period over Period Support LookML
Step1) 汎用のpop_supportを追加したいExploreのJOINにペーストします
Step2) 基準日フィールドを持つ基底ビューをRefinementsします
以下のRefinementsテンプレートをペーストして、いくつかの参照を修正します。（既存のView名及び日付フィールド名称と一致させる）その後、準備しておいたPoP機能のロジックを既存の日付フィールドに適用します。
Refinements テンプレート
まとめ）特定のファイル名に基づいて、includesステートメントが必要に応じて更新されることを検証および確認します。
既知の問題
-
基準日フィールドのSQLにダブルクォーテーション(“)が含まれている場合、これはLiquidベースの数式の構築に影響を与える可能性があります。ほとんどのダイアレクトでは、引用符の代わりに[]を使用するか、予約文字なしで物理列の名前を変更することにより、ダブルクォーテーションを回避できます。 -
以前のバージョンでは、datatype：dateとともに「${pop_support.now_converted_to_date_with_tz_sql::date}」を使用していましたが、特定のダイアレクトと基本データ型でデータ型エラーが発生しました。 よって、「${pop_support.now_converted_to_date_with_tz_sql::datetime}」とdatatype:datetimeを使用するようにコードを更新しました。他のダイアレクトまたは他の生のデータ型が「${pop_support.now_converted_to_date_with_tz_sql::date}」に戻す必要がある場合に備えて、ここに付記しております。 -
(訳註：いくつかのダイアレクトでは、datetime を unknown に設定する必要がある場合があります)
その他追加の複雑さ及び考慮事項
-
このプロセスでは、まだ到来していない「将来の期間から見た過去データ」が表示されます。技術的には正確な表現ですが、ユーザーにとってはわかりにくい可能性があります。これをサポートするために、オプションのalways_filterまたはその他のフィルターを適用することを選択できます。 -
正しいグループ化を維持できるよう、日付操作の前にタイムゾーン変換を行う必要があるため、lookerにconvert_tz：yesを実行させるのではなく、liquidを使用してタイムゾーン変換を適用します。これにより、Refinementsのロジックが複雑になり、タイムゾーン変換を使用しない場合は削除できる可能性がありますが、害はありません。 -
PoP機能は追加の日付フィールドにも適用できることがありますが、しかしながら作成すPoP ピボットディメンションの名前が競合しないように注意する必要があります
-
データベース構文の違いに注意してください... looker式を使用して、lookerに組み込まれているダイアレクト固有の日付関数の処理を活用していますが、一部のダイアレクトには、ファンアウト結合に関する課題など、まだ特定されていない他の制限がある場合があります（代わりにtype：crossを試す、など）。
おわりに
このパターンが、基本コードを複雑にしたり、PoP専用の新しいExploreを追加したりすることなく、チームが期間比較の機能をすばやく実装するのに役立つことを願っています。さらに、これにより、コードの編成と機能管理を改善するための改良を使用するように促されることを願っています。このPoPアプローチやRefinementsを実際に使ってみてフィードバックがありましたらお知らせください。