ソリューション → データを落としてくる部門、パッケージして出すところ
サイエンス → 使いやすくするところ、レコメンデーションとかするところ
データインフラ
膨大なデータボリューム 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起動・再起動
- 運用手順で対応 10分くらいで終わる
-
根本対策
- コミュニティと連携して根本敵にソースコードを修正する
- 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の世界だとクエリ並列化
歴史に学べば良いはずだ!