@ariarijp さんと、@kakakakakku さんが運営されているRedash Meetup #1に参加してきました。
僕は年始から会社でRedashを導入していて、MySQL（AWS Aurora）と Elasticsearchをデータソースとして運用しています。
日本初のRedash Meetup！？
Redashについて、以前から名前は知っていましたし、昨年12月、今年の1月と続いてハンズオン会などが開催されていたりしたものの、ユーザーなどが集まってRedash単体の話をするような勉強会は僕が調べた限り始めてだったのではないかと思います。（間違っていたらすみません）
そういう会に参加できてうれしかったです！
会自体は2人の方の20分ほどの発表、5分 * 2のLTという構成でした。
19時半開始、20時45分解散というすごく健全な勉強会でした。
発表
Redash 導入事例から考える OSS BI ツール導入チェックリスト - ariarijp
ariarijpさんが働かれているSNS広告を運用をされている会社さんでの導入の経緯や利用され方、困った点を紹介した後に、同様のユースケースではBIツールにどういう要素を求めるのか、ということを話されていました。
こちらの会社では、広告運用の中で日々出てくるデータ抽出作業をすべての人に開放するためにRedashを使われている、ということでした。
業務上、重要な作業をRedashが担うということになったがゆえにRedashのパフォーマンスが業務効率に大きく寄与するようになり、その上でメンテナンス性をBIツールに求めるべきという話と、実際の運用のノウハウなどの紹介も面白かったです。
ジモティーでの Redash 活用事例 - kyoshidajp
ジモティーさんでは、Redashの利用者が40人でクエリ数が2300クエリあるということでした。
比較的大規模に使われている、ということでユーザー管理のGoogle認証連携とそれに付随するOSSとしてのRedashへの貢献についての紹介も面白かったです。
また、少し早めに発表が終わったこともあって、Q&Aの時間が長くあったのですが、その中で、クエリの管理の方法についての議論になっていてそれが面白かったです。
クエリが多くなりすぎると検索しづらくなるという問題があるという話で、たしかに僕の会社でも導入して1ヶ月足らず程度にも関わらず、50近いクエリができているので棚卸しが必要だなと思いました。
参加者の方々は、すでに運用されていた方も多いようで、ディスカッションの中でこの問題への対処方法が紹介されていました。
- Redash管理層のDBから使われていないクエリを抽出して、スプレッドシートに削除対象リストとして公開
- クエリのDiscriptionの部分にタグのようなものを書いておいて、検索性を上げる
LT 僕と Redash と Athena - dyuju_you
S3にためたログやデータをAthena経由で抽出、分析したいというときに、無邪気にクエリを打つと
- Redashのリソース
- ブラウザ性能
- Athenaの課金
の観点で色んな意味で死んでしまうという問題をRedashにおけるAthenaのデータソースのコードをカスタマイズして仕組みで防いだという話でした。
OSSだからソースコード読めば良いという話をされていましたが、僕は完成度高そうなツールのコードを読みに行って改善するのって大変そうだなぁと漠然と思っていたので、
データソースのコードに絞って手を入れて、ツールの中のコードに手をいれて改善する良い事例紹介だったのではないかなと思いました。
LT Redash ユーザーのための Metabase 入門 - manabusakai
Redash Meetupでは挑戦的な、別のOSS BIツールであるMetabaseの紹介LTでした。
- インターフェースの美しさ
- SQLを書かずに分析ができること
Metabaseはより簡単に、早くデータ可視化、分析をできるようにしたツールで、
Redashのように多くのデータソースやそれらをまたいだ分析などをコードで解決できるというツールとは、対象ユーザーが違う、という話をされていました。
まとめ
Redashを会社に導入して思ったのは、ダッシュボードやグラフ化などの可視化の機能が見栄えが良いのでそこに意識が向きがちで、様々なデータソースにアクセスができてjoinできるという点をうまく活用するのは、データのありかや意味がわかっているエンジニアばかりになってしまうということでした。
可視化して美しいダッシュボードを作るのは夢のある話だな思いますが、まずは日々のデータ抽出から始めて、エンジニア以外の人も巻き込んでやっていくのがよいというのは、いろいろな方がおっしゃっており、地道にやっていくしかないのだなと思いました。
その中でパラメータによって誰でも使えるクエリをたくさん作る、など少しでもRedashを触るハードルを下げる取り組みはもう少し積極的に社内でも推し進めていこうと思いました。
また、今回、OSSとしてのRedashへの貢献であったり、ハックであったりの事例も多く話されていたように思います。
先程も書きましたが、そういう貢献はハードルが高そうに思えていました。
こういう勉強会の場でその事例が紹介されていると、アプローチの方法がぼんやり浮かんできそうで、その辺を意識してツールを触れたら良さそうだなと思いました。
最近導入して、たくさん触っているというのもあって、総じてすごく良いイベントでした。運営のお二方ありがとうございました！！
おまけ
今回の運営の一人である@kakakakakku さんが公開されているハンズオン資料を実施して、ブログで紹介していたり
WEBエンジニア勉強会#05にて導入して少したったタイミングでの所感などを話しています。
メモ
以下、勉強会中のメモです。
Redash導入事例から考えるOSS BI導入チェックリスト
@ariarijp
ユニトーン(SNS広告の運用) ariarijp.hatenablog
ユニトーンにおける導入事例
導入以前
データ抽出は社内ツール、SQL
=> ツールの魔改造、EXCELによるデータ加工 => データ抽出へのリードタイム
導入の経緯
- クエリのFork
- APIで扱える
導入後の変化
大変になったこと
- 複雑な集計クエリが大量に
- 今までにないデータを集計対象にしたいという要望
- Redashが業務の中心になり、業務効率に直結 => 棚卸しが必要
チェックリスト
前提: エンジニアは10人
- データ抽出がしたい
- エンジニアの工数削減
- コストをかけたくない
誰が使うかを考える
非エンジニアも使える？
BIツール導入と併せて、データに係る知識の底上げをエンジニア主体で行う
どのDBを参照するか？本番、レプリカ？
ネットワーク上どこに置くか？
可能であれば集計用DWHに逃がすのが吉？ => BigQuery、Redshift、TDなど
運用
まとめ
- 誰が使うか？エンジニアが巻き込む
- データ基盤の整理
- 安定運用できる知識が必要
ジモティーでのRedash利用事例
kyoshidajp
40人でクエリ数が2300
PostgreSQLからメタデータも簡単に取れる
基盤
mongoDB、Aurora ↓ embulk Redshift、BigQuery // BigQueryのほうが安くてよい？
dry runモードというのがあって、料金を抑えたりする
利用事例
アカウント管理
- Google認証の導入
- セキュリティグループによる制限
データ抽出
BigQueryの場合はユーザ定義関数も使える
Pythonデータソース
Redash社内勉強会
パラメータが便利
まとめ
OSSなので不満や、こうなれば便利というのがあればPRを投げる
僕と Redash と Athena
dyuju_you
Hadoopが好き
webpage tracking nginx golang fluentd s3
データソースは２つ
- presto => hadoop
- athena => s3
無邪気なクエリ
- Redashの死 =>
*使うな！！ - ブラウザの死
- お金の死 （Athena高い、1クエリ/500$）
どうする？
システム的に何とかするのが吉
OSSだからソースコード読めば良い
- Limit制約
- 一定のLimitを付けないとだめ
- Pertition制約
- テーブルのパーティションがあるかを確認？
スキャン量を減らす
Glue Data Catalog
怖くないSQLライフを
Redash ユーザーのための Metabase 入門
manabusakai
Metabase？
- 異なるData Sourceのjoinが出来ない
- Data Sourceがやや少ない
ターゲットユーザーが違う
エンジニアチームにはRedash、分析チームにはMetabase
Redashとは補完し合うツール
権限管理はMetabaseのほうが良い
