「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
分散処理(分散コンピューティング)とは、
- 複雑な計算などをネットワークを介して複数のコンピュータを利用して行うことで、
- スループットを上げようとする取り組み、またはそれを実現する為の仕組み。
詳細 †
- 基本的には1990年代までの並列データベースの技術に基づいた並列データ処理系
- ハードウェアの高性能化や新たな需要を踏まえ,その中核をなす技術は少しずつ進展を遂げつつある。
基礎 †
アーキテクチャ †
無共有型のアーキテクチャが主流である。
- 型
- 共有メモリ型(シェアード・メモリ)
- 共有ディスク型(シェアード・ディスク)
- 無共有型(シェアード・ナッシング)
- 単一ハードウェアコンポーネントにおけるレイテンシ低減の停滞のため、
複数のハードウェアコンポーネントを効率的に活用する方向にシフトしている。
- 複数のコモディティサーバを高速なネットワークで接続した無共有型のクラスタシステムが
昨今のビッグデータ解析においては,価格性能比の点から,後者が広く利用されつつある。
実行プラン †
ざっくり、
「手続型言語によるデータ処理ではない、
宣言型言語によるデータ処理では、
処理の内容が、実行プランという形で別途計算される。」
みたいな話。
※ この中で、性能向上のために、並列化が行われる。
並列処理 †
- 問い合わせ間の並列性(Inter-query Parallelism)
複数の異なる問い合わせを並列に実行するときの並列性
- 問い合わせ内の並列性(Intra-query Parallelism)
1つの問い合わせを並列に実行可能な複数の
サブタスクに分解して実行するときの並列性
- オペレータ間の並列性(Inter-operator Parallelism)
問い合わせにおける複数の異なるオペレータを並列に実行するときの並列性
- パイプライン並列性(Pipelined Parallelism)
あるオペレータが出力するデータを
別のあるオペレータが入力する場合において,
これらのオペレータを並列に実行するときの並列性
- 独立並列性(Independent Parallelism)
データの依存関係がない複数の独立したオペレータを並列に実行するときの並列性
- オペレータ内の並列性(Intra-operator Parallelism)
1つのオペレータを並列実行可能な複数のサブタスクに分解して実行するときの並列性
- パーティション並列性(Partitioned Parallelism)
データを複数にパーティショニングし,
オペレータの複数のインスタンスが当該パーティションを
並列に読み出すことにより,オペレータ内の並列性を活用する。
※ SQL Serverの並列クエリはファイル・グループによるパーティション並列性になる。
データ分割 †
パーティション並列性のデータの分割方法には、主に次の3つの方法がある。
- ラウンドロビン分割(Round-Robin Partitioning)
均等に分散される。
- ハッシュ分割(Hash Partitioning)
均等に分散される。
- 範囲分割(Range Partitioning)
不均等だが、データが値でクラスタ化されており、
処理系が処理の効率化を図ることができる場合がある。
性能指標 †
並列処理の性能指標
- スケーラビリティ(Scalability)
以下の指標があるが、ビッグデータ系では、
スケールアップ(Scale-up)がより重要になる。
- スピードアップ(Speed-up)
ジョブを処理する計算資源をN倍に増やしたときに,
ジョブの処理時間がどの程度低下するか?
- スケールアップ(Scale-up)
ジョブを処理する計算資源をN倍に増やしたときに,
ジョブの仕事量(データ量)もN倍に増やしたときに,
ジョブの処理するための時間が同程度か?
- 線形なスケーラビリティ
理想的には線形なスケーラビリティを有することが望ましい。
- スピードアップ(Speed-up)では、
計算資源N倍で1/N時間になる場合。
- スケールアップ(Scale-up)では、(同じ処理時間で)
計算資源N倍で仕事量(データ量)もN倍になる場合。
アルゴリズム †
並列処理のオペレータとアルゴリズム
- 選択オペレータ
- スキャン(・アルゴリズム
- 索引スキャン(・アルゴリズム
- ソートマージ結合(アルゴリズム
- 並列化が可能(並列ソートマージ結合)
- 双方のソート済み結合キーで再パーティションして、結合。
- ソートマージ結合はハッシュ結合よりも低速
- ハッシュ結合(アルゴリズム
- 並列化が可能(並列ハッシュ結合)
- 片方の結合キーをハッシュに読み込み(再パーティションして)、結合。
- ハッシュ結合はソートマージ結合よりも高速
分散処理 †
本項での処理系は
「分散システム技術を活用した、
データ処理専用の並列システム」
と言うことができる。
- Hadoop MapReduce?
- ラウンドロビン分割(HDFS)のパーティション並列性を活用
- Map処理においては,並列スキャンを行う。
- 一種の並列ソートマージ結合処理フレームワーク的。
・通常はReduce側で並列ソートマージ結合を行う。
・Map側で並列ハッシュ結合を行うことも可能。
- Cloudera Impala / Presto
- ラウンドロビン分割(HDFS)でパーティション並列性を活用
- Map処理においては,並列スキャンを行う。
- 結合にハッシュ結合を使用しパイプライン並列性を活用
- Spark
Hadoopに類したデータ処理系
- ラウンドロビン分割(HDFS)のパーティション並列性を活用
- map(),filter()においては,並列スキャンを行う。
- 結合にハッシュ結合を使用しパイプライン並列性を活用
ストア †
データ・ストア、ディスクか?メモリか?
ディスク †
メモリ †
Apache Spark の Resilient Distributed Dataset (RDD)
その他 †
- NoSQL
SparkとCassandraなんて組み合わせもある模様。
処理 †
どのような処理を実行できるか?
分散(バッチ) †
得意とするストレージによってフレームワークが異なる感じ。
※ Hadoop MapReduceは他の分散エンジンの隆盛によってフェードアウト気味らしいが、
Hadoop や Hadoop Distributed File System (HDFS) は進化しつつあるらしい。
ストリーム †
- CEP(complex event processing)とも言う。
分散(バッチ) + ストリームみたいな組み合わせ。
目的 †
ビジネス上の目的の例。
意味付け †
前もって意味付けせずに生のまま蓄積できる。
- データ分析時にいろいろな意味付けを試してみる探索的なデータマイニングできる。
- 最新の統計理論をベースにゼロからプログラミングできる自由度をもっている。
データアナリストというよりデータサイエンティストに向いたアーキテクチャ
可視化 †
- 可視化が目的の場合、以下のような流れで処理を行う。
- ストリーム
- データ収集
- エンリッチメント
- 分散(バッチ)
- 蓄積
- 可視化
※ ディスクのデータをDWHにロードし、従来タイプのBIツール群を使うこともできる。
プロダクト †
分散(バッチ)系 †
HDFSを使ったビッグデータの分散(バッチ)処理のプロダクト。
ビッグデータの分散(バッチ)処理のプロダクト。
ストリーム系 †
ビッグデータのストリーム処理のプロダクト
ビッグデータのストリーム処理のプロダクト
※ Apache Stormとの違いはリンク先参照を。
データ収集・格納 †
- データ生成元 → HadoopのHDFS部の課題
- スクラッチ開発が必要なので、OSSのプロダクトが存在する。
非構造化データ
非構造化データ
時系列データ
業務データベースからのデータ
EAI/ETL系のデータフロー・オーケストレーション・ツールだが、
ビッグデータのコンテキストでデータ収集+エンリッチメント役割を担う。
処理性能を重視したメッセージキュー
- データをロストし難い仕組みを備える。
- 複数台のマシンでクラスタを構成
- 分散処理により高いスループットを発揮
目的別 †
分散(バッチ)系 †
- 繰返しの多い処理や、複雑な処理が苦手
- 複雑な処理は、MapReduce?ジョブの組み合わせで実現
- MapReduce?ジョブの都度、ディスクの読み書きが発生
- 複数台のサーバのメモリ/CPU/ディスクを効率よく利用
- 複雑な処理を実行できる。
- SQL(汎用化)
- 機械学習
- ストリーム
- ライブラリ、API
ストリーム系 †
... †
Elasticsearchの推奨構成
- ビッグデータの可視化のプロダクト群
- データはドキュメントで、全文検索処理を行う。
- ストレージにHadoopを使えるので分散処理系に分類
Kibana †
Logsatsh †
Beats †
参考 †
@IT †
- Amazon EMRで構築するApache Spark超入門
Think IT †
Qiita †
NTTデータ †
システム技術本部 †
先端技術株式会社 †