REDASH JOURNEY

発表勉強会：Redash Meetup 6.0.0
タイトル: REDASH JOURNEY
Redash を中心に分析基盤の失敗談・知見をシェアします！

Transcript

1. REDASH JOURNEY istyleのBI基盤の歴史、向き合ってきた課題
 Can we change the BI? リダッシュ・ジャーニー
 山本 泰毅

2. contents
 第1部　istyleのBIツールの歴史・・・・・・・・・・・・・・・・・・・・・・・・05
 第2部　istyleのデータソースの歴史・・・・・・・・・・・・・・・・・・・・09
 第3部　小ネタ・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・16
 第4部　今後の展望・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・・21

3. プロローグ
 これは株式会社istyleで働く社員の「やーすー」が20年続くwebサービ スの分析基盤の運用の中で、BIツールやデータソースに関する知見 をまとめたスライドである。
 
 登場人物紹介
 やーすー（@YASU11552288）：
 株式会社 istyleには新卒入社で4年目。主にGCP運用、BigQuery, Digdag, Embulk, Redashといった技術を利用して分析基盤の運用を 行なっています。

4. 会社・サービス紹介
 コスメ・美容の総合サイト「＠ｃｏｓｍｅ」
 国内外3万以上のブランド、30万点以上ものコスメの商品データベースと、クチコミ検索機 能や新商品情報などを備えた日本最大のコスメ・美容の総合サイト。 1999年のオープン以来、会員数・クチコミ件数・ページビュー数ともに伸び続け、累計ク チコミ数は1,500万件を突破しています。

5. 第1部 istyleの BIツールの歴史
6. Redash採用の背景：内製BIツール保守コストの増大
 - 2017年まで内製BIツールでデータ抽出をカバー
 - 対応データソース
 - SQL Server, BigQuery(legacy)
 - 新規サービスはほぼMySQLであったり、今後データ ソースの種別が増えるたびに改修コストが増える
 - グラフ描画機能なし
 → Redashの採用
 - 改修コスト、接続DBの対応数、IAMなどの観点で採用
 - シンプルなダッシュボードとしての機能が良い
 - 英語メニューが懸念として上がった
 現在のRedash
 - 登録クエリ数：1867, 直近半年の利用者数：163人
 
 第
 1
 部
 
 BI ツ| ル の 歴 史
7. 他BIツールの住み分け
 - 社内で利用されているBIツール
 - Redash
 - 定点観測のKPI、ダッシュボードツールとして利用
 - 営業からプロデューサーまで幅広く利用
 - Tableau Desktop & Tableau Server
 - GUIのテーブル結合や対応データソースの数が魅力
 - ↑コード管理できず保守や引き継ぎコスト高
 - Google Analytics 360
 - 約3億PV/月のためサンプリングが発生しやすい
 - BigQueryへデータをエクスポートし分析に利用
 - 注目しているBIツール
 - Google Data Studio (Data Portal)
 - Looker
 第
 1
 部
 
 BI ツ| ル の 歴 史
8. 今後BI(ダッシュボード)ツール選定の際に考慮すること
 - 多種のIAM
 - 実行・作成・閲覧・管理者
 - 部署単位・データ単位（個人情報・売り上げなど）で分けられ るグループ管理
 - Redash運用アンチパターン - Speaker Deck 
 - バージョン管理
 - 修正を手軽に戻せる安心感
 - 複数人ユーザーが同時編集する可能性がある場合は特に
 - 集計・描画の機能と保守性のトレードオフ
 - 何でもできるツールは何でもできるようになるまでの教育コ ストが高い
 - BIツールはデータ取得（SQL）と
 集計・描画（GUI）で大きく構成されている
 - 集計・描画が多機能なほど便利だが、コード管理
 などできず保守コストが高くなる傾向にある
 → Redashはいい塩梅だと思います
 第
 1
 部
 
 BI ツ| ル の 歴 史
9. 第2部 istyleの データソースの歴史
10. 複雑化するクエリと異機種DBをまたがる要望の増加
 - 2017頃まで：分析DB1台(SQL Server)+各サービスの待機系を利 用
 - 分析用のクエリに耐えきれないことが増えてきた
 - 実行時間30分越えなど
 - analyst experienceが低い
 - 異機種DBとの連携はSQL Serverの
 OPEN QUERY関数を利用
 - SQL Server記法のSQLの中にMySQL記法が
 混じり可読性が低い
 - 保守しづらい
 → 既に利用していたBigQueryをデータウェアハウスとして
 利用することに
 第
 2
 部
 
 デ| タ ソ| ス の 歴 史
11. BigQuery上のデータウェアハウスについて
 - 分析用のためデータの同期は日次
 - Embulkでバッチ処理
 - テーブルエクスポートが10行程度で記述可
 - 様々なDB Plugin&その他がある
 - Embulk(エンバルク)プラグインのまとめ - Qiita 
 
 
 
 
 
 - BigQueryのコスト（SQLで計算可能）
 - 同期：約450テーブル/日
 - クエリ実行数：約3000クエリ/月 (DW以外のPJT含まず)
 第
 2
 部
 
 デ| タ ソ| ス の 歴 史
12. DW（バッチ）は作ったがリアルタイムが求められることも
 - 日次・月次のKPI管理などには使えるDWだが
 リアルタイムのデータが求められることもある
 - 分析ではなくオペレーション業務でデータが必要な場合
 → Prestoの導入
 - 分散型のSQLクエリエンジン (https://prestodb.io/)
 - インメモリでサクサク
 - 異なるDBを1SQLでJOINできる魅力
 - SQL SERVERの
 OPENQUERY関数の課題解消
 第
 2
 部
 
 デ| タ ソ| ス の 歴 史 クライアント （BIツール、アナリストなど） SQL etc.
13. Prestoの利用例
 1. DBへの接続情報をカタログと呼ばれる設定ファイルに記述
 
 
 
 
 2. クエリを実行
 第
 2
 部
 
 デ| タ ソ| ス の 歴 史
14. 現在のRedash周辺のざっくりデータ分析基盤
 
 
 
 
 
 
 
 
 
 - アプリケーション要望を叶えるために
 別途ストリーミングに対応したHadoop基盤開発中
 - ＠ｃｏｓｍｅにおけるビッグデータのこれまでとこれから 
 第
 2
 部
 
 デ| タ ソ| ス の 歴 史 BigQuery ユーザーの行動ログ クチコミや EC・実店舗 購買ログなど
15. 現在のデータ分析基盤で出てきた課題
 - DW PJTに不要なデータセット乱立
 - GCPはプロジェクトという単位の下にデータセット（DB）、テーブル が存在する
 - プロジェクト毎にサービス単位でIAM管理可能
 - 種類：データ閲覧者、 データ編集者、データオーナー、ユーザー、ジョブユーザー、 管 理者、メタデータ閲覧者
 - tmpで格納したいテーブルなどもあるためDW PJTには基本的に データ編集者で付与していた
 → アナリストが自由に使えるBI PJTを作成（移行中）
 　 データセットの作成・tmpのテーブルは BI PJTで作成
 DW PJTは閲覧のみ可でクリーンなプロジェクト運用を目指す
 第
 2
 部
 
 デ| タ ソ| ス の 歴 史
16. 第3部 小ネタ
17. Google Compute EngineにRedash配布Versionは何があるのか
 - GCEに構築する公式の手順はこちら
 
 
 
 
 
 
 - 2019年9月現在、公式の手順には Redash ver 5.0.2
 のイメージが例として出てきている
 - 調べると過去にはRedash ver 0.9.1もあったらしい
 - 他のversionのイメージも配布されているか知りたい！！
 第
 3
 部
 
 小 ネ タ
18. どう調べるか
 - 手順ではイメージのファイルをGoogle Cloud Storage(GCS)
 から呼び出している
 
 
 
 → gs://Redash-images/ のオブジェクトリストを取得すればいい
 → 権限エラーで失敗
 
 GCSの権限でstorage.objects.get はあるが
 storage.objects.listは与えられていない…
 →片っ端からgetしたらわかるんじゃないか 
 第
 3
 部
 
 小 ネ タ
19. tarファイルの名前を推測
 - Redash.5.0.2-b5486-build2.tar.gzの
 「Redash.5.0.2-b5486」部分はdocker hubで
 配布しているRedash imageのtag名から来ているみたい
 - https://hub.docker.com/r/Redash/Redash/tags 
 - docker hubはimageのtag一覧を取得できるAPIを提供しているので利 用する
 - https://registry.hub.docker.com/v2/repositories/Redash/Redash/tags 第
 3
 部
 
 小 ネ タ
20. 結果…圧倒的敗北！
 
 
 
 
 
 
 - 取得したtagでGCSからイメージを取得できたのは公式手順にあるイ メージのみだった
 - 敗北の反省
 - 何も見えないわからないものに無闇に検索かけた時点で敗北
 - https://github.com/anntoque/look-Redash-images/blob/master/look-Redash-images.py 
 第
 3
 部
 
 小 ネ タ
21. 第4部 今後の展望
22. 非エンジニア部署の方へのSQL普及
 - BIチームのタスクは6割データ抽出依頼、4割改善
 - データ抽出タスクの効率化を目指してSQL講座の準備中
 - 一番の課題は分析しやすいビュー設計
 - 近年マイクロサービス化の影響で多くのDBが生まれ分析泣 かせになってきた
 サービス横断の分析
 - 各サービス共通の会員IDを保持しているため
 店舗、ECで購入した人がその後レビューしたかや
 どの商品と比較検討したかがわかる
 - もう少し発展した分析を行う時間を増やしていきたい
 WE ARE HIRING!!
 第
 4
 部
 
 今 後 の 展 望