Hadoop/Spark Conference Japan 2016 、午後最初のセッションはノーチラス・テクノロジーズの神林さんのセッションに参加。
最初から、メモを取るのは相当しんどいだろうと覚悟のセッションでしたが、濃厚濃密な内容で最後まで楽しむことができました。
自分が参加した中からベストセッションを選ぶなら間違いなくこの神林さんのセッションがベストでした。こんなの他では聞けませんもの。
では以降よりメモ。
次世代アーキテクチャから見たHadoop/Sparkの位置づけ ～特にRDMA・NVMを軸としたときの分散並列処理の観点から / 神林 飛志氏（ノーチラステクノロジーズ）
- 完全裏番組宣言。マニア向け。 Hadoop/Spark 知りたいなら表番組に行ったほうがいいよ、の前置きからスタート。
- そもそもメモをとれるのか、というチャレンジを自分もしにきてみた。
- ノーチラスがみてるのは 2020 年の展望。
- 今更、 Hadoop/Spark どう動いてるかのはなしはしないよ。
- 現状認識
- ビッグデータ、終わりました。ビジネスになってません。
- IoT も話題にはなっているけど、お金になってません。
- POC の話はよくある。
- 最大のボトルネックは NW
- まだまだ手探り状態
- Internet よりも Intranet が多い
- 結局、従来からの CRM とあまり変わっていない。
- ほとんどの案件が既存の DWH からの移行案件
- 日本市場どうよ
- 中小規模が多い
- 100node はまれに出る程度
- 大きいものはあるがとりあえずなんでもつっこんでいるもの、ようはゴミ
- つまり日本市場では基本的にノードは大規模にせず、どうやってレバレッジ利かす？って考えたほうがいい
- 中小規模が多い
- 日本は圧倒的にデータ容量が少ない
- 10node 以下がほとんど
- 1,000node 以上もいるけどほとんどない
- その間は空洞状態
- んで、 Hadoop/Spark
- やっぱり分散並列処理基盤としてはきわめて優秀
- データ集約基盤として考えると効率が悪い
- 想定しているユースケースが日本に合わない
- 課題
- 100node 以上のクラスターが主要ターゲット
- 何が問題なのか→故障率が高いこと
- 常に何かが壊れてると思っていたほうがいい
- そもそも Hadoop/Spark
- それゆえに障害復旧のアーキテクチャがそもそも論
- 難易度が高い
- 常にどこかで障害が起きていることが前提だから
- 難易度が高い
- それゆえにトレードオフ
- バリヤーいれまくり
- オーバーヘッドを許容する
- 余分にデータをもつ
- データ書きまくり、レプリケーションとりまくり
- それゆえに障害復旧のアーキテクチャがそもそも論
- ベストは自分で調整できること
- 結局何が問題なのか、障害対策復旧のトレードオフ
- 小規模小回り優先 (ノーチラスはここが戦場)
- 大規模ノンストップ優先
- 規模にあわせて調整したいができない
- 結局何が問題なのか、障害対策復旧のトレードオフ
- やれやれ Hadoop/Spark
- OSS だから Pull-req おくればいいじゃん
- 100node 以下、みてないし、と却下
- Hadoop/Spark は OSS でないという現実がある
- 結局、閉鎖的に
- 政治・勢力争い
- ソースがオープンなだけ
- だーかーら、コミッターがいることが重要だったりする
- フリーじゃないってこと
- OSS だから Pull-req おくればいいじゃん
- 重要なところ
- Hadoop/Spark の基本
- 100node 以下でも動くけど最適化はない
- 開発陣営がみてるところが違う
- Source が Open になった IBM ですよ！
- 新しいアーキテクチャへの対応は Hadoop/Spark からは出ない
- 99% SQLだろ、 DataFrame なんていらないだろ
- MW ベンダで最適化したい人だけでしょ、いるのは
- Hadoop/Spark の基本
- 新しいアーキテクチャ
- トレンド：ムーアの法則おわりました。
- 終わったと言ってないのが終わってるということ
- なので IO まわりをガッツリやっていこう
- 不揮発性メモリ
- メモリーバス強化
- ストレージのIOコストを減らす
- 高密度サーバ
- TheMachine(HP), RSA(Intel), Firebox(AMPLab)
- トレンド：ムーアの法則おわりました。
- Rack-scale-architecture
- Intel が提唱
- ラック単位
- バックプレーン統合
- 高速の Interconnect
- RDMA の提供
- NVM
- 1,000core
- メモリは基本的に共有化
- 一種の小型のスーパーコンピュータ
- MS の解説がオンラインになる
- ASPLOS'14 Scale-out NUMA: Rack scale In memory Computing
- とにかく Enterprise 系が多い
- SAPが力いれてる。 HANA が遅い。
- ようは金がよく流れてる
- RSAの主たる特徴
- なにはなくとも不揮発性メモリ
- NVM (Non-Volatile-Memory)
- データベースの革新に使うことができる
- データベースのログリカバリがほぼすべて image ベースになる。
- これをベースにした OSS がでてくるはず。
- コミットするなら絶対こっち。
- 特許切れでバンバンくるよ
- RDMA
- 共有メモリー
- Ramote-Direct-Memory-Access
- リモートの DMA
- HPC の主要機能
- ミドルが全然おいついてないのが問題
- OSS 陣営は何もできてないが、 MS(独自分散DB開発中), Oracle(EXAに投入したいらしい), SAP はがんばってる
- というわけで Hadoop/Spark はあと2−3年よ？
- 共有メモリー
- なにはなくとも不揮発性メモリ
- RSA でおさえておくべきもの
- OS
- node 管理の単位としてのOS
- 全体を統括する単位としてのOS
- 分散 OS 難しいよね
- 芽があるとしたら仮想基盤
- Mesos ぅう？
- 個々のノードが剥き出しの場合
- 全体を統括する MW が必要になる
- アプリだけで分散統括を処理することは非現実的
- 仮想基盤が対応可能かどうか
- データの置き方
- 基本戦略
- localメモリにデータを可能な限り置く
- 実はそうでもない。という結果が徐々に出始めている
- レーテンシー以外にデータ転送でバンド幅を使いきってスループットが極端に落ちるということになる
- 処理をインターリーブしたほうがいい
- 分散処理の基本に立ち戻ることになる
- データを飛ばすか？処理を飛ばすか？
- バンド幅を使い切ることがないかぎりはデータ転送が有利
- そうでないかぎりは処理をインターリーブしたほうがいい
- ベストの戦略は事前に計算できるか？
- ムリポ
- 全部 broadcast するか semi-join で往復ビンタするか？→ Population による
- stats とっておけばよくね？
- 更新どうする
- 完全に分散トランザクションの世界
- 基本的に MVCCC がベースになる
- 更新されたバージョンをどうよむか？
- Cache コントロールの話か、分散Tx の話か、整理が必要
- 完全に分散トランザクションの世界
- 基本戦略
- OS
- RSA で押さえておくべき要素技術
- 処理の選択とリソース管理
- ひとつのコンピュータとみせる場合
- 分散OS下で管理
- 複数ノードとみせる場合
- 分散ミドルで管理
- いままでのスケジューラでは機能が足りない
- 分散ミドルで管理
- ひとつのコンピュータとみせる場合
- 同時制御 - 分散トランザクション
- 人類にはまだ早い
- 前提として NVM
- Snapshot を有効に使える
- MVCC は大前提になる
- 低遅延もさらに前提
- RSA 上での分散トランザクション (主流)
- SSI方式
- shared nothing の延長
- ロックは利用しない
- SILO方式
- Writeのみロックをとる
- SSI方式
- オレオレ分散トランザクション最強説？！
- 前提として分散トランザクションを完全理解していることが前提
- シンプルな更新は SILO -> 変形 2PL
- 問題はメンテできるのかソレ問題
- 同期処理
- 対障害性設計
- Byzantine Failure まで考えるのか？
- Omission Failure は最低でも考えたほうがいい
- Byzantine Failure まで考えるのか？
- 合意プロセス
- 何かの障害で値がずれた、まあ、ありがち
- Paxos はあるか？
- Raft はあるか？
- RSA的な環境がノード分散とコア分さんんの中間的な位置づけなのできわめて微妙
- 何かの障害で値がずれた、まあ、ありがち
- 対障害性設計
- 処理の選択とリソース管理
- Hadoop/Spark からみると
- 居直り戦略
- 無視するということ
- 神林さんならこっちをとる
- Adaptive にいく
- RSAのようなものにも対応する
- 対応方針
- クラウド的なもので対応
- Mesos が大化けすれば可能性がある？？？？
- ガチで最適化
- クラウド的なもので対応
- 居直り戦略
- Hadoop/Sparkでの適応
- OS 実は分散 OS は必要ない
- 単純に各ノードでDAGのオペレータが走ればよい
- とりあえず走るミドルとしては Hadoop/Spark はRSAの最有力候補
- データの置き方で転ぶ
- リモートメモリーへの対応がどうしても必要になる
- スケジューラ
- 現状では空いてる CPU リソースに突っ込め、が限界
- トランザクション
- これは無理
- RAMP でお茶を濁すレベル
- 管理粒度変更、TM、ロック制御、全部ない
- これは無理
- 耐障害設計
- ZK の魔改造が必要になる
- 超高速な Omission Failure の処理が最低限必要
- OS 実は分散 OS は必要ない
- ということで Hadoop/Spark を RSA に対応させるには
- 絶望的にいろいろやりすぎる必要がある
- それをやるにはいろいろ周りにつくりすぎた
- ようは、無理です、という話。
- ただし無理なのはわかるがどのくらい無理なのかを知っておく必要があるということ
- 合意問題
- 分散トランザクション
- クエリー最適化
- NUMA
- ただし無理なのはわかるがどのくらい無理なのかを知っておく必要があるということ
- で、以上は全部、予想。
- うしろからよむとう・そ・よ。おあとがよろしいようで。
資料埋め込みリンク
- 公開されているものはこちらに埋め込みリンクさえていただく所存。
Hadoop/Spark Hadoop Conference 2016 でとってきた他のエントリへのリンク
- のちほどリンクを追加していく所存。
garagekidztweetz.hatenablog.com garagekidztweetz.hatenablog.comgaragekidztweetz.hatenablog.com garagekidztweetz.hatenablog.com garagekidztweetz.hatenablog.com
