データ集計基盤のいままでとこれから 〜Hadoopからdataflowまで使い込んだ経験を徹底共有〜
•Download as PPTX, PDF•
5 likes•2,354 views
DB(mysql)上で実行することから始まった広告系大量データの処理に関して、試行錯誤しながらもHadoopを経てdataflow(BigQuery)に置き換えて大幅な効率化、低コスト化を実現。その過程で得た大量データを効率的に処理するための使いこなし戦略について徹底共有。
Recommended
More Related Content
What's hot
What's hot (20)
Similar to データ集計基盤のいままでとこれから 〜Hadoopからdataflowまで使い込んだ経験を徹底共有〜
Similar to データ集計基盤のいままでとこれから 〜Hadoopからdataflowまで使い込んだ経験を徹底共有〜 (20)
Recently uploaded
Recently uploaded (9)
データ集計基盤のいままでとこれから 〜Hadoopからdataflowまで使い込んだ経験を徹底共有〜
- 8. パイプライン実行
- 11. 手軽な使い方 ETLで手軽に使えるようテンプレートが用意されている。 下記のようなテンプレートを使うとコード書く必要なく使える。 •Pub/Sub to BigQuery •Cloud Storage Text to Pub/Sub •Datastore to Cloud Storage Text •Storage Text to Datastore •Bulk Compress Cloud Storage Files コードはgithubで公開されていて、カスタマイズ可能。
- 20. Hadoop導入 (2011頃)
- 37. BigQuery • 簡単に使い始められる • サーバレス、フルマネージドで PB級のデータも難なく処理 • 料金もリーズナブル • ストレージ：$0.02/GB • クエリ：$5/TB すごい謎技術😇
- 44. 処理の流れと種類図に表すと データをkey毎にまとめ上げる key毎のデータを読み込みながら個別処理 key毎のデータを〜 key毎のデータを〜 key毎のデータを〜 key毎のデータを〜 ログ
- 49. パイプライン
- 50. オートスケール
- 51. 難題は解決した？ • CP高いBigQueryを中心にMapReduceで補完する役割分 担でコスト削減 • 処理負荷に応じた自動スケールで楽になった！ 難題 運用を楽に、より効率的な処理方法へ！ 解決
- 56. まとめ • Dataflowは様々なデータ処理を連携できる。 • 連携機能を活用して、難題だった 「処理効率改善」「運用手間改善」を解決。 • 今回紹介したのはほんの一例 (機械学習と組み合わせたり、ストリーム処理化...)
- 57. ご静聴ありがとうございました。
Editor's Notes
- 資料は後ほど公開する予定です〜
- スライドは後ほど公開。写真は撮るひつないです。
- Inputとなるログデータを規模の大小に関わらず同じアプリケーションで処理する仕組み。 ログデータの規模によって変わるのはインフラ〜ミドル部分。 「大規模データをどれだけスムーズに処理できるか」にやりがい。
- Googleではビックデータ＝データという。
- 裏ではComputeEngineが起動されてパイプライン処理が動きだす。 上から下へ流れていくイメージ
- ちなみに、ビックデータ処理の先駆けとして有名になったHadoopは 当時Googleが社内で使っていたMapReduceが元になったが、 論文を元にOSS化されたためGoogle初感なく悔しい思いがあった。 Dataflow
- githubのURLを入れる。 様々なサービスとの組みあわせができる。
- DBにデータを入れさえすれば
- これはヤヴァイ。 心身ともに消耗する... （データ量：数千万行）
- オンプレなので、注文したサーバが届く日を心待ち(２ヶ月くらい) にしつつ置き換え...思ったより性能でない... スケールアップで重いデータ処理は解決できない。
- 全ページに年代入れる...
- しばらく運用してたら、 当時の規模では、オンプレで１クラスタを運用するのが精一杯だった。 （データ量：〜１億行） excelで実行管理表作ってタスク運用。
- 一言でいうと「オンプレの物理的制約から解放してくれた救世主」
- データ処理をオンプレからクラウドに移行して、 物理的な問題からは解放され、ダイブ助かるようになったが... 個別の処理リソースの調整をしなければ処理が終わらないなのど、運用面での難題が残った。 待ちサーバ：Hadoopの マシン使用率低下問題 MapperとReducerでサーバが別れる
- EMRのWebUI画面のキャプチャ。 ここにでているマスターノード、コアノード、タスクノード数の他にもMapper/Reducer割合やメモリ調整 を個別のデータセットに合わせて調整していく必要がある。 個別のデータセットは十数個あって１日一回データ処理が動く。
- 検討した結果。SQL型で難題の解決に一番近いのはBigQueryと結論して試して見ました。 １ページじゃまとめ切れないほどのネタがありますが、一言で表すと
- 全体を俯瞰するUIで見るとこんな感じ。 ポイントポイント絞って見ていきます。
- 上から下へ流れるイメージです。 BigQueryからデータを読み出し、 マスターデータと結合。 統合処理を実行した後outputをBigQueryに書き出す処理です。 途中で失敗した場合は赤色になってログが出力される。
- オートスケール
- サーバ利用効率悪く、 データ量に応じて個別のパラメータ調整
- 最後に新しい取り組みについて紹介したいと思います。
- 機会学習をやってて、こういう目的でやってるんです。
- メッセージにポイントをつけてピアボーナスを送りたい人に向けて投稿します。 投稿された内容は誰もが見れるタイムラインに表示される。
- ピアボーナスの要素は メッセージ ポイント 拍手 メッセージとポイントは投稿者から付与されるもの。 拍手はそれを見て共感したら送るもの。 良い投稿があってもタイムラインで流れてしまうのがもったいないところ 機会学習onDataflowで、メッセージ、ポイント、拍手数からよい投稿を再度ピックアップする機能を開発中 データ処理の制約少なくサクッと実装できるのがよいところ。