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の世界だとクエリ並列化

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