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

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

134 Topics

Lookerで始める機械学習

Looker Advent Calendar 2019 Day 8の投稿になります。 Lookerで始める機械学習ということで、Lookerを使って機械学習をする手順とそのメリットについてまとめていきたいなと思っています。 ##機械学習に必要なステップ 例えば、機械学習や統計解析などを使ってデータサイエンス的ななにかを行う場合、多くの場合以下のような手順で行います。 1. ローデータの収集 2. データのクレンジング 3. 検証したい仮説の実績データを取得 4. 統計/機械学習アルゴリズムを使用して予測の実施 5. 可視化やアラートなどを利用し、結果を共有 この手順にツールを追加すると・・・ 1. ローデータの収集 → ETLツール 2. データのクレンジング → ETLツール/SQL 3. 検証したい仮説の実績データを取得 → SQL 4. 統計/機械学習アルゴリズムを使用して予測の実施 → R/Python/各種機械学習サービス 5. 可視化やアラートなどを利用し、結果を共有 → BIツール データ活用を検討されている企業の場合、その多くはすでに1,2については安定した運用が行われているケースが多いですが、3以降ではそれぞれの手順で異なるツールやテクノロジーが必要とされるため、利用にあたり高いスキルが必要とされたり、運用管理が複雑になってしまいます。 しかし、Lookerではこの手順で必要とされるものをシンプルにして実行することを可能にします。 ##Lookerで実施する場合の手順 前述の通り、1,2に関してはすでに構築済みだと思いますので3からの手順に焦点を当てていきます。 ###3. 検証したい仮説の実績データを取得 機械学習を利用して様々な状況の予測を実施するためには、仮説を立て、仮説が正しいかデータをクエリし確認します。 通常、この手順では立てた仮説のもと実態の確認のためにデータを探索します。この際、多くのパターンの仮説検証を繰り返すために何度もSQLを書きます。これが地味に手間なのですが、LookerではExploreの画面から簡単にデータセットの中に自由にクエリをかけることができるため、思いつく限りの多くのパターンの仮説の検証が可能になります。 ###4. 統計/機械学習アルゴリズムを使用して予測の実施 3で検証したデータを元に予測をしていきま

Looker導入時のQ&A集

初めまして!株式会社ヤプリの阿部と申します。今年からLookerを導入しましたが、Lookerの方々にPoC段階で沢山の質問に答えて頂いたので、noteの記事にまとめました。https://note.com/abe_masatoshi/n/n38d9fbae57e8下記質問への回答をまとめております。既出や初歩的な質問も多そうで恐縮ですが、少しでも皆さまのご参考になれば幸いです。 <BigQuery編>・BigQueryの関数をすべて利用できる?・BigQueryの複数プロジェクトをまたげる?・ユーザ定義関数(UDF)を利用できる?・PARTITIONやCLUSTERでスキャン量を制限できる?・window関数使える?・集計結果に対して、window関数使いたいときはどうする?<LookML編>・複数フィールドを基準に区分するdimensionを作成するLooker nativeな記法ある?・ダッシュボードのフィルターで期間粒度を切り替えられる?(月 or 四半期 or 年など)・ダッシュボードのフィルターで指標を切り替えられる?(税抜 or 税込など)<可視化編>・参考になる既存ダッシュボードある?・ダッシュボードの要件をチェックできるようなtipsある?・棒グラフで前の数字との比率を出せる?(ファネル分析などを想定)・英語表記しかない部分はいつか日本語対応される?・元データで改行されているテキストを、改行を保ったまま表示できる?・新たな可視化手段を導入したり、図表で設定できない部分のデザインをいじることできる?・データと連動して画像を出せる?・ダッシュボードをデコるときはどうする?<ダッシュボード上のアクション編>・集計結果の図表からID単位にドリルダウンできる?・図表で複数箇所をまとめて選択できる?・エクスポートの上限件数は?・スケジューラーで図表をslackに自動送信できる?数字をテキスト通知できる?<運用編>・ビジネスユーザー向けのオンライン研修やトレーニングコンテンツある?・ユーザーの権限設定や、ユーザー属性ごとのデータ出しわけが正しく設定できているか確認できる?(特に社外向けの提供を想定)・1つのGitレポジトリを、複数のLookMLプロジェクトで共用することはできる?・model名やview名を変更したときの、ダッシュボードの表示エラーを防げる? L

データドリブンな企業文化を育むために始めるべき5つのこと

本記事は、2020年1月に投稿されたこちらのLookerブログ記事の日本語訳となります。これまで以上にデータドリブンな組織になっていくための方法を探している皆様にとって、何かしらのヒントとなれば幸いです。   Getting people on board with data では、2019年に脚光を浴びた「データ文化」と「データリテラシー」という2つの用語について多く語られていますが、実際にお客様とこれらの用語に対する取り組みについて話を聞くと、(1)多くの人がデータ文化を持つべきだと感じている、しかしその一方で (2)それが何を意味するのか誰しもが理解しているわけではない、ということがわかりました。   Lookerではそれらの用語については以下のように考えています: データ文化:あらゆる部門、またレベルにまたがり、データドリブンな人々で構成されるコミュニティがある。このコミュニティでは、誰もがデータを効果的に使用し、データに基づく意志決定を行い、データをクローズなものにすることなくオープンに会話をすることができる データリテラシー:データを読み、理解し、またデータを元にしたコミュニケーションができる能力のことこれらの定義についてより深く知りたい場合は、how to build data literacy をチェック データドリブンな文化を推進することで、従業員はデータに基づく意思決定を行えるようになり、ビジネスを正しい方向に進めることができるようになります。また洞察を得るためにボトルネックを感じることもなく、さらにはデータチームが設置したガバナンスの効いたデータ基盤のおかげで、人によってデータの定義が曖昧になるといったこともないでしょう。 ただ、データ文化を作るということは、残念ながらそれほどシンプルなことではありません。全従業員にデータリテラシーの認定試験に合格させたり、CEOに「今年はデータ文化を持つ!」と高らかに宣言させるだけでは不十分です。 以下に、組織内でデータ文化を醸成するために、これから2020年の戦略に組み込んでいただきたい5つのイニシアチブを紹介します。  1. ミッション・ステートメントに「データドリブン」や「データリテラシー」を組み込む2. 企業内にデータギルド(コミュニティ)を作る3. 誰もがアクセスできる企業のパフォーマンスダッシュボ

Looker Git Repository 移行手順

本記事では、既にGitリポジトリに接続しているLookMLプロジェクトを、別のリポジトリに移行したい場合の手順を紹介します。 方法としては、Masterブランチの履歴を保持するパターン(シンプル)と、すべてのブランチを保持するパターン(ちょっと大変)の2つがあります。 本記事の内容は、Help Centerに記載の内容を翻訳したものとなります。最新の情報については、Help Centerの記事を参照してください。 Simple Solution: Masterブランチの履歴を保持 Git connectionをリセットし、新しいGit URLを登録すると、LookMLは新しいリポジトリへ移行されます。以下の手順を参照ください。 該当プロジェクトのプロジェクト設定ページへ移動します。 プロジェクト設定ページにて、Reset Git Connection ボタンをクリックします Gitの設定画面において、新しいGit URL(移行先として利用したいGit URL)を入力し、Continue ボタンをクリックします。 接続にSSHを利用している場合は、 Reset Key ボタンを確実にクリックして下さい。そうでない場合、同じSSHキーが利用され、両方のリポジトリが同じサービス(i.e., Github)で利用されている場合、コンフリクトが発生する可能性があります。 SSHコネクションにおいて、リポジトリに新しいdeploy keywoを追加し、Write Accessを付与するのを忘れないようにしてください。HTTPSを利用している場合、Gitリポジトリに対するログイン・クレデンシャルを入力します。(Gitの設定に関する詳細は このページを参照してください)。. 以上で、プロジェクトは新しいリポジトリに接続されます。 Advanced Solution: すべてのブランチの保持 上記の手順では、マスターブランチと、ログインして操作した開発者のブランチの履歴のみが保持されます。すべてのブランチとその履歴を保存するには、より複雑なプロセスが必要です。 最初に、自身でリポジトリを保有する必要があります。プロジェクト設定ページにの下部にURLが記載されています。URLがlloker/始まる場合、Lookerがホスティングしているものになります。

ダッシュボード上で、フィルタで月を指定し、指定した月から過去2年分の期間比較をする

 期間比較(Period-over-Period)するのに、要件によって、いろんなやり方がありますが、この記事では、ダッシュボードのフィルタで特定の月を指定した際に、指定した月から過去X年分のデータを裏側で取得し、月での期間比較をできるようにします。 最終アウトプットはこのようになります。  ダッシュボードのフィルタにて、2021年5月を指定しています。(ちなみダッシュボードネクスト・・URLにdashboard-nextと入っている方です・・から、フィルタにて、このような柔軟な時間指定ができるようになりました。) LookML       1.時間のfilterフィールドを作成します  このfilterフィールドの値を元に、次のステップで過去X年を計算していきます。ダッシュボード上では、このfilterフィールドに、時間のフィルターをかけてください filter: current_date_range { type: date label: "1. Current Date Range" }  過去X年を計算するdimensionと、日付がこの過去X年の範囲内であるかを判定するdimensionを作成します。今回の例では、過去2年なので、24ヶ月で差分を取るように書いていますまた、liquid変数`{% date_start current_date_range %}`は、1のフィルタで選択された期間の開始日を取得するものになります。もし、指定されたendを取得したい場合は、`{% date_end current_date_range %}`を使います。 dimension_group: 24months_period { type: time timeframes: [month,date] sql: dateadd(month, -24 , {% date_start current_date_range %}) ;; }dimension: is_24_month { type: yesno sql: ${created_date} >= ${24months_period_date} and ${created_date} < dateadd('month', 1, {% date_start

Looker 7.18 リリースノート

リリース予定スケジュール リリース開始日: 2020/10/18リリース完了およびダウンロード可能: 2020/10/29⚡ 日本のお客様を含む地域は日本時間2020年 10月30日早朝  11月3日(火) 未明のリリースを予定しています⚡⚡ リリース予定日は変更となる可能性があります。予めご了承ください⚡   リリース予定の変更など、リリースに関する重要な通知はLooker Technical Contacts 宛にメール配信されます。Lookerの管理画面よりTechnical Contactsの登録をお願い致します。その他リリースに関する概要はこちらをご参照ください。  過去のリリースノート レガシー機能の終了スケジュール  重要なお知らせ:オリジナルのリリースノート(英語版)は標準のLooker documentation にて掲載されます。以下リンクよりご参照ください。Looker 7.18 Release Highlights Looker 7.18 Changelog   その他日本語のLookerドキュメントリスト  本スレッドへのコメントは公式には追跡されないことにご注意ください。ヘルプ・リクエストや障害報告については、新規トピックを追加いただくかLooker Help Centerからご連絡ください。   リリース・ハイライト New Dashboard Experience - 新ダッシュボード Google Cloud Platform に合わせたリブランディング エクスプローラの Quick Start (クイックスタート) Looker Mobile App 影響のある変更 その他の追加・変更・修正     New Dashboard Experience - 新ダッシュボード!   これまでダッシュボード(ベータ) としてご利用いただいていた新しいダッシュボードが、今回のリリースよりLookerでのデフォルトのダッシュボードとなります。        新しいダッシュボードでは、より高速な読み込み、新しいフィルターコントロール (強力!!)、再設計されたスケジューラー、および折りたたみ可能なフィルターバーがご利用いただけます。   ダッシュボードを作成する際、デフォルトで新しいダッシュボードが使用されるようになります。   ダッシュ

Looker 21.20 リリースノート

リリース予定スケジュール リリース開始日: 2021/11/16リリース完了およびダウンロード可能: 2021/12/02日本のお客様を含む地域は日本時間2021年12月9~10日頃に順次リリースを予定していますリリース予定日は変更となる可能性があります。予めご了承ください。 リリース予定の変更など、リリースに関する重要な通知はLooker Technical Contacts 宛にメール配信されます。Lookerの管理画面よりTechnical Contactsの登録をお願い致します。その他リリースに関する概要はこちらをご参照ください。 レガシー機能の終了スケジュール 重要なお知らせ:オリジナルのリリースノート(英語版)は標準のLooker documentation にて掲載されます。以下リンクよりご参照ください。Looker 21.20 Release HighlightsLooker 21.20 Changelogその他日本語のLookerドキュメントリスト本スレッドへのコメントは公式には追跡されないことにご注意ください。ヘルプ・リクエストや障害報告については、新規トピックを追加いただくかLooker Help Centerからご連絡ください。 ​リリース・ハイライト System Activity Guided Analysis 機能の追加 Dashboard Details panel 機能の追加 Visualization componentsの追加 Looker public Marketplaceの公開 PDT Dependency Visualizer機能の追加 影響のある変更 その他の追加・変更・修正 System Activity Guided Analysis The Guided Analysis 機能でインスタンスの利用状況に関する重要な質問を掘り下げることができます。 管理者は、「 Guided Analyses in System Activity」をLabsのページから有効にすることができます。 Guided Analysisでは、質問と回答の形式で分析を行うことが可能です。 System ActivityのHistory Exploreから4種類のGuided Analysisにアクセスできます。

GoogleスプレッドシートからLooker APIでLookを実行してデータをダウンロードする方法

Lookerのデータを元にして、時折、Googleスプレッドシートで計算を実行する場合があると思いますが、LookerからGoogleスプレッドシートにデータを取り込むために、Lookを公開設定で 保存しなければならない問題におそらく直面しているのではないでしょうか。これもLookerからGoogleスプレッドシートにデータを取り込むための有用な手段ですが(Looker作成のGoogleスプレッドシートへのデータインポートスクリプトのヘルプセンターの記事を参照)、Looker APIを使用して実現もできます。何も書き直すことなく、Lookにアクセスして実行でき、これはとても素晴らしいところです。 Google AppsのスクリプトがURL Fetch Serviceを内蔵しており、これを利用すれば、自分たちのスプレッドシートから直接HTTPのリクエストを送信できます。 今回の例では、任意のLookの結果を取り込むことができるSheetsのカスタム関数を定義します。 Githubで、スクリプトの最新バージョンを見つけることができます。 手順 Googleスプレッドシートを開き、 ツール > スクリプトエディター に移動します。以下のスクリプトをエディターにコピー&ペーストします。この時、function myFunction()のダミー部分を削除できます。 スクリプト最上部にある、BASE_URLの値に記述されているmycompanyの部分を、ご利用されているLookerのドメイン名に変更し、API credentials(クライアントIDとシークレット)を追記します。 注: シートにアクセスする全てのユーザーが同一のcredentialsにアクセスできるため、スクリプトに登録するcredentialのユーザーの権限を、適切に制限することが重要となります。 save をクリックして、プロジェクトに名前を付けます。 スプレッドシートに戻り、LOOKER_RUN_LOOK()と入力します 。 =LOOKER_RUN_LOOK(look_id, format, query_limit) look_id ( 数値型 )— LookのID ( 例:) 345。 format ( 数値型、オプション )—要求された形式。数値 1 はデータを返します。数値

Lookerリリース概要

本トピックはこちらの記事をベースに日本語化したものとなります。Lookerでは継続的な機能改善および新機能追加のために、月次での製品バージョンアップを実施しています。本記事ではLookerの基本的なリリース及びアップデートのプロセスについてご紹介します。 目次Lookerの開発及びリリースサイクル リリースプロセスダイアグラム リリースナンバーについて 現在のLookerバージョンの確認方法 リリースノート リリースサポート 廃止予定の機能 アップデートプロセス Looker-Hostedインスタンスのアップデート Hosted On-Premises インスタンスのアップデート その他のお問い合わせ Lookerの開発及びリリースサイクル Lookerでは、お客様からのフィードバックや、優先度の高い機能改修をタイムリーに製品に取り込むために、高速なリリースサイクルを実施しています。月に一度、新機能追加を含む新しいバージョンがリリースされます。これをマイナーバージョンアップと呼びます。マイナーバージョンのリリースは、一ヶ月かけてすべてのお客様に順次展開されていきます。(例外的に、12月のみこのマイナーバージョンアップはお休みとなります。)また、月一度のマイナーバージョンアップ以外にも、更新パッチがリリースされることがあります。これは基本的にはバグやセキュリティ問題のFixのためのリリースとなり、新機能は含まれません。このようなパッチリリースも、標準のリリースプロセスに従って各環境に適用されるものとなります。 リリースプロセスダイアグラム   リリースナンバーについてLookerのリリースのナンバリングは、X.Y.Zの3つの数字により構成されます。Xはメジャーバージョン、Yはマイナーバージョン、Zはそのマイナーバージョンに対するパッチナンバーを意味します。メジャーバージョンアップは、製品として非常に大きな変更が入る場合、または大きなマイルストーンが発生する場合にのみ実施されます。このバージョンアップに際してお客様側で必要なプロセスとしては通常のマイナーバージョンアップ時と変わりませんが、製品としては何かしら大きな機能追加が入ることになりますので、別途大々的にアナウンスを実施します。 現在のLookerバージョンの確認方法お客様が現在ご利用の環境のバージョンは、Look

良いダッシュボードを作成するための5つの原則

(本記事はこちらのLooker Blogをベースに日本語で再構成したものとなります) 本記事では、単にデータを見せるためのダッシュボードではなく、真にエンドユーザーの役に立つダッシュボードを作成するための5つの原則についてご紹介します。その原則とは以下のとおりです ダッシュボードの “Big Idea” (目的) を見つける ワイヤーフレームについて賛同を得る 明快にする シンプルに保つ フロー(流れ)を作る 最初の2つは実際のダッシュボード構築を始める前に実施するので「調査フェーズ」と定義し、後の3つは実際にダッシュボードを構築する際に考慮することなので「作成フェーズ」としたいと思います。調査フェーズ “Big Idea” は何ですか? 伝えたいことを理解することは、良いダッシュボードを構築するためのスタート地点と言えます。そのダッシュボードを作成する背景は?なぜそれが必要なんでしょう?これらの答えを得るには、データの利用者と実際に対話するのは一番です。利用者が誰であるのか、このデータで何を達成したいのか、そしてその情報に基づいてユーザーがどんな行動をとるのか。まずはこれらを理解することが極めて重要となってきます。例えば、ビジネス上の意思決定を行う役員層と、日々物事をスムーズに動かし続ける現場のマネージャー層ではそれぞれ異なる情報を必要とします。データの利用者となるユーザーに、ダッシュボードから何を得たいのかをしっかりとヒアリングすることは、それぞれのユーザーの目標を実現するための最初のステップとなります。ユーザーには以下のような質問をして、詳細を掘り下げてみましょう:あなたにとって、データがどのように役立つと思いますか? どんな質問に対してデータで回答したいと思いますか?言い方を変えると、どのような問題を解決したいと思いますか? あなたが気にかけている最も重要な3つの指標は何ですか? それらの指標はどのように定義または計算されますか? 表示するデータを制限する必要がありますか(例えば、特定の地域または特定の期間の結果のみを確認する必要がありますか)?その理由は? 質問に答えるために必要なデータソースは現在すべて利用可能な状態になっていますか? 現状使用しているレポートで、役立っているものの例として挙げられるものはありますか?(もしあれば共有しても

テーブル計算を使った小計の計算方法

本記事は Subtotals with Table Calculations 🇺🇸 の翻訳記事です。 本記事はLookerの標準のテーブル計算機能を使って小計を算出する方法を紹介しています。Looker 6.10 では、テーブルネクストが追加されており、これを使うと小計がネイティブに算出できるようになります。より詳しい情報についてはこちらのドキュメントを参照してください。 小計(subtotal)はグループ分けされた項目の合計を手早く確認するのに使われ、例えば、全体の合計の売上数値を見つつ、同時にブランド別の売上の小計なども参照する、というようなケースで便利です。本記事ではこの実現方法についての手順をご紹介します。 これは暫定的なやり方になりますので、こちらのコミュニティーに投稿されている優れたクロス結合による小計(Subtotals with a CROSS JOIN)パターンも参照してください。より柔軟な魔法のようなやり方を学ぶことができます。 例 下記画像のような例を使って考えてみます。いくつかのブランドがあって、その中にカテゴリーとメジャーがあり、売上合計または利益が算出できるものとします。これを今回のデータセットとして考えます。 さて、ここで、例えばブランドマネジャーがブランド毎の売上合計がどのくらいなのか、つまりそれぞれのブランドの小計が欲しいというケースを考えます。 テーブル計算を使うと、それぞれのブランドの最後の行と同じ行に4つ目の列を生成することができます。 これをやってみましょう。非常にシンプルなやり方です。 方法 ステップ1 テーブル計算を作成して、それぞれのブランド毎に行番号を表示させます。 この番号はブランドが変わるたびに 1,2,3... のようにカウントしていきます。 テーブル計算は次のように書きます。 if(match(${products.brand},${products.brand})=offset(match(${products.brand},${products.brand}),-1) , 1+row()-match(${products.brand},${products.brand}) , 1) ここでは match() を使ってそれぞれのブランドが最初に登場するユニ

System Activityエクスプローラを使ってLooker活用のPDCAを回す

※ 本投稿はLooker Advent Caledar 2021 初日の記事となります。 みなさんは、社内で、あるいは社外のダッシュボードを提供している先で、どれくらいのユーザーがLookerを使っているか正しく把握できていますでしょうか?Lookerを活用してデータの民主化を進めていく上で、「多くのユーザーがきちんとLookerを使えている状態にあること」というのは気にするべき一つの重要な指標になります。せっかく頑張って作成したエクスプローラやダッシュボードも、ユーザーに使われなければ意味がありません(悲しい)。 Lookerのシステムアクティビティを使うと、みなさんが作成したダッシュボード/エクスプローラが果たしてどれだけ実際に使われているのか、ライセンスを付与したユーザーがどれだけアクティブにLookerの機能を使っているのかを確認することができます。デフォルトで用意されているSystem Activity ダッシュボードでは大まかな活用状況を知ることができますが、System Activity エクスプローラを使用すると更に一歩踏み込んだ活用状況の探索が可能になります。  以下にSystem Activityエクスプローラを使った実際の探索例と、そこから見える課題、更にはそれをどう改善していくべきか、というサンプルをいくつか示したいと思います。 ケース1: Viewerの人たち、ちゃんとLooker使ってる?利用するエクスプローラ:User利用するフィールド例: フィルター例: Viewer権限を持つユーザー数のうち、直近7日間 or 30日間にクエリを実行した人の数を取得します。部署やチーム毎にグループを設定している場合、グループ (Group.Name)のディメンションを追加することで部署・チーム毎での利用実態を確認することも可能です。 [ここから見えること]例えば以下の結果だと、Viewer相当のユーザーは128名いますが、直近7日間にクエリ実行した人は4名、30日間でも8名しかいません。これは由々しき自体です。より多くのユーザーにもっとLookerにログインし、ダッシュボードをみてもらうようにする必要があります。 [取るべきアクション]ユーザーに対して、なぜダッシュボードをみないかの理由をヒアリングしてみましょう。よくあるパターンと改善の方向性を以下