Impala Meetupで発表した資料です

1. USERDIVEによる
Impala導入へのミチ
@kuni_nakaji

2. お前だれよ
• 株式会社UNCOVER TRUTH 立ち上げメンバー
• 中島邦弘(@kuni_nakaji)
• ８年間某SIerで基幹システムを構築
• 官公庁(国土交通省）/ 某クーポンECサイト
• 京王ハイウェイバス / 某海上保険
• 大手ECのメインフレームからの移行
• etc..
• Australiaへ1年半ほど留学
• 某ポイントサイトのベンチャー企業で
• インフラ運用 / 開発 / 内部監査
• 海外にてチームビルディング
• UNCOVER TRUTHにてUSERDIVEを開発
2

3. アジェンダ
• USERDIVEとは
• USERDIVEのデータ量の推移
• impalaを使用するまでの軌跡
• 大量データを扱う場合の所感
• 今後解決していきたいこと
• まとめ
3

4. USERDIVEとは

5. これまでのWeb/Smartphone解析
従来から様々なアプローチでサイト解析が行われています。しかし、各アプローチにはそれぞれ以下
のような課題がありより効果的な施策が求められてきています。
5
トラフィック分析
• データ加工に時間がかかる
• 離脱ページがわかってもどう
改善すべきかわからない
ユーザービリティテスト
/ アイトラッキング
• コストが高い
• 分析の自由度が低い
従来のヒートマップ
• 機能が限られており、踏み
込んだ分析ができない
• 活用しきれず、社内の運用
サイクルに乗らない
• 定量的な検証ができない
分析課題の事例
▶ 制作したコンテンツが、どの程度興味を惹いているのか分からない
▶ どのように改善すべきか分からない
▶ ABテストを繰り返しても、何が効果的か分からない
▶ ページ内改善する目安がなく、効果的にPDCAサイクルを回せない

6. 機能一覧
これまでのサイト内解析では解決できなかった課題を解決できる
9つの機能を搭載しています。※マルチディバイス対応
①動画分析②マウスヒートマップ③マウスヒートマップ④スクロールヒートマップ⑤ルッキングヒートマップ
⑥動線分析⑦フォーム分析⑧フィルター機能⑨ダッシュボード
6

7. USERDIVEの
データ量の推移

8. 導入クライアント件数推移
100up!
8
12月に100サイトを超え
毎月順調に拡大中
160
120
80
40
0
7月8月9月10月11月12月2014年1月2月3月4月5月

9. イベント量推移
9
400,000,000
300,000,000
200,000,000
100,000,000
0
2014/2 2014/7 2014/10
トラフィック流量
データ量

10. impalaを使用するまでの軌跡

11. 第一次データ問題 (2013/1～2013/5)
• 初期設計時にファイルDB
• MySQLもある時代なのに。。。
• 当然inodeの不足が起きる
• ブロックサイズを変えるなど悪あが
きをしてみるが、格納できてもlsが
出来ないという残念な状態になる
11

12. 第二次データ問題 (2013/5～2013/12)
• レスポンス速度を優先するためKVSを検討する
• Redis / Cassandra / MongoDBを選定候
補に
• トラッキングデータがjsonだったためにパース
にかかる時間を節約するためMongoDBを採用
• DBロックと容量不足に悩まされる
• トラッキングが増大すると更新が増えて、DB
ロックが発生しレスポンスが劇的に低下する
• 圧縮がサポートされていなかったので容量が
肥大の一途
• データを削除するがDBロックがかかる
• 人間システムバッチ
• バッチの処理が間に合わずリカバリの毎日
12

13. 救世主現る！

14. 推奨メモリ128GB！

15. 最低４台必要！
※マスターを含む

16. スタートアップには
ツライっす orz

17. CDH採用時の印象
• メリット
• CDHによりノードの管理が一元化されている!
• ノードが拡張しやすい!
• impalaが高速でデータ量を感じさせない!
• ロックが気にならない!
• おすすめしないと言われたのに...
• メモリ25GBのノードを10個用意して、推奨の128GBを超えたように見せてみる
• 「物理サーバを」というアドバイスがあるがVMばかりにしてしまう
• 監視(amon/smon/rmon等)をよく分からず設定してしまいMeta serverに負荷
をかけてしまう
• 台数を節約するため、なんちゃってHA構成を作ってしまう
17

18. 第三次データ問題 (2013/12～2014/6)
• CDH4.3 + impala 1.0.1～1.1.1
• shardingでデータを日単位に分割でスタート
• [課題] バッチでデータ取得単位が大きくなり、
いつまでも終了しない現象が発生
• [課題] データ増加によりI/Oを減らす必要が出
てきた
• shardingを時間単位に変更
• CDHへ直接更新せず、バッチサーバにファ
イルを落としてを処理
• [課題] バグにより一定量のデータが増えてくる
と負荷が高騰してくる問題が発生する
https://issues.cloudera.org/browse/IMPALA-592
• 悪夢の再来、人間バッチを実施
18

19. パーティションを使用するため
impala 1.2.4へ

20. add partitionにかかった時間
tsv数
800
1300
2500
0 125 250 375 500
処理時間 [分]
2014年4月 impala1.2.4時点
20

21. 第四次データ問題(←イマここ）
• CDH4.6 + imapla 1.2.4
• データの取得サイズを下げるためパー
ティションでデータの分割を考える
• [課題] 20万パーティションを超える
とレスポンスが劇的に低下する問題が
発生する
• impala catalogが溢れてしまう
• [課題] 導入クライアントが増加しディ
スク容量も格段に増加
• [課題] データ量の増加に伴いIOと
データ転送量も増加
21

22. 今後impalaで解決したいこと
方法備考
IO軽減同一テーブルで途中から
parquetに変更可能
22
impala1.4以降
http://goo.gl/XLeHv3
容量軽減snappy, gzip or
bzip で圧縮
impala 2.0以降
http://goo.gl/K2hGIz
パーティション分割向上パーティション分割の速度向
上 (10k/sec->30k/sec)
impala1.4以降
https://issues.cloudera.org/
browse/IMPALA-887
パーティション最適化扱い方を間違えていたの
で認識を改めて変更
パラメータ調整
io.file.buffer.size や
dfs.block.sizeのようなパ
ラメータを調整してみる

23. 大量データを扱う場合の所感
ファイルDB Mysql mongoDB Impala
操作性大変◎ ◯ ◯
データの扱い大変◯ ◯ ◯
排他制御大変◎ ✕ ◎
レスポンスlsが応答しなくな
るのでほぼ困難◯ ◯ ◎
23
拡張性inodeが不足して
ほぼ困難
△
masterが増やしにくい
△
マルチマスタの構築は用意だがロックについ
て考える事が多くなる
◎
導入の容易さ簡単◎ ◎ △
リソースブロックサイズと
inodeとの戦いメモリとの戦いDisk容量と
メモリとの戦いメモリとIOとの戦い
使用メモリ0GB - 16GB x 3 24GB x 10

24. 結局どのような流れで来たか
24

25. まとめ
• CDHのアップデートの速度が早い
• 半年でメジャーバージョンが上がる
• impalaもすごい勢いでアップデートされている
• 使用できるSQLも増えてきている
• 既存の設定を変更するだけでもまだ速度向上出来る
• impalaの新機能はさらに高速が見込めそう
• Microsoft様とも組むようなのでAzureでの使い勝手も
気になります
25

26. 『離脱率90％が当たり前』という世界を変える
Analysis tools to visualize the movement of all users