Yahoo Japan データインフラワークショップ

ソリューション → データを落としてくる部門、パッケージして出すところ
サイエンス → 使いやすくするところ、レコメンデーションとかするところ
データインフラ

膨大なデータボリューム 650億PV

## ヤフーの広告システムとSQL on Hadoop

**成長する広告事業と業界を技術で加速**

YDN広告…Yahooトップにでてるオススメのあれ。

最近急成長してる

- 広告レポートの使命
- これまでの取り組み
- 挑戦と貢献

### 広告レポートの使命

#### 求められるもの

スループットとスケーラビリティ

60億行が1日に発生する。

サービス追加・集計項目の追加に伴い急激なデータ増加が発生する。
それに対応できる柔軟なスケーラビリティ。

#### 目指すもの

- 機能
- 体感
- 使い勝手

Yahooの運用、調査考察においてGoogleとコストに3，4倍も差があった

### これまでの取り組み

レガシーシステム

1日10億行発生
RDBにさばくのは難しい

当時の対策
アカウントグループ別にファイルを出力してた
水平分割
スループットはでるようになったが…

機能制限が発生
ファイル分割速度が遅くなる→翌朝提供するデータが間に合わない

#### SQL on Hadoop導入

##### Impala

最初にImpalaを試した

機能制限・サービスレベルの低減に貢献。
しかし、スケーラビリティに問題。
クラスタを増やした

2015/7サービス開始

##### Hive on Tez

レイテンシはそこまでじゃないが、よかった
従来のMapReduceの問題を解決するアプローチを取っている

スケーラビリティ確保できた

2016年サービス開始予定

### 挑戦と貢献

#### Sub-secondクエリを目指す

日々低レイテンシ化が期待されてる

Hive on Tez + llap vs Phoenix

問題も出てるので日々改善している
両方見てる

今まではYahoo.incのクローズドなソースを使っていたが、HortonWorksと組んでがんばるようになった
OSSのパッチ提供とか業界への貢献ができはじめている。
プレゼンスを発揮していきたい。

## 大規模HDFS & Erasure Coding

分散コンピューティング黒帯

- Yahoo JapanのHadoopが取り巻く環境
- 大規模HDFSが直面する課題

データ使用量、CPU使用量が指数関数的に増加
クラスタが6000台に増加

普通のHDFS…

DataNodeが3000台
ファイルが1.3億、ブロックが1.6億
そしてブロックレポートが遅くなる…

NameNodeでGCが発生して遅くなる

有効なデータが60PB、実際使えるのは20PBでコスト的にすごい

### ブロックレポート遅い問題

NameNodeの起動が遅い(数時間) → 起動するまでに数時間かかってたらサービスできない

ブロックレポートは何故遅いのか
Diffとったり色々やってて遅い

原因は分かった

- 暫定対策
	- 運用手順で対応 10分くらいで終わる
		- 全DataNode Stop
		- NameNode起動・再起動

- 根本対策
	- コミュニティと連携して根本敵にソースコードを修正する
	- Hadoop2.6.1から入る

### ストレージコストの問題

耐障害性を保つために3レプリカ

Durability=2,Overhead=200%

ErasureCodingで改善する
ReedSolomon(6,3)で改善

細かくストライピングする
6ブロックのストライプ、3つのパリティ

Durability=3、Overhead=50%

最大のメリットはディスク容量が少なくてすむ
デメリットはネットワークトラフィック、CPU使用率が多く発生する

ErasureCodingはWrite性能がいい。
9スレーブ同時に走らせるから速い

- CPU,Networkのデメリットは許容できる
- ストレージコストのメリットが大きい

ストレージポリシー

データアクセス頻度で決める

- HOT 毎日・毎週
- WARM 毎月
- COLD ほとんど使わない

## Yahooの次世代パイプラインについて

データパイプラインとは？

分散したデータを効率よく解析基盤に集める基盤

パイプラインはデータソリューションの好循環を生み出す

DataHighway

Yahoo.inc製

### クローズなシステムの限界

- 試行回数が少ない
- システムそのものの開発スピードが遅い
	- 成長速度について行けない
- I/Fがオープンではないため、ガラパゴス化する
	- 汎用的よりも特化的
	- 導入コストがかかる
	- プロダクトごとに管理が必要になって困る

売上げはデータ量の爆増に伴って増えない
技術力でカバーする

サーバを増やすだけではなく各レイヤを増やして対応

オープンな技術を使う

### 次世代パイプライン

- Kafka
- MirrorMaker
- OCP
- sw
- Fabric Network

Kafkaとは

メッセージングブローカー。
他社でも大規模データをさばいている実績がある。

MirrorMaker

Kafkaクラスタのデータをミラーリングするやつ

### まとめ

データパイプラインの世界的な発展に寄与します。

Kafka Meets up Japan予定！ 1/16

## LT

### YahooのRDBと最新のMySQL検証結果

三谷さん
DB Administration黒帯

ヤフーはどんなRDBを使っているか？

- Oracle 11g RAC Enterprise Edition
	- 200DB
	- 広告、ヤフオク、ショッピング、トラベル、ニュースetc...
- MySQL 5.1 Percone 5.5

### MySQL新バージョン

5.7リリース

Query Rewrite Plugin

バッファプール
→ Oracle, PostgreSQLではできない

### Ambariと大規模クラスタと私

Hadoopの構築・管理・運用を管理する100%OSS

本番用にAmbari Cluster4つ使ってる。

#### 1000台デプロイ問題

同時に1000台追加できない
ちょっとずつ増やそうとしたら通信gなできない

原因
DBのデッドロック
コネクション数の限界

対応
100台ずつ追加（ムリ）
Arp Queeue設定

#### WebUI激重問題

2.1.0アップグレード後極端に重くなる
いくつかのFunctionが重かった
パッチを適用

### InfluxDBについて

Time Series DataBase

ある現象の時間的な変化を連続的に観測して得られた値の系列

株価とかに使える

Time Structured Merge Tree
ディスク容量を削減

すぐにバグを踏んでしまう

rpmでインストールしたらバグ踏んだ

### Yahoo Japan IDの裏側

サービス利用時に必要なYahoo Japan ID
Yahoo Japan専用の識別子

- ヤフーIDの属性管理DB
- 独自KVS

格納データ
2億以上
800種以上
1アカウントあたり6kb

接続クライアント10000台以上
リクエスト数110k rps

サーバーの台数は？
16台
4重化のため、80台

情報資産のACL

### 分散システムの課題

処理モデルの推移
乱立しまくってる。

なぜいっぱいあるのか？

既存モデルが過度に単純化されすぎていた。
現実は複雑…

- リアルタイム処理にそもそも向かなかった
- 処理最適化してもうまくいかなかった
- 分散クラウドデータベースの分野でも単純化の反動

いっぱいあって困る問題

デジャヴ…？

スパコン（超並列）の世界だとジョブ管理
並列DBの世界だとクエリ並列化

歴史に学べば良いはずだ！