並列データベースシステムの概念と原理
•
120 likes•36,256 views
2014/01/30 筑波大学情報システム特別講義Dの講義資料です。 join関係はNAIST時代の宮崎先生のデータ工学Ⅱの内容を参考にしてます。 animation有効なビデオはこちら https://vimeo.com/85598907
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (16)
Similar to 並列データベースシステムの概念と原理
Similar to 並列データベースシステムの概念と原理 (20)
More from Makoto Yui
More from Makoto Yui (20)
Recently uploaded
Recently uploaded (9)
並列データベースシステムの概念と原理
- 1. 並列データベースシステム の概念と原理 産業技術総合研究所 情報技術研究部門 油井 誠 <m.yui@aist.go.jp> 2014/01/30 筑波大学情報システム特別講義D
- 3. 講義内容 序論 - 並列データベースの前に 並列処理の基礎 並列処理のTerminology 並列計算機アーキテクチャ 並列データベースのアーキテクチャ データベース処理の並列化 結合処理の高速化 並列ハッシュ結合 並列ソート パーティショニング手法 多重結合や計算機間のデータ交換で発生する問題 MapReduceによる関係演算の並列処理 3
- 4. データベース開発の流れ Coddの論文: 1970年 System RやIngres: 70年代中盤 Oracle, IBM DB2, Ingres: 80年代序盤 並列データベースの隆盛: 80年代後半 A Relational Model of Data for Large Shared Data Banks, Communications of ACM 商用: Teradata, Tandem、アカデミア: Gamma, SDC Google MapReduce発表: 2004年 並列データベースに再び脚光が集まる DeWitt, Stonebraker: MapReduce: A Major Step Backwards 「ちっとも革新的な所がない。25年前に開発された技術を実装したもの でしかない」 並列データベース技術の再訪、MapReduceも並列DBと同様の道を辿っている 10+スタートアップが開発/exit競争: 現在 Netezza => IBM, Greenplum => EMC, Vertica => HP, Aster Data => Teradata, DATAllegro => MS, Kickfire, ParAccel, Exasol etc. 4
- 6. 並行/並列/分散コンピューティング Concurrent (並行) Task1-a Task1-b Task1-b Task1-a timeline アプリケーションからみて 論理的に並行に実行される e.g., マルチタスクOSのスケジューリング Parallel (並列) Task1-a Task1-b Task1-a Task1-b 物理的に並行に実行される timeline Distributed (分散) Node 1 node 2 Node 3 ネットワークを介した複数の 計算機でタスクを処理すること （同時実行とは直接関係はない） 6
- 7. 並列処理の基礎 パイプライン並列（pipeline parallel) 依存関係のある演算を直列に並べて、各演算ステップを複数の PEでconcurrentに処理 入力⇒出力⇒入力のデータをパイプライン的に流す Dependent parallelとも言われる 独立並列（Independent parallel） op2 データの依存関係 op3 op1 op5 Pipeline並列が可能 op4 7
- 8. 並列処理の基礎 パイプライン並列（pipeline parallel) 依存関係のある演算を直列に並べて、各演算ステップを複数の PEでconcurrentに処理 入力⇒出力⇒入力のデータをパイプライン的に流す Dependent parallelとも言われる 独立並列（Independent parallel） 演算を並列にならべて、依存関係のない演算を複数のPEで parallelに処理 データ並列やパーティション並列とも言われる op2 データの依存関係 op3 op1 op4 op5 独立並列に実行しやすいようにデータを 分割(partitioning)しておくことが重要 8
- 9. なぜデータ並列が重要か At 10 MB/s 1.2 days to scan 1 Terabyte 1,000並列 1.7 minutes to scan 1 Terabyte 10 MB/s Materials taken from “Readings in Database Systems”, Joseph M. Hellerstein and Michael Stonebraker, eds. 9
- 12. 並列計算機のアーキテクチャ Shared-memory（共有メモリ） 単一のメモリ空間を共有できるのでプログラミングは容易 (メモリ上で同期処理をすればよい） 専用の相互接続網を利用するため高価 Scale-up構成によりスケーラビリティに制限がある メモリバンド幅が相互接続網によって制限をうける 最大CPU接続数に制限がある PE1 PE2 PE3 PE4 CPU CPU CPU CPU Mem Mem Mem Mem 相互接続網 プロセッサ要素 (Processor Element) （バス/クロスバースイッチ） Mem Disk Disk Disk Disk 12
- 13. 並列計算機のアーキテクチャ Shared-disk（共有ディスク） ネットワーク帯域とストレージの性能依存 I/Oに関してScale-up型の構成となる ファイバーチャネル等の高価な高速ネットワークが前提 共有ディスク上でのデータ同期をする ディスクバンド幅がStorage Area Networkの性能で制限される PE1 PE2 PE3 PE4 CPU CPU CPU CPU Mem Mem Mem Mem プロセッサ要素 (Processor Element) 高速ネットワーク Storage 13
- 14. 並列データベースの実行環境 Shared-nothing（無共有型） Shared-memory（共有メモリ） Hard to program / Cheap to build / Easy to scale-up Teradata, Greenplum 等、現在の並列データベースで主流の構成 MapReduce等もこの構成 一般的に同期処理の少ないバッチ処理/分析タスクに適する Easy to program / Expensive to build / Hard to scale-up VMS cluster、MySQL cluster MySQL clusterはN/Wを介したメッセージパッシングによりオンメモリテーブル を共有（ HWは無共有型だが、SWレベルで共有メモリ型） Shared-disk（共有ディスク） プログラミングのしやすさやスケールアップのしやすさは Shared-nothingとshared-memoryの中間 Oracle RAC, DB2 pure scale トランザクション処理をする既存DBの高性能化でよく利用される 現在のトレンドはShared-Nothing （共有ディスクに移行したDB2のような例もあり、用途次第） 14
- 15. データベース処理の並列化 Intra-query並列化 Intra-operator並列化 Scan, Sort, Join, Aggregation等を並列に処理 Inter-operator並列化 Join 問合せ木の中の並列性を抽出して並列実行 Sort scan scan A B それぞれの演算が異なるサイトでconcurrentに動作 Pipeline並列化 Inter-query並列化 複数の独立したクエリを異なるProcessor Elementが 並列に実行する 複数のトランザクションの並列実行 多くのインターネットサービスプロバイダが行っている Database shardingはこのタイプ e.g., IDの範囲ごとにDBを分けてトランザクションを分割 15
- 16. Nested-loop Join (入れ子ループ結合) 結合処理はデータベースで もっとも重たい処理 SELECT C.name, C.email FROM Customers C, Sales S WHERE C.custId = S.custId and S.amount > 1000 C.name, C.email nested-loop join projection for each s for each c s.custid = c.custid C.custId = S.custId Eq-Join 外側テーブル (N件) 内側テーブル (M件) Selection Sales表 Customer表 ３ ７ １ ４ S.amount > 1000 ２ ４ ９ ２ タプル読み書き回数から 時間計算量 O(N×M) 外1行毎に 全スキャン 16
- 17. Hash Join (ハッシュ結合) 等結合の場合 R[i].attr=S[j].attr h(R[i].attr) = h(S[j].attr)が成り立つ ただし、h(x)はハッシュ関数 Ｒ h(R)=0 h(R)=1 h(R)=2 h(R)=3 h(S)=0 Ｓ h(S)=1 h(S)=2 h(S)=3 突き合せる領域が圧倒的に減る 17
- 18. Hash Join Buildフェーズ 事前に内側テーブルのハッシュ表を作成 Probeフェーズ 外側テーブルを一行づつ読み込み、ハッシュ関数を適用したタ プルと対応するハッシュバケット内のタプルを照合 内側テーブル 外側テーブル (M件) scan Hash bucket (N件) ３ ２ ７ build probe １ ４ h(x) h(x) ４ ２ ９ Hash表 二次記憶へのタプル読み書き回数から 時間計算量 O(N+M) Pros: 一度ハッシュ表を作ってし まえばメモリ内の検索なの で高速 Cons: ハッシュ表がメモリに収ま らないと性能劣化、巨大 データに使えない 先頭から一列づつ probe 18
- 19. Grace Hash Join (Kitsuregawa et al.) ハッシュ表がメモリから溢れる場合の結合アルゴリズム Splitフェーズ build Ｒ h1(x) R1 R2 Joinフェーズ S … Rn build h1(x) h2(x) h1とh2でハッシュ関数が 異なってもよい h2(x) Hash表 … N+Mの読み込み N+Mの書き込み N+Mの読み込み probe Ｒi S2 Sn ハッシュバケットを メモリに乗切る量ごとに ファイルに格納 ここは通常のHash Joinと同じ（build⇒probe) この作業を各バケットごとに行う 並列化可能! build S1 Si タプル読み書き回数から 時間計算量 O(3(N+M)) 19
- 20. Hybrid Hash Join (Gamma by DeWitt et al.) Grace Hash Joinのちょっとした改良 Splitフェーズ それぞれ1つのバケットR1をメモリ上に保持しておく h1(s)=1に関しては、R1を使って、この段階でprobeしてしまう R1を使ってprobe build Ｒ h1(x) R1 R2 … build S h1(x) Rn S2 … Sn （N + M）% BucketSize 分のディスク 読み書きを削減 タプル読み書き回数から 時間計算量 O( 3(N+M)-2(N+M)/BucketSize ) 20
- 21. Parallel Grace Hash Join (Kitsuregawa et al.) Graceハッシュ結合をn台の計算機を利用して 並列に行うもの Splitフェーズで計算機間にパーティショニング 結合キーで予めデータ分割されていればデータ交換不要 Joinフェーズは各計算機でローカルに並列実行 build Ｒ h1(x) R1 R2 … Rn build S h1(x) S1 S2 … Sn ハッシュ値の偏りに対処した分散バケット法も提案されている Bucket spreading parallel hash: a new, robust, parallel hash join method for data skew in the super database computer, Masaru Kitsuregawa, Yasushi Ogawa, In Proc. VLDB, 1990. 21
- 22. 結合以外の関係演算の並列処理 選択、射影演算 各PEで独立に演算 集約演算 結合則と交換則を満たせば並列化可能 各PEでPartial aggregation（部分集約）した結果をまとめる 分割統治してO(logN) Group-byによるグループ化演算 count(S) = S count(s(i)) sum(s) = S sum(s(i)) avg(S) = S sum(s(i)) / S count(s(i)) グループ化する属性値に基づいて並列ハッシュ結合と同様の手法 で計算 ソート演算 マージソートの並列化、部分奇数ソートの並列化 22
- 23. マージソートの並列化 各runごとの2wayのマージを複数のPEで並列 に実行 問題点：処理が進むごとに並列性が落ちる 3,4 6,2 9,4 8,7 5,6 3,1 3,4 2,6 4,9 7,8 5,6 1,3 入力ファイルは適度にブロック分割 2 2 4,7 8,9 2,3 4,6 1,3 5,6 2,3 4,4 6,7 8,9 2 1,2 3,5 6 1,2 2,3 3,4 4,5 6,6 7,8 9 1st run ８並列 2nd run ４並列 3rd run ２並列 4th run Runが進むごとに遊休PEが発生 23
- 25. 部分奇数ソートの並列化 1. 2. 各PEで、ソートキーの上位数ビットのみを用いてnグ ループに分割 分割されたグループを各PEに転送 バケットの偏りは問題 ⇒バケットのbin packing問題をfirst fitアルゴリズムでとけばよい （バケットを割り当て済み容量のもっとも小さいPEに埋める） 3. 各PEで独立並列にソート 0100011 1100101 1011101 0011111 … PE1 PE2 PE3 00 01 Bucket spreading parallel hash: a new, robust, parallel hash join method 1100101 0011111 for data skew in 0100011 the super database computer, Masaru Kitsuregawa, 00 1111011 Yasushi Ogawa, In Proc. VLDB, 1990. 01 11 10 11 0011111 1111010 0111101 10 1011101 1100101 のbucket spreading法を応用するとこれらのフェーズを賢く実装出来るので興 0111010 1000011 0011010 味がある方は読んでみるとよい 0011011 25
- 26. データ分割 Range partitioning Pros. 範囲問合せや結合が容易 Cons. データの偏りが発生 Round-robin partitioning 選択、射影演算ぐらいにしか使えない i-p q-z a Pros. データの偏りが少ない 負荷の均等分散が可能 Cons. 等結合も範囲問合せも困難 a-h z a d c f b e a z Hash partitioning Pros. 比較的データの偏りが小さい Pros. 等結合に適する 偏りを小さくする手法が確立されている 並列ハッシュ結合で高速実行できる b d a c e Hash(x) a z Cons. 範囲問合せが困難 多くの商用並列DBでハッシュ分割+並列Graceが採用されている パーティショニングはデータ並列への鍵 26
- 27. データ分割 Range partitioning なおList partitioningというのもあり、Range partitioning q-z i-p a-h Pros. 範囲問合せや結合が容易 は暗黙的なList partitioningといえる Cons. データの偏りが発生 Round-robin partitioning Pros. データの偏りが少ない 負荷の均等分散が可能 Cons. 等結合も範囲問合せも困難 a 選択、射影演算ぐらいにしか使えない a d z c f b e a z Hash partitioning Pros. 比較的データの偏りが小さい Pros. 等結合に適する 偏りを小さくする手法が確立されている 並列ハッシュ結合で高速実行できる b d a c e Hash(x) a z Cons. 範囲問合せが困難 多くの商用並列DBでハッシュ分割+並列Graceが採用されている パーティショニングはデータ並列への鍵 27
- 28. Partitioned Join 事前にデータ分割を行うパーティション並列を活かした結 合処理 並列ハッシュ結合のsplitフェーズを省略してローカルにJoin 事前データ分割に用いる属性の選択が鍵 Join on R.x = S.x build Ｒ h1(x) R1 S1 R2 S2 … … Rn build S Sn 事前にデータ分割 h1(x) 事前にデータ分割 28
- 29. 多重結合(Multi-way Joins)の問題 タプルの再分散が発生してしまう Select R1.A, R3.B From R1, R2, R3 Where R1.A = R2.A and R2.B = R3.B Requires R2 partitioned by attribute A Join Requires R2 partitioned by attribute B Conflict Shuffle R3 Join R1 R2 29
- 30. Shuffleの問題点 スパコンとは異なり、汎用の計算機クラスタではラック 間の接続が細い（48Gbps未満) バイセクションバンド幅（全ての計算ノードが全力で通信した 時にシステム全体で達成しうる通信性能）が低い Many-to-one通信パターンで tcpパケットの再送が発生 http://www.pdl.cmu.edu/Incast/ Root switch Rack switch 10GbE Rack switch 1GbE DB DB Node DB Node 1 rack DB Node DB Node DB Node Ethernet Node FAT-tree (Tsubame2で採用) 30
- 31. Shuffleの問題点 スパコンとは異なり、汎用の計算機クラスタではラック 間の接続が細い（48Gbps未満) バイセクションバンド幅（全ての計算ノードが全力で通信した 時にシステム全体で達成しうる通信性能）が低い Many-to-one通信パターンで tcpパケットの再送が発生 http://www.pdl.cmu.edu/Incast/ 猛烈shuffleにはTCP incastという問題があり、商用並列DBではtcp以外の独自 ネットワークプロトコルが利用されている Root switch Rack switch 10GbE Rack switch 1GbE DB DB Node DB Node 1 rack DB Node DB Node DB Node Ethernet Node FAT-tree (Tsubame2で採用) 31
- 32. Shuffleの問題点 ネットワークでの競合以外にも送信側、受信側もそれぞ れボトルネックに成りえる At a sender At a receiver In the network Facebookのある一週間の実績（188,000 MapReduce jobs、3000ノード） では、全体の33%の時間がshuffleに費やされている Orchestra, Proc. SIGCOMM, 2011 Shuffle処理では、タプルのディスクからの読み出し、タ プルごとのハッシュ値の計算といったコストもかかる 32
- 33. MapReduce 複雑な分散処理を単純なプログラミングモデルに包んで 抽象化 並列ハッシュ結合のSplitと同じことをshuffleでやっている ユーザはmap/Reduce関数を書くだけ map(k1, v1) => k2, v2 reduce(k2,list<v2>) => k3, v3 Map Merge Sort reduce Merge Sort reduce Shuffle Map Map Local disk write/read Local Disk write/read 33
- 34. MapReduceの実行イメージ Machine 1 <k1, v1> <k2, v2> <k3, v3> <nk1, nv1> <nk2, nv2> <nk3, nv3> Local Map <nk1, nv1> <nk3, nv3> <nk1, nv6> Global Shuffle <nk1, nv1> <nk1, nv6> <nk3, nv3> Local Sort <nk1, 2> <nk3, 1> Local Reduce Machine 2 <k4, v4> <k5, v5> <k6, v6> <nk2, nv4> <nk2, nv5> <nk1, nv6> <nk2, nv4> <nk2, nv5> <nk2, nv2> <nk2, nv4> <nk2, nv5> <nk2, nv2> <nk2, 3> 34
- 35. ワードカウントの実行例 入力ファイル: doc1 foo foo foo bar bar buz Map Input Output Map Map DFS Reduce Reduce shuffle DFS 35
- 36. ワードカウント – map input 入力ファイル: doc1 foo foo foo bar bar buz map(k1, v1) => k2, v2 doc1: foo doc1: foo Map Reduce doc1: foo doc1: bar Input Output Map doc1: bar doc1: buz Map DFS Reduce shuffle DFS 36
- 37. ワードカウント – map output 入力ファイル: doc1 foo foo foo bar bar buz map(k1, v1) => k2, v2 foo: 1 foo: 1 doc1: foo doc1: foo Map doc1: foo doc1: bar Input Output Map doc1: bar doc1: buz bar: 1 buz: 1 Map DFS Reduce foo: 1 bar: 1 Reduce shuffle DFS 37
- 38. ワードカウント – reduce input 入力ファイル: doc1 foo foo foo bar bar buz reduce(k2,list<v2>) => k3, v3 foo: 1 foo: 1 bar: <1,1> buz: <1> Map Reduce foo: 1 bar: 1 Input Output Map bar: 1 buz: 1 Map DFS foo: <1, 1, 1> Reduce shuffle DFS 38
- 39. ワードカウント – reduce output 入力ファイル: doc1 foo foo foo bar bar buz reduce(k2,list<v2>) => k3, v3 bar: 2 buz: 1 bar: <1,1> buz: <1> Map Input Reduce Output Map foo: <1, 1, 1> Map DFS foo: 3 Reduce shuffle DFS 39
- 40. ワードカウントの実行例 入力ファイル: doc1 ワードカウント結果 foo foo foo bar bar buz bar: 2 buz: 1 foo: 3 bar: 2 buz: 1 Map Input Reduce Output Map foo: 3 Map DFS Reduce shuffle DFS 40
- 41. MapReduce Internal 基本的に次のフェーズから成る map, shuffle(copy+sort)、reduce Tom White: Hadoop: The Definitive Guideより抜粋 41
- 42. MapReduce Internal 並列データベースだとmapからreduceへの入力はpushされるが、 基本的に次のフェーズから成る MapReduceは実際にはreducerがmapperの出力をpullするという モデルになっている map, shuffle(copy+sort)、reduce Tom White: Hadoop: The Definitive Guideより抜粋 42
- 43. MapReduceによる関係演算の実行 pv_users pageid age 1 25 2 25 1 32 2 25 pageid age count 1 25 1 2 25 2 1 32 1 SELECT pageid, age, count(1) FROM pv_users GROUP BY pageid, age 43
- 44. GROUP BY in MapReduce SELECT pageid, age, count(1) FROM pv_users GROUP BY pageid, age pv_users pageid age key value key value pagei 1 25 <1,25> 1 <1,25> 1 1 2 25 <2,25> 1 <1,32> 1 1 Map pageid 1 age 32 key <1,32> value 1 Shuffle Sort Reduce key <2,25> value 1 pagei 2 2 25 <2,25> 1 <2,25> 1 44
- 45. GROUP BY in MapReduce SELECT pageid, age, count(1) FROM pv_users GROUP BY pageid, age key value key value pageid age count <1,25> 1 <1,25> 1 1 25 1 <2,25> 1 <1,32> 1 1 32 1 pageid age count 2 25 2 key <1,32> <2,25> value 1 1 Shuffle Sort Reduce key <2,25> <2,25> value 1 1 45
- 46. Reduce-side Join Map task 1 テーブルR(a,b)をスキャン 各タプルごとにb属性を出力キーとして hash(b)=iのReduceタスクにタプルを送信 Reduce task i R.b=S.b Map task 2 結合処理をreducer側で行う テーブルS(b,c)をスキャン 各タプルごとにb属性を出力キーとして hash(b)=iのReduceタスクにタプルを送信 46
- 47. Reduce-side Join Example SELECT pv.pageid, u.age FROM page_view pv JOIN user u ON (pv.userid = u.userid) page_view pageid userid time userid value userid value 1 111 9:08:01 111 <pageid,1> 111 <pageid,1> 2 111 9:08:13 111 <pageid,2> 111 <pageid,2> 1 222 9:08:14 222 <pageid,1> 111 <age,25> Map user Shuffle Sort Reduce userid age gender userid value userid value 111 25 female 111 <age,25> 222 <pageid,1> 222 32 male 222 <age,32> 222 useridが <age,32> 47
- 48. Reduce-side Join Example SELECT pv.pageid, u.age FROM page_view pv JOIN user u ON (pv.userid = u.userid) pv_users userid value userid value 111 <pageid,1> 111 <pageid,1> pageid age 111 <pageid,2> 111 <pageid,2> 1 25 222 <pageid,1> 111 <age,25> 2 25 Map Shuffle Sort Reduce userid value userid value 111 <age,25> 222 <pageid,1> 222 <age,32> 222 <age,32> useridが同じpageidとageの組合せを列挙 pageid age 1 32 48
- 49. Map-side Join (Fragment and Replicate Strategy) 小さなテーブルを全ノードにコピーしてmap側で結合 処理を実行 問題点: データ量に対するスケーラビリティ データを全ノード（タスク）にコピーしなければならない 複製するテーブルが巨大だったらローカルの結合処理でボトル ネックとなる Fragment (large table) Map tasks: Split 1 Duplicate (small table) Split 2 Split 3 Split 4 Duplicate 49
- 50. Multi-way Join by MapReduce A (A join B on A.k1=B.k1) as AB join C on AB.k1 = C.k2 k1 av 1 111 AB k1 B av 1 k1 bv 1 bv ABC 111 222 MapReduce 222 k1 C MapReduce k2 bv cv 111 222 333 cv 1 1 av 333 複数回のMapReduceイテレーションが必要 ⇒Shuffleのオーバヘッドや分散ファイルシステム への入出力が増える 50
- 51. Multi-way Join for M/R [Arfati & Ullman, EDBT 2010] R.B=S.B and S.C = T.Cの結合のときに、hash(B) とhash(C)をshuffleに用いる Rには属性Cは存在しない⇒すべてのノードに複製を置く MapReduceのイテレーションは一回で済む タプルの一位性が崩れるので、事前のデータ分割には使 えない R(A,B) h(B,C) 0 1 S(B,C) 2 T(C,D) 3 4 X軸=hash(C) 5 0 1 2 3 4 Y軸=hash(B) 5 51
- 52. 本日話した内容のまとめ BigDataに対処するための並列データ処理技術を紹介した 並列データベースの構成法 Shared-{Nothing|Disk|Memory}等のアーキテクチャ 並列ハッシュ結合、並列ソート BigDataの技術的に最も困難な課題は巨大なデータ同士のN×Nの結合 データ分割（ハッシュ、範囲、Round-Robin） 多重結合（multi-way Join)やshuffleといった並列処理で 発生する問題 ⇒ データ並列、Partitioned Parallelの重要性 MapReduceを利用した関係演算の処理手法 Facebook Hive(Hadoop), Google BigQueryなどでは、SQLイ ンタフェースをMapReduceの上に被している 関係データベースの機能（ビューや索引、統計情報の利用）を取り込みつつある MapReduceでは並列DBと同様のコア技術が使われている 大きな違いはトランザクションのありなし、非構造データの扱いやすさ、構 造データを扱う上での効率、分散ファイルシステムを前提とするか否か 52