運用してわかったLookerの本質的メリット : Data Engineering Study #8
?
1 like?2,579 views
Data Engineering Study #8 でのLooker事例発表です。 https://forkwell.connpass.com/event/209803/ BIツールの運用コストは「データアーキテクチャの複雑さ」と「アウトプットの多様さ」の掛け合わせで決まると考えています。その2つをマネジメントしやすいBIツールとして、株式会社ヤプリのLooker事例をご紹介します。Lookerは「強くてニューゲーム」ができる素敵なツールだと思います。
![BIツール 運用コスト対応例
これまでBI界隈では、運用コストへの対応方法が議論されてきた
対応キャパシティを増やす取組 [データの民主化]
● SQL研修、BIツール運用スキルシェア
● 質問窓口やオフィスアワーの設置
クエリ作成労力を
軽減する取組
● クエリのGit管理
● viewテーブル活用
最小限のアウトプットで要望を満たす取組
● 依頼テンプレ化、チケット制
● Google スプレッドシートのデータコネクトや定型クエリでの運用
● 分析環境や分析作法の社内共有
vs
同コストで成果を最大化する取組
● 精緻なニーズヒアリングとアウト
プット活用コンサルティング
● BIツール利用状況モニタリング
● 意思決定層向けアウトプットのみ対
応
∝](https://image.slidesharecdn.com/ccc-210602080223/85/Looker-Data-Engineering-Study-8-16-320.jpg)
![最小限のアウトプットで要望を満たす取組
● 依頼窓口統一、依頼テンプレ化、チケット制
● 定型クエリや、Google Sheetsやslackでの定型アウトプット運用
● 分析環境や分析リテラシーの社内共有
これまでBI界隈では、運用コストへの対応方法が議論されてきた
対応キャパシティを増やす取組 [データの民主化]
● SQL研修、BIツールスキルシェア
● 質問窓口やオフィスアワーの設置
Looker はテーブル構造の複雑さにアプローチしやすいツール
クエリ作成労力を
軽減する取組
● クエリのGit管理
● viewテーブル活用
vs
∝](https://image.slidesharecdn.com/ccc-210602080223/85/Looker-Data-Engineering-Study-8-17-320.jpg)
![一元管理
機能適用
出しわけ
dimension: xx_id {
label: "xxID"
type: string
description: "??の場合に想定外に IDを発行してしまうため、 ${correct_flg} = 1のみIDを残す。
sql: IF(${correct_flg}=1, ${xx_id}, NULL) ;;
}
measure: UU {
label: "ユーザ数"
type: count_distinct
sql: ${uuid} ;;
drill_fields: [user_id, os, age] #全ダッシュボードで、この項目でドリルダウンできる
link: {
label: "管理画面を確認する "
url: "https://xxxxxxxxxxxxxxxx"
}}
measure: UU_dynamic {
label: "ユーザ数"
type: number
sql:
{% if _parameter_value == '有効ユーザー' %} #このパラメーター値はダッシュボード上から指定できる
${UU_effective}
{% else %}
${UU_total}
{% endif %};;
}
Lookerのviewファイル例（LookML）](https://image.slidesharecdn.com/ccc-210602080223/85/Looker-Data-Engineering-Study-8-24-320.jpg)
運用してわかったLookerの本質的メリット : Data Engineering Study #8
- 2. 1. BIツール 弊社導入状況 2. BIツール 運用コストの考察 3. Looker の本質的メリット Today’s BIツール運用コスト = テーブル構造の複雑さ × アウトプットの多様さ AGENDA Lookerはアジャイル的に運用しやすい Lookerを社内外向けに広く利用
- 4. 株式会社ヤプリ 東京都港区六本木 3-2-1 住友不動産六本木グランドタワー 41階 設立：2013 年4月 資本金：24億9,741万円 上場市場：東証マザーズ（銘柄コード： 4168） ※2021年1月31日 時点
- 5. 近年スマートフォンが急速に人々の生活に普及している中、アプリのテクノロジーの重要性は日々増してきております。 Yappliは「Mobile Tech for All～モバイルテクノロジーで世の中をもっと便利に、もっと楽しく～」という経営理念の下、 アプリ開発技術がなくてもノーコード（プログラミング不要）で アプリを開発、運用できるクラウド型のアプリプラットフォーム提供することで、 アプリのテクノロジーをあらゆる企業や産業に開放し、 社会のデジタルトランスフォーメーションやモバイルシフトの支援を行っています。
- 7. Yappliプラットフォームが提供する主なソリューション Yappli for Marketing（toC アプリ） Yappli for Company（toB アプリ） 店舗?OMO ポイントカードやクーポンで店舗集客 EC 連携 EC サイト連携やプッシュ通知で EC 集客強化 BtoB コミュニケーション 商品カタログや営業資料をデジタル化。 取引先や販売店への営業支援に活用 社内コミュニケーション 社内報や研修動画をアプリに集約。 社内コミュニケーションを強化
- 8. 导入実绩450社以上
- 10. Looker 利用状況 社内?社外向けに2つの Looker インスタンスを契約 App by Yappli Cloud Run, DataFlow, Pub/Sub etc Employee Client for Internal Use for External Use
- 11. Looker 利用状況 少人数で多様なデータ活用に対応 App by Yappli Cloud Run, DataFlow, Pub/Sub etc Employee Client for Internal Use for External Use Users 15+ Avg Queries 700+ Avg Minutes 100+ Used Dashboards 30+ * last 7 days 経営企画, マーケティング, IS/FS, カ スタマーサクセス オプションを ご契約頂いた クライアントさま ETL / LookML 1.5人で対応 SRE 1人 Server 2人 Apps 550+ DataSources 30+
- 12. ご参考 Google Cloud Day: Digital ’21 発表 アプリのログ収集基盤の詳細はこちらをご覧ください Google Cloud 事例記事
- 13. 2 BIツール 運用コストの考察
- 14. BIツール 運用コストとは BIツール 運用コスト = テーブル構造の複雑さ × アウトプットの多様さ
- 15. BIツール 運用コスト例 どんな集計も GROUP BY 一発で対応可能ならば アウトプット増えても平気 WITH句で何百行も消費するくらい 事前のデータハンドリングが必要ならば アウトプット少なくても大変
- 16. BIツール 運用コスト対応例 これまでBI界隈では、運用コストへの対応方法が議論されてきた 対応キャパシティを増やす取組 [データの民主化] ● SQL研修、BIツール運用スキルシェア ● 質問窓口やオフィスアワーの設置 クエリ作成労力を 軽減する取組 ● クエリのGit管理 ● viewテーブル活用 最小限のアウトプットで要望を満たす取組 ● 依頼テンプレ化、チケット制 ● Google スプレッドシートのデータコネクトや定型クエリでの運用 ● 分析環境や分析作法の社内共有 vs 同コストで成果を最大化する取組 ● 精緻なニーズヒアリングとアウト プット活用コンサルティング ● BIツール利用状況モニタリング ● 意思決定層向けアウトプットのみ対 応 ∝
- 17. 最小限のアウトプットで要望を満たす取組 ● 依頼窓口統一、依頼テンプレ化、チケット制 ● 定型クエリや、Google Sheetsやslackでの定型アウトプット運用 ● 分析環境や分析リテラシーの社内共有 これまでBI界隈では、運用コストへの対応方法が議論されてきた 対応キャパシティを増やす取組 [データの民主化] ● SQL研修、BIツールスキルシェア ● 質問窓口やオフィスアワーの設置 Looker はテーブル構造の複雑さにアプローチしやすいツール クエリ作成労力を 軽減する取組 ● クエリのGit管理 ● viewテーブル活用 vs ∝
- 19. ※ Looker blog : Data matters. The journey to agile analytics. https://looker.com/blog/the-journey-to-agile-analytics, (参照 2021-05-15)
- 20. 多様なデータ 多様なアウトプット モデリング層で、多様性への対処が可能 ※モデリング層：超ざっくりいうと、 LookMLという言語で、高機能で一元的な viewテーブルを作成できる層 ※ Looker blog : Data matters. The journey to agile analytics. https://looker.com/blog/the-journey-to-agile-analytics, (参照 2021-05-15)
- 23. モデリング層の得手不得手 不得意なこと / 気をつけること 計算に時間を要する処理 計算時間がかかるクエリ処理をモデリング層に託すとダッ シュボード操作時の待ち時間が長くなり、実用性が低下す る。その場合はデータマート化を検討する必要あり（データ マート作成もLookerで賄えますが、既存システムと相談し ましょう） モデリング層の設計難易度 モデリング層で冗長にviewファイルを用意してしまうなど、 設計によっては、一元管理できない事態に容易に陥る。つ まり、指標や定義が乱立してしまい、折角のLookerの恩 恵を受けられなくなる。イメージとしてLookerは「拡張性の 高いデータマートを簡便に試作?運用できるツール」であ る。だからこそ、従来のデータマート構築と同様に設計が 大事 得意なこと 一元管理 モデリング層では、既存のデータマートの拡張や変更 を一元的に行える 機能適用 ドリルダウンやリンク遷移などの機能を、ディメンジョン やメジャーに対してパラメーターとして設定可能。全ダッ シュボードに対して、分析の価値を高める機能を一括 アップデートできる 出し分け 例えば、期間粒度（年 or 四半期 or 月）や、指標の種 類を、ダッシュボード上のフィルター操作やユーザー属 性に応じて変更できる。そのため、データソースを1つに 留めたまま用途を拡張できる
- 24. 一元管理 機能適用 出しわけ dimension: xx_id { label: "xxID" type: string description: "??の場合に想定外に IDを発行してしまうため、 ${correct_flg} = 1のみIDを残す。 sql: IF(${correct_flg}=1, ${xx_id}, NULL) ;; } measure: UU { label: "ユーザ数" type: count_distinct sql: ${uuid} ;; drill_fields: [user_id, os, age] #全ダッシュボードで、この項目でドリルダウンできる link: { label: "管理画面を確認する " url: "https://xxxxxxxxxxxxxxxx" }} measure: UU_dynamic { label: "ユーザ数" type: number sql: {% if _parameter_value == '有効ユーザー' %} #このパラメーター値はダッシュボード上から指定できる ${UU_effective} {% else %} ${UU_total} {% endif %};; } Lookerのviewファイル例（LookML）
- 25. まとめ Lookerは強くてニューゲームしやすいツール その心は…… ● 強い状態でニューゲームできる ○ 「豊富な経験値を持った今の俺たちが考える理想構成」を、 ETL / ELT ワークフローを変更せ ずとも、モデリング層で疑似的に実現できる ● 何周もするほど強くなる ○ 1周目のLookML構築は大体上手くいかない ○ 1周目で見逃していたオイシイ仕掛け（機能）に、 2周目以降気付く ● やりこみ要素が満載 ○ 己が強くないと裏ボスにボコボコにされる。 Lookerの力を引き出せないまま比較的高価なラ イセンスフィーを持っていかれる
- 26. Happy Analysis !