コラム

Lookerにまつわるあれこれ

  • 69 Topics
  • 8 Replies

69 Topics

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インスタンス全体でページからページへの

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

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

※ 本投稿は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

ネイティブ派生テーブル(NDT)の活用方法

※ 本投稿はLooker Advent Caledar 2021 5日目の記事です。 派生テーブル LookerにはNative Derived Table(ネイティブ派生テーブル)という強力な機能があります。これを活用すると、わざわざ新規にSQLを書かなくても、既存のExploreを使うことで、かなり複雑なケースにも対応した派生クエリーを書くことができます。一方で、SQLとは異なりLookMLで記述する必要があるため、どうしてもSQLの方が書きやすいということで敬遠されることがあると感じています。そこで、ネイティブ派生テーブルがどのように利用されると良いか、今日は単純化した例を用いて説明させていただこうと思います。 ネイティブ派生テーブルの活用 以下のような注文ビュー(order_items)を基底ビューとしたシンプルな注文Exploreで考えてみます。注文Viewに対して、ユーザー情報、在庫製品、製品のビューをそれぞれ結合しています。explore: order_items {    join: users {    sql_on: ${order_items.user_id} = ${users.id} ;;    type: left_outer    relationship: many_to_one  }    join: inventory_items {    sql_on: ${order_items.inventory_item_id} = ${inventory_items.id} ;;    type: left_outer    relationship: many_to_one  }    join: products {    sql_on: ${inventory_items.product_id} = ${products.id} ;;    type: left_outer    relationship: many_to_one  }} ここで、たとえばカテゴリーごとの集計値を取りたい場合、どのようにすれば良いでしょうか。Exploreを使えば以下のような結果が簡単に手に入ります。 Explore実行結果1次に、カテゴリー及び個別のブランド別の集計が欲しい場合はどうでしょうか。この場合は、単純にブランドディメンションを追加すれば

Extension Frameworkを利用してPDTの依存関係を表示させる

※ 本投稿はLooker Advent Caledar 2021 2日目の記事となります。さて、Looker 21.20ではPDT Dependency Visualizerという機能がリリースされました。この機能によって、管理者メニューのPDT画面から依存関係を確認することが可能となります。しかし、本機能を利用するためには管理者権限が必要となるため、今回はAPI Endpointを利用するExtension Frameworkを利用して依存関係のグラフだけを表示するアプリケーションを作成してみたいと思います。Reactに関しての細かい部分については、ここでは割愛します。 Extension Frameworkとはまずは、Extension Frameworkをご存知ない方のために、少しご紹介しておきます。Lookerでは、このフレームワークを利用して、Looker上で動作するJavascriptアプリケーションを構築することが可能になっています。代表的な例としては、Looker MarketPlaceからインストール可能なData DictionaryやLookML Diagramがあります。本フレームワークは、Webアプリケーション開発時に必要となる以下のような認証などの実装は、Looker側で管理可能なため、機能開発に注力することが可能です。 Authentication - Lookerの既存の認証オプションを利用可能 (パスワードログイン、 LDAP、 SAML、 やOpenID Connect). アクセス管理とパーミッション管理 APIアクセス -  他の開発リソースの活用、サード・パーティAPIやLooker Extension Frameworkの機能また、Looker Extension Frameworkは以下のような機能を備えています: Looker Extension SDK: Looker環境において、ユーザーのインタラクティブな操作を可能とするLookerの外部APIアクセス Looker Components: Extensionで利用可能なReact UIコンポーネント Embed SDK: ダッシュボード、LookやExploreをExtensionへ埋め込むためのライブラリ(サンプルコードとして、kitchen