Real Time Analytics via Spark & Scala | Spark & Scala Fundamentals | Spark & Scala Architecture
20160127三木会 RDB経験者のためのspark
-
Upload
ryuji-tamagawa -
Category
Software
-
view
1.759 -
download
1
Transcript of 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もいける
質問タイムです!