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


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


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


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


第1部 istyleの BIツールの歴史

Redash採用の背景：内製BIツール保守コストの増大
 - 2017年まで内製BIツールでデータ抽出をカバー
 - 対応データソース
 - SQL Server, BigQuery(legacy)
 - 新規サービスはほぼMySQLであったり、今後データ ソースの種別が増えるたびに改修コストが増える
 - グラフ描画機能なし
 → Redashの採用
 - 改修コスト、接続DBの対応数、IAMなどの観点で採用
 - シンプルなダッシュボードとしての機能が良い
 - 英語メニューが懸念として上がった
 現在のRedash
 - 登録クエリ数：1867, 直近半年の利用者数：163人
 
 第
 1
 部
 
 BI ツ| ル の 歴 史

他BIツールの住み分け
 - 社内で利用されているBIツール
 - Redash
 - 定点観測のKPI、ダッシュボードツールとして利用
 - 営業からプロデューサーまで幅広く利用
 - Tableau Desktop & Tableau Server
 - GUIのテーブル結合や対応データソースの数が魅力
 - ↑コード管理できず保守や引き継ぎコスト高
 - Google Analytics 360
 - 約3億PV/月のためサンプリングが発生しやすい
 - BigQueryへデータをエクスポートし分析に利用
 - 注目しているBIツール
 - Google Data Studio (Data Portal)
 - Looker
 第
 1
 部
 
 BI ツ| ル の 歴 史

今後BI(ダッシュボード)ツール選定の際に考慮すること
 - 多種のIAM
 - 実行・作成・閲覧・管理者
 - 部署単位・データ単位（個人情報・売り上げなど）で分けられ るグループ管理
 - Redash運用アンチパターン - Speaker Deck 
 - バージョン管理
 - 修正を手軽に戻せる安心感
 - 複数人ユーザーが同時編集する可能性がある場合は特に
 - 集計・描画の機能と保守性のトレードオフ
 - 何でもできるツールは何でもできるようになるまでの教育コ ストが高い
 - BIツールはデータ取得（SQL）と
 集計・描画（GUI）で大きく構成されている
 - 集計・描画が多機能なほど便利だが、コード管理
 などできず保守コストが高くなる傾向にある
 → Redashはいい塩梅だと思います
 第
 1
 部
 
 BI ツ| ル の 歴 史

第2部 istyleの データソースの歴史

複雑化するクエリと異機種DBをまたがる要望の増加
 - 2017頃まで：分析DB1台(SQL Server)+各サービスの待機系を利 用
 - 分析用のクエリに耐えきれないことが増えてきた
 - 実行時間30分越えなど
 - analyst experienceが低い
 - 異機種DBとの連携はSQL Serverの
 OPEN QUERY関数を利用
 - SQL Server記法のSQLの中にMySQL記法が
 混じり可読性が低い
 - 保守しづらい
 → 既に利用していたBigQueryをデータウェアハウスとして
 利用することに
 第
 2
 部
 
 デ| タ ソ| ス の 歴 史

BigQuery上のデータウェアハウスについて
 - 分析用のためデータの同期は日次
 - Embulkでバッチ処理
 - テーブルエクスポートが10行程度で記述可
 - 様々なDB Plugin&その他がある
 - Embulk(エンバルク)プラグインのまとめ - Qiita 
 
 
 
 
 
 - BigQueryのコスト（SQLで計算可能）
 - 同期：約450テーブル/日
 - クエリ実行数：約3000クエリ/月 (DW以外のPJT含まず)
 第
 2
 部
 
 デ| タ ソ| ス の 歴 史

DW（バッチ）は作ったがリアルタイムが求められることも
 - 日次・月次のKPI管理などには使えるDWだが
 リアルタイムのデータが求められることもある
 - 分析ではなくオペレーション業務でデータが必要な場合
 → Prestoの導入
 - 分散型のSQLクエリエンジン (https://prestodb.io/)
 - インメモリでサクサク
 - 異なるDBを1SQLでJOINできる魅力
 - SQL SERVERの
 OPENQUERY関数の課題解消
 第
 2
 部
 
 デ| タ ソ| ス の 歴 史 クライアント （BIツール、アナリストなど） SQL etc.

Prestoの利用例
 1. DBへの接続情報をカタログと呼ばれる設定ファイルに記述
 
 
 
 
 2. クエリを実行
 第
 2
 部
 
 デ| タ ソ| ス の 歴 史

現在のRedash周辺のざっくりデータ分析基盤
 
 
 
 
 
 
 
 
 
 - アプリケーション要望を叶えるために
 別途ストリーミングに対応したHadoop基盤開発中
 - ＠ｃｏｓｍｅにおけるビッグデータのこれまでとこれから 
 第
 2
 部
 
 デ| タ ソ| ス の 歴 史 BigQuery ユーザーの行動ログ クチコミや EC・実店舗 購買ログなど

現在のデータ分析基盤で出てきた課題
 - DW PJTに不要なデータセット乱立
 - GCPはプロジェクトという単位の下にデータセット（DB）、テーブル が存在する
 - プロジェクト毎にサービス単位でIAM管理可能
 - 種類：データ閲覧者、 データ編集者、データオーナー、ユーザー、ジョブユーザー、 管 理者、メタデータ閲覧者
 - tmpで格納したいテーブルなどもあるためDW PJTには基本的に データ編集者で付与していた
 → アナリストが自由に使えるBI PJTを作成（移行中）
 　 データセットの作成・tmpのテーブルは BI PJTで作成
 DW PJTは閲覧のみ可でクリーンなプロジェクト運用を目指す
 第
 2
 部
 
 デ| タ ソ| ス の 歴 史

第3部 小ネタ

Google Compute EngineにRedash配布Versionは何があるのか
 - GCEに構築する公式の手順はこちら
 
 
 
 
 
 
 - 2019年9月現在、公式の手順には Redash ver 5.0.2
 のイメージが例として出てきている
 - 調べると過去にはRedash ver 0.9.1もあったらしい
 - 他のversionのイメージも配布されているか知りたい！！
 第
 3
 部
 
 小 ネ タ

どう調べるか
 - 手順ではイメージのファイルをGoogle Cloud Storage(GCS)
 から呼び出している
 
 
 
 → gs://Redash-images/ のオブジェクトリストを取得すればいい
 → 権限エラーで失敗
 
 GCSの権限でstorage.objects.get はあるが
 storage.objects.listは与えられていない…
 →片っ端からgetしたらわかるんじゃないか 
 第
 3
 部
 
 小 ネ タ

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
 部
 
 小 ネ タ

結果…圧倒的敗北！
 
 
 
 
 
 
 - 取得したtagでGCSからイメージを取得できたのは公式手順にあるイ メージのみだった
 - 敗北の反省
 - 何も見えないわからないものに無闇に検索かけた時点で敗北
 - https://github.com/anntoque/look-Redash-images/blob/master/look-Redash-images.py 
 第
 3
 部
 
 小 ネ タ

第4部 今後の展望

非エンジニア部署の方へのSQL普及
 - BIチームのタスクは6割データ抽出依頼、4割改善
 - データ抽出タスクの効率化を目指してSQL講座の準備中
 - 一番の課題は分析しやすいビュー設計
 - 近年マイクロサービス化の影響で多くのDBが生まれ分析泣 かせになってきた
 サービス横断の分析
 - 各サービス共通の会員IDを保持しているため
 店舗、ECで購入した人がその後レビューしたかや
 どの商品と比較検討したかがわかる
 - もう少し発展した分析を行う時間を増やしていきたい
 WE ARE HIRING!!
 第
 4
 部
 
 今 後 の 展 望