はじめに
これは ドリコムAdventCalendar の7日目です
6日目は、keiichironaganoさんによる iTunes 使用許諾更新のとき一旦キャンセルしてほしい話 です
【その2】ドリコム Advent Calendar 2015 もあります
自己紹介
去年の ドリコムを支えるデータ分析基盤 に引き続き、今年もドリコムのデータ分析基盤を担当しています。
分析基盤をTreasure Dataに移行
オンプレ環境の Hadoop からTreasure Data に移行しました。
また、ジョブ管理ツールやBIツールといったサーバーもAmazon EC2 に移行しており、 徐々にオンプレ環境を離れつつあります。
背景
オンプレ環境で Hadoop を運用して3年も経つと考えなければならないのが HW の寿命です。
さてどうしようかとなった時に、ほぼ迷いなく外部サービスに移行するという選択を取りました。
Treasure Data、BigQuery、Amazon Redshift のようなサービスがある中で HW の交換作業をしてまでこのままオンプレで運用し続けるメリットはあまり感じられなかったためです。
サービス選定
候補として上で挙げた Treasure Data、BigQuery、Amazon Redshift の3サービスを実際に触ってみて最終的に Treasure Data を使うことに決めました。
Redshift はちょっと触っただけなのですが、実際に触ってみた所感の比較です。 ※ 2015.1 時点
| Treasuredata presto | BigQuery | Amazon Redshift | |
|---|---|---|---|
| リソースのスケール | フルマネージ | フルマネージ | ユーザがノード変更 |
| 同時実行 | 4〜 | 20 | 5〜 |
| 課金 | 固定額。お高め | データサイズ＋クエリ数＋クエリスキャンサイズ＋etc 。全体的にお安い。データ抽出サイズに気をつけないとウン百万の請求も | 固定額＋etc |
| パフォーマンス | 速い (件数依存、対象が数十億ならHiveにする) | 件数に関係なく速い | 速い (件数に依存) |
| テーブル(分散) 設計 | 不要 | 不要 | 必要 |
| スキーマレス | ○ | 固定 (json構造ならレス) | 固定 (json構造ならレス) |
| データ投入 | 実質入れ放題 | 制約有り (回避方法あり) | S3経由 (大量データのインポートが遅い) |
| サポート | ◎ | △ | ○ |
| 総評 | バランスが良い。専任で人をつけなくても安定した価格、性能で運用できそう | パフォーマンスを保つため、制約が多いので注意が必要 (制約条件が突然変わったら爆死する可能性)。節約したい時、件数が多くてどうしようもなくなった時に使えるかも | 安価で始められるDWH。大規模になるほどチューニングが必要になってくる。 スモールスタート。データマート向き。変更に弱い。 |
他にも比較する部分が色々あるのですが、あんまり細かくなってもしょうがないので、ざっくりとした所感で書きました。
また、弊社の分析基盤としては職人をできるだけ作らないような体制を目指しているので一番運用が楽で安定しそうな Tresure Data を使うことになりました。
新データ分析基盤全体図
大きなところは Hadoop が Treasure Data に変わり、AWS のサーバーを徐々に使い始めているというところで、それ以外のところは去年の ドリコムを支えるデータ分析基盤 とほぼ変わっていません。
DBのスナップショットはS3へ
Hadoop の時は、アプリのログもDBから取ってきたスナップショット(tsv) もHDFS に置いていたのですが、Treasure Data にはデータ件数の制限があるので、無闇に全部 TD に置くということはせずに TD 上で集計が必要なもの以外は S3 に置くことにしています。
また、ログもTD上には直近x日まで保存して、古いものはS3に逃がすということもログ件数調整の一環としてやっています。
闇のスクレイピング技術は今も健在
去年のエントリの闇スクレピングは今も元気に動いています。。。地味に便利なのが憎らしい。。。
まとめ
・安定した運用、職人芸を少しでも減らすために Treasure Data を分析基盤に
・特定の条件下であれば、BigQuery、Redshift はあり
・金を出した分だけ楽ができる
8日目は @sazae657 さんです
