前書き

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

以前のガイドでは、https://www.digitalocean.com/community/tutorials/an-introduction-to-big-data-concepts-and-terminology [一般的な概念、処理段階、および用語ビッグデータシステム]。 この記事では、ビッグデータシステムの最も重要なコンポーネントの1つである処理フレームワークを見ていきます。 処理フレームワークは、不揮発性ストレージから読み取るか、システムに取り込まれると、システム内のデータを計算します。 データの計算は、大量の個々のデータポイントから情報と洞察を抽出するプロセスです。

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

  • バッチのみのフレームワーク:

  • * link:#apache-hadoop [Apache Hadoop] *

  • ストリーム専用フレームワーク:

  • * link:#apache-storm [Apache Storm] *

  • * link:#apache-samza [Apache Samza] *

  • ハイブリッドフレームワーク:

  • * link:#apache-spark [Apache Spark] *

  • * link:#apache-flink [Apache Flink] *

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

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

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

データライフサイクルのこの段階を処理するシステムは複雑になる可能性がありますが、広いレベルの目標は非常に似ています。

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

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

バッチ処理システム

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

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

  • 制限あり:バッチデータセットはデータの有限コレクションを表します

  • 永続的:データはほとんどの場合、何らかのタイプの永続的なストレージによってバックアップされます

  • 大規模:多くの場合、バッチ操作が非常に大きなデータセットを処理するための唯一のオプションです

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

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

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

Apache Hadoop

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

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

  • * HDFS *:HDFSは、クラスターノード全体でストレージとレプリケーションを調整する分散ファイルシステムレイヤーです。 HDFSは、避けられないホスト障害にもかかわらず、データが引き続き利用可能であることを保証します。 データのソースとして使用され、中間処理結果を保存し、最終的な計算結果を保持します。

  • * YARN *:YARNは、Yet Another Resource Negotiatorの略で、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は、非常に低いレイテンシに焦点を当てたストリーム処理フレームワークであり、ほぼリアルタイムの処理を必要とするワークロードにおそらく最適なオプションです。 非常に大量のデータを処理でき、他のソリューションよりも少ないレイテンシで結果を提供できます。

ストリーム処理モデル

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

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

  • ストリーム:従来のデータストリーム。 これは、システムに継続的に到達する無制限のデータです。

  • スパウト:トポロジの端にあるデータストリームのソース。 これらは、API、キューなどです。 操作対象のデータを生成します。

  • ボルト:ボルトは、ストリームを消費し、それらに操作を適用し、結果をストリームとして出力する処理ステップを表します。 ボルトを各スパウトに接続し、次に相互に接続して必要なすべての処理を調整します。 トポロジの最後に、最終的なボルト出力を接続システムの入力として使用できます。

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回限りの処理の保証が必要な場合は、トライデントが提供できます。 ただし、その時点で他のストリーム処理フレームワークも適している場合があります。

アパッチ・サムザ

Apache Samzaは、Apache Kafkaメッセージングシステムと密接に結び付けられたストリーム処理フレームワークです。 Kafkaは多くのストリーム処理システムで使用できますが、SamzaはKafkaのユニークなアーキテクチャと保証を活用するために特別に設計されています。 Kafkaを使用して、フォールトトレランス、バッファリング、および状態ストレージを提供します。

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

ストリーム処理モデル

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

  • トピック:Kafkaシステムに入るデータの各ストリームはトピックと呼ばれます。 トピックは基本的に、消費者が購読できる関連情報のストリームです。

  • パーティション:ノード間でトピックを配布するために、Kafkaは着信メッセージをパーティションに分割します。 パーティション分割はキーに基づいており、同じキーを持つ各メッセージが同じパーティションに送信されることが保証されます。 パーティションの順序は保証されています。

  • ブローカー:Kafkaクラスターを構成する個々のノードはブローカーと呼ばれます。

  • プロデューサー: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回だけのセマンティクスが必要な場合は、適切ではない可能性があります。

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

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

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

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

Apache Spark

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

Sparkは、(有効なストレージレイヤーと組み合わせて)スタンドアロンクラスターとして展開するか、MapReduceエンジンの代替としてHadoopにフックできます。

バッチ処理モデル

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は、レイテンシよりもスループットを重視するワークロード向けの優れたストリーム処理ソリューションです。

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

このストリームファーストアプローチは、* Kappaアーキテクチャ*と呼ばれます。これは、より広く知られているLambdaアーキテクチャ(初期の洗練されていない結果を補完および提供するために使用されるストリームを含む主要な処理方法としてバッチ処理が使用される)とは対照的です。 すべてにストリームが使用されるKappaアーキテクチャは、モデルを簡素化し、ストリーム処理エンジンがより高度になったため、ごく最近可能になりました。

ストリーム処理モデル

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

  • *ストリーム*は、システムを流れる不変の無制限のデータセットです

  • *演算子*は、データストリームを操作して他のストリームを生成する関数です

  • *ソース*は、システムに入るストリームのエントリポイントです

  • *シンク*は、ストリームが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管理クラスターで実行する機能により、評価が容易になります。 急速な開発により、注目する価値があります。

結論

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

時間に依存しないバッチのみのワークロードの場合、Hadoopは他のいくつかのソリューションよりも実装コストが低い可能性が高い適切な選択です。

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

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

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