yahoo! japanを支えるビッグデータプラットフォーム技術

1 Privileged and Confidential

Yahoo! JAPANを支えるビッグデータ

プラットフォーム技術

遠峯康夫データソリューション本部

ヤフー株式会社

自己紹介

Privileged and Confidential 2

遠峯康夫(とおみねやすお) 事業戦略統括本部データソリューション本部データインフラ開発部

2010年新卒入社 Hadoopクラスタ立ち上げの部署に配属

2012年データソリューション配属 Hadoop、リアルタイム処理基盤などを担当


is


…

…

…


…

…

…

あらゆるジャンルのビッグデータを保有

目次


月間総ページビュー数

(2013年7-9月平均)


年間ユニーク検索クエリ数

(Yahoo! JAPAN調べ)

ビッグデータはユーザーのために利活用


ページビュー

広告ログ

検索クエリ

購買履歴

データ処理

・・・

アクセス解析

効果測定

日本語処理

マルチメディア処理

レコメンデーション

ターゲティング

データフィード

!

ユーザー属性

ビッグデータはユーザーの課題解決につながる

利活用事例


サービス改善

利活用事例


縦22ピクセル縦28ピクセル

サービス改善

利活用事例


￥

ターゲティング広告

ＰＲ

閲覧

検索キーワード

購買

広告閲覧/クリック

…

興味関心を推定し最適な広告を掲出

利活用事例


レコメンデーション

利活用事例


単なる検索量のみではない様々なパラメータ

キーワード補助入力

利活用事例


音声アシスト（音声認識、意図解析）

利活用事例


画像認識

利活用事例


マーケットインテリジェンス

パズル＆ドラゴンズ（パズドラ）

利活用事例



パズル＆ドラゴンズ（パズドラ）艦隊これくしょん～艦これ～

利活用事例



利活用事例


Twitterのつぶやきを解析 “ネガティブ”,”ポジティブ” の割合をグラフ化

感情分析

利活用事例


ビッグデータレポート

利活用事例


都道府県別の議席獲得予測 42都道府県で獲得政党が一致

目次


どのようなシステムでデータを処理しているのか？

Yahoo! JAPANデータインフラ概要


・・・

Storm

生成

収集

格納・処理

利活用

本日はHadoopの話を中心に


・・・

Storm

生成

収集

格納・処理

利活用


Yahoo! JAPANの Hadoopについて


Yahoo! JAPANの Hadoopについての前に・・・

Hadoopはもちろん重要、でも・・・


本当にデータを使い倒すには Hadoop以外の周辺システムとの連携が必要

Hadoop周辺システムのご紹介


・・・

Storm

生成

収集

格納・処理

利活用

Hadoopを中心とした周辺システムとの連携


Storm

DataHighway データ入力

一次加工データ分析用データ連携

DataHighwayについて


Storm



DataHighwayについて


とは？

Yahoo! JAPANで利用しているログ収集プロダクト全てのWeblogを回収する仕組み大量のデータを処理できる環境に運ぶために必須の仕組み

DataHighwayの規模

・回収先：約8,500台・データ転送量：約13TB/day (圧縮済み)

DataHighway

Stormについて


Storm



Stormについて


Stormとは？ Twitter社がOSSとして公開した、分散ストリーム処理プラットフォーム 9/18にApache Incubatorプロジェクト化（リアルタイムに）逐次流れてくるデータを

即時に処理していこうという仕組み。

Yahoo! JAPANでの活用例

・各ページのリンクのクリック速報・広告改善のための一次データ加工・スマートフォンアプリのエラー速報など

Teradataについて


Storm



Teradataについて


とは？ Teradata社の商用RDBMS 並列分散処理で、高速にSQLを実行できる Yahoo! JAPANでは、主にアナリストの分析用途として活用

Yahoo! JAPANでの活用例

・広告レポートの抽出・広告モデルの効果測定など

Hadoopだけではなく適切な役割分担が必要


Storm

・大規模バッチ処理・大規模アドホック処理・大量データの蓄積

・リアルタイム処理・逐次流れるデータの一次加工

・大規模な結合処理・高速なアドホック分析処理


Yahoo! JAPANの Hadoopについて

Yahoo! JAPANのHadoopについて – 目次


1. Hadoop構成

2. Hadoop規模

3. Hadoopの特色

4. チューニング事例

5. 機材の選び方

6. 今後の展望


Yahoo! JAPANのHadoop構成

Hadoopクラスタの状況


本番系：2クラスタ

Production Cluster1

開発系：6クラスタ

Production Cluster2

開発系は本番と比べると非常に小さいクラスタ次期投入バージョンの検証なども実施

エコシステム


Oozie,Pig,Hive等のエコシステムを活用


Yahoo! JAPANのHadoopの規模

Yahoo! JAPANのHadoop規模


約3,500台

国内最大級その規模感は？

Yahoo! JAPANのHadoop規模感


・1日に故障するサーバ台数

約1.5台/day

・1日にRead/Writeされるデータ量

Read:約750TB/day Write:約60TB/day

・1日に処理されるJobの積算時間

約1,000時間/day


Yahoo! JAPANのHadoopの特色

Yahoo! JAPANのHadoop特色


400ユーザを超える規模でのマルチテナンシー運用

どれくらいマルチテナンシー？


・平均同時実行Job数

・同時最大実行ユーザ数

・最大同時実行Job数

約40Job

120Job超

約30ユーザ

マルチテナンシーの難しさ


いかに安定・公平にマルチテナント運用を行うか

状況の可視化


リソース使用状況の可視化

ある一日の利用状況グラフの色でどの部署（ユーザ）がどの程度利用しているかを可視化

最大能力

使用量

状況の可視化


もちろん、曜日によって使われ方も違う

濃青は主に個人ユーザのアドホック利用土日はあまり使われていないのがわかる

マルチテナントでうまく回すために


・利用者による一定の自治

・リソースキャパシティの定期的な見直し

・スケジューラ設定のチューニング

先の可視化グラフをユーザに見せ、空いている時間帯を自ら選んでもらう。

部署毎に利用できるリソースの量に違いを持たせる。利用率などを見て定期的に見直し。

Job同士のリソースの分け方に最適値はない。トライアンドエラーで最も良いものを探し続ける。


Yahoo! JAPANでのチューニング事例

チューニングの内容


タスクslot数の最適化

タスクslot数とは？

単純に言うと、どれだけHadoopで並列処理をさせるかの指標これを多く出来れば、同じ機材でより処理効率が高まる。

ここの高さを高くするということ

そもそもチューニングしようとした訳


H/Wのリソースが余っていることを発見

今のH/Wに合った最適な設定値を探していた

CPU,DiskI/O,Memory Netowork,etc… 様々な指標を確認そのうち、全ての指標に若干の余裕があることがわかる

それならば・・・


1ノードでもっとTaskが動かせる！かもしれない

しかし、既に本番稼動しているクラスタチューニングして問題がでないか・・・？

テストクラスタでは規模が大きく異なるため、必ずしも参考にはならない。 ※ネットワークトラフィックなど

テスト：本番 = 1:50~100 くらいの差

まずは再度現状の把握


チューニング前に様々な指標を確認

・当然、個別のノードの指標（CPU,Mem,Disk等）は重要

・個別のノードだけでなく、システム全体の指標（スイッチのトラフィック等）もとても重要

気をつける項目の一例


気をつける項目の一例

・個別のノード（計算ノード側）

・CPU（特にwaitIO）・Memory ・Disk（IObusy, queue）・LoadAverage ・インターフェーストラフィック・システム全体（スイッチ、マスタノード等）・スイッチトラフィック・マスタノードリソース（CPU, Mem, etc…)

個別のノードの指標に集中しすぎると、システム全体のデグレに気付かない可能性がある

本番でのテスト実施


一部のラックに対してチューニング実施

ラックスイッチの限界などを測定するためにもラック単位で設定値を変える必要がある

タスクslotの増加により新しくボトルネックが生まれてしまう可能性に注意

結果の検証


デグレされていないかの確認

グラフでのH/W指標の確認はもちろん既存Jobのジョブ実行時間、タスク実行時間なども比較

タスク実行時間

＜＜＜未チューニングノードチューニングノード

となっていないか

チューニングの一例 – 結果


チューニングの成果

チューニング実施

実施後の最大性能

50%向上


機材の選び方

「コモディティ」が大切


コモディティな機材を選ぶ

コモディティ＝低性能・低価格

ディスク：CPUコア数メモリ：CPUコア数これらの比率に特に注意して選定

HBase等、使うエコシステムは事前に考えておく

コモディティ＝最高のコスパ

Yahoo! JAPANで使っている機材の一例


メモリ： 64GB CPU ： 12コア24スレッドディスク： 3TB × 4ディスク

Yahoo! JAPANでも当初それに倣い構成を計画

ディスクIOがネックになると言うのがHadoopのセオリー

定期的な計測により、ディスクを重視しない（CPU重視）のYahoo! JAPANの現在に合った構成に

処理に応じた適切な構成を選択する必要がある


今後の展望

今後の課題


安定性基本的に安定的に運用できているが、単一障害点（SPOF）があるのがネック

拡張性 MapReduceだけでは今後の処理ニーズに対応しきれない新しいフレームワークの模索の必要性

今後の展開の一つのケースとして


Hadoop-2.xの導入

単一障害点（SPOF）であったNameNodeの可用性が向上より信頼のおけるシステムへ

・NameNode-HA

・YARN JobTrackerというSPOFのあったアーキテクチャを改良全くJobが動かせなくなる可能性を低減 MapReduceのみならない多様なフレームワークの可能性

10/15にHadoop-2.2.0-GAリリース！


Ready?

目次


どのようにしてビッグデータを利活用しているのか？全員がデータに触れることが重要

データは一部の人だけのものではない

目次


どのようにしてビッグデータを利活用しているのか？全員がデータに触れられる環境

まとめ


・Yahoo! JAPANではあらゆるジャンルのビッグデータを保有・活用・ビッグデータを徹底的に活用するため Hadoopを中心としたデータ処理システムを構築、運用・データを効果的に利活用するには技術面だけでなく組織面での整備も必要


データで、ユーザーファーストを実現

yahoo! japanを支えるビッグデータプラットフォーム技術

Documents