2009年にカリフォルニア大学バークレー校のAMPラボによって開発されたSparkは、インメモリコンピューティングに基づくビッグデータ向けの並列コンピューティングフレームワークで、大規模かつ低レイテンシのデータ分析アプリケーションの構築に使用できます。
Spark
スパークにはいくつかの重要な特徴があります：
高速：Sparkは、高度なDAG実行エンジンを使用して、周期的なデータフローとインメモリ計算をサポートし、メモリベースの実行速度はHadoop MapReduceの最大100倍、ディスクベースの実行速度は最大10倍です。Sparkは、Scala、Java、Python、およびRでのプログラミングをサポートしています。そのクリーンなAPI設計により、ユーザーは並列プログラムを簡単に構築でき、Spark Shellを介して対話的にプログラミングできます；
汎用性：Sparkは、SQLクエリ、ストリーミングコンピューティング、機械学習、グラフアルゴリズムコンポーネントを含む完全で強力なテクノロジースタックを提供し、同じアプリケーションにシームレスに統合でき、複雑な計算を処理するのに十分です；
さまざまな動作モード：Sparkは独立したクラスタモードで実行したり、Hadoopで実行したり、Amazon EC2などのクラウド環境で実行したりすることができ、HDFS、Cassandra、HBase、Hiveなどのさまざまなデータソースにアクセスできます。
SparkHadoopを超える利点
Hadoopはビッグデータ技術のデファクトスタンダードとなっていますが、それ自体にはまだ多くの欠陥があります。最も重要な欠陥は、そのMapReduceコンピューティングモデルがリアルタイムで高速なコンピューティングニーズに対応するにはレイテンシーが高すぎるため、オフラインのバッチ処理アプリケーションシナリオにしか適していないことです。
Hadoopのワークフローを見直すと、以下のようなデメリットがあります：
表現力が弱い。計算をMapとReduceの2つの操作に変換する必要がありますが、これはすべてのケースに適しているわけではなく、複雑なデータ処理を記述するのは困難です。各実行ではディスクからデータを読み込み、計算完了後に中間結果をディスクに書き込む必要があり、IOオーバーヘッドが大きい。計算は、順次実行される一連のMapReduceタスクに分解する必要がある場合があり、タスク間のアーティキュレーションは、IOオーバーヘッドを伴うため、高いレイテンシを発生させます。さらに、前のタスクの実行が完了した後、他のタスクを開始することができないため、複雑で多段階の計算タスクを実行することが困難です。Sparkには主に次のような利点があります：
Sparkの計算モデルもMapReduceに属しますが、MapとReduce操作に限定されず、様々なデータセット操作タイプを提供し、プログラミングモデルはMapReduceよりも柔軟です。Sparkはインメモリ計算を提供し、中間結果は直接メモリに置かれ、より高い反復計算効率をもたらします。SparkのDAGベースのタスクスケジューリング実行メカニズムは、MapReduceの反復実行メカニズムよりも優れています。Sparkの最大の特徴は、計算データ、中間結果をメモリ上に保存し、IOオーバーヘッドを大幅に削減することです。
Sparkはさまざまな高レベルで簡潔なAPIを提供しており、通常、同じ機能を実装するアプリケーションでは、Sparkのコード量はHadoopの2～5倍少なくなります。
しかし、SparkはHadoopの完全な代替ではなく、主にHadoopのMapReduceコンピューティングモデルを置き換えるために使用されます。実際、SparkはHadoopのエコシステムにうまく統合され、重要なメンバーになっています。YARNの助けを借りてリソーススケジューリング管理を実現し、HDFSの助けを借りて分散ストレージを実現できます。
Sparkエコシステム
Spark Core: Spark Coreには、インメモリ計算、タスクスケジューリング、デプロイモード、障害回復、ストレージ管理など、Sparkの基本的な機能が含まれています。Sparkは統一された抽象RDDの上に構築されているため、基本的に一貫した方法でさまざまなビッグデータ処理シナリオに対応できます。コア; Spark SQL: Spark SQLにより、開発者はRDDを直接処理できるほか、HiveやHBaseなどの外部データソースにクエリを発行できます。Spark Streaming: Spark Streaming は、高スループットで耐障害性に優れたリアルタイムのストリーミングデータ処理をサポートします。 Spark Streaming は、Kafka、Flume、TCP ソケットなど、さまざまなデータ入力ソースをサポートしています。MLlib：MLlibは、クラスタリング、分類、回帰、協調フィルタリングなど、一般的に使用される機械学習アルゴリズムの実装を提供し、機械学習の敷居を下げます。豊富な関数と演算子を備え、大量のデータに対して複雑なグラフアルゴリズムを快適に実行できます。
Spark基本概念
Sparkのランタイムアーキテクチャを具体的に説明する上で、まず理解しておくべき重要な概念がいくつかあります：
RDD: Resilient Distributed Datasetの略で、共有メモリの高度に制約されたモデルを提供する分散メモリの抽象化。DAG: Directed Acyclic Graphの略で、RDD間の依存関係を反映。タスク：エクゼキュータ上で実行される作業単位、ジョブ：ジョブには複数のRDDと、対応するRDDに対する様々な操作が含まれます、ステージ：ジョブの基本的なスケジューリング単位で、ジョブは複数のタスクグループに分割され、各タスクグループは「ステージ」、または「フェーズ」とも呼ばれます。各タスクグループは「フェーズ」と呼ばれ、「タスクセット」とも呼ばれます。
Sparkアーキテクチャ設計
Sparkのランタイムアーキテクチャは、クラスタリソースマネージャ、ジョブタスクを実行するワーカーノード、各アプリケーションのタスクコントロールノード、特定のタスクを担当する各ワーカーノード上の実行プロセスで構成されます。このうち、クラスタリソースマネージャは、Sparkに付属するリソースマネージャでも、YARNやMesosなどのリソース管理フレームワークでもかまいません。
さまざまなSparkコンセプトの関係
Sparkでは、アプリケーションはタスク制御ノードと複数のジョブで構成され、ジョブは複数のフェーズで構成され、フェーズは複数のタスクで構成されます。アプリケーションを実行する場合、タスクコントロールノードはクラスタマネージャにリソースを要求し、Executorを起動し、アプリケーションコードとファイルをExecutorに送信し、Executor上でタスクを実行し、実行終了時に実行結果をタスクコントロールノードに返したり、HDFSなどのデータベースに書き込んだりします。
Executor
Sparkで使用されるエクゼキュータには、Hadoop MapReduceコンピューティングフレームワークに対して2つの利点があります：
特定のタスクを実行するためにマルチスレッドを使用することで、タスクの起動時のオーバーヘッドを削減します。ExecutorにはBlockManagerストレージモジュールがあり、メモリとディスクを一緒にストレージデバイスとして使用します。複数ラウンドの反復計算が必要な場合、中間結果をこのストレージモジュールに保存しておくことで、次に必要なときにHDFSなどのファイルシステムに読み書きすることなく、ストレージモジュール内のデータを直接読み込むことができ、IOオーバーヘッドを効果的に削減します。あるいは、インタラクティブなクエリのシナリオでは、テーブルがあらかじめストレージシステムにキャッシュされているため、読み書きIO性能が向上します。HDFSなどのファイルシステムに読み書きすることで、IOオーバーヘッドを効果的に削減します。また、インタラクティブなクエリシナリオでは、テーブルが事前にストレージシステムにキャッシュされるため、読み取りと書き込みのIOパフォーマンスが向上します。
Spark基本フローの実行
スパークの基本的なランタイムは以下の通りです：
Spark アプリケーションがサブミットされると、最初にアプリケーションの基本的な実行環境を構築する必要があります。つまり、タスク制御ノードが SparkContext を作成し、リソースマネージャとの通信や、リソースの申請、タスクの割り当て、アプリケーションの監視などを行います。SparkContextはリソースマネージャに登録し、Executorを実行するためのリソースを要求します。リソースマネージャはExecutor用のリソースを割り当て、Executorプロセスを開始します。Executorの実行状況は、"heartbeat "と一緒にリソースマネージャに送信されます。SparkContextはRDDの依存関係に基づいてDAGグラフを構築し、DAGグラフはDAGスケジューラに提出されます。SparkContextはRDDの依存関係に基づいてDAGグラフを構築し、DAGグラフはDAGスケジューラに提出されます。DAGグラフはDAGスケジューラに提出され、DAGスケジューラはDAGグラフを複数の「フェーズ」に分解し、フェーズ間の依存関係を計算します。タスクスケジューラはExecutorにタスクを配布して実行させ、同時にSparkContextはアプリケーションコードをExecutorに配布します。タスクはExecutor上で実行され、実行結果はタスクスケジューラにフィードバックされ、DAGスケジューラにフィードバックされ、DAGスケジューラはデータを書き込み、すべてのリソースを解放します。リソースを解放します。
Spark実行アーキテクチャの特徴
スパークのランタイムアーキテクチャには、以下のような特徴があります：
各アプリケーションは、専用のExecutorプロセスを持っており、プロセスは、アプリケーションの期間中常駐します。Executorプロセスは、マルチスレッド方式でタスクを実行し、マルチプロセッシングタスクの頻繁な起動オーバーヘッドを削減し、タスクの実行は非常に効率的で信頼性が高くなります。Executor は、反復計算タスクの処理において、HDFS や他のファイルシステムに中間結果を書き込む必要がなく、直接ストレージシステム上にある、キーバリューストレージシステムに似た BlockManager ストレージモジュールを持っています。インタラクティブなクエリーシナリオでは、このストレージシステムにテーブルを事前にキャッシュして、読み取りと書き込みのIOパフォーマンスを向上させることもできます。このタスクは、データ局所性や投機的実行などの最適化メカニズムを採用しています。データローカリティとは、データのあるノードに計算を移動させようとすることです。つまり、「計算をデータに近づけよう」ということです。さらに、Sparkは遅延スケジューリングメカニズムを使用して、実行プロセスをより大きく最適化します。例えば、データのあるノードが現在他のタスクで占有されている場合、そのデータを他の空いているノードに移動させる必要があるのでしょうか？答えは必ずしもそうではありません。なぜなら、現在のノードがデータを移動するよりも現在のタスクの終了にかかる時間の方が短いと予測される場合、スケジューリングは現在のノードが使用可能になるまで待つからです。
Sparkの展開モデル
Sparkは、スタンドアロン、Spark on Mesos、Spark on YARNという3つの典型的なクラスタ展開方法をサポートしています。次に、エンタープライズにおけるSparkフレームワークの具体的な展開方法と適用方法を紹介します。実際のエンタープライズアプリケーション環境では、アプリケーションシナリオに応じて、異なる展開方法と適用方法を使用したり、Sparkを完全に使用したりすることができます。Sparkは、異なるアプリケーションシナリオのために異なる方法で展開することができ、またはSparkは完全に元のHadoopアーキテクチャを置き換えるために使用することができ、またはSparkとHadoopを一緒に展開することができます。
Spark3つのデプロイ方法
Sparkアプリケーションがクラスタ上で実行されるようにデプロイされるとき、さまざまなコンポーネントがそのためのリソース管理スケジューリングサービスを提供することができます。例えば、独自のスタンドアローンクラスターマネージャーを使用することも、YARNを使用することも、Mesosを使用することもできます。 1. スタンドアローンモード MapReduce1.0フレームワークと同様に、Sparkフレームワーク自体には完全なリソーススケジューリング管理サービスが付属しています。MapReduce1.0フレームワークと同様に、Sparkフレームワーク自体には完全なリソーススケジューリング管理サービスが付属しており、リソース管理スケジューリングサービスを提供する他のシステムに依存することなく、クラスタに独立してデプロイすることができます。アーキテクチャの設計上、SparkとMapReduce1.0は同じで、マスターと複数のスレーブ、リソース割り当て単位としてのスロットで構成されています。違いは、SparkのスロットはMapReduce1.0のようにMapスロットとReduceスロットに分かれておらず、統一されたスロットのみが設計されており、様々なタスクを利用することができます。2.Spark on Mesosモデル Mesosは、その上で動作するSparkにサービスを提供するリソーススケジューリング管理フレームワークです。Spark on Mesosモデルでは、MesosはSparkアプリケーションが必要とするさまざまなリソースのスケジューリングを担当します。MesosとSparkは、一定の血縁関係があるため、したがって、Sparkは、Mesosの完全なサポートの完全な配慮の設計と開発では、このフレームワークは、したがって、相対的に言えば、Mesos上で実行されているSparkは、YARN上で実行するよりも、より柔軟で自然です。現在、Sparkは正式にこのモデルを推奨しているので、多くの企業はまた、実用的なアプリケーションでこのモデルを使用します。
- Spark on YARNパターン SparkはYARNとHadoopの上で実行することができ、統一されたデプロイメントが可能です。
HadoopSparkによる統合デプロイメント
一方、Hadoopのエコシステムのために、機能のいくつかのコンポーネントは、現在のまたはSparkで置き換えることはできません達成するために、たとえば、Stormはミリ秒応答のストリームコンピューティングを達成することができますが、Sparkはミリ秒応答を行うことはできません。一方、すでに企業内の多くの既存のアプリケーションは、既存のHadoopコンポーネントに基づいて開発され、完全にSparkに転送するには、一定のコストが必要です。したがって、多くの実用的なエンタープライズアプリケーションでは、HadoopとSparkの統一展開は、より現実的かつ合理的な選択です。Hadoop MapReduce、HBase、Storm、Sparkなどは、リソース管理フレームワークYARNの上で実行できるため、YARNの上で統一的なデプロイを行うことができます。これらの異なるコンピューティングフレームワークがYARN上で統一的に実行されることで、以下のようなメリットが得られます：
コンピュートリソースをオンデマンドでスケーリング; アプリケーションを混在させてロードする必要がなく、高いクラスタ利用率; クラスタ間でのデータ移行を回避するために、基盤となるストレージを共有。
元の住所
