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

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

134 Topics

Refinementsを使用して既存のExploreに期間比較 (Period Over Period) の機能を追加する

本記事は、Use Refinements to add Period over Period functionality to existing explores の翻訳になります。 この例では、よくご要望としていただく 期間比較 (Period Over Period) 機能を Refinements を使用して実装する方法をご紹介しております。 一般的なRefinements利用の背景 期間比較(Period over Period)の背景 refinementsを利用することで、主要なロジックと機能を実現するロジックをそれぞれ完全に分離することができ、しかも同時に対象となる元オブジェクトに対して機能を追加することができます。例えば、ここでご紹介するパターンを使って、元のコアオブジェクトには手を入れずに、既存のExploreの日付フィールドにPoP機能をシームレスに追加することができます。   これについての詳細はこちらの the lookml refinements doc page をご覧いただくか、Fabioの記事をご覧ください。(訳註:Fabioの記事には翻訳記事がございます) PoPはよくご要望として上がる機能で、いくつかのやり方があります。例えばこちら (Flexible Period-over-period Analysis) やこちら(An Explore filter based approach) の記事でも他のやり方がご紹介されています。   本記事でご紹介する方法は実装がシンプルで、またExploreに変更が入ったとしても特別なメンテナンスが不要です。ユーザーにとっては過度な複雑さを避けた柔軟な方法となります。  期間比較 (Period Over Period) の見た目はどのようになりますか? ユーザーは新しく作成したディメンションをピボットすることができ、また期間の長さと表示する数を選択することができます。 パラメータの入力例など他の2つの例をご覧になる場合はこちらをExpandしてください。 (訳註:フィールドピッカーに、Pivot for Period over Period という追加ディメンションが追加されており、また PoP Periods Ago to Include

Support Accessの設定について

この投稿は、Support Access英語版に投稿されたものの翻訳です。 Looker 22.0以降、Looker管理者は、アクセスを許可する担当者を指定するなど、Googleの担当者によるLookerインスタンスへのアクセスをさらに制限できるようになっております。サポートアクセスが必要な場合、お手数ですが、次頁以降の手順に従い担当者の追加をお願いいたします。 1. サポートアクセスの設定状況確認 1.1 ヘルプメニュー サポート・アクセスはデフォルトでは無効化されており、ヘルプ・メニューに Support Access: Off と表示されていることが確認できます。有効化されると、次のように設定されている残期間が表示されるようになります。  1.2 管理者画面 管理 > 一般 > サポートアクセスの画面においても同様に、サポートアクセスの状況を確認することができます。サポートアクセスが無効化されている場合、以下のようにEnable Support Accessのボタンが表示されます。 サポートアクセスが有効化されている場合、以下のように有効化されている残期間が表示されます。2. サポートアクセスの許可 弊社Google社員に対してのアクセスを設定していただく場合、サポートアクセスの有効化および、アクセス可能な個人を登録していただく必要があります。 2.1 サポートアクセスの有効化 サポートアクセスの有効化により、Allowlistに登録されているユーザー全てがインスタンスへアクセス可能になります。 有効化するためには、 アクセスを有効化する期間(数値および時間の単位)を設定します。アクセスを有効にできる最大期間は90日です。 チェックボックスをオンにして、Googleの担当者がLookerインスタンスにアクセスすることを許可していることを理解していることを示します。 [Enable support Access]をクリックします。  2.2 アクセス権を付与するユーザーの特定 アクセスを許可するユーザーを指定するには、[Support Access Authorization]セクションで、[Add users to allowlist]をクリックします。 [Add users to allowlist]というダイアログが表示されます。  ア

可読性の高い項目名をつける

🇺🇸 Naming Fields for Readability in English 🇺🇸 ディメンションとメジャーの名前は、特にモデルが充実してくるにつれて混乱する可能性があります。LookML作成中に適切な参照項目を作成し、フィールドピッカーの中で正しいフィールドを選択できるようにするには、わかりやすい命名規則が必要です。これに役立つ一つのアプローチは、一貫した命名規則です。次の規則は、Looker内で内部的によく利用される規則です。 “Count” はカウント計測用 type: count メジャーは [フィルター] Count で呼ばれます。例えば: - view: users fields: - measure: count type: count - measure: active_count type: count filters: status: 'active' これにより、LookerのUIに次のような名前がつけられます: USERS Count USERS Active Count これらのフィールド名は自然に読めますが、ビジネスユーザーは最初に"number of"や"total"でなく、”count”を検索する事を知らない場合があります。しかし、いくつかのとても単純なトレーニングにおいては、これが最良な選択肢のようです。 "number of"や"total"をカウントには利用しません。なぜなら、これらの言葉を別のケースに利用するために予約したいからです。 “Unique Count”は 固有の数の計測用 type: count_distinct メジャーは Unique [フィルター] [エンティティ名] Count で呼ばれます。例えば: - view: users fields: - measure: unique_user_count type: count_distinct sql: ${id} - measure: unique_active_user_count type: count_distinct sql: ${id} filters:

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

Looker 22.4 リリースノート

リリース予定スケジュール リリース開始日: 2022/03/14リリース完了およびダウンロード可能: 2022/03/24日本のお客様を含む地域は日本時間2022年03月24~25日頃に順次リリースを予定していますリリース予定日は変更となる可能性があります。予めご了承ください。 リリースに関する概要はこちらをご参照ください。 レガシー機能の終了スケジュール重要なお知らせ:オリジナルのリリースノート(英語版)は標準のLooker documentation にて掲載されます。以下リンクよりご参照ください。Looker 22.4 Release HighlightsLooker 22.4 Changelogその他日本語のLookerドキュメントリスト本スレッドへのコメントは公式には追跡されないことにご注意ください。ヘルプ・リクエストや障害報告については、新規トピックを追加いただくかLooker Help Centerからご連絡ください。 ​リリース・ハイライト API 4.0一般利用機能としてリリース Embedded query visualizationsの追加 Custom fields permissionの追加 影響のある変更 その他の追加・変更・修正 ​💡API 4.0API 4.0が一般利用機能としてリリースされました 複数のエンドポイントをベータ版から一般利用機能へ昇格させる過程で、既存のコードに影響を与える変更が適用されています。これらの変更の詳細については、このドキュメントをご覧ください Looker API 3.1および3.0は影響を受けません LookerとコミュニティがサポートするSDKは、Looker API 4.0 GAエンドポイントをサポートするように更新される予定です 💡​Embedded query visualizationsQuery Visualizationの埋め込みが可能になりました ユーザーは、/embed/query-visualization/query_slug の URL を使用して、クエリからビジュアライゼーションを埋め込むことができるようになりました クエリの query_slug を取得するには、まずクエリの Short URL を取得します。query_slug は、Shor

テンプレートフィルターで日付別シャード化テーブルをフィルタ

BigQueryのテーブルが日付別で [PREFIX]_YYYYMMDD のようにシャード化されており、この日付とテーブル内の日付のカラムがUTCになっている場合に、LookerのExploreやダッシュボードではJSTで指定した期間のデータだけを検索したいケースがあります。 <例> log_20200728(UTC)テーブルには以下のtimeカラムがあり、データはUTCで入っている。 この場合、JST 7/29で検索したい場合は、シャード化テーブルはog_20200728とlog_20200729を対象とし、timeカラムはJSTに変換したデータを検索したい。 2020-07-28T04:00:00.000+00:00 (JSTは2020-07-28T13:00:00.000+00:00) 2020-07-28T18:00:00.000+00:00 (JSTは2020-07-29T03:00:00.000+00:00) log_20200729(UTC)テーブルには以下のtimeカラムがあり、データはUTCで入っている 2020-07-29T06:00:00.000+00:00 (JSTは2020-07-29T15:00:00.000+00:00) 2020-07-29T19:00:00.000+00:00 (JSTは2020-07-30T04:00:00.000+00:00) LookMLでは、以下のようにfilterの中でテンプレートフィルターを使うことで、シャード化したテーブルをJSTで検索しつつ、timestampカラムの値もJST変換して検索することができます。 Viewファイル view: ga_sessions { sql_table_name: `test.test.ga_sessions_*` ;; filter: target_date { type: date datatype: date sql: ({% condition target_date %} ${partition_date} {% endcondition %} OR {% condition target_date %} ${partition_date_

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

SharePointにLooksを埋め込む (Embed)

Lookerの強力なデータデリバリーパターンの一つにEmbed (埋め込み分析) があります。既存のアプリケーションやポータルサイトにiFrameでLookerのLooksやダッシュボードを埋め込むことでユーザーが複数のアプリを行き来することなく(もっと言うとBIツールを見ていると意識することすらなく)、いつも見ている場所で必要なデータを自然に見られるようしてあげることは、データの民主化を進める上でも有効な手段の一つとなります。 SalesforceへのEmbedについては既に多くの記事がでておりますので、本記事では次いでお問い合わせの多いSharePointページへのEmbed方法をご紹介します。 Salesforceへの埋め込みについてはこちら🔽Looks や Dashboards のSalesforce (SFDC)への埋め込み 前提条件: Looker !!! SharePoint (Microsoft 365) の管理権限 Embedの方式はPrivate Embedとする* (閲覧ユーザーはLookerのアカウントが必要となります) *LookerのEmbedには大きく3つ (Public, Private, SSO) の方法があります。用途・要件に応じて方式を選択しましょう。Public Embed Private Embed SSO Embed Step 1. Look / Dashboardの作成 (Looker) 今回は例として主要KPIをMultiple Value Vizで可視化したシンプルなLookを用意しました。  Step 2. Embed用のURLを取得する (Looker) Step 1で作成したLook / DashboardのURLを元に、Embed用のURLを取得します。と言っても /looks/ を /embed/looks/ に変更するだけです。https://<<instans_name>>.looker.com/looks/816↓https://<<instans_name>>.looker.com/embed/looks/816 Step 3. SharePointページに埋め込む (SharePoint)まずはSharePointページの編集モードに入りま

ダッシュボードで期間を選択式にして集計の絞り込みを行う方法

Lookerでは、高度フィルタ(matches Advanced)を使えば、日付項目などに対して柔軟な絞り込み条件をセット可能です。詳しくは、こちらのページを参照ください。 ただ、エンドユーザーのユーザビリティを考えた場合、もっとシンプルに期間を指定したい、というご要望を何度かお聞きしました。そこで、以下の画面例のように絞り込み期間の選択肢をダッシュボード上に表示し、簡単に期間を選択できるようにする方法をご説明いたします。今回の例では、「直近一週間」、「直近一ヶ月」、「直近一年」の選択肢を作成いたします。 1. パラメータの追加 まずはじめに、オプションボタンで表示する選択肢を用意します。絞り込み対象となるビューに、以下のパラメータを追加します。 parameter: search_duration_selection { type: unquoted default_value: "1w" allowed_value: { label: "直近1週間" value: "1w" } allowed_value: { label: "直近1ヶ月" value: "1m" } allowed_value: { label: "直近1年" value: "1y" } } 2. ディメンションの追加 先ほどと同じビューに、パラメータで選択した選択肢に従って、期間が変化するディメンションを追加します。 ※ こちらはBigQueryでの期間指定例になりますので、お使いのDBで利用可能な書式に変更してください。また、${TABLE}.event の部分は、絞り込みに使う日付項目に適宜置き換えてください。 dimension: duration { type: yesno sql: {% case search_duration_selection._parameter_value %} {% when '1w' %} DATE_ADD(CURRENT_DATE(), INTERVAL -8 DAY) < CAST(${TABLE}.event AS DATE) AND CAST

Chrome のカスタム検索でよく使うダッシュボードに即座にアクセス

些細なことだけど地味に便利、Lookerを使う上でのライフハックシリーズです。 普段みなさんがお使いのダッシュボードで、特定の製品、ブランド、顧客名などをフィルターで指定して利用するようなものはありませんか。 本記事ではGoogle Chromeのカスタム検索機能を使って、ブラウザの検索バーから一発で特定の条件でフィルターをかけたダッシュボードを開く方法をご紹介します。 ここでは弊社がデモでよく利用しているブランドアナリティクスのダッシュボードを例に挙げます。 こちらのダッシュボードは、フィルターで指定した特定のブランドについて各種数値を表示するものとなります。通常の使い方を想像すると ブラウザからLookerにアクセスする ブランドアナリティクスのダッシュボードを開く フィルターに特定のブランド名を指定する 実行(データ取得)する といったステップを踏む必要がありますが、今すぐある特定のブランドについての数字を見たい!や、いくつかブランドのフィルター条件を切り替えて見たい!といった場合、都度上記のステップを踏むのが煩わしく感じることはないでしょうか(私は感じる) そんなときは、Google Chromeのカスタム検索機能を使って、ブラウザから一発で特定のパラメータでフィルタをかけたダッシュボードを開けるようすると、作業時間を大幅に短縮することが可能です。 1. 該当のダッシュボードのURLをコピーする フィルターに適当な値を指定して実行し、URLを取得します。以下のように、フィルタに指定した文字列をパラメータに含むURLが取得できるかと思います。 ※ &filter_config 以降は不要 https://<LOOKER_HOST_NAME>/dashboards/6?ブランド=Lee&期間=90%20days 2. Chromeの設定で、検索エンジンに以下を追加する こちらはGoogle Chrome側の設定となりますので、こちらを参照しながら以下のように検索エンジンを設定します。 Search Engine : 任意の名称(例:ダッシュボードの名前) Keyword : 任意のキーワード(例:"brand" などクイックに入力できるもの) URL with %s in place of query : 1でコピ

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

■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) 有効なキャッシュがある状態でクエリを走らせるブラウザを再

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

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

次世代ホスティングインフラストラクチャへの移行について

本記事はこちらのHelp Centerの記事の日本語版となります。 既にTechnical Contactの皆様には別途ご連絡がいっております通り、Lookerは、より優れたスケーラビリティと信頼性をユーザーの皆様に提供するため、2020/11/1より順次 次世代ホスティングインフラへの移行を行っていきます。  こちらの移行に伴い、お客様側の環境設定について一部変更を実施いただく必要がございます。大変お手数をお掛けしますが、下記にて必要な変更点をご確認の上、ご利用中の処理に影響が出ないよう 2020/10/31までに 必要な設定変更を実施いただけますよう宜しくお願い致します。  内容についてのご質問やサポートが必要な場合は、Livechat, help.looker.com または担当のLookerチーム (担当営業・CSM・プロフェッショナルサービス) へご連絡ください。   データベース接続について 3rdパーティーサービスへの接続について Lookerへのアクセス(ブラウザ・API)について PDT (永続的派生テーブル) について     データベース接続について   もし、現状Lookerをデータベースに接続する際に IPアドレスホワイトリスト及びSSHトンネルの設定を実施されている場合、次世代Lookerインスタンスの新しいIPアドレスをご登録いただく必要があります。    Enabling secure database access のページを参考に、Lookerインスタンスがホストされているリージョンに紐づくIPアドレスをご確認ください。新しいIPアドレスは Instances Hosted on Google Cloud Platform (GCP) または Instances Hosted on Amazon Elastic Kubernetes Service (Amazon EKS) の下に記載されています。     日本のお客様につきましては以下のIPアドレスが対象となります。GCP : 日本、東京(asia-northeast1) 34.84.255.194 35.243.85.184AWS (Amazon EKS) : アジア太平洋地域(東京)(ap-northeast-1) 54.250.91.57 13.112.30.110 54

Looker 21.18 リリースノート

リリース予定スケジュール リリース開始日: 2021/10/19リリース完了およびダウンロード可能: 2021/10/28日本のお客様を含む地域は日本時間2021年10月28~29日頃に順次リリースを予定していますリリース予定日は変更となる可能性があります。予めご了承ください。 リリース予定の変更など、リリースに関する重要な通知はLooker Technical Contacts 宛にメール配信されます。Lookerの管理画面よりTechnical Contactsの登録をお願い致します。その他リリースに関する概要はこちらをご参照ください。 レガシー機能の終了スケジュール 重要なお知らせ:オリジナルのリリースノート(英語版)は標準のLooker documentation にて掲載されます。以下リンクよりご参照ください。Looker 21.18 Release HighlightsLooker 21.18 Changelogその他日本語のLookerドキュメントリスト本スレッドへのコメントは公式には追跡されないことにご注意ください。ヘルプ・リクエストや障害報告については、新規トピックを追加いただくかLooker Help Centerからご連絡ください。 ​リリース・ハイライト URL Links(ボードの機能向上) ダッシュボードのUIに関わるオプションの追加 デフォルトのDeveloperパーミッションセットの変更 影響のある変更 その他の追加・変更・修正  URL Links(ボードの機能向上) Labsの新機能:URL Links in Boards Labsの新機能「URL Links in Boards」は、ボードの編集者が既存のLooksやダッシュボードと一緒に、ボード上に任意のURLへのリンクを追加できる機能です。 同じLookerインスタンスへのリンクは現在のタブで開き、インスタンス外へのリンクは新しいタブで開きます。   ダッシュボードのUIに関わるオプションの追加 The Revert to Legacy Dashboards 機能​​のサポート期間がバージョン22.0までに延長されました Legacy Featuresに「Use old dashboard routes」を追加しました。このオプションをオフにすると、新しい