Lookerで設定可能な「タイムゾーン」について整理・理解する #looker

Lookerでは、アプリケーションが稼働する・ユーザーが利用する上で考慮すべき「タイムゾーン」の概念が幾つか存在し、適切な処理を行わせる上では、それらのタイムゾーンの仕組みを把握しつつ、ユーザー側での利用状況を加味した設定を行っておく必要があります。当エントリではその辺りの情報を整理して、実際直面したユースケースで設定をどの様に行ったかについてまとめておきたいと思います。

目次

• 当エントリをまとめるきっかけ
• Lookerにおける「タイムゾーン」
• 参照DBの「データベースタイムゾーン」(Database Time Zone)
• 参照DBに発行するSQLの「クエリタイムゾーン」(Query Time Zone)
• Lookerホストの「システムタイムゾーン」(System Time Zone)
• Lookerの「アプリケーションタイムゾーン」(Application Time Zone)
• Looker利用ユーザーの「ユーザー指定タイムゾーン」(User Specific Time Zones)
• Lookerユーザーがスケジュール設定を行う時に用いる「スケジュールタイムゾーン」(Schedule Time Zone)
• Lookerのモデルに指定可能な「convert_tz」LookMLパラメータ
• Lookerのモデルに指定可能な「sql」LookMLパラメータ
• まとめるとこうなる
• 実際のユースケースに当てはめてみた
• まとめ

　

当エントリをまとめるきっかけ

きっかけは、Lookerで作成したダッシュボードを「スケジュール配信」させようと思った際に『正しくタイムゾーン設定を行っているつもりだったのだが、実際は意図していた形で設定されている状況では無かった』というものでした。

　

Lookerにおける「タイムゾーン」

情報を整理しつつ、またLookerにおける「タイムゾーン」の概念を調べていくと、実に様々な設定項目があることが分かりました。内容については以下のドキュメントにそれぞれまとめられています。

以下、それぞれの「タイムゾーン」について見ていきます。

　

参照DBの「データベースタイムゾーン」(Database Time Zone)

Lookerインスタンスが利用しているDB接続(Connection)がアクセスしている接続先データベース環境そのもののタイムゾーン設定部分。ここについてはLookerインスタンスで制御出来るものでは無く、実際に稼働しているデータベースの設定に基づいて、Looker側の設定を合わせておく必要があります。

　

参照DBに発行するSQLの「クエリタイムゾーン」(Query Time Zone)

Lookerの「General Settings」でユーザー指定のタイムゾーン(User Specific Time Zone)」設定を無効にしていると設定出来る項目。クエリ時に日付と時刻を表示するタイムゾーンを決定します。こちらも、データベース由来のものとなるので「そのデータベースで得られた結果をどうしたいか」によって変えるべき設定と言えます。

上記「データベースタイムゾーン」(Database Time Zone)とこの「クエリタイムゾーン」(Query Time Zone)については、下記エントリでまとめていますので合わせてご参照頂けますと幸いです。

　

Lookerホストの「システムタイムゾーン」(System Time Zone)

Lookerを実行しているサーバーが構成されているタイムゾーン。

このタイムゾーンはLookerアプリケーションで制御出来るものでは無く、Lookerがホストするインスタンスの場合、システムのタイムゾーンは「常にUTC固定」となります。

　

Lookerの「アプリケーションタイムゾーン」(Application Time Zone)

Lookerインスタンス全体に掛かる形になるタイムゾーン設定。この設定を切り替えた後に新しく設定される「スケジュール配信設定」(※後述)は、デフォルトでこの「アプリケーションタイムゾーン設定」に倣う形となります。

ユーザー固有のタイムゾーンオプションを有効にすると、アプリケーションのタイムゾーン値がアカウントに設定されていないユーザーのデフォルトのタイムゾーンがアプリケーションのタイムゾーンになります。

　

Looker利用ユーザーの「ユーザー指定タイムゾーン」(User Specific Time Zones)

ユーザーが個別に指定出来るタイムゾーン指定。クエリ実行時に都度指定可能です。

この設定を有効にするには、管理者設定で「User Specific Time Zone」を有効(Enabled)にする必要があります。

ユーザー毎のアカウント設定から、

個別のタイムゾーン設定デフォルト値を指定出来るようになります。

また、Lookやダッシュボードにおけるクエリ実行時にも、適宜タイムゾーンを指定出来るようにもなります。

　

Lookerユーザーがスケジュール設定を行う時に用いる「スケジュールタイムゾーン」(Schedule Time Zone)

Lookやダッシュボードをスケジュールの設定で配信(Send)する時に設定出来る項目。

基本的にはアプリケーションのタイムゾーンでデフォルト設定されていますが、スケジュール設定時に個別の設定を行う事も可能となっています。

　

Lookerのモデルに指定可能な「convert_tz」LookMLパラメータ

Lookerでは、クエリ実行時にデフォルトでタイムゾーン変換を行います。この挙動を無効化するには、ビュー(*.view)のフィールド設定にconvert_tz: noの設定を追加することで対応出来ます。

• convert_tz

  dimension_group: post {
    label: "投稿日"
    type: time
    timeframes: [
      raw,
      time,
      time_of_day,
      hour,
      hour_of_day,
      date,
      week,
      day_of_week,
      month,
      month_num,
      month_name,
      day_of_month,
      quarter,
      quarter_of_year,
      fiscal_quarter,
      year
    ]
    sql: ${TABLE}.post_date ;;
    ## ブログ投稿データはRedshiftで既に日本時間に変換済なので、
    ## Looker上でのタイムゾーン変換は不要.
    convert_tz: no
  }

　

Lookerのモデルに指定可能な「sql」LookMLパラメータ

対応しているデータベースであれば、LookMLパラメータのsqlにデータベース言語の関数を使用してタイムゾーン変換を手動で定義する事も可能です。(下記はMySQLでのタイムゾーン変換定義例)

• sql (for Fields)

dimension: created {
 type: time
 timeframes: [time, date]
 sql: CONVERT_TZ(${TABLE}.created_at,'UTC','PST')
}

　

まとめるとこうなる

上記ポイントを一枚絵に整理し、まとめてみたのが以下の内容。

　

実際のユースケースに当てはめてみた

そして、実際のユースケースを元に「あって欲しい状況」と「状況を実現するための各種設定」を定めた内容が以下。「データベースの状況」がまずあって、その次に「アプリケーションでどう活用したいか」を定め、それらをひっくるめて実現する設定を検討・調整していく...という流れが良いのかな、と思います。

今回はケースの考慮対象外となりましたが、ここに「異なるタイムゾーンから、そのLookerインスタンスを利用する人が居る」という場合、"ユーザー指定タイムゾーンを有効にして、利用者毎にタイムゾーンを変える"、"スケジュール配信はタイムゾーン毎に作り分けて運用する"などの考慮が必要になってくるのではないでしょうか。

　

まとめ

という訳で、Lookerでの「タイムゾーン」設定に関する情報のまとめでした。

調査・まとめの過程では「タイムゾーンの設定ポイント、多いなぁ...」と思ってたのですが、Lookerが複数のデータベースに対応し、また異なるタイムゾーンから利用され得るケースを想定していることを考えると、この設定ポイントの多さはあらゆる局面に柔軟に対応するためのLookerなりの「対応方法」を提示しているのかな、と思うようになりました。

Lookerをご利用の皆様におかれましては、実際に利用する状況を整理頂き、それに合わせて適切な設定を行って活用頂けますと幸いです。

• Looker ｜ 特集カテゴリー ｜ Developers.IO