20160127三木会 RDB経験者のためのspark

データベース技術者の皆様に

なるべくわかりやすく

Apache Spark を説明してみます

Sky株式会社　玉川竜司

自己紹介

玉川竜司です• 本職はセキュリティソフトの開発

• 一番使っているのはSQL Server

• SQLiteも大好きです

• db tech showcaseではMongoDBの

人としてデビュー

• 今年はSparkの人で登壇？

• オライリージャパンで翻訳してます

• FB: Ryuji Tamagawa

• Twitter : tamagawa_ryuji

過去の翻訳

2015年の翻訳

2016年の予定

本日の内容• HadoopエコシステムとSpark

• MapReduceとSpark

• Sparkの動作

• Sparkの今後

HadoopエコシステムとSpark

Hadoop 0.xの時代

HadoopRDB

OS

ファイルI/O

メモリバッファ

クエリ実行エンジン

SQL

ドライバ

OS

HDFS

MapReduce

• 分散処理の基盤だけがある状態

• HDFS / MapReduceによる耐障害性と分散処理の性能の保証

• プログラミングはめっちゃ大変

Hadoop 1.xの時代

HadoopRDB

OS

ファイルI/O

メモリバッファ

クエリ実行エンジン

SQL

ドライバ

OS

HDFS

Hive e.t.c.

HBaseMapReduce

ドライバ

• 「上物」の整備が進む

• Hiveの登場で、SQLでのアクセスが可能に

• ランダムアクセスで読み書き可能なデータベースエンジンであるHBaseが登場

• その他、エコシステムの整備が進む

Hadoop 2.xとSparkの登場

OS

HDFS

Hive e.t.c.

HBaseMapReduce

YARN

Spark（Spark Streaming, MLlib,

GraphX, Spark SQL)

注：この階層図は技術的に正確ではありません。複雑すぎて正確に描くことはたぶん無理･･･

Impalaなど（インメモリ系SQL）

「Hadoopって何？」という問いに対する答はどんどん難しくなっていて、狭義ではHDFS+YARN+MapReduceあたりです。ただ、全部ひっくるめて「エコシステム」って表現することが多くなりました。

RDB

OS

ファイルI/O

メモリバッファ

クエリ実行エンジン

SQL

ドライバ

MapReduceによらない

クエリ実行エンジンが増えてきた

ターゲットの違い基本的な指向 I/Oの特性 集中 / 分散

RDB小さいレコードを細かく読み・書き・更新

比較的小さな領域をランダムアクセス

集中

Hadoop エコシステム

1回書いて何度も読む

比較的大きな領域をシーケンシャルアクセス

分散

• RDBもHadoopエコシステムも、それぞれの領域をカバーするような取り組みが進んでいますが、基本的な性格を理解しておくことは重要だと思います。

MapReduceとSpark

Sparkが注目される2つの理由

処理が高速

プログラミングが容易

その他の特徴• Scale-inが容易（小規模な方向へのスケーラビリティ）

• インタラクティブシェルによる探索的コンピューティング

• 豊富なライブラリ（MLlib、GraphX、SparkStreaming･･･）

• ファイルI/OはHadoopのライブラリを利用できる

• HDFSやS3をファイルシステムとしてそのまま活用できる

フレームワークの違い基本的な処理の単位 処理の対象 JVM クラスタ管理

MapReduce Map / Reduce ファイル フェーズごとに起動・終了 YARN

SparkRDD / DataFrameに対する操作

（高レベルなAPI）RDD 起動しっぱなし YARN / Mesos / ス

タンドアローン

Sparkが高速な理由

map

JVM Invocation

I/0

HD

FS

reduce

JVM Invocation

I/0

map

JVM Invocation

I/0

reduce

JVM Invocation

I/0

f1（read data to RDD）

Executor（JVM）Invocation

HD

FS

I/O

f2

f3

f4（persist to storage）

f5（does shuffle） I/O

f6

f7

Mem

ory (RDD

s)

access

access

access

access I/O

access

access

MapReduce Spark

MapReduceとSparkの速度

Spark

MapReduce

データ量

処理時間

注：イメージです

Sparkの動作

RDD（耐障害性分散データセット）

• 論理的には、プログラミング言語でいうところのコレクション

• 実体としては、RDBでのビューにキャッシュの機能を追加したもの、という感じ

• 「パーティション」に分割され、クラスタを構成するノード群にまたがって配置される

ノード

RDD-A Partition #1

RDD-B Partition #1

ノード

Partition #2

Partition #2

ノード

Partition #3

Partition #3

ノード

Partition #4

Partition #4

RDDの処理• 論理的にはコレクション。物理的にはクラスタ内のノードに分散配置される

• RDDに対して「変換」をかけて、新たなRDDを生成する。データベースで言えば、ビューの定義にビューの定義を重ねているような感じ。

• RDDに対して「アクション」を行うと、RDDをさかのぼって計算が実行される。

# テキストを読んでRDDを生成rmRDD = sc.textfile(‘readme.md’)

#フィルタをかけて次のRDDを生spRDD = rmRDD.filter(…)

#もう1つフィルタ。sp10RDD = spRDD.filter(…)#この時点ではまだテキストファイルも読まれていない

#行数のカウント。この時点ですべての処理が走るcount = sp10RDD.count()

元のファイル

rmRDD

spRDD

sp10RDD

123

table

create view…

create view…

create view…

select count…

RDDの処理（論理構造）# テキストを読んでRDDを生成rmRDD = sc.textfile(‘readme.md’)

#フィルタをかけて次のRDDを生成RDD_1 = rmRDD.filter(…)

#もう1つフィルタ。RDD_2 = RDD_1.filter(…)

#この時点ではまだテキストファイルも読まれていない

#キャッシュを指示RDD_2.persist()

#1つめの分岐RDD_2_a = RDD_2.filter(…)

#行数のカウント。この時点ですべての処理が走るcount = RDD_2_a.count() #RDD_2はここでキャッシュ

#2つめの分岐RDD_2_b = RDD_2.filter(…)

#行数のカウント。この時点ですべての処理が走るcount = RDD_2_b.count() #演算はRDD_2以降のみ

ファイル

rmRDD

RDD_1

RDD_2

RDD_2_a RDD_2_a

123 456

RDDの処理（実行）driver Executor1 Executor2

# テキストを読んでRDDを生成rmRDD = sc.textfile(‘readme.md’)

#フィルタをかけて次のRDDを生成RDD_1 = rmRDD.filter(…)　#フィルタ1

#もう1つフィルタ。RDD_2 = RDD_1.filter(…) #フィルタ2

#この時点ではまだテキストファイルも読まれていない

#キャッシュを指示RDD_2.persist()

#1つめの分岐RDD_2_a = RDD_2.filter(…) #フィルタ2a

#行数のカウント。この時点ですべての処理が走るcount = RDD_2_a.count() #RDD_2はここでキャッシュ

#2つめの分岐RDD_2_b = RDD_2.filter(…) #フィルタ2b

#行数のカウント。この時点ですべての処理が走るcount = RDD_2_b.count() #演算はRDD_2以降のみ

rmRDD登録

フィルタ1登録

フィルタ2登録

RDD_2のキャッシュ準備

フィルタ2a登録

rmRDDの読み取り、フィルタ1,2,2aの実行、RDD_2のキャッシュ

フィルタ2b登録

フィルタ2b実行

シャッフルについて• RDDの変換は2種類に分類できる。シャッフルを伴うものと伴わないもの

• シャッフルを伴わないもの：変換前のパーティションと変換後のパーティションが一対一対応するもの。例えば単純なフィルタリング。

• シャッフルを伴うもの。変換前後でパーティション構成が変化するもの。例えば集計や結合処理。

Executor1

Partition #1

Partition #1’

Partition #A

Executor2

Partition #2

Partition2’

Partition #B

Executor3

Partition #3

Partition3’

Partition #C

シャッフルについて• 並列処理を行う際のコスト構造が

RDBとは大きく異なる

• Sparkにおいては、シャッフルの際にはストレージI/Oが生ずるため、非常にコストが大きい

• プロセスをまたがるデータの転送はネットワークを経由するという点でもコストが大きい

• 耐障害性の観点からも差異がある

Executor1

Partition #1

Partition #1’

Partition #A

Executor2

Partition #2

Partition2’

Partition #B

Executor3

Partition #3

Partition3’

Partition #C

DataFrame / Dataset（SchemaRDD）

• RDDはスキーマレス

• スキーマを適用することで、効率化とSQLでの処理をできるようにしたのがSchamaRDD（1.3）

• SchemaRDDをさらに発展させたのがDataFrame

• SQLはHiveに準拠。Select系のSQLは普通に書けるレベル

デモします

Sparkの今後

Project Tangsten

• RDBでいうクエリオプティマイザの強化プロジェクト

• バージョン1.5で登場

• まだまだ進行中

今後も発展していきそう• 「MapReduceは徐々にSparkに置き換えられていくだろう」

• 機械学習の分野がドライバになっている（MLlib）。イテレーティブな処理においては、MapReduceよりも圧倒的に高速

• Sparkをデータ処理の基盤としておくと何かとつぶしがきく感

• SQLもいけるし、手続き型の言語（Java, Scala, Python）もいける。Rもいける

質問タイムです!