Linux DistributionとHadoop Distribution似てる感
本格的に成熟していくのはこれから
Keynotes
Apache Hadoopの現在と将来
大量に並べることで高いスループットを発揮するのがHadoop
MapReduce
並列分散処理を実行するためのミドルウェア
かなり使われてる
HDFS
MapReduce
YARNの現状と未来
Hadoopの計算機リソース管理を汎用化するための手段
分散処理ミドルウェアが普及
分散処理ミドルウェアのインターフェース
SQL的な記述が主流
MapReduceだと機械学習に使う行列計算は苦手
現在はCPU,Memory,Disk中心処理に焦点
高水準言語の中でGPGPU,FPGAなどを利用したミドルウェアが登場してきている
↓
これらでYARNはどうなっていくのか
YARNの将来
GPGPUやFPGAを含む計算リソースを扱えるようなデータセンターOSとして発展する
HDFSの現状と将来
ここ1-2年で様々な機能が追加された
- 性能
- よく使うデータはSSDに書き込むとかコントロールできるようになった
- メモリをストレージとして使ったり
- セキュリティ、運用性
- データの暗号化
- ローリングアップグレードで無停止運用できるようになってきた
- これまで使えなかった領域で使えるようになってきた
- ハードウェアの進化に合わせて進化していく
開発コミュニティ
日本だとNTT, Yahooが貢献大きい
コミュニティの今後
もっｔHadoopをよくしたい
- メンテナンスリリースの継続
- Java 8/9対応
- 新しいハードウェアを意識した高速な処理基盤の実現
- SSD
- GPGPU
- NVMeSSD
- インターコネクト
- Hadoopの開発者をもっと増やしたい
YARNは着実に広まっている
Yahoo Japanのデータプラットフォームの全体像と未来
Yahoo Japanのマルチビッグデータ
- 100以上のデータバラエティ
- 膨大なデータボリューム（649億PV)
- 秒間50000アクセス
データプラットフォームの全体像
- RDB
- MySQL(percona)
- Oracle
- DWH
- Teradata
- Object Storage
- S3互換の独自ストレージ(Go製)
- KVS
- Cassandra
これから
Presto, Redis, OpenStack
インメモリ系
HBase,Phoenix → 広告系
Erasurecode Archival Tier
Spark
70台規模で検索データのグラフデータ化を試験的に取り組んでる
Hadoopに関する技術チャレンジ
データの爆増
4倍/年
3000台のHadoopクラスタリソースを8ヶ月で使い切る…
課題は、これらをお金ではなく技術で解決する
Hive on Tez
性能要求→10万/h
最初測ったら1万だった
Metastoreがボトルネックになっていた
RemoteからLocalにすることで2万クエリ
リソースマネージャ
ApplicationMasterの起動数を引き上げた
ランチャースレッド数増加して4万クエリ
データノード
他ノードでの再利用（リユース）
直近のデータにアクセスが殺到してそれがボトルネックになっていた
直近データのレプリケーションを増やして8万クエリ
クライアント
付加ツールの最適化
同時実行を増やせば良いというものでもない。減らしてよくなることも。
ジョブ終了時に一斉に終わってしまうと、ネームノードに一斉に書き込みが始まるため、ランダムスリープを入れて時間差を発生させることで10万クエリ
- Metastore ServerはLocalMode
- RM、AMをバランスよくチューニング
- DataNodeのリソースを有効活用
- クライアントサイドの最適化
最後に
USEからMAKEへ
HortonWorksと組んで徐々に作る側にシフトしてる
課題解決エンジン→世の中の課題を解決する
Hadoop Storage
2006-2007 Basics
基本的なバッチプロセスのみ
2008-2011 Production
色々拡張された
商用ディストリビューション出てきた
2012-2015 Enterprise
セキュリティ
パフォーマンス
SQL
Evolution of Storage
Basics
HDFS only
MapReduce遅かった
アーリーアダプターが使ってた
Production
HDFSが進化した
セキュリティやら色々
パフォーマンスの最適化した
HBase
Enterprise
安定してきた
アクセスコントロール、ディザスタリカバリ、暗号化
新しいクエリエンジンを取り入れたり
2016年以降
HDDからSSDへ
NAND Flash
3D Xpoint memory（NANDよりも1000倍速い、しかもRAMより安い）
Kuduがいい。
HDFSともHBaseともかぶらないところ
Spark Conference Japan 2016
コントリビュータ増えてきた
よく利用されているコンポーネント
- Spark SQL
- Core
- MLlib
- Spark Streaming
- GraphX
GraphXはもうちょいわかりやすい活用事例が欲しい
Spark 2.0 What's Next
Spark＝スピード、使いやすさ、洗練された分析を兼ね合わせたデータ処理エンジン
2015年はSparkにとって大きな年
新しくR言語をサポートした
ミートアップの数がめっちゃ増えた
Sparkはビッグデータソフトウェアのテイラー・スウィフトだ
北川景子だｗ
様々な実行環境
- Standalone
- YARN
- Mesos
これらの半分がパブリッククラウドで動かしている
Sparkはもう完成しているか？
No!!!
- APIを作るに当たっての指針
- シンプルだが表現豊かに
- セマンティクスが十分に定義されてる
- バックエンド
Dataframeを動かすプラットフォーム
- JVM
- Tungsten
- Spark 2.0におけるAPIの創設
- Streaming DataFrames
- DataFrameとDatasetの成熟とマージ
- ANSI SQL（自然結合、サブクエリ、ビューのサポート）
ストリーム処理に関する課題
難しい理由
- 長い期間に渡すアウトプット
- 遅れてくるデータ
- 障害
- 分散
Sparkはすでにかなり速い
2.0でもっと速くなる
Spark2.0 4-5月に正式リリース
さくらインターネットが構築したApache Sparkによる原価計算システム
ビッグデータではない。
大規模分散システムでもない。
がっかりしないでね。
ほとんどAsakusa Frameworkがやってくれている
プロジェクトの背景
規模を追求する＝持つ経営
資産が大幅に増える
投下した資本は計画通り改修できているのか？
コストがわかれば改修状況が把握できるはず！
最強ツールに大量データ入れて固まるｗ
Asakusa Frameworkがバックエンド処理にHadoop使うかSpark使うかを隠蔽しているので、使う側はほとんど関係ない
基本的にオンプレ
- 物理サーバー30台
- コア数200
- メモリ1.6TB
- アドホックに増設してる
意識低い系
ランチセッション
ストリーム処理プロダクトをベンチマークしてみた
- Flink
- Spark
- Samza
- Storm
チューニングほぼなしで試してみた
Kafka4台でデータ投入
CPU使用割合（効率性）
同じデータ量でどれくらい使ったか
Sparkが一番速かった
Samzaだけベンチ取れなかった
僕が考える最強のビッグデーエンジニア
T字型ではなくつらら型エンジニアが最強
- 運用力
- 開発力
- コミュ力
- マーケティング力
- KPI
- 機械学習
- 統計...
- 語学力
- 先見性
- 作らない能力
- アリものを組み合わせて使う能力
Distributed TensorFlow
Jupiter Network
1Pbps
Tensor＝多次元配列
GPU使って機械学習やってるけど、大体1台でやってる
分散でやらなきゃ
TensorflowはChainerとかより遅い
TensorflowがGPUとか管理勝手にやってくれる
プログラムは気にしない
午後のセッション
ストリーミングアーキテクチャ StateからFlowへ
分断を補うためのアーキテクチャ
エンタープライズサービスバス
コントロールの集中は解決できていなかった
スタートアップの侍
振り子が揺り戻すとき
ESBはまだ有効でよく使われている
反動が進行中
MSA→N層アーキテクチャを置き換える
パーティショニングを考える
ジョブとコミュニケーションの方法を与えてあげる
MSAを採用した企業は成功している例が多い
なぜ実現できたか？
→ エンジニアの能力によるものが大きい
重要なのは遅延処理をどうするか
サービスはこの遅延を考慮してサービスを構成する。
メッセージングキュー
細かいメッセージング処理数が多い
既存のエンタープライズがこれを導入するのはハードルが高い
MSAは耐障害性のある高性能なメッセージングキューを必要とする
必須。
これまでのキューでは対応できない
使い古されたメタファー
雲の上からの眺め
コミットメントレベル
リクルートライフスタイルの考えるストリームデータの活かし方
AWS + Kafka + Soark Streaming
ビッグデータの普遍的テーマ
容量(Volume)
集約(Variety)
鮮度(Velociry)
日々増加し続けるデータ量
行動ログは1000億レコード
RDB/ファイルにデータが点在しているため、活用しづらい
集計に時間がかかり、データの鮮度が落ちてる
全社共通の分析基盤に利用
DWHを導入
- レガシーなりソースからもデータ取得できる
- 過去〜直近データも一様に見れる
データハブ基盤が必要！
Waterプロジェクト
- 蛇口をひねれば新鮮な水が出てくる
- Kafkaを使用したデータハブ基盤
- Sparkを使用したストリーム基盤
検討したもの
- クラウド vs オンプレ
検証→開発→運用環境を即座にできる
AWSを採用
データハブ基盤
- Kafka vs Kinesis
OSSを使いたかったのでKafka
ストリーミング基盤
- Spark Streaming vs Storm
MLlibとかあったのでSparkで
ビジネス要件
鮮度の高いデータを活用することで創出できるサービス案を検討
技術詳細・Tips
FluentdからKafkaの連携チューニング
Fluentdが詰まることがあったからチューニングした
KafkaがSSL対応したから、中間のFluentdはやめようとしてる
ログ出力は定期的なチューニングが必要。
Spark Streaming アプリ開発
- 理想
- 手元で簡単に実装/デバッグできる
- テスト環境で本番同様に実行できる
- 現実
- スペック不足による停止なのか環境なのか判断が難しい
- コストメリットの問題だけど、本番と同じ環境をAWSで用意してやってみる
ストリーム処理を動かし続けるポイント
- 理想
- 処理が止まらず稼働し続ける
- 現実
- エラーハンドリングする
- 51日以上連続して動いてる
動き続けるストリーム処理の定義
- 理想
- 止まらない
- 現実
- 停止は起きる
- ストリーム処理停止とシステム全体の停止は異なる
データストアにDynamoDB
メトリクスの集約はInfluxDB
ふりかえり
- 少人数で機動力持ってできた
- なかったら作る（プロダクトとプロダクトの隙間は自分で埋める）
- OSSに対する取り組み（コア部分はOSSで性能を担保する）
- AWSを使いこなすはゴールではない
- 性能観測を重視
- メトリクスを取得することで改善に取り組んだ
これから
- 道は半ば
- やってみたいこと
- データソースを増やす
- 新しいサービスを作りたい
- さらにサービスのスピードを上げたい
- エンジニアがビジネスを創出する環境ができてきた
今改めて考えるHive
Hiveも8年目
圧倒的Hiveユーザー数
Sparkに負けてるけど他には2倍差を付けてる！
ここ2〜3年でHiveも大幅変化
Hive LLAP
- プログラミングHive
- Hadoop Hacks
どちらもHive使いは必読だが、最新機能については書いてない。
Web上にも情報がそんなに充実してない
Hiveに様々な現場で関わってきた経験から得たTipsやチューニングの話
国内でHadoop導入は進んでいる
近年見かけるようになった使い方
- 将来のデータ量処理量が増大することを見越したスモールスタート
- すでに実績のあるところに相乗り
HiveQL
あるある→RDBMSと同じようにHiveQLを書いてしまう
- 無邪気なORDER BY問題
- 分散処理が分散しない
- BIツールで普通に出てくるので困る
- マルチインサート使ってない
- 大規模処理が効率よくできる
- Hadoop HacksにRDBとの違いとか書いてるのでオススメ
RDBでできるようなことが使えるようになってきてる！
- Common Table Expression
- 通称WITH句
- WINDOW関数
- UDFでがんばってたのがビルトインの構文でできる
- LATERAL View + Explode
Hiveだけでシンプルにできるようになってきている
ORCFileについて
カラム思考フォーマット
高速・高圧縮率
RDBのアイデアを持ち込んだ高速化の試み
圧縮率が高いことが性能問題になることも
改めて考えたHive
様々なワークロードに対応可能
カラムなストレージを利用する場合は、枯れていないリスクも多くて使い倒す覚悟が必要
RDBからしたら今更かよ感あるかもしれない
棲み分けは？
性能要件次第
Hiveを高速化するLLAP
Hiveの実行エンジン
- MapReduce
- 今でもこれを想定する人は多い
- YARN時代に置いてはHadoop1系の名残
- 今はほとんどメリットがない
- Tez
- Sparkのライバル的存在
- MapReduceに代わるやつ
- Spark
Hiveの限界
- インタラクティブな処理には使えない
- SQLライクに使うための物
- 最近はだいぶ速い
- エンジンをTezにするだけでもMapReduceよりも速くなる
- カラムナー形式にするのもいい（ORCはHiveで使うこと前提に作られてるので相性も良い）
- CBO オプティマイザ。
- Vectorization
- CPUの命令セットのレベルに処理してくれる
LLAPとは
Tezでもだいぶ速くなったけど、DWHに入れたりとかの使い方が多いか
Hive2.0からの新機能
LLAPの基本的な思想
- Daemon化することで起動コストを削減
- Apache Sliderを利用
- Hadoop上でDaemonとして動かす仕組みを提供するもの
- Pig並にググラビリティが低い
- Hybridな環境
- TezのVrtexをDaemon化するのがLLAP
- LLAP自体は実行エンジンではない
キャッシュ
中央集権的に持っているわけではなく、ノード毎に持ってるだけ
Off-Heapを利用しているので、JavaのフルGCとかの危険性は下がっている
マルチスレッド、パイプライン
複数のExecutorで実行
ノード数×Executor数が実際に実行できる並列数になる
増やせばいいってもんではない。
適切な数に設定する必要がある。
有効に使い切れて枯渇しない数にする必要がある。
Hive LLAP vs Spark SQL
HiveQLはSQLとは違う
Hive使ってる人は互換性の分で乗り換えるの辛いんじゃないか
データがメモリに乗り切らない場合はTezが有利なはず
ストリーム処理をしたい場合
→ HDFSに依存しているので、Spark Streamingの方が便利か
LLAPの実行速度
Hive on Tezの速度比較
- LLAPを使うとどれくらい速くなるのか？
- 3回同じ処理を実行しての平均速度
TCP-DSの結果
ほとんどのクエリに置いてはLLAPを利用した方が速い
LLAPで極端に遅くなっているけど、原因は今見てる途中
LLAPの今後
- セキュリティ周り
- バグ周り
- キャッシュの洗練
Maintainable Cloud Architecture of Hadoop
クラウドでHadoopを使う理由
日々勝手に性能あがって安定して安くなっていく
Hadoopが他のWebサービスとかと決定的に違うのは、Hadoop自体が他のアプリケーションに使われる物だから、その下地になるものが必要。
それをクラウドは提供してくれる。
メンテなビリティとあｈ
- ステートレス・状態を持たない
- モビリティ・簡単に別の場所で動かせる
- キューイング・エラー処理とかを適切にできる
Stateless
- Stateless Hive Metastore
ステートフルなメタデータは？
MySQLかなんかにツッコんでる
HCatalog使えばできるかもしれんが…
コストがかかる
Metastoreを捨てられなくなる。
ステートレスなめたストア
組み込みのローカルメタストアを作る
MessagePackでデータやりとりしてる
問題があれば消せばいい
PlazmaDB
- PostgreSQL(Amazon RDS)
- トランザクション処理
- S3 or Riak
- Immutable
- S3とRiakの使い分けは？
- 使い分けてると言うよりは、サービスの違いでそれぞれ使ってるって感じ。
ここで大事なのはステートレスにできない。
上記二つを組み合わせることで整合性が保てなくなるってことがないことを保証できる
Mobility
複数のHadoopバージョンを管理するために
色んなディスとろ、色んなバージョン使うことになって維持する必要があったりする。
クライアントも一個一個管理しないといけない。
これを最小限に抑える。
ジョブワーカーを一つにまとめる。
Queueing
REST API for Hadoop
Workerはキュー。
Hadoop Job ServerがいるとPresto APIと同じように使えて便利
Perfect Queue
Perfect Queue
- キューをRDBMSに構築
- Amazon SQS like
- グレースフルシャットダウンとライブ離スターティングができるので、ジョブのデータが消えない。気を遣わなくていい。
まとめ
- Stateless
- 状態を持たないアプリケーションは究極的にはできないけど、できるだけどっか一つに集める
- Mobility
- マイグレーションのしやすさ
- Queueing
- ジョブが動いてるのか、とか止めることを気にせずにできる仕組みにする必要がある
複数バージョンを維持するメリットはない