Hadoop Spark Conference Japan 2016 いった


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

コントリビュータ増えてきた

よく利用されているコンポーネント

1. Spark SQL
2. Core
3. MLlib
4. Spark Streaming
5. 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
	- ジョブが動いてるのか、とか止めることを気にせずにできる仕組みにする必要がある

**複数バージョンを維持するメリットはない**