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

序章

ビッグデータは、大規模なデータセットから洞察を収集、整理、処理、および収集するために必要な非従来型の戦略とテクノロジーの総称です。単一のコンピューターのコンピューティング能力またはストレージを超えるデータを処理する問題は新しいものではありませんが、このタイプのコンピューティングの普及、規模、および価値は、近年大幅に拡大しています。

以前のガイドでは、ビッグデータシステムで使用される一般的な概念、処理段階、および用語のいくつかについて説明しました。この記事では、ビッグデータシステムの最も重要なコンポーネントの1つである処理フレームワークについて説明します。処理フレームワークは、不揮発性ストレージから読み取るか、システムに取り込まれるときに、システム内のデータを計算します。データの計算は、大量の個々のデータポイントから情報と洞察を抽出するプロセスです。

次のフレームワークについて説明します。

バッチのみのフレームワーク：
- Apache Hadoop
ストリームのみのフレームワーク：
- Apache Storm
- Apache Samza
ハイブリッドフレームワーク：
- Apache Spark
- Apache Flink

ビッグデータ処理フレームワークとは何ですか？

処理フレームワークおよび処理エンジンは、データシステム内のデータの計算を担当します。「エンジン」と「フレームワーク」を区別する正式な定義はありませんが、前者をデータの操作を担当する実際のコンポーネントとして定義し、後者を同じように設計されたコンポーネントのセットとして定義すると便利な場合があります。

たとえば、 Apache Hadoop は、MapReduceをデフォルトの処理エンジンとして使用する処理フレームワークと見なすことができます。エンジンとフレームワークは、多くの場合、交換したり、タンデムで使用したりできます。たとえば、別のフレームワークである Apache Spark は、HadoopにフックしてMapReduceを置き換えることができます。コンポーネント間のこの相互運用性は、ビッグデータシステムに大きな柔軟性がある理由の1つです。

データライフサイクルのこの段階を処理するシステムは複雑になる可能性がありますが、広いレベルでの目標は非常に似ています。理解を深め、パターンを表面化し、複雑な相互作用についての洞察を得るために、データを操作します。

これらのコンポーネントの説明を簡単にするために、これらの処理フレームワークを、処理するように設計されたデータの状態ごとにグループ化します。一部のシステムはデータをバッチで処理しますが、他のシステムはデータがシステムに流入するときに連続ストリームでデータを処理します。さらに、これらの方法のいずれかでデータを処理できるものもあります。

さまざまな実装の詳細と結果に飛び込む前に、概念として各タイプの処理を紹介します。

バッチ処理システム

バッチ処理はビッグデータの世界で長い歴史があります。バッチ処理では、大規模な静的データセットを操作し、後で計算が完了したときに結果を返します。

バッチ処理のデータセットは通常…

制限付き：バッチデータセットは、データの有限のコレクションを表します
永続的：データはほとんどの場合、ある種の永続的なストレージによって支えられています
大規模：バッチ操作は、多くの場合、非常に大規模なデータセットを処理するための唯一のオプションです。

バッチ処理は、レコードの完全なセットへのアクセスが必要な計算に最適です。たとえば、合計と平均を計算する場合、データセットは個々のレコードのコレクションとしてではなく、全体的に扱う必要があります。これらの操作では、計算の間、状態を維持する必要があります。

非常に大量のデータを必要とするタスクは、多くの場合、バッチ操作で処理するのが最適です。データセットが永続ストレージから直接処理される場合でも、メモリにロードされる場合でも、バッチシステムは大量を念頭に置いて構築され、それらを処理するためのリソースを備えています。バッチ処理は大量の永続データの処理に優れているため、履歴データで頻繁に使用されます。

大量のデータを処理する場合のトレードオフは、計算時間が長くなることです。このため、処理時間が特に重要な状況では、バッチ処理は適切ではありません。

Apache Hadoop

Apache Hadoopは、バッチ処理のみを提供する処理フレームワークです。 Hadoopは、オープンソースコミュニティで大きな注目を集めた最初のビッグデータフレームワークでした。当時の膨大な量のデータをどのように処理していたかについてのGoogleによるいくつかの論文とプレゼンテーションに基づいて、Hadoopはアルゴリズムとコンポーネントスタックを再実装して、大規模なバッチ処理をより利用しやすくしました。

最新バージョンのHadoopは、いくつかのコンポーネントまたはレイヤーで構成されており、これらが連携してバッチデータを処理します。

HDFS ：HDFSは、クラスターノード全体のストレージとレプリケーションを調整する分散ファイルシステムレイヤーです。 HDFSは、避けられないホスト障害が発生した場合でも、データが引き続き利用可能であることを保証します。これは、データのソースとして、中間処理結果を保存し、最終的な計算結果を保持するために使用されます。
YARN ：Yet Another Resource Negotiatorの略であるYARNは、Hadoopスタックのクラスター調整コンポーネントです。基盤となるリソースの調整と管理、および実行するジョブのスケジューリングを担当します。 YARNは、クラスターリソースへのインターフェイスとして機能することにより、Hadoopクラスター上で以前の反復で可能であったよりもはるかに多様なワークロードを実行することを可能にします。
MapReduce ：MapReduceは、Hadoopのネイティブバッチ処理エンジンです。

バッチ処理モデル

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

HDFSファイルシステムからのデータセットの読み取り
データセットをチャンクに分割し、使用可能なノードに分散します
各ノードの計算をデータのサブセットに適用します（中間結果はHDFSに書き戻されます）
キーごとにグループ化するための中間結果の再配布
個々のノードによって計算された結果を要約および結合することにより、各キーの値を「削減」します
計算された最終結果をHDFSに書き戻します

利点と制限

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

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

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

概要

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

ストリーム処理システム

ストリーム処理システムは、データがシステムに入るときにデータを計算します。これには、バッチパラダイムとは異なる処理モデルが必要です。ストリームプロセッサは、データセット全体に適用する操作を定義する代わりに、システムを通過するときに個々のデータ項目に適用される操作を定義します。

ストリーム処理のデータセットは「無制限」と見なされます。これにはいくつかの重要な意味があります。

total データセットは、これまでにシステムに入ったデータの量としてのみ定義されます。
working データセットはおそらくより関連性が高く、一度に1つのアイテムに制限されます。
処理はイベントベースであり、明示的に停止されるまで「終了」しません。結果はすぐに利用可能であり、新しいデータが到着すると継続的に更新されます。

ストリーム処理システムは、ほぼ無制限の量のデータを処理できますが、一度に1つ（真のストリーム処理）またはごく少数（マイクロバッチ処理）のアイテムしか処理せず、レコード間で最小限の状態が維持されます。ほとんどのシステムは、ある状態を維持する方法を提供しますが、蒸気処理は、副作用がほとんどなく、より多くの機能処理用に高度に最適化されています。

機能操作は、状態または副作用が制限されている個別のステップに焦点を合わせます。同じデータに対して同じ操作を実行すると、他の要因に関係なく同じ出力が生成されます。この種の処理はストリームによく適合します。これは、アイテム間の状態が通常、困難で制限され、場合によっては望ましくない組み合わせであるためです。したがって、ある種の状態管理は通常可能ですが、これらのフレームワークは、それらがない場合ははるかに単純で効率的です。

このタイプの処理は、特定のタイプのワークロードに適しています。ほぼリアルタイムの要件での処理は、ストリーミングモデルによって十分に提供されます。分析、サーバーまたはアプリケーションのエラーロギング、およびその他の時間ベースのメトリックは、これらの領域の変更に対応することがビジネス機能にとって重要になる可能性があるため、自然に適合します。ストリーム処理は、変化や急増に対応する必要があり、時間の経過に伴う傾向に関心があるデータに最適です。

Apache Storm

Apache Stormは、非常に低いレイテンシーに焦点を当てたストリーム処理フレームワークであり、ほぼリアルタイムの処理を必要とするワークロードにおそらく最適なオプションです。非常に大量のデータを処理し、他のソリューションよりも少ないレイテンシで結果を提供できます。

ストリーム処理モデル

ストームストリーム処理は、トポロジと呼ばれるフレームワークでDAG（有向非巡回グラフ）を調整することによって機能します。これらのトポロジは、データがシステムに入るときに各入力データに対して実行されるさまざまな変換またはステップを記述します。

トポロジは次の要素で構成されています。

ストリーム：従来のデータストリーム。これは、システムに継続的に到着する無制限のデータです。
Spouts ：トポロジのエッジにあるデータストリームのソース。これらは、API、キューなどです。操作するデータを生成します。
ボルト：ボルトは、ストリームを消費し、それらに操作を適用し、結果をストリームとして出力する処理ステップを表します。ボルトを各注ぎ口に接続し、次に相互に接続して、必要なすべての処理を調整します。トポロジーの最後で、最終的なボルト出力を接続システムの入力として使用できます。

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

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

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

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

ストリームバッチ：これらは、バッチ処理セマンティクスを提供するためにチャンク化されるストリームデータのマイクロバッチです。
操作：これらはデータに対して実行できるバッチ手順です。

利点と制限

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

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

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

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

概要

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

Apache Samza

Apache Samzaは、ApacheKafkaメッセージングシステムと緊密に連携しているストリーム処理フレームワークです。 Kafkaは多くのストリーム処理システムで使用できますが、Samzaは、Kafkaの独自のアーキテクチャと保証を利用するように特別に設計されています。 Kafkaを使用して、フォールトトレランス、バッファリング、および状態の保存を提供します。

SamzaはリソースネゴシエーションにYARNを使用します。これは、デフォルトでHadoopクラスター（少なくともHDFSとYARN）が必要であることを意味しますが、SamzaがYARNに組み込まれた豊富な機能に依存できることも意味します。

ストリーム処理モデル

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

トピック：Kafkaシステムに入るデータの各ストリームはトピックと呼ばれます。トピックは基本的に、消費者がサブスクライブできる関連情報のストリームです。
Partitions ：トピックをノード間で分散するために、Kafkaは受信メッセージをパーティションに分割します。パーティションの分割はキーに基づいているため、同じキーを持つ各メッセージは同じパーティションに送信されることが保証されます。パーティションは順序付けを保証しています。
ブローカー：Kafkaクラスターを構成する個々のノードはブローカーと呼ばれます。
プロデューサー：Kafkaトピックに書き込むコンポーネントはすべてプロデューサーと呼ばれます。プロデューサーは、トピックを分割するために使用されるキーを提供します。
コンシューマー：コンシューマーは、Kafkaトピックから読み取るコンポーネントです。消費者は、障害が発生した場合にどのレコードが処理されたかを認識できるように、自分のオフセットに関する情報を維持する責任があります。

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

利点と制限

一見、カフカのようなキューイングシステムへのサムザの依存は制限されているように見えるかもしれません。ただし、他のストリーム処理システムでは一般的ではない独自の保証と機能をシステムに提供します。

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

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

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

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

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

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

概要

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

ハイブリッド処理システム：バッチおよびストリームプロセッサ

一部の処理フレームワークは、バッチワークロードとストリームワークロードの両方を処理できます。これらのフレームワークは、同じまたは関連するコンポーネントとAPIを両方のタイプのデータに使用できるようにすることで、さまざまな処理要件を簡素化します。

ご覧のとおり、これを実現する方法は、これから説明する2つのフレームワークであるSparkとFlinkの間で大幅に異なります。これは主に、2つの処理パラダイムがどのようにまとめられ、固定データセットと非固定データセットの関係についてどのような仮定が行われるかによって決まります。

1つの処理タイプに焦点を当てたプロジェクトは特定のユースケースにぴったりかもしれませんが、ハイブリッドフレームワークはデータ処理の一般的なソリューションを提供しようとします。これらは、データを処理するためのメソッドを提供するだけでなく、グラフ分析、機械学習、インタラクティブクエリなどを実行するための独自の統合、ライブラリ、およびツールを備えています。

Apache Spark

Apache Sparkは、ストリーム処理機能を備えた次世代のバッチ処理フレームワークです。 Sparkは、HadoopのMapReduceエンジンと同じ原則の多くを使用して構築されており、完全なメモリ内計算と処理の最適化を提供することにより、主にバッチ処理のワークロードを高速化することに重点を置いています。

Sparkは、スタンドアロンクラスターとしてデプロイすることも（対応するストレージレイヤーとペアになっている場合）、MapReduceエンジンの代わりにHadoopにフックすることもできます。

バッチ処理モデル

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

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

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

ストリーム処理モデル

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

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

利点と制限

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

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

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

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

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

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

概要

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

Apache Flink

Apache Flinkは、バッチタスクも処理できるストリーム処理フレームワークです。バッチは単に境界が有限のデータストリームであると見なされるため、バッチ処理はストリーム処理のサブセットとして扱われます。すべての処理に対するこのストリームファーストのアプローチには、いくつかの興味深い副作用があります。

このストリームファーストのアプローチは、カッパアーキテクチャと呼ばれています。これは、より広く知られているラムダアーキテクチャ（バッチ処理が主要な処理方法として使用され、ストリームを使用して初期の未精製の結果を補足および提供する）とは対照的です。ストリームがすべてに使用されるカッパアーキテクチャは、モデルを単純化し、ストリーム処理エンジンがより高度になるにつれて、ごく最近になってようやく可能になりました。

ストリーム処理モデル

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

Streams は、システムを流れる不変の無制限のデータセットです。
Operators は、データストリームを操作して、他のストリームを生成する関数です。
Sources は、システムに入るストリームのエントリポイントです。
シンクは、ストリームがFlinkシステムから流出する場所です。それらは、データベースまたは別のシステムへのコネクタを表す場合があります

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

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

バッチ処理モデル

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

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

もう1つの最適化には、バッチタスクを分割して、ステージとコンポーネントが必要な場合にのみ関与するようにすることが含まれます。これにより、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は、従来のバッチタスクをサポートする低遅延ストリーム処理の両方を提供します。 Flinkは、大量のストリーム処理要件といくつかのバッチ指向のタスクがある組織におそらく最適です。ネイティブのStormおよびHadoopプログラムとの互換性、およびYARNで管理されたクラスターで実行できる機能により、評価が容易になります。その急速な発展により、注目する価値があります。

結論

ビッグデータシステム内で処理するためのオプションはたくさんあります。

時間に敏感ではないバッチのみのワークロードの場合、Hadoopは、他のいくつかのソリューションよりも実装に費用がかからない可能性が高い適切な選択です。

ストリームのみのワークロードの場合、Stormは幅広い言語をサポートし、非常に低遅延の処理を提供できますが、重複を提供でき、デフォルト構成での順序付けを保証できません。 Samzaは、YARNおよびKafkaと緊密に統合して、柔軟性、簡単なマルチチームの使用、および簡単なレプリケーションと状態管理を提供します。

混合ワークロードの場合、Sparkはストリーミング用の高速バッチ処理とマイクロバッチ処理を提供します。幅広いサポート、統合されたライブラリとツール、および柔軟な統合があります。 Flinkは、バッチ処理をサポートする真のストリーム処理を提供します。高度に最適化されており、他のプラットフォーム用に作成されたタスクを実行でき、低遅延の処理を提供しますが、まだ採用の初期段階にあります。

状況に最適なのは、処理するデータの状態、要件の期限、および関心のある結果の種類に大きく依存します。オールインワンソリューションの実装と厳密に焦点を絞ったプロジェクトでの作業の間にはトレードオフがあり、成熟した十分にテストされた対応物に対して新しく革新的なソリューションを評価する場合にも同様の考慮事項があります。