コラム

Lookerにまつわるあれこれ

  • 73 Topics
  • 8 Replies

73 Topics

不要なコンテンツやフィールドを特定してLookerインスタンスをクリーンに保つ

※ 本投稿は Looker Advent Caledar 2022 初日の記事となります!みなさん年末の大掃除はお済みでしょうか。まだ在宅勤務中心の方も多いかもしれませんが、一般に脳は秩序を好むため、物が多く散らかった環境だと集中力が落ちる等の悪影響があるということが研究結果でも示されているそうです。Looker も同じです。Looker を長らく使っていただいていると、もう久しく見ていないダッシュボードや Explore、あるいはディメンションやメジャーが大量にあったりしませんでしょうか。あるいは LookML のコードが肥大化してよく分からない JOIN が蔓延していませんでしょうか。そういった状況はアナリストの分析作業に悪影響があるだけでなく、システム的にも余計な負荷がかかって思わぬパフォーマンストラブルを引き起こしてしまう可能性があります。 Looker にはそういった不要なコンテンツやフィールド・join を特定したり、パフォーマンス問題に繋がる箇所を見つけたりするための仕組みがいくつかありますので以下で紹介する方法を試して自身の Looker インスタンスをすっきり保つようにしましょう。 Content Activity ダッシュボード 管理 > コンテンツアクティビティ からご利用いただける Content Activity ダッシュボードを使うと、お使いの Looker インスタンスに作成されている各種コンテンツ (ダッシュボードや Explore) の利用状況を確認することができます。 Unused Content タイル 直近30日以内に参照されていない各種コンテンツ (ダッシュボード、Look、ボード) がリストされます。Content Title から直接該当のコンテンツを開くこともできるので、確認して不要と見なせるものは削除してしまいましょう。[ここから探索] でフィルタ条件を変更し、例えば1年以上アクセスがないようなものは削除してしまうような運用にしても良いでしょう。   Unused Explores タイル 直近30日以内にクエリが実行されていない Explore がリストされます。これも同様に [ここから探索] で条件を調整し、不要と見なせるものは断捨離しましょう。まずは LookML コード内で hidden にし、特にユー

【新機能】Performance Recommendations dashboardと Query Performance Metrics Exploreについて

日本語で情報が少ないトピックの記事を翻訳しています。今回はLookerバージョン22.16からGA機能となったPerformance Recommendations dashboardと Query Query Performance Metrics Exploreについて紹介します。パフォーマンスに問題のあるExploreやDashboardを特定して対策を検討することができます。この記事はこちらの英語バージョンの日本語訳です。元の記事の最終情報更新日時:2022年 9月 23日 LookerのSystem Activity dashboardsのシリーズの中に新たにPerformance Recommendations dashboardが追加されました。これまで提供されていたユーザー活動状況やコンテンツ使用状況、インスタンスの性能などに加えて、パフォーマンスを改善するための実用的な推奨事項を提供し、詳細なクエリパフォーマンスのデータにアクセスできるようになります。 Performance Recommendations dashboardでダッシュボードでできること:Lookerのベストプラクティスに沿って、コンテンツのパフォーマンスを向上させる ユーザーのパフォーマンスを低下させているクエリのボトルネックを特定する パフォーマンス問題の重大度に基づいて作業に優先順位を付ける ダッシュボードとExploreのパフォーマンスを最適化する方法について学ぶPerformance Recommendations dashboard: Performance Recommendations dashboardには 2つのタイルがあります。1つはDashboard Recommendations (ダッシュボードに関する推奨事項)で、もう 1 つは Explore Recommendations(Exploreに関する推奨事項)です。それぞれで何ができるか解説します。Dashboard Recommendations のタイルは、Looker パフォーマンスのベストプラクティスと一致しないダッシュボードを特定することに重点を置いており、各ダッシュボードは問題の重大度に基づいてランク付けされています。ここに表示される主な警告は次のとおりです。ダッシュボードのauto-ref

PDTのリーパープロセスについて

日本語で情報が少ないトピックの記事を翻訳しています。今回はLookerで古いPDTをスクラッチスキーマから削除するリーパーというプロセスについて紹介します。この記事はこちらの英語バージョンの日本語訳です。元の記事の最終情報更新日時:2019 年 12月 12日 リーパーの役割:リーパーの役割は、非アクティブな PDTをDBのスクラッチスキーマから削除することです。 動作スケジュール:リジェネレーターとは異なり、すべてのConnectionに対して合計 1 つのリーパースレッドしかありません。 クラスターインスタンスの場合、リーパースレッドはマスターノードで動作します。接続設定のPDT And Datagroup Maintenance Scheduleセクションで設定されたcronに対して、最頻で 1 時間ごとに動作します。 プロセス:LookerはLookerのinternal DBのactive_derived_tablesテーブルを使用して、どのテーブルをスクラッチスキーマからdropするべきか判断します。リーパーはテーブルを実際にdropする前に、まずactive_derived_tablesテーブルを更新します。  active_derived_tablesテーブルを更新する リーパーはまず初めに、本番環境で構築された LookMLで使用されているすべての派生テーブルのリストを取得し、そのリストになかったテーブルのレコードをactive_derived_tablesテーブルから削除します。 次にリーパーは現在スクラッチスキーマに存在するすべてのテーブルのリストを取得し、そのリストになかったテーブルのレコードをactive_derived_tablesテーブルから削除します。 次にリーパーは、 persist_forで永続化されている PDTのうち有効期限切れになったPDTのレコードを、active_derived_tablesテーブルから削除します。 上記のステップが終わると、active_derived_tablesテーブルは、スクラッチスキーマに存在するアクティブなテーブルを反映した状態になります。 更新された状態のactive_derived_tablesテーブルは、スクラッチスキーマ上に存在する全てのアク

PDTのリジェネレータープロセスについて

日本語で情報が少ないトピックの記事を翻訳しています。今回はLookerでPDTの構築を管理しているリジェネレーターというプロセスについて紹介します。この記事はこちらの英語バージョンの日本語訳です。元の記事の最終情報更新日時:2020 年 11 月 4 日  リジェネレーターの役割:リジェネレーターの役割は、スクラッチスキーマでの PDT の構築を管理することです。主には、datagroupのtriggerをチェックし、本番環境にプッシュされた新しい PDT を構築し、トリガー値が更新された既存の本番環境の PDT を再構築します。 リジェネレーターのスレッド数:それぞれのConnectionに対して リジェネレータースレッドは1つあります。リジェネレーターは 1 つのスレッドのみであるため、一度に 1 つの操作しか実行できません。つまり、一度に 1 つのトリガーのみをチェックしたり、1 つの PDTのみをビルド/再ビルドしたりできるということです。(ConnectionのMax PDT Builder Connections設定でParallel  PDT が有効になっている場合は一度に複数の PDT をビルドできます) インスタンス全体では最大 25 個のリジェネレータースレッドが使用できますが、Connectionごとに 1 つのスレッドしか使用できません。つまり、Lookerの インスタンスに 25 の異なるデータベースが接続されている場合にのみ、理論的には 25 の PDT を同時に構築できることを意味します。インスタンスで PDT が有効になっているConnectionが 25 を超える場合、複数のConnectionが同じリジェネレータースレッドを共有します。 Regeneratorの実行スケジュール: リジェネレーターは、接続設定のPDT And Datagroup Maintenance Scheduleセクションで設定されたスケジュールで実行されます。デフォルト値の実行間隔は5分です。このスケジュールはcron式を使用して設定されます。デフォルトcron 式は、一連の時間を表す空白で区切られた 5 つまたは 6 つのフィールドで構成される文字列です。 cron 式の詳細については、こちらを参照してください。注意: リジェネレーターの最頻の実行間隔は

Custom ActionでCSV(ZIP)ファイルをSJISで送信

※ 本投稿はLooker Advent Caledar 2021 7日目の記事となります。Lookerから出力/送信されるCSVファイルは他システムで利用されることを考慮して、UTF8でエンコーディングされるようになっています。しかしながら、Microsoft ExcelはUTF8でエンコーディングされたCSVファイルをそのまま開くと文字化けしてしまうため、テキストエディタで開いて、エンコードを変更するか、Excelでファイルを開くメニューから順にウィザードに従って処理をする必要があります。CSVファイルがExcelに関連づけられていたりすると、ダブルクリックするとExcelが開いてしまってということで、CSVという形式に馴染みのない方もいらっしゃるのかもしれません。 そこで、今回は、Lookerが提供しているActionを利用して、Lookerから出力されるCSV形式のファイルをShift_JISやBOM付きCSVファイルに変換してメール送信してみたいと思います。今回の開発に際しての前提条件:Typescript/Javascriptをかけること NodeJSを起動できる環境をお持ちであること Yarnがインストールされていること SendGridのアカウントがあることそれでは、早速始めていきましょう。Custom Action Hubの開発まずは、ローカルの開発環境にCustom Action Hub Exampleのソースをクローンします。次に、ZIPファイルを圧縮/解凍するライブラリと文字コード変換を行ってくれるライブラリを追加します。yarn iconv-lite adm-zip @sendgrid/helpers @sendgrid/mailiconv-lite adm-zip @sendgrid/mail @sendgrid/helpersCustom Actionのコードを記載していきます。必要なライブラリのimportなどimport * as Hub from "looker-action-hub/lib/hub"import * as helpers from "@sendgrid/helpers"const AdmZip = require('adm-zip')const iconv = require('iconv-lite')const

Chrome Extension から Looker APIを読んだ際に色々分かったことを共有します。

 Chrome ExtensionからLookerのAPIを使ってなにか出来ないかと思い、実装してみました。その段階で、調べて分かったこと、今の所ここまでしか出来ないといったところを共有したいと思います。APIの基本的な処理の流れは以下になります。1.Client_ID/Client_Secretを使って認証を行います。Client_ID/Client_Secretの取得はここから取得します。このClient_IDとClient_Secretを利用します。 例:https://xxxxxx.looker.com/api/4.0/login&client_id=xxxxxxxx&client_secret=xxxxxxx2.そうするとaccess_tokenが発行されますのでそれを使って今後操作をしていくことになります。3.Access_Tokenをつかっての操作はこんな感じです。例:https://xxxxxx.looker.com/api/4.0/queries/models/thelook-model/views/order_items/run/json?fields=order_items.total_revenue&access_token=xxxxxxxxxxxxxxxxxxxxxx&f[products.brand]=filter用の検索ワードqueries以下は操作に寄って色々変わりますが、&access_token=xxxxxxxxxxxxxxxxxxxxxxは必ずどの操作でも必要となります。APIのリファレンスはここになります。 次にChrome Extensionの話です。ミニマムなファイル構成はmanifest.jsonmain.js(名前は何でも良い、manifest.jsonの中で呼び出す名称と一致していれば良いです。)Chrome Extension の開発はこの開発モードで行います。デベロッパーモードをオンにするとパッケージ化されていない機能拡張を読み込むオプションが利用できるようになるので、上記のmanifest.jsonなどがあるフォルダを指定することで作成中の新しい機能拡張が利用できるようになります。 開発が終了したらパッケージ化してGoogleの審査を通るとようやく一般に開放できることとな

Cloud Functionsを使用してLookerで実行したクエリの結果をBigQueryにロードする

※ 本投稿はLooker Advent Calendar 2021 18日目の記事となります。※ 英語版もご覧になります こんにちは! Lookerで実行したクエリの結果を取得して、BigQueryのテーブルにロードする、Google Cloud Function向けのコードを書いてみました。Looker Python SDKとBigQueryのPython clientを利用しています。このワークフローは、Cloud Workflow を使って cron ジョブで自動実行するように設定することができます。 コードサンプルはこちら    使用例 System Activityのデータを取得する:現在のLookerの仕様上、System ActivityのLookMLはユーザーからは編集できません。このワークフローを利用して、System Activityのデータに対して実行したクエリの結果を取得し、直接BigQueryにロードすることができます。そのBigQueryのテーブルをLookerのコネクションとして登録すれば、LookMLのデータモデリングを追加してユーザーが自由に編集できるSystem Activityのデータモデルを作成することができます。(現在、Lookerのシステムアクティビティには最大100,000行または過去90日分のクエリ履歴とeventデータが保存されています。)   別のDBからBigQueryへのデータ転送 : 他のDBデータからのデータをLookerで実行したクエリの結果を取得して、BigQueryのテーブルにロード  注意事項  Google Cloud Functionは簡単に設定でき、軽い処理の実行に適しています。重い処理を実行する場合は、LookerのネイティブActions(Google Cloud Storage、 S3への送信)や、追加でETL/ELTツール(GCPのDataflowなど)を利用することを検討してください。 System Activityのパフォーマンス等に柔軟性を持たせるために、Elite System Activityの利用の検討をお勧めします。 ご質問等がございましたらぜひコメントください!

Legacyダッシュボードから新しいダッシュボード表示への移行について

LookerではLegacy表示のダッシュボードから新しいダッシュボードの表示に徐々に移行しようとしています。その一環として、先日リリースされたLooker 21.20では、ダッシュボードとLegacyダッシュボードのURLルーティングに変更を加えています。  Dashboard タイプ Lookerバージョン21.18以前のURL Lookerバージョン21.20以降のURL 新しい表示のダッシュボード  https://instance.looker.com/dashboards-next/1 https://instance.looker.com/dashboards/1 Legacy ダッシュボード https://instance.looker.com/dashboards/1 https://instance.looker.com/dashboards-legacy/1   この変更により、既存のダッシュボードへのリンクやブックマークが壊れることはありません。 dashboards-next/を使ったリンクやブックマークは、自動的にdashboards/にリダイレクトされます。dashboards/へのリンクやブックマークは、Legacyダッシュボードではなく、新しいダッシュボードの表示へ遷移します。 Lookerインスタンス内でLegacyダッシュボードにrevertされていないダッシュボードは、デフォルトで新しいダッシュボードの表示になります。  Lookerをバージョン7.18 (2020年10月)以降に導入した場合 ユーザ定義ダッシュボードについては、お客様のインスタンスはすでに新しいダッシュボード表示がデフォルトとなっており、ダッシュボードはユーザが作成したとおりに表示されます。Looker 21.20以前のLegacyダッシュボードは、Looker 21.20以降もLegacyダッシュボード表示のままです。LookMLダッシュボードおよびAPI経由で作成されたダッシュボードについて、preferred_viewerパラメータが設定されていない場合は、新しいダッシュボード表示にアップグレードされます。L

新しいランタイムAragoniteについて

Lookerバージョン21.20にて、Lookerの新しいランタイムAragoniteのbeta版がリリースされました。製品発足当初から使用されていたサブシステムを大幅に変更したもので、今までのLookMLのランタイムと比べて、大規模で複雑なモデル(例:ネストされたNDT)やLookerがクエリを並行で準備・実行する際などのパフォーマンス問題の改善が期待されます。具体的には下記のシーンでのパフォーマンス改善が期待されます。 Exploreやdashboardでのメタデータローディング LookML validation、content validation SQL生成 Project内に大量のコンテンツがありLookMLのValidation実行に毎回時間がかかるケースなどで有効そうですね! 使用方法 Admin > Labs feature> LookML New Runtime(Aragonite)を有効にした上で、projectのmanifest fileに”aragonite: yes” を記載してファイルを保存すると、project内でaragoniteランタイムが有効になります。"aragonite: yes" を削除またはコメントアウトすると、aragoniteランタイムは無効になります。 今までのランタイムでサポートされているLookMLと互換性がありますので、既存のコードに変更を加えずそのままご利用いただけます。詳しくはこちらをご覧ください。  注意バージョン21.20現在、aragoniteは現在ベータ版での提供となりますので、バグなどが含まれている可能性があります。manifestファイルに”aragonite:yes”を記載して今までのランタイムで発生しなかったエラーが出現した場合は、aragoniteのバグの可能性があります。バグが修正されるまで”aragonite:yes”をコメントアウトして通常のランタイムをご利用ください。

ラーニングアセット「Looker Connect」のご紹介 - Viewer/Explore ユーザー向け

※ 本投稿はLooker Advent Calendar 2021 9日目の記事となります。 Looker Connectのご紹介Looker Connectは、セルフラーニングでLookerのスキルを習得できるプラットフォームです。Looker上の役割別(Viewer/Explore/Developer/Admin)に教材が用意されていて、必要なスキルを体系的に学ぶことが可能です。動画学習、ナレッジチェック、テスト環境での練習を無料で行うことができますので、社内の利用促進にぜひご活用ください。 *本稿では、Viewer/Exploreにフォーカスしてラーニングアセットをご紹介いたします 事前準備アカウントの作成 Create Accountをクリック 必須情報を入力しアカウントを作成 ステップ2で入力したメールアドレスとパスワードでSign in Looker上での役割を以下の4つから選択(1) 分析、レポートを作成される方は「I analyze and report data」を選択(2) 共有を受けたデータを元に業務を行われる方は「I receive and act on data」を選択(3) Lookerデベロッパーの方は「I’m a developer」を選択(4) Lookerの管理者のかたは「I’m administer a Looker instance」を選択 Get startedをクリックするとラーニングモジュールページにたどり着きます スキルアップされたいエリアを確認した上で、学びたいレッスンを選択し学習を開始してください    翻訳方法現在、Looker Connect上のほとんどのコンテンツが英語のため、日本語で学習する場合は以下のような方法で翻訳することをお勧めしております。本稿で紹介する方法で翻訳される場合は、特別なツールや拡張機能をインストールする必要はございません。少々読み難い所があるかもしれませんが、ぜひお試しください。 ページ全体の翻訳方法 翻訳したいページ上で右クリック 「Translate to 日本語」を選択 ステップ2を完了すると以下のようにページが日本語化されます   *ブラウザは、Google Chromeをご利用になられていることを想定しております。**翻訳機能がうまく動作せずご不明

Lookerのパフォーマンスの問題を解決したい!原因別解決方法

Lookerが重い・・・と思ったらまずは原因を調査しましょう!Lookerでのパフォーマンス問題の原因は主に4つに分類されます。発生している事象によって原因が異なるので、どれに当てはまるか順番に見ていくのがおすすめです。↓ 1. データベースの負荷 LookerはDBにクエリを投げ、実際にクエリを処理するのはDBです。Lookerは、DBから帰ってきた結果を表示します。Dashboad/Look/Exploreの画面自体は開けるけれど、なかなか結果が表示されない場合は、DB側での処理に時間がかかっている場合が多いです。 事象: Lookやdashboardのページは表示されているが、tileやvisualization部分が長い間loadingしている 特定のクエリの実行に時間がかかっているが、Lookerインスタンス内の他のページはスムーズに開く  原因:Lookerから接続しているDBへ負荷をかけ過ぎているのが原因です。特に、複数のクエリを同時に実行している場合は、クエリが実行待ちのキューに入ったりしてさらに時間がかかることがあります。System ActivityのDatabase Performance dashboardを使用して、クエリの数や時間がかかっているクエリを確認することができるので、ぜひ活用してみて下さい。また、Admin>Queries から直近のクエリの状況を確認することができます。 解決方法:基本的には処理性能を上げるようにDB側の設定を変更するか、Lookerインスタンス側でDBに極力負荷がかからないように設定を見直す必要があります。Looker側でできることとしてはクエリが取得する結果が多くならないよう、Row limitを設定したりデータにフィルタをかける 同時に大量のクエリを発行しないようDashboard上のタイルの数を減らす/スケジューラーの間隔をあける PDTを作成してクエリの負荷を減らす Datagroupなどを使用してキャッシュを作成し、DB対して発行されるクエリの数を減らすなどがあります。Lookerがどのような時にキャッシュを使用するか、実際に実行したクエリがキャッシュを参照したか調べる方法はこちらのポストをご覧ください。 2. インスタンスの負荷 事象: Lookerインスタンス全体でページからページへの

週の始まりをフィルターで選択された日付を見て動的に変更する

※ 本投稿はLooker Advent Caledar 2021 6日目の記事です。Lookerでは、LookMLの中でLiquidを使うことができ、より動的で柔軟なロジックを組むことができます。今回は、ユーザが画面で設定した日付のフィルターの開始日を見て、もし水曜日がフィルターの開始日であれば、水曜日始まりで、週の計算をしていくサンプルコードになります。このロジックがない場合は、基本的には月曜始まりで週の計算をしていくので、水曜日を開始日とした場合は、1週目は他の週よりも値が少なく算出されます。 通常のdimension group weekを使った場合月曜始まりになるので、2021/8/30から週を始めていますが、中身の計算は、2021/9/1からになります。 Dynamic weekを使って水曜始まりで計算した場合水曜始まりになるので、2021/9/1から週を始めています。もちろんそれ以降の週も水曜始まりとなります。 LookML#元々の日付 dimension_group: created_at { type: time timeframes: [date,raw,day_of_week,week] sql: ${TABLE}.created_at ;; convert_tz: no }#メインのロジック dimension: dynamic_week { description: "フィルタで選択した期間の開始日を見て、開始日の曜日を週の始まりに設定して週ごとにする" sql: CASE WHEN EXTRACT(DAYOFWEEK FROM {% date_start created_at_date %}) = 1 THEN FORMAT_DATE('%F', DATE_TRUNC(${created_date} , WEEK(SUNDAY))) WHEN EXTRACT(DAYOFWEEK FROM {% date_start created_at_date %}) = 2 THEN FORMAT_DATE('%F', DATE_TRUNC(${created_date} , WEEK(MONDAY))) WHEN EXTRACT(DAYOFW