Más contenido relacionado
La actualidad más candente (20)
Similar a マーケティングテクノロジー勉強会 (20)
マーケティングテクノロジー勉強会
- 1. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
マーケティングテクノロジー勉強会
How to 大量データ処理
~Hadoop/Redshift/Aerospike~
株式会社 EVERRISE
伊藤、中川
- 2. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
はじめに
本日は、お越しいただきありがとうございます。
講座を通じて、以下をご説明します。
How to 大量データ処理
① バッチ編
② トランザクション編
約 40 分程度の講座となりますが、よろしくお願い
いたします。
- 3. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
EVERRISE ご紹介
会社名 : EVERRISE CO.,LTD.
代表: 倉田 宏昌
設立日: 2006 年 7 月 3 日
所在地: 東京都港区六本木 4-11-13
ランディック六本木ビル 3F
Url : http://www.ever-rise.co.jp/
事業内容: - 業務系システム構築
- Web システム構築
社員数: 33 人 ( 技術者約 25 名 )
会社名 : EVERRISE VIETNAM CO.,LTD.
代表: 山崎 利崇
設立日: 2012 年 11 月 14 日
所在地: ベトナム ホーチミン
DA KAO Center
Url : http://www.everrise.asia
事業内容: - 業務系システム構築
- Web システム構築
社員数: 25 人 ( 技術者約 20 名 )
- 4. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
取引先一覧
・インターネット広告代理店
・配信事業社 (DSP / SSP / ADNW)
・メディアレップ
・総合代理店
・リサーチ企業
・ Web 系サービス提供企業
- 5. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
EVERRISE 社での開発・案件の事例
・ DMP 、アトリビューション分析
・スマートフォン向け独自アドネットワーク
・広告配信サーバカスタマイズ
・マーケティングオートメーションツール
※ アドテク系受託開発の会社です※
- 6. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
FAworks のご紹介
アドテク、 Web 系案件をご紹介!『 faworks 』で検索!
- 7. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
講師紹介
◆ 基本情報 伊藤孝 (38 歳 )
EVERRISE 取締役
Facebook takashi.itou.er
◆ 経歴
1989 年頃 プログラムと出会う
1999 年 4 月 PG として就職
2004 年~ 物流・在庫コンサル
2006 年 6 月 EVERRISE 起業
2006 年 9 月~ アド関連システム開発多数
- 8. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
アドテクブログもやってます!
http://www.ever-rise.co.jp/adtech-blog/
「アドテクブログ」で検索
サイバーエージェント、
リクルートをおさえて第一位
- 10. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
本パートでの要点
私は現役技術者では無いで、
SIer として
大量データ処理 ( バッチ ) を受託する際の
How to というか注意点
をご紹介させていただきます。
大量データ処理の歴史を振り返り、ご紹介します。
- 11. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
データベース時代の大量データ
某携帯キャリアの 2003 年頃、約 12 年前の話です。
契約者数: 4 千万
通話回数: 1 日 1 億回、月間で 30 億回
このデータを元に、個人宛てに請求書を発行する
システムを担当 ( 料金計算+請求書作成 )
この処理を全て Oracle で実現する必要があった。
- 12. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
データベース時代の大量データ
データベースは専用スパコンで驚異的なサーバスペック。
C 言語でカリカリにチューニング。
何と言っても驚きは、そのサーバの価格!
1 台 100 億円以上!
それでも、携帯契約者が毎日のように増加していたので、
耐えられずに「もう 1 台 DB サーバを買う?」という議論
が出たが、さすがに即断はできなかったようで、
まずはデータ圧縮チームを結成!
- 13. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
データベース時代の大量データ
Oracle 社員、プラチナ資格保有技術者で 20 名程度。
当時の想定単価:月額 200 万円
月額 200 万円 ×20 人 ×12 ヶ月=約 5 億円
その技術者で
「データ圧縮とパラメータチューニング」
だけを、ひたすら実施。
結果、 100 億円のサーバ購入を回避!
- 14. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
Hadoop 時代の大量データ
弊社は 2008 年頃から Hadoop の利用を開始。
Amazon EMR の提供は 2009 年頃で、 Hive もない。
その頃に利用した苦労話を。
技術的に面白そうだからと、
弊社 CTO が「 Hadoop でやります!」
という前提で、あるアド系のシステムを受託。
( 本当は DB でも十分なデータ量でしたが・・・ )
- 15. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
Hadoop 時代の大量データ
文献はほとんどなく、 AWS 自体も不安定のなか、
S3 、 EC2 でガリガリと作りこみました。
…結果は
リリースは、延期に次ぐ延期。
2 ~ 3 ヶ月間、担当者は休みなし。
リリース後も不具合連発!
- 16. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
Hadoop 時代の大量データ
どんな事象でハマったか?
数台で分散処理させる際、極まれに 1 台だけ失敗する
⇒ 根本原因不明。クラウドの特性上致し方ない?
S3 から処理対象ファイルを読み込むと、極まれにリストが欠損する
⇒ 当時の S3 バグ
エラーログ、実行ログが各サーバに分散して、処理が追えない
⇒ ログを追うためだけの処理を別途記載
エラー対策記述が集計ロジックの約 10 倍に
- 17. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
Amazon EMR + Hive 時代の大量データ
2013 年頃、アトリビューション分析をいくつか受託開発。
Amazon EMR + Hive 構成でそれなりに実装できました。
ただし
> 数台で分散処理させる際、極まれに 1 台だけ失敗する
等の問題は発生していました。
上記のようなエラー時の回避には慣れていたのですが、
「対策記述量の多さと HiveQL の癖に手こずる」
という問題は残りました。
- 18. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
Amazon Redshift 時代の大量データ
そこで 2014 年頃から Redshift 利用(現在メイン利用)
◆Redshift の良い点
・ Hive のような独自文法がほぼなく、
副問い合わせなど複雑なクエリも実行可能
・集計指示出してからの結果が早い ( 数秒で可能 )
・ EMR で発生していた失敗がなく非常に安定
・既存 DB システムから容易に切り替え可能
- 19. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
Redshift を検証して分かっていること
ファイルの読み込みは方法次第で大きく変動
copy という機能で S3 からのファイルを取り込むことが基本だが、複数ファイル
を 1 ファイルにマージして取込むと大幅に時間短縮される。ただし、使用するノー
ドが複数のノードスライス (CPU コア数 ) を持つ場合は、その分だけファイルを分
割した方が早い。
データ量、処理量、ノード数の関係性がリニア
データ・処理量が増えても、ノード数やノードスライス数等を増やせば、処理時間
は一定を保てるので、計算が立つ ( 処理の組み方次第 ) 。一定閾値を超えると急激
にパフォーマンス悪化という状況は見られない。
いくつかの注意点がある
vacuum 処理をしないと select のパフォーマンスが低下する / ノードの停止がで
きず「停止=削除」となる / PostgreSQL ベースなので mysql と文法が違う / サ
ポートしていない型も多い / etc
- 20. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
Redshift と TreasureData(TD) の弊社的比較
なぜ、 TD ではなく Redshift を利用しているのか?
1.弊社に Redshift 習熟者が多い
2. AWS 導入は検証済で容易 (TD は実績が少ない? )
3. DWH 経験者がすぐに利用できる
4. HiveQL よりも生 SQL に近い
5. AWS 担当者に文句を言える ( 逆に TD に知り合いが居ない )
- 21. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
最初から Redshift にしておけば良かった!実例①
データ量は想定より増える
とある「 MA ツール」の開発例で、顧客ランク推移を月単位で見れれば
良かったはずが日単位でランクが変動を見たいと変更。過去 1 年間だけ
のデータ保持の想定が、前年度、前々年度との比較もしたい!と変更。
30 万ユーザの 12 ヶ月の月別の顧客ランク推移
30 万 ×12 ヶ月= 360 万レコード想定
30 万ユーザの 36 ヶ月の日別の顧客ランク推移
30 万 ×1095 日= 3 億 3 千万レコード
- 22. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
最初から Redshift にしておけば良かった!実例②
想定以上に「無茶をするユーザ」がいる
弊社「アドレポ」の実例。事前にサンプルを集め、調査・設計を実
施。 20 ユーザ位まではデータベースでも余裕なデータ・処理量と想定。
リリース後どうなったか?
2 ユーザ目で「無茶する想定外ユーザ」が登場。
データ量が数倍、出力レポート量も 10 倍以上
その後、 5 ユーザ目に同様の「無茶するユーザ」が登場。
あっさりとデータベースが処理量でパンク。
- 23. Copyright © EVERRISE CO.,LTD. All Rights Reserved.
大量データ処理を開発する時の教訓
データ・処理量的に見通しが立たない
または、すぐ増強が必要そうなものは
迷わず Redshift(TD 等 ) にしておくべき!