Hadoop、Storm、Samza、Spark、およびFlink：ビッグデータフレームワークの比較

Hadoopの処理機能は、MapReduceエンジンに由来しています。 MapReduceの処理技術は、キーと値のペアを使用してマップ、シャッフル、リデュースアルゴリズムに従います。 基本的な手順は次のとおりです。

この方法論は、タスクごとに何度も読み取りと書き込みを行う永続ストレージを大いに活用するため、かなり遅くなる傾向があります。 一方、ディスクスペースは通常、最も豊富なサーバーリソースの1つであるため、MapReduceが膨大なデータセットを処理できることを意味します。 これはまた、HadoopのMapReduceは、すべてをメモリに保存しようとしないため、通常、他の選択肢よりも安価なハードウェアで実行できることを意味します。 MapReduceは信じられないほどのスケーラビリティの可能性を持ち、数万のノードで実稼働で使用されています。

開発のターゲットとして、MapReduceはかなり急な学習曲線を持つことで知られています。 Hadoopエコシステムへのその他の追加により、この影響をさまざまな程度に減らすことができますが、Hadoopクラスターにアイデアを迅速に実装する要因になる可能性があります。

Hadoopには広範なエコシステムがあり、Hadoopクラスター自体は他のソフトウェアのビルディングブロックとして頻繁に使用されます。 他の多くの処理フレームワークとエンジンには、HDFSとYARNリソースマネージャーを利用するためのHadoop統合があります。

Apache HadoopとそのMapReduce処理エンジンは、十分にテストされたバッチ処理モデルを提供します。これは、時間が重要な要素ではない非常に大きなデータセットの処理に最適です。 適切に機能するHadoopクラスターに必要なコンポーネントの低コストにより、この処理は多くのユースケースで安価で効果的になります。 他のフレームワークおよびエンジンとの互換性と統合により、Hadoopは多くの場合、多様なテクノロジーを使用する複数の処理ワークロードの基盤として機能します。

ストームストリーム処理は、*トポロジ*と呼ばれるフレームワークでDAG（Directed Acyclic Graphs）を調整することで機能します。 これらのトポロジは、システムに入力されるデータの各受信部分で実行されるさまざまな変換またはステップを記述します。

トポロジは次のもので構成されます。

Stormの背後にある考え方は、上記のコンポーネントを使用して小さな個別の操作を定義し、それらをトポロジに構成することです。 デフォルトでは、Stormは少なくとも1回の処理保証を提供します。つまり、各メッセージが少なくとも1回処理されることを保証できますが、一部の障害シナリオでは重複する可能性があります。 Stormは、メッセージが順番に処理されることを保証しません。

正確に1回のステートフル処理を実現するために、* Trident と呼ばれる抽象化も利用できます。 明確にするために、TridentのないStormは、多くの場合 Core Storm *と呼ばれます。 トライデントは、Stormの処理ダイナミクスを大幅に変更し、レイテンシを増加させ、処理に状態を追加し、アイテムごとの純粋なストリーミングシステムの代わりにマイクロバッチモデルを実装します。

通常、Stormユーザーは、これらのペナルティを回避するために、可能な限りCore Stormを使用することをお勧めします。 これを念頭に置いて、アイテムを1回だけ処理するというTridentの保証は、システムが重複メッセージをインテリジェントに処理できない場合に役立ちます。 トライデントは、1時間以内にリンクをクリックするユーザーの数をカウントする場合など、アイテム間の状態を維持する必要がある場合のStorm内の唯一の選択肢です。 トライデントは、フレームワークの本来の長所に合わない場合でも、Stormに柔軟性を与えます。

トライデントトポロジは以下で構成されます。

Stormはおそらく、ほぼリアルタイムの処理に現在利用可能な最良のソリューションです。 最小限の遅延で処理する必要があるワークロードに対して、非常に低いレイテンシでデータを処理できます。 Stormは、処理時間がユーザーエクスペリエンスに直接影響する場合（たとえば、処理からのフィードバックがWebサイト上の訪問者のページに直接フィードバックされる場合）に適しています。

Storm with Tridentは、純粋なストリーム処理の代わりにマイクロバッチを使用するオプションを提供します。 これにより、ユーザーはツールを意図した用途に合わせて柔軟に調整できますが、他のソリューションに対するソフトウェアの最大の利点のいくつかを無効にする傾向があります。 そうは言っても、ストリーム処理スタイルを選択できることは依然として役立ちます。

Core Stormは、メッセージの順序保証を提供しません。 Core Stormは、少なくとも1回の処理保証を提供します。つまり、各メッセージの処理は保証できますが、重複が発生する可能性があります。 トライデントは、1回限りの保証を提供し、バッチ間の順序付けを提供できますが、内部ではできません。

相互運用性の観点から、StormはHadoopのYARNリソースネゴシエーターと統合できるため、既存のHadoopデプロイメントに簡単に接続できます。 ほとんどの処理フレームワークよりも、Stormは非常に幅広い言語をサポートしており、トポロジを定義するための多くのオプションをユーザーに提供します。

非常に厳しいレイテンシ要件を持つ純粋なストリーム処理ワークロードの場合、Stormはおそらく最も成熟したオプションです。 メッセージ処理を保証し、多数のプログラミング言語で使用できます。 Stormはバッチ処理を行わないため、これらの機能が必要な場合は追加のソフトウェアを使用する必要があります。 1回限りの処理の保証が必要な場合は、トライデントが提供できます。 ただし、その時点で他のストリーム処理フレームワークも適している場合があります。

Samzaは、Kafkaのセマンティクスに依存して、ストリームの処理方法を定義します。 Kafkaは、データを扱うときに次の概念を使用します。

Kafkaは不変ログを表すため、Samzaは不変ストリームを処理します。 これは、変換によって新しいストリームが作成され、初期ストリームに影響を与えることなく他のコンポーネントによって消費されることを意味します。

Samzaは、一見したところ、Kafkaのようなキューイングシステムに依存しているため、制限されているように思われます。 ただし、他のストリーム処理システムでは一般的ではない独自の保証と機能をシステムに提供します。

たとえば、Kafkaはすでに、低レイテンシでアクセスできるデータの複製ストレージを提供しています。 また、個々のデータパーティションに非常に簡単で安価なマルチサブスクライバモデルを提供します。 中間結果を含むすべての出力もKafkaに書き込まれ、ダウンストリームステージで個別に消費できます。

多くの点で、Kafkaへのこの緊密な依存は、MapReduceエンジンが頻繁にHDFSを参照する方法を反映しています。 各計算間でHDFSを参照すると、バッチ処理時の深刻なパフォーマンスの問題が発生しますが、ストリーム処理時の多くの問題が解決します。

SamzaとKafkaの強力な関係により、処理ステップ自体が非常に緩やかに結び付けられます。 事前の調整なしで、任意の数のサブスクライバーを任意のステップの出力に追加できます。 これは、複数のチームが同様のデータにアクセスする必要がある組織にとって非常に役立ちます。 チームはすべて、システムに入力されるデータのトピックにサブスクライブできます。または、何らかの処理を受けた他のチームが作成したトピックに簡単にサブスクライブできます。 これは、データベースなどの負荷に敏感なインフラストラクチャに追加のストレスを加えることなく実行できます。

Kafkaに直接書き込むことで、*背圧*の問題も解消されます。 バックプレッシャーとは、負荷の急上昇により、コンポーネントがリアルタイムで処理できるよりも速い速度でデータが流入し、失速処理やデータ損失が発生する可能性がある場合です。 Kafkaは、非常に長期間データを保持するように設計されています。つまり、コンポーネントは都合の良いときに処理でき、結果なしで再起動できます。

Samzaは、ローカルキー値ストアとして実装されたフォールトトレラントチェックポイントシステムを使用して、状態を保存できます。 これにより、Samzaは少なくとも1回の配信保証を提供できますが、データが複数回配信される可能性があるため、障害が発生した場合に集計状態（カウントなど）を正確に回復できません。

Samzaは、Stormなどのシステムが提供するプリミティブよりも多くの点で簡単に使用できる高レベルの抽象化を提供します。 現時点では、SamzaはJVM言語のみをサポートしています。つまり、Stormと同じ言語の柔軟性はありません。

Apache Samzaは、HadoopとKafkaがすでに利用可能であるか、実装に適しているストリーミングワークロードに適しています。 Samza自体は、複数のチームが処理のさまざまな段階でデータストリームを使用している（ただし、必ずしも緊密に調整されているわけではありません）組織に適しています。 Samzaは、ストリーム処理の多くの部分を大幅に簡素化し、低レイテンシパフォーマンスを提供します。 展開要件が現在のシステムと互換性がない場合、非常に低遅延の処理が必要な場合、または1回だけのセマンティクスが必要な場合は、適切ではない可能性があります。

MapReduceとは異なり、Sparkはメモリ内のすべてのデータを処理し、ストレージレイヤーと対話して最初にデータをメモリにロードし、最後に最終結果を保持します。 すべての中間結果はメモリで管理されます。

メモリ内処理は速度に大きく貢献しますが、Sparkはディスク関連のタスクでも、タスクの完全なセットを事前に分析することで達成できる全体的な最適化により高速です。 これは、実行する必要があるすべての操作、操作対象のデータ、およびそれらの間の関係を表す有向非循環グラフ、または* DAG *を作成することでこれを達成し、プロセッサーにインテリジェントな作業調整機能を提供します。

インメモリバッチ計算を実装するために、Sparkは、Resilient Distributed Datasets（* RDDs *）と呼ばれるモデルを使用してデータを処理します。 これらは、データのコレクションを表すメモリ内に存在する不変の構造です。 RDDの操作により、新しいRDDが生成されます。 各RDDは、親RDDを介して最終的にディスク上のデータまでその系統をトレースできます。 基本的に、RDDはSparkが各操作の後にディスクに書き戻す必要なくフォールトトレランスを維持する方法です。

ストリーム処理機能は、Spark Streamingによって提供されます。 Spark自体は、バッチ指向のワークロードを考慮して設計されています。 エンジンの設計とストリーミングワークロードの特性の不一致に対処するために、Sparkは_micro-batches_ *という概念を実装しています。 この戦略は、データのストリームを、バッチエンジンのネイティブセマンティクスを使用して処理できる一連の非常に小さなバッチとして扱うように設計されています。

Spark Streamingは、1秒未満の増分でストリームをバッファリングすることで機能します。 これらは、バッチ処理用の小さな固定データセットとして送信されます。 実際には、これはかなりうまく機能しますが、実際のストリーム処理フレームワークとは異なるパフォーマンスプロファイルにつながります。

Hadoop MapReduceではなくSparkを使用する明白な理由は、速度です。 Sparkは、メモリ内の計算戦略と高度なDAGスケジューリングにより、同じデータセットを非常に高速に処理できます。

Sparkのもう1つの大きな利点は、その汎用性です。 スタンドアロンクラスターとして展開するか、既存のHadoopクラスターと統合できます。 バッチ処理とストリーム処理の両方を実行できるため、単一のクラスターを操作して複数の処理スタイルを処理できます。

エンジン自体の機能を超えて、Sparkには、機械学習、対話型クエリなどに使用できるライブラリのエコシステムもあります。 Sparkタスクは、MapReduceよりも記述しやすいことがほぼ普遍的に認められており、生産性に大きな影響を与える可能性があります。

ストリーム処理にバッチ方式を適合させるには、データがシステムに入るときにデータをバッファリングする必要があります。 バッファにより、大量の着信データを処理できるため、全体的なスループットが向上しますが、バッファのフラッシュを待機すると、レイテンシが大幅に増加します。 つまり、低レイテンシが不可欠な処理にはSpark Streamingが適切でない可能性があります。

RAMは一般にディスク容量よりも高価なので、Sparkはディスクベースのシステムよりも実行コストが高くなります。 ただし、処理速度の向上により、タスクの完了がはるかに速くなり、リソースに対して1時間ごとに支払う環境で運用する場合のコストが完全に相殺される可能性があります。

Sparkのインメモリ設計のもう1つの結果は、共有クラスターにデプロイされたときにリソース不足が問題になる可能性があることです。 HadoopのMapReduceと比較すると、Sparkはかなり多くのリソースを使用するため、その時点でクラスターを使用しようとしている他のタスクに干渉する可能性があります。 本質的に、Sparkは、Hadoopスタックで動作できる他のコンポーネントよりも、あまり考慮されていない隣人である可能性があります。

Sparkは、さまざまな処理ワークロードを持つユーザーにとって最適なオプションです。 Sparkバッチ処理は信じられないほどの速度の利点を提供し、高いメモリ使用量と引き換えになります。 Spark Streamingは、レイテンシよりもスループットを重視するワークロード向けの優れたストリーム処理ソリューションです。

Flinkのストリーム処理モデルは、受信データをアイテムごとに真のストリームとして処理します。 Flinkは、データストリームAPIを提供して、データの無制限のストリームを処理します。 Flinkが動作する基本コンポーネントは次のとおりです。

ストリーム処理タスクは、問題が発生した場合の回復に使用するために、計算中に設定点でスナップショットを作成します。 状態を保存するために、Flinkはさまざまなレベルの複雑さと永続性に応じて、多くの状態バックエンドで動作できます。

さらに、Flinkのストリーム処理は、「イベント時間」の概念、つまりイベントが実際に発生した時間を理解でき、セッションも処理できます。 これは、いくつかの興味深い方法で順序付けとグループ化を保証できることを意味します。

Flinkのバッチ処理モデルは、多くの点でストリーム処理モデルの単なる拡張です。 連続ストリームから読み取る代わりに、永続ストレージからストリームとして境界のあるデータセットを読み取ります。 Flinkは、これらの両方の処理モデルにまったく同じランタイムを使用します。

Flinkは、バッチワークロードの最適化を提供します。 たとえば、バッチ操作は永続的なストレージによって支えられているため、Flinkはバッチロードからスナップショットを削除します。 データは引き続き回復可能ですが、通常の処理はより速く完了します。

別の最適化では、バッチタスクを分割して、ステージとコンポーネントが必要な場合にのみ関与するようにします。 これは、Flinkがクラスターの他のユーザーとうまく遊ぶのに役立ちます。 タスクのプリエンプティブな分析により、Flinkは一連の操作全体、データセットのサイズ、および後続のステップの要件を確認して最適化することもできます。

Flinkは現在、処理フレームワークの世界でユニークなオプションです。 Sparkはバッチ処理とストリーム処理を実行しますが、マイクロバッチアーキテクチャのため、ストリーミングは多くのユースケースに適していません。 Flinkのストリームファーストアプローチは、低レイテンシ、高スループット、およびエントリごとの実際の処理を提供します。

Flinkはそれ自体で多くのものを管理します。 やや型破りで、パフォーマンス上の理由でネイティブのJavaガベージコレクションメカニズムに依存するのではなく、独自のメモリを管理します。 Sparkとは異なり、Flinkは、処理するデータの特性が変更されたときに、手動で最適化および調整する必要はありません。 データのパーティション化とキャッシュも自動的に処理します。

Flinkは作業を分析し、さまざまな方法でタスクを最適化します。 この分析の一部は、SQLクエリプランナーがリレーションシップデータベース内で行うことに似ており、特定のタスクを実装する最も効果的な方法をマッピングします。 ブロックタスクのためにデータをまとめながら、並行して完了することができるステージを並列化することができます。 反復タスクの場合、Flinkはパフォーマンス上の理由でデータが保存されているノードで計算を試みます。 また、「デルタ反復」、つまり変更があったデータ部分のみの反復を行うこともできます。

ユーザーツールの面では、FlinkはWebベースのスケジューリングビューを提供して、タスクを簡単に管理し、システムを表示します。 ユーザーは、送信されたタスクの最適化計画を表示して、クラスターに実際に実装される方法を確認することもできます。 分析タスクについては、FlinkはSQLスタイルのクエリ、グラフ処理、機械学習ライブラリ、およびメモリ内計算を提供します。

Flinkは他のコンポーネントとうまく動作します。 これは、Hadoopスタック内で使用される場合、適切な隣人になるように記述されており、常に必要なリソースのみを使用します。 YARN、HDFS、Kafkaと簡単に統合できます。 Flinkは、互換パッケージを使用して、HadoopやStormなどの他の処理フレームワーク用に記述されたタスクを実行できます。

現時点でのFlinkの最大の欠点の1つは、まだ非常に若いプロジェクトであることです。 野生での大規模な展開は、他の処理フレームワークほど一般的ではなく、Flinkのスケーリングの制限に関する調査はあまり行われていません。 迅速な開発サイクルと互換性パッケージなどの機能により、組織がそれを実験する機会を得るにつれて、より多くのFlink展開が開始される可能性があります。

Flinkは、低レイテンシのストリーム処理と従来のバッチタスクのサポートの両方を提供します。 Flinkは、ストリーム処理の要件が厳しく、いくつかのバッチ指向のタスクを行う組織におそらく最適です。 ネイティブのStormおよびHadoopプログラムとの互換性、およびYARN管理クラスターで実行する機能により、評価が容易になります。 急速な開発により、注目する価値があります。