コラム

Lookerにまつわるあれこれ

  • 69 Topics
  • 8 Replies

69 Topics

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

TopoJSON を利用した地図上での可視化分析 (500m メッシュ)

Lookerで地図上にデータを可視化する方法として、一番手軽なのは、topoJSONファイルを用意して可視化をする方法になります。ただし、topoJSON形式で表示する地図データは粒度が細かくなるほど、ファイルサイズが大きくなってしまうため、市区町村単位や、250m、500mメッシュという細かい粒度で表現するには向いていません。上記の場合は、タイルを利用した大規模カスタム・マップ・レイヤー を参照ください。 とはいえ、一部の地域に限定する形でも構わないので、タイルを利用せずにメッシュ表示を行うための方法をご紹介します。(なお、当記事で記載しているリンク先は執筆現在の情報ですので、変更があった場合は、コメントなどで教えていただけますと幸いです。また、LookMLの書き方以外の部分については、弊社サポートチームではご対応致しかねますので、本記事に関してのご質問はコメントにてお願いいたします) 今回は、東京都の中央区・千代田区・港区・新宿区の事業所数を500mメッシュで表示してみようと思います。実現するためには、以下の手順が必要となります。 境界線データの準備 データ表示用のサンプルデータの準備 LookMLの作成 なお、今回は、メッシュコードを利用して表示しています。メッシュコード については、e-Statのホームページに定義が記載されています 1. 境界線データの準備 まずは、地図上に表示する際に必要となる境界線データは、こちらの e-Statのホームページから境界線データを取得します。 今回は500mメッシュでの表示を行いますので、4次メッシュから世界測地系緯度経度・Shapefileを選択します。ファイルが1次メッシュ単位で区切られているのですが、東京都が含まれているのは、M5339となります。 このままでは、Lookerで取り扱えないのでファイルを変換する必要があるのですが、そのまま変換してしまうとファイルサイズが大きくなってしまうので分割を行います。 分割を行うために、 先ほどダウンロードしたZIPファイルを解凍する 含まれているdbf, prj, shp, shxをドラッグ&ドロップしてmapshaperというサイトでインポートします。 画面でExplortをクリックし、geoJSON形式してダウンロードします 次に、ダウンロードしたファ

Lookerで表計算結果のランクを動的なフィルタとして使う - Qiita

※タイトル通り&ほとんどこの記事の和訳です。 やりたかったこと 事前にviewで定義しておくのではなく、粒度や集計軸を動的に変えられるランクをフィルタとして使いたかった。 ハードル 事前にviewで定義したrank dimensionを使うと、集計軸ごとに複数dimensionを作らなければいけない。 Explore上でTableCalcurations機能を使って作った計算結果はフィルタとして使えない。 使っているテクニック parameter Table Calculations Hide from Visualization Hide "No"s from Visualization やり方 ①viewに type: numberのdimension と parameterの2つを追加する。この時、dimensionのsql句ではparameterの名前を指定する。(この例ではmax_rank) parameter: max_rank { type: number } dimension: rank_limit { type: number sql: {% parameter max_rank %} ;; } ②Exploreに移動。好みの粒度で集計し、ソートをかけたところにさっき作成したdimension(例ではrank_limit)を追加。max_rankはfilterとして追加し、上位何件表示したいかを入力しておく。 (max_rankで入力した値はrank_limitに渡され、固定値として表示される) ③表計算を2つ作成。1つ目はRankで、どの指標でランキングを作成するかを指定。2つ目はBooleanで、前に作成したRank計算結果とrank_limitを比較するもの。戻り値はyesno型。 (この時、表計算を利用するため表の中に使っていないmeasureを使うことはできないので注意) ④作成した2つの表計算はHide from Visualizationする。 ⑤表計算結果であるshow_in_visualizationの設定から、Hide "No"s from Visualizationを選択すると、Noが返ってきている行がVisualizationに出てこなくなる。 解説 データベース上に存在しない値でもユーザー側から任

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

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

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で検証したデータを元に予測をしていきま

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

🇺🇸 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:

[Analytic Block]派生テーブルのパターン

🇺🇸 [Analytic Block] Derived Tables Pattern in English 🇺🇸 このブロックについて 多くの場合、私達のデータベースは分析のために最適化された情報を保持していません。必要なものを計算するための非効率なディメンションやメジャーを記述するのではなく、派生テーブルを使用すると、私達のデータベースの中に直接一時テーブルを作成できます。派生テーブルを使用すると、中間集計を必要とする分析を実行し、複雑なクエリのクエリパフォーマンスを向上させ、データをクレンジングまたは正規化するためのパターンを作成できます。 簡単に言えば、派生テーブルは、データベースに存在しない新しいテーブルを作成するLookerの方法です。 結果セットが派生テーブルそのものになるSQLクエリを提供することによってこれを定義します。 Lookerは派生テーブルに一時的 か 永続的の 2つのオプションを提供しています。一時的な派生テーブルはデータベースに保存されません。Lookerは共通のテーブル式を利用するか、この派生テーブルが参照されるたびに毎回一時テーブルを生成します。あるいは、永続派生テーブル(PDTs)はディスクに書き込まれ、選択した頻度で更新されます。このプロセスを行うために、データベース内のスクラッチスキーマにLookerの書き込み権限を提供する必要があります。PDTはマテリアライズド・ビューによく似ています。 理想的なデータ型 すべてのどんなデータでも、派生テーブルの恩恵を受けることができます。この記事の終わり近くに、派生テーブルを活用するデザインパターンへのリンクがあります。データベースによっては、PDTは利用できない場合がありますので注意してください。ただし、Lookerでサポートされているすべてのダイアレクトでは、一時派生テーブルをサポートしています。 期待される出力 下記は、以下のコードで書かれている派生テーブルのExploreです。機能的には通常のビューと同じであることに注目してください。 Explore Data in Full Screen 使い方 標準的なEコマースの例を使い、同じユーザーによって複数の注文が入ってくる”orders”というテーブルがあるとします。

salesforceをIdPにしてSAMLでSSOする方法

LookerはSAMLに対応しており、SP-initiatedでSSOすることが可能です。 今回は、SalesforceをIdPとして接続し、Lookerにログインするための設定手順を以下に示します。 まず、salesforceをIdPとして利用できるようにするために、salesforceにて以下の設定がまず必要です。salesforceのヘルプを参照して、設定してください。 A. 私のドメインを登録 B. IDプロバイダの有効化 こちらが完了していることを前提に、今回の目的のための設定手順を説明します。 手順 Salesforceの接続アプリケーションを登録 1.1 設定画面に移動し、ID -> IDプロバイダ へ移動する 1.2 画面上部にある”証明書のダウンロード”ボタンをクリックし、証明書をダウンロードする ※ Lookerでの設定に利用 1.3 画面下部にあるサービスプロバイダのセクションにあるリンクをクリック 1.4 表示された画面の項目に、以下のLookerのインスタンスに関する情報を入力し、保存する 接続アプリケーション名: 任意の名前 (例 Looker) API参照名: 任意の名前 (例 Looker) 取引先責任者メール: システム管理者のメールアドレス 開始URL: LookerインスタンスのURL (例 https://xyz.jp.looker.com/) SAMLの有効化:チェック入れる エンティティID:任意のFQDN形式の文字列 ※Lookerでも同じ文字列をセットする必要あり ACS URL:LookerインスタンスのURL + /samlcallback (例 https://xyz.jp.looker.com/samlcallback) 件名識別:統合ID 名前ID形式:urn:oasis:names:tc:SAML:2.0:nameid-format:transient 発行者:任意のFQDN形式の文字列 ※Lookerでも同じ文字列をセットする必要あり Idp証明書:デフォルトのIdP証明書 他の項目は空白のまま 1.5 保存後、以下の画面にて"Manageボタン"をクリック 1.6 画面が切り替わった後、画面下部にあるプロファイルにて、"プロファイルを管理する"ボタンをクリックする 1.7 Loo

Firebase Blocks v3 (日本語翻訳記事)

本記事は github で提供されている Firebase Blocks 🇺🇸の Readme の翻訳です。 この block の役割 BigQueryにあるFirebaseデータには大きな分析ポテンシャルがありますが、クエリーできるようにするのは簡単ではありません。それは以下のような理由があります: 毎日新しいテーブルが(events_YYYYMMDDという名前で)作成されてしまうため。これによりBigQueryのコストは下がりますが、クエリーがより複雑になってしまいます。 どの event_name も、 event_params.key や event_params.value のようなネストされた Key-Value 型のペアになっており、クエリーするときに複雑な UNNEST 処理を行う必要があるためです。 user_properties も同様に Key-Value のペアになっていて何階層にもネストしているからです。 この block でできること 期間を選択して魔法のようにパーティションされたテーブルから必要なデータを選択できるネイティブな方法を生成します。 セッション化(Sessionization)を追加できます。(これはFirebaseデータにはありません) [訳注] 「セッション化」についてはこちらの記事も参考にしてください。 リテンションのコホート分析を追加できます。 event_name または event_params.key 、 user_properties の組み合わせのディメンションを作成できます。 データのモデリングを開始して価値を引き出すための最初のステップとして最適です。 仕組み どの Firebase スキーマも類似点は多いものの event type と user properties は異なるため、この block が event 構造に沿ったユニークなスキーマを生成します。Python notebook を使用して Looker API とご自身のデータベースに接続してLookMLを自動生成します。 利用方法 Looker側の準備 こちらの記事を参考にしてリポジトリーからクローンしてプロジェクトを新規作成します。 https://docs.looker

JOIN 2017- Deep Dive - PDTを利用するかどうか

🇺🇸JOIN 2017 - Deep Dive - To Use or Not Use PDT’s🇺🇸 何故PDTとETLの実用的なバランスが重要なのでしょうか? データベースリソースをより効率的かつ効果的に利用する エンドユーザーの体験を向上させる 最適化されたデータパイプラインはスケーラブルな分析のために安定したインフラストラクチャを提供する 1. ETD,PDTとETLをいつ使うか EDT リアルタイムデータ 高速にクエリする 動的な構築 PDT データの新鮮さ データベースリソースが利用可能であること プロトタイプづくり ETL 強力なETLツール - Discourse Discussion 例を上げると: Matillion, Talend, Alooma, ETLeap, Keboola, DataVirtuality, Xplenty PDTの十分な理解 一貫して使用されるPDT Lookerの外部で使用されるPDT 2. データベースを知る Looker The Pocket Guide to Databases Looking for a database solution? Get started with this guide by the experts at Looker. Discourse Discussion 3. PDT構築とETLパフォーマンスを向上させるためにデータベースを最適化 Fabioのディープドライブ - LookerのRedshiftブロックプレゼンテーションを使ったRedshift の最適化では、幅広いデータベースに適用される一般的なデータベース最適化と同じような概念と手法を提供します。 JOIN 2017 - Deep Dive - Redshift Optimization with Looker's Redshift Block Modeling Whether business users are exploring or just loading a

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がホスティングしているものになります。

System Activityで見えること

こんにちは。LookerAdvent Calendar15日目の記事として「System Activity」について少し掘り下げて書いて見ようと思います 。 1. System Activityとは Lookerは、インストールされているインスタンスに関する使用状況やパフォーマンス情報等を保持しています。System Activityは、Labsの機能ですが有効にするとそれらの情報をダッシュボードやExploreで閲覧することができるようになります。 System Activity 2.誰がアクセスできるの? Lookerの管理者および、「see_system_activity」パーミッションが与えられているユーザーが利用可能です。(Permission Listについてはこちら) 3. 有効化方法 Lookerの[管理]メニュー内の[Labs]の中の[System Activity Model]をONにします。 Lookerの画面を更新すると、管理メニュー内に[System Activity] メニューが表示されるようになります。 4. User Activityで見えること ユーザーの利用状況に関する情報を確認することが出来ます。 例えば、以下の数値が確認出来ます。 ユーザーアカウントと利用状況 各種ユーザー数 どんな権限のユーザーがどのくらいいるかを確認出来ます。 ユーザー数合計、管理者/開発者、コンテンツ制作者、データコンシューマ(閲覧者)、埋め込みコンテンツ制作者、アクティブユーザーの割合(過去7日間にクエリかけたことある人/全ユーザー) クエリーユーザー数:過去6週間の、週次のクエリ実行者数です。 ユーザー別エンゲージメント 過去6週間の、週次のユーザーあたりの平均利用時間(クエリ実行時間から推測)と平均クエリ実行数 グループ別のクエリ実行者数(過去7日) 過去7日以内で実行した人、していない人の人数をグループ別に。 日別のクエリソース別の実行者数(過去7日) Dashboard、Explore、API、スケジュールタスク等のクエリソース別の実行者数 ユーザーに関する詳細 トップユーザー 過去7日以内の利用時間(クエリ実行時間から推測)のトップ10ユーザー トップダッシュボード構築者 過去7日以内に

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

本記事は 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() を使ってそれぞれのブランドが最初に登場するユニ

強力なデータのドリルダウン

🇺🇸More Powerful Data Drilling🇺🇸 基本的なメジャーのドリルダウン Lookerのユニークな点の一つは、データベースに直接接続するところです。これは、常に新鮮なデータにアクセスでき かつ 常に最も細かい粒度のレベルまでドリルダウンできる事を意味します。そのため、もちろん年次や月次のサマリーを見ることができますが、Lookerは日、時間や秒にまで瞬時にドリルダウンするオプションを提供します。 常時のカテゴリ概要からはじめ、次に1つのカテゴリ(ジーンズ)の月次売上チャートにドリルダウンするのを以下で見ることができます。 さらにいろいろな使い方 しかし、LookerのWebネイティブのモダンなアーキテクチャは、1つのレベルから次の粒度までドリルダウンするだけでなく、もっと多くを実現できる事を意味しています。いくつかの簡単なパラメータを利用して、ユーザーが望む洗練されているカスタムドリルパスを構築することができます。 これを実証するために、以下で最も一般的なドリルパターンのいくつかのサンプルコードを作成しました。: 並べ替えと制限 (例:上位20件を表示) データのピボット トレンドラインを使用した高度なビジュアライゼーションへのドリルダウン D3とJavascriptで構築できるカスタムVizへのドリルダウン 条件付き書式を使用した表計算へのドリルダウン カスタム制限の追加 (5000まで) 最初の20件の結果を表示する LookML measure: returned_count { type: count_distinct sql: ${id} ;; filters: { field: is_returned value: "yes" } drill_fields: [detail*] link: {label: "Explore Top 20 Results" url: "{{ link }}&limit=20" } } 並べ替えの追加 売上上位20件を表示する LookML measure: returned_count { type: count_di

「最新の」値だけをメジャーにする方法

この記事は、Only measuring the “latest” values🇺🇸 の翻訳記事です メジャーとは何か? 非常に多くのケースで、私たちは、自分自身に不必要な制約をかけてしまって、メジャーやメトリック、あるいは集約するということは、SQLで提供される基本的な集約であるSUM、COUNT、AVERAGE(あるいは方言がサポートされている場合はMEDIANも含む)のことであると考えてしまいます。 しかしここでちょっと立ち戻って、なんのメジャーが本質的なのかを考えてみましょう - 通常、あるグループやディメンションの中で、潜在的に多数の基礎データポイントを取得して、それらを利用可能なデータに凝縮するメジャーを選びましょう。数千の注文を集約する際は? メジャーには総売上が良いです。数百万のセッションでは? サイトの平均滞在時間が良さそうです。何百万人ものセグメントあたりユーザー数は? 訪問頻度のヒストグラムになります。多数のキャンペーンと、たくさんの日付、訪問データは? 直近30日間の訪問回数のスパークラインなど。 上記の例はちょっと言い過ぎかもしれませんが、要点はつまり、あなたの想像力が制約になっているということです。ここでは、最新のデータポイントのみを使用する必要があるデータを要約するときの簡単なメジャー使用方法を次に示します。例としては、在庫のスナップショットや、バランス・シート、タイムスタンプ付きの変更リストが与えられた属性の状態履歴などのデータです。 「最新の」メジャー 今、以下のような在庫のスナップショットデータで、日毎にそれぞれ在庫数を持っているとします。 INVENTORY_SNAPSHOT inventory_id | taken_at | amount ------------------------------------ 1 | 2018-01-01 | 17 2 | 2018-01-01 | 9 3 | 2018-01-01 | 29 1 | 2018-01-02 | 13 2 | 2018-01-02 | 37 3

アグリゲートアウェアネスによるパフォーマンス改善

本トピックは、弊社のHelpに記載のAggregate Awareness using _in_queryを翻訳したものになります。 Liquid attribute の _in_query を利用することで、Exploreでユーザがどのフィールドを選択し、SQLを動的に変更することが可能になります。これにより、多くの潜在的なユースケースが考えられます。この記事では、データベースリソースの消費を削減することで合理的にパフォーマンスを向上させる「アグリゲート・アウェアネス」と呼ばれる概念に焦点を当てています。 Lookerの多くのお客様は、イベントレベルまたはトランザクションレベルで非常に大量の詳細なデータをレポーティングしています。これは、個々のレコードの調査など、特定のシナリオには役立ちますが、基本的な統計だけが必要な場合、詳細なデータのクエリには多大なコストがかかります。 一般的な解決策は、これらのユースケース用に、より集約されたテーブルを作成することです。この場合、クエリのコストは低くなりますが、それぞれ独自のエクスプローラを利用する必要があります。そして、エンドユーザーが利用すべき最適なエクスプローラを知らない状況が発生する可能性があります。 _in_queryを利用することにより、一つのExploreだけを利用して、最適な集約データへのルーティングを行うことが可能になり、この問題を解決することができます。これは、基本的な統計に対しての問合せ時間を減らすことが可能です。 サンプル これは、LookerのLiquid variable ドキュメントにて提供されているものに近い基本的な利用例です: view: orders { sql_table_name: {% if orders.created_date._in_query %} orders {% elsif orders.created_week._in_query %} orders_smry_week {% elsif orders.created_month._in_query %} orders_smry_month {% else %} orders_smry_year {% endif %} ;;

Looks や Dashboards のSalesforce (SFDC)への埋め込み

🇺🇸 Embedding Looks and Dashboards into Salesforce (SFDC) in English 🇺🇸 多くのデータに精通した企業は、Salesforceのようなツールを運用するチームを持っています。一部のお客様は、LookerをSalesforceに組み込んで内部のデータベースからアカウントアクティビティのクイックビューやリード情報を閲覧できるようにしています。 以下は、LookerをSalesforceに埋め込む方法の例 です。 LookerをSalesforceに埋め込むには、各ユーザーにLookerのアクセス権限が必要です。データはSalesforceプラットフォームには渡されるのではなく、パラメータ化されたiFrameとして埋め込まれます。 始めるためにの簡単な手順を次に示します: 前提条件: Looker! Salesforce の管理者アカウント SFDCレコードとデータベース内レコード間のマッピング可能な関係(結合可能なキー) ステップ 1: VisualForceページを作成する((設定 - 開発 - ページ).ダッシュボードか単一のルック/クエリを挿入するかで、コードは若干異なりますl.要素をページに適切に合わせるために、幅と高さを調整する必要があります。 ダッシュボード 例 ダッシュボードまたはExploreのURLから、Salesforce変数を利用してクエリをフィルタリングするためのワイルドカードを挿入するだけです。最初の例では、ページの SalesforceアカウントIDを挿入し、 {!Account.Id}をLookerダッシュボードのsalesforce_userid フィルターに挿入します。通常のダッシュボードはURLの前に/embed/を付加する必要があることに注意してください。 <apex:page standardController="Account"> <apex:iframe src="https://example.looker.com/embed/dashboards/123?salesforce_userid={!Account.Id}" width="900px" height=