コラム

Lookerにまつわるあれこれ

  • 77 Topics
  • 9 Replies

77 Topics

【小ネタ】PDT Dependency Graph が大きすぎてクラッシュする時の対処法

PDT Dependency Graph という機能を利用すると、PDTを複数組み合わせて運用している場合に、ある PDT が依存するすべてのPDTの関係図を確認することができます。PDTの管理やエラーが発生している上流のPDTを特定する際に便利です。しかし、PDTの数があまりにも多く大きなグラフになってしまう場合に、ブラウザがグラフを表示しきれずクラッシュすることが稀にあります。この場合の対処方について紹介します。 Dependency Graph  まずPDTのDependency Graph の通常の表示方法を紹介します。Admin > Database > Persistent Derived TablesのメニューからPDT Dependency Graph を表示します。表示したいPDTの右横のメニューからPDT Detailsをクリック Show Dependency Graphをクリック Open dependency graph in new tabをクリック先ほどのShow Dependency Graphをクリックした際、PDTの数が多く画面におまりきらない場合でも、さらにOpen dependency graph in new tabをクリックすると新しいタブが開き、大体の場合表示できます。 あまりにもグラフが大きくなりすぎているとOpen dependency graph in new tabを押した際に稀にクラッシュします。 グラフが大きすぎてDependency Graph を表示できない場合の対処法 Open dependency graph in new tabで遷移した先のURLをコピーします。  URLデコーダー(たとえばこちら)に貼り付けてデコードします。 グラフ描写ツール(たとえばこちら)にデコードしたURLのhttps://<インスタンス名>.looker.com/admin/pdt_graph?graph=から後のdigraph  { 以下の部分を貼り付けます。通常ルートで表示できなかった大きなグラフでも描画できます。

各ユーザーのお気に入りコンテンツを取得する方法

LookerのPython SDKによる各ユーザーのお気に入りコンテンツを取得する方法(アドミン権限必須) “Show Content”ボタンをクリックすると該当の画像が見えます更新:改良版ができましたので、リンクを共有します。背景:ユーザーのお気に入りコンテンツを管理する必要があったりします。例えば、既存のコンテンツを削減したい時に、どれを削除するかとか・・またはコンテンツを改善するときにどのユーザーが旧ダッシュボードを利用しているかを把握して知らせたい時とか。しかし、Lookerのお気に入りコンテンツの詳細を取得することが困難で、非常に制限されております。通常のユーザーであれば自分のお気に入りコンテンツしか見れないことがわかるけど・・・アドミンでも結局自分のお気に入りコンテンツしか見れません。ただし、アドミン権限があれば、打開策があります。 方法:まずは、アドミン権限を持った上で、APIのIDとシークレットを作ります。  その後、自分自身の開発環境を構築し、手始めます。 (リンクを開けない場合は下記に画像もございます。)上記のリンクにて自分の完成の開発環境とイシューの打開策を共有しておりますが、続きましょう。LookerのApi Explorerを使い、お気に入りコンテンツに関するSDKを検索・試しても、すぐに「自分自身のユーザー」のお気に入りコンテンツしか取得できないことに気づきます。そのためにアドミン権限が必要になります。打開策は、各ユーザーにログインし、ユーザー自身の個人のお気に入りコンテンツを取得し、結合することです。 SDKの内訳:お気に入りコンテンツのリスト作成には下記の過程が必要です:インスタンスのユーザーのリストを作成 ダッシュボード(またはボード・ルック等)のリストを作成 本ユーザーのお気に入りコンテンツを取得するファンクションを作成 各ユーザーにログインし、3のファンクションを実行するループを作成開発環境の構築 (画像付き):画像が大きいので、デフォルトで非表示化されております。見たい時は”Show content”をクリックしてください。環境を操作する前に、ご自身のgDriveにコピーすることを推奨します。ただし、ノートブックに書くものは他のユーザーは閲覧することができません。環境作りに二つのフェーズがあります。1つ目はSDKを立ち上げるこ

Looker プロダクトファミリーを使ってデータ利活用を充実させよう!

こんにちは。Google Cloud カスタマーエンジニアのHuskyです。この記事はLooker Advent Calendar 2022の記事の一つとして執筆しています。2022年10月22日にGoogle Cloud Next’22が開催されました。日本ではデータポータルという名前で親しまれていたData StudioがLookerのプロダクトファミリーに追加され、Looker StudioとしてリブランディングされたことがKeynoteで発表されました。(発表の詳細についてはこちらを参照)これにより、Google Cloudには異なるキャラクターのBIに関連する製品が3つ並ぶことになりました。3製品の概要は以下の通りです。Looker Studio : 従来Data Portalと呼ばれていたセルフサービスBIツール。無償で利用が可能。Looker Studio Pro : Looker Studioの有償版。エンタープライズ向け機能やテクニカルサポートが付随。Looker : 従来からLookerとして提供していたビジネスロジックを含めた定義の一元管理が可能なデータプラットフォーム。また、Looker Studioの発表と同時にLooker StudioでLooker上で定義されたデータモデルをデータソースとして利用が可能となるコネクターのPublic Previewも発表になりました。この発表とNext’21で発表のあったTableauとのインテグレーションにより様々な用途のデータ活用シナリオに対応することが可能になりました。従来、BIツールを選ぶ際に「どのツールが優れているか」といった視点で一つの製品を選定するケースが大半でしたが、利用者の目的、スキルレベルなどに合わせて柔軟なツール選択をすることが出来るようになりました。下図は全社でデータ活用を促進しようと考えた場合の参考の構成図です。  もちろん、このような大規模な構成をいきなりとらなくても、 Looker Studio でデータ分析に親しむところから始め、チーム間での利用を考慮して Looker Studio Pro にアップグレードし、全社利用に進むために Looker でセマンティックモデリングレイヤーを構築しガバナンスを強化する、といった具合に自社の状況に合わせて段階的に利用を始めていくとい

System Activity入門 よくある質問と回答を紹介します!

※ 本投稿は Looker Advent Caledar 2022 12/8分の記事です。こんにちは!12月に入っていきなり寒くなって驚いています。記事を見ていただいた方、暖かくしてお過ごしください〜! 今回はSystem Activity について入門記事を書きます。これから使用を検討している方への参考や、すでに使い倒している方のおさらいになれば幸いです。 Lookerでは、通称internal DBと呼ばれているアプリケーションデータベース内に、ユーザー、コンテンツ、クエリ履歴などの情報を保存しています。情報によっていくつかのテーブルがあり、System ActivityのExplore/Dashboardを使用するとそれらのテーブルにクエリを発行し情報を閲覧することができます。System Activityをうまく使用すると監視や測定にとても役に立つので、是非この機に使用してみてください。この記事はLookerのユーザー様からよくいただく質問に回答する形式で記載していこうと思います。 質問1 LookMLを編集してSystem ActivityのExploreにカラムを追加したい。 回答 System ActivityのLookMLは編集できない System ActvitiyにはLookMLモデルがあるのですが、これはビルドインモデルとなっておりユーザーからは編集できません。すなわち、LookMLを編集してカラムを追加したり、キャッシュポリシーを変更したり派生テーブルを作成することはできません。 カスタムフィールド(Custom Measure, Custom Dimension, 表計算)、Merged Resultsは使用できます。独自にフィールドを追加したり簡単な計算を行いたい場合はこれらの機能を使用してみてください。  質問2 System Activityのデータが更新されていない気がする。 System Activityのデータを配信するスケジュールを設定したが、最新のデータが配信されない。  回答 キャッシュに注意 System ActivityではビルドインLookMLモデル内でキャッシュの設定がされており、質問1の回答に記載の通り、System ActicityのLookMLモデルはユーザー様から編集できないため、

不要なコンテンツやフィールドを特定して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 式の詳細については、こちらを参照してください。注意: リジェネレーターの最頻の実行間隔は

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”をコメントアウトして通常のランタイムをご利用ください。