ScholarGate
アシスタント

ビッグデータ処理フレームワーク

ビッグデータフレームワークは、プログラマーが単一のマシンでは処理できないほど大規模なデータセットを、ランタイムが分散させ、耐障害性を持たせる並列データフローとして計算を表現することで処理することを可能にします。

PaperMindでテーマを探す近日公開Find papers & topics
Tools & resources
スライドをダウンロード
Learn & explore
動画近日公開

Definition

ビッグデータ処理フレームワークとは、プログラマーが非常に大規模なデータセットに対する計算を、高レベルのデータフロー演算子として表現することを可能にし、データを自動的にパーティション分割し、クラスター全体での並列実行をスケジュールし、ノード障害を許容するシステムのことです。

Scope

このトピックでは、クラスター規模のデータ処理のためのデータフロープログラミングモデルについて扱います。具体的には、MapReduceパラダイムとその限界、回復力のある分散データセットに基づいて構築されたインメモリデータフローエンジン、およびウィンドウ処理、イベント時間セマンティクス、厳密に1回(exactly-once)保証を備えた統合されたバッチ処理とストリーム処理についてです。また、膨大で、おそらく無限のデータがどのようにパーティション分割され、並列処理され、障害発生後に回復されるかについても説明します。

Core questions

  • 1台のマシンには大きすぎるデータに対する計算は、どのように表現され、並列実行されるのでしょうか?
  • インメモリエンジンとストリーミングエンジンは、バッチMapReduceをどのように改善しているのでしょうか?
  • 無制限で順不同のストリームに対して、正確性、レイテンシ、耐障害性はどのようにバランスが取られているのでしょうか?

Key theories

MapReduce
MapReduceは、データ処理を、レコードをキーと値のペアに変換するマップステップと、キーによって集約するリデュースステップとして表現します。ランタイムは、並列化、データのシャッフル、失敗したタスクの再実行を処理します。
Resilient distributed datasets
RDDは、耐障害性のあるインメモリ抽象化を提供します。その決定論的変換の系統(lineage)により、失われたパーティションを再計算できるため、ディスクベースのMapReduceよりもはるかに高速な反復的かつ対話的なクラスターコンピューティングが可能になります。
Unified batch and stream dataflow
最新のエンジンは、バッチ処理をストリーミングの特殊なケースとして扱い、イベント時間ウィンドウ処理とウォーターマーク、および一貫性のあるスナップショットを使用して、無制限で順不同のデータに対して厳密に1回(exactly-once)の結果を提供します。

Clinical relevance

これらのフレームワークは、検索、分析、レコメンデーション、機械学習パイプラインの背後にあるデータを処理し、ストリームエンジンはリアルタイム監視およびイベント駆動型アプリケーションを強化するため、データ集約型コンピューティングの中核インフラストラクチャとなっています。

History

Googleの2004年のMapReduce論文(2008年改訂)は、クラスター規模のデータ処理を確立しました。Sparkの回復力のある分散データセット(2012年)は、高速なインメモリ処理と反復処理をもたらしました。そして、Flinkやデータフローモデル(2015年)のようなシステムは、強力な正確性保証を備えたバッチ処理とストリーム処理を統合しました。

Debates

主要な処理モデルとしてのバッチ処理対ストリーミング処理
バッチ処理はより単純で、厳密に1回(exactly-once)の保証を容易に実現できますが、レイテンシが増加します。一方、ストリーミング処理は低レイテンシを提供しますが、順不同のデータに対する正確性の確保がより困難になります。統合エンジンは、ストリーミングがバッチ処理を包含できると主張していますが、大規模な履歴ジョブではバッチ処理が依然として一般的です。

Key figures

  • Jeffrey Dean
  • Sanjay Ghemawat
  • Matei Zaharia
  • Tyler Akidau

Related topics

Seminal works

  • dean2008
  • zaharia2012
  • akidau2015

Frequently asked questions

なぜSparkや類似のシステムは、多くのワークロードで単純なMapReduceに取って代わったのでしょうか?
MapReduceは、各ステップ間で中間結果をディスクに書き込むため、反復アルゴリズムでは処理が遅くなります。回復力のある分散データセットのようなインメモリ抽象化は、ステップ間でデータをメモリに保持し、障害発生時に失われたパーティションのみを再計算するため、反復的および対話型分析において大幅な高速化をもたらします。

Methods for this concept

Related concepts