コミュニティフォーラム (Japanese)

ようこそLookerの日本語コミュニティへ!リリースノートやイベントのご案内などは「ニュースと告知」、Lookerの製品機能に関するちょっとした疑問・質問は「ヘルプとサポート」、その他TIPsやデータにまつわる話は「コラム」のカテゴリへご投稿ください。みなさまの投稿・コメント、心よりお待ちしています!

135 Topics

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

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

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 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をご利用になられていることを想定しております。**翻訳機能がうまく動作せずご不明

新しいランタイム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 21.14 リリースノート

​リリース予定スケジュール リリース開始日: 2021/8/16リリース完了およびダウンロード可能: 2021/8/26日本のお客様を含む地域は日本時間2021年8月26~27日頃に順次リリースを予定していますリリース予定日は変更となる可能性があります。予めご了承ください。 リリース予定の変更など、リリースに関する重要な通知はLooker Technical Contacts 宛にメール配信されます。Lookerの管理画面よりTechnical Contactsの登録をお願い致します。その他リリースに関する概要はこちらをご参照ください。 レガシー機能の終了スケジュール 重要なお知らせ:オリジナルのリリースノート(英語版)は標準のLooker documentation にて掲載されます。以下リンクよりご参照ください。Looker 21.14 Release HighlightsLooker 21.14 Changelogその他日本語のLookerドキュメントリスト本スレッドへのコメントは公式には追跡されないことにご注意ください。ヘルプ・リクエストや障害報告については、新規トピックを追加いただくかLooker Help Centerからご連絡ください。 ​リリース・ハイライト GitHub認証の変更 Forecasting (未来予測値)  拡張アラート 影響のある変更 その他の追加・変更・修正  GitHub 認証の変更 GitHub がすべてのGitオペレーションについてトークン認証を必要とするようになります。こちらは今回のアップデートに伴うLookerの変更ではありませんが、お客様のGitHub連携の設定内容によっては影響がありますためハイライトさせていただいております。  2021年8月13日より、GitHubがGit操作の認証のについてユーザー/パスワードによる認証を受け付けないようになりました。LookMLプロジェクト上でのGitアクションについても、ユーザー/パスワードの認証方式にて連携設定している場合にはエラーとなります。 Looker開発者は、ユーザー/パスワードの認証方式にてGitHubとの連携設定をしている場合、個人のアクセストークンを使用して連携するように設定を更新する必要があります。 デプロイキーを使用した連携設定をし

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

Looker APIを使ってユーザーを一括無効化・削除

使用しないユーザーが増えてしまったときに、複数のユーザーを一括で無効化・削除できると便利です。LookerのUIからでは1つのユーザーごとにしか無効化・削除を実施できないのですが、APIを使用することで、簡単に複数のユーザーを一括で無効化・削除することができます。 今回はGoogle Colab上でLooker SDKを使用してpythonでこの方法を実装してみたいと思います。Google Colabは、ブラウザ上でPythonを記述・実行できるサービスです。すでにpythonやJupyterがインストールされているので、初期セットアップ不要で気軽にお使いいただけます。  準備Google Colabで新しくノートブックを開いたら、まずは必要となるパッケージのimportと環境変数の設定を実施します。#Looker_sdkをインストール! pip install looker_sdk#パッケージをインポートimport looker_sdkimport osfrom looker_sdk import modelsos.environ['LOOKERSDK_API_VERSION']='3.1'os.environ['LOOKERSDK_BASE_URL']='XXXXX'os.environ['LOOKERSDK_CLIENT_ID'] = 'XXXXX'os.environ['LOOKERSDK_CLIENT_SECRET']='XXXXX'#looker_sdkを初期化sdk = looker_sdk.init31()XXXXX部分には下記を記載してください。LOOKERSDK_BASE_URL LookerインスタンスのAPI URL LOOKERSDK_CLIENT_ID Admin > User > Edit > API3 keys > Edit Keysに記載されているClient ID LOOKERSDK_CLIENT_SECRET Admin > User > Edit > API3 keys > Edit Keysに記載されているClient Secret  ユーザーを一括無効化 update_userエンドポイントを使用して無効化します。 #1. 無効化したいユーザーのIDをリストの中に記載し

コミット履歴をLooker上で可視化する

System ActivityのEvent Attribute Explore を使用することで、コミット履歴の可視化や履歴情報に基づいてアラート/スケジュールの配信を行うことができます。ご使用のGitプロバイダー上でも確認することができますが、Looker上で誰がどのプロジェクトに変更を加えたのかをクイックに確認したい時などに便利です。 アウトプットの例: 実装方法System ActivityのUser Attribute Exploreを開く Event Categoryのフィールドを選択し、フィルターバリューにgit を追加します Event Nameのフィールドを選択し、フィルターバリューに任意の値を追加します(例では、コミット・プッシュ・デプロイに関わるイベント名前をフィルターバリューとして追加しています) Event Attribute Nameのフィールドを選択し、フィルターバリューにprojectを追加します その他使用されたいフィールドがあれば追加するサンプルExplore:https://<ここにご使用されているドメインを挿入してください>/explore/system__activity/event_attribute?fields=event.created_time,user.name,event.id,event.category,event.name,event_attribute.name,event_attribute.value&f[event.category]=git&f[event.name]=%22git_commit%22%2C%22git_deploy%22%2C%22git_push_branch%22%2C%22git_deploy_via_webhook%22&f[event.created_time]=10+hours&f[event_attribute.name]=project&sorts=event.created_time+desc&limit=500&vis=%7B%22show_view_names%22%3Afalse%2C%22show_row_numbers%22%3Atrue%2C%22transpose%22%3Afalse%2C%

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の利用の検討をお勧めします。 ご質問等がございましたらぜひコメントください!

Lookerの最大イベント「JOIN」が日本語で放送されます!

 Looker Japanチーム が開催する今年最大のイベント「JOIN Recap 2021」が11月18日(木) 15:00 - 17:00に開催されます!  JOIN Recap 2021では、グローバルで行われる JOIN@Home で注目度の高いセッションを日本語にてお送りいたします。 JOIN Recap 2021の登録はこちら 今回のJOIN Recapでは、基調講演の内容をご紹介する他、Looker を活用したデータエクスペリエンスの向上や、機能面でのアップデートについてエキスパートが解説します。Lookerに関する最新の情報や、Google Cloud 製品と組み合わせた活用方法について知りたい方に最適なコンテンツになっております、ぜひご参加ください! アジェンダとタイムテーブルはこちら:15:00–15:05|オープニング15:05–15:35|基調講演と最新プロダクト情報  注目ポイント✋👀 データ活用から得られる価値の創出までリードタイムを最小化するLookerのアプローチ 未発表のリリース予定機能...❗️  15:35–15:55|Looker と BigQueryによるログ分析と可観測性  注目ポイント✋👀 ログの取得からLooker上でモニタリングするまでのチュートリアルがあります❗️(特にAdminの方におすすめのセッション)  15:55–16:15|Vertex AI を用いたLookerカスタム分析アプリの構築  注目ポイント✋👀 Vertex AIを用いた予測分析〜Looker上での予測データ活用のデモがあります❗️(特にDeveloper・Analystの方におすすめのセッション)  16:15–16:35|最先端のマーケティング 3つのアプローチ  注目ポイント✋👀 サードパーティCookieの廃止とこれからのマーケティングについて デジタルマーケティングをサポートする為に最近開発された機能と事例の紹介❗️  16:35–16:55|Looker Marketplace で ユースケースを促進する方法  注目ポイント✋👀 Marketplaceのコンテンツを使ったデモあります❗️ 2022年のロードマップの紹介...🔍  16:55–17:00|クロージング 是非ご視聴下さい👍尚、セッション録画

Custom Mapを利用して都道府県別の数値を地図上に可視化する

Lookerでは、自作した境界データを利用して地図上での可視化を行うことが可能です。これにより、営業エリアが複数の市区町村をまたがっている場合などでも、棒グラフ・円グラフなどだけではなく地図上での塗分けによる可視化を行うことが可能になります。(都道府県別の数値を可視化したいというご質問が多いようですので、こちらに、その方法を記載します) (注:本文中に記載のリンクは本記事執筆時のものでありリンク先URLが変更になっている可能性があります。 また、こちらに記載の内容については、弊社サポートチームにお問合せ頂いても対応致しかねる場合がございます点についてご留意ください) 領域データの準備上記可視化を行うためには、各地域の地形シェイプデータおよび各地域情報を含めたデータが必要になります。Lookerでは、地図上の領域を表現するためにTopoJsonという形式のデータを利用します。地形データは複雑な地形になってくるとデータサイズが巨大になってしまいますが、このTopoJsonを利用することで軽量化を行うことができます。TopJsonについては、shapefileフォーマットやgeoJson形式のデータをお持ちになられていれば、Mapshaperというオンラインツールで簡単に変換することが可能です。変換方法については、こちらの記事を参照ください。今回は、都道府県の境界線データを利用してコロナ感染者数を地図上に可視化します。  上記感染者数は、こちらの新型コロナウィルス感染症対策で公開されているオープンデータから、11/1現在の都道府県別の感染者数をCSV形式に加工して利用しています。また、都道府県別の境界データについては、こちらのData Of Japanにて公開されている行政区分データを利用しています。(出典元:地球地図日本) 境界データのアップロードLookerでアップロードしたいプロジェクトを開き、topoJSONファイルをドラッグ・アンド・ドロップすることでインポートができます。 Mapレイヤーの作成地図の境界データがアップロードできましたので、LookML上にMapレイヤーを作成していきます。以下のようにモデルファイルに追加します。map_layer: japan_pref {  file: "japan.topojson"  format: topojson  p

表計算 (Table Calc) の窓関数 (Windows function) を使う方法

みなさんこんにちは!表計算による窓関数は非常に便利なものでぜひ記事をアップしたいと思いました。下記の画像をぜひご覧ください。極端な例になりますが、およそ300行ほどのデータを2つの行に圧縮することができました。男子・女子の合計売り上げこちらのメソッドは割とシンプル、しかし魔法的と言えるでしょう。 まずはGroup集計(窓関数)かけたいコラムを指定し、(今回はProducts Department)値がはじまる行と次の値がはじまる行を変数にする表計算を作ります→ 表計算1名前:group_start_row:コード:match(${products.department}, ${products.department})そして→ 表計算2名前:next_group_start_row:コード:count(${products.department}) - match(${products.department}, offset(${products.department}, count(${products.department}) - row()*2 + 1)) + 2上記のデータ変数があれば、様々な窓関数が開放されます。例えば:名前:group_count:コード:${next_group_start_row} - ${group_start_row}又は、上の画像で使っている名前:group_sum:コード:sum(offset_list(${inventory_items.total_cost}, -1 * (row() - ${group_start_row}), ${next_group_start_row} - ${group_start_row})) 他にはRunning_totalの窓関数も 名前:group_running_total:コード:sum(offset_list(${inventory_items.total_cost}, -1 * (row() - ${group_start_row}), row() - ${group_start_row} + 1)) 上記の方法で簡単な集計が容易くなりますが、MAX()とか、複数の数字を比べるような器用な関数はどうしたらいいのか?となった時は今度はListの関数を使う出番です。例えば、ミッションは

クエリのログからキャッシュを理解する

■Lookerのキャッシュについて Lookerでは、新たなクエリを実行しようとするとまず、Looker内に有効なキャッシュがあるかどうかを確認します。有効なキャッシュがある場合は、DBにクエリせずにキャッシュの結果を使用してdashboardやexplore、スケジューラーの結果が表示されます。有効なキャッシュがない場合に初めて、DBにクエリが発行され、その結果は設定した時間だけキャッシュされます。クエリの結果はデフォルトで1時間Lookerにキャッシュされますが、キャッシュの有効時間を変更するには、LookMLでpersist_forパラメーターやdatagroupパラメーターを使用します。Lookerのキャッシュについて詳しくはこちらのドキュメントをご確認ください。キャッシュの機能をうまく使用すると、DBへ投げるクエリの数を減らしたり、実行に時間がかかるクエリの表示にキャッシュを使用することでダッシュボードを開いたときに早く結果を表示したりすることができます。  ■クエリとキャッシュのログを確認しながら仕組みを理解する exploreやdashboardの実行時に、キャッシュされた結果を表示したのか、DBに投げたクエリの結果を表示したかのログは、System ActivityのHistory Exploreで確認できます。System Activityは、Admin権限またはsee_system_activityのpermissionを付与されたユーザーが閲覧可能です。 準備それでは実際にクエリのログを確認してみましょう♪Explore > System Activity > History のExploreを開いて、画像にあるフィールドを選択していただくとうまく情報を取得できます。今回の例では、ログは下が古いもの、上が新しいものになるようにソートしています。 有効なキャッシュがない状態でクエリを走らせるdashboardやexploreを実行すると、まず書き込まれたクエリの有効なキャッシュがないか確認します。(Attempted Cache = Yes)しかし、有効なキャッシュがなかったため、DBにクエリを投げ、クエリの結果を表示しました。(Result Resource = query) 有効なキャッシュがある状態でクエリを走らせるブラウザを再