ビッグデータ ツールのリストでこの画像を見ると、この分野の可能なニッチはすべて既に占有されているように見えるかもしれません。 これだけ競争が激しいと、画期的な技術を生み出すのは非常に難しいはずです。
Apache Flink の作成者はこれに対して異なる考えを持っています。 それは、Stratosphereという研究プロジェクトとして始まりました。 Stratosphereはフォークされ、このフォークがApache Flinkとして知られるようになったのです。 2014年にはApache Incubatorプロジェクトとして受け入れられ、そのわずか数カ月後にはApacheのトップレベルプロジェクトとなりました。 この記事を書いている時点で、このプロジェクトのコミット数は約 12,000 で、貢献者は 300 人を超えています。
なぜこれほどまでに注目されているのでしょうか。 それは、Apache Flink が新世代のビッグ データ処理フレームワークと呼ばれ、Apache Spark を置き換えて、バッチおよびストリーム処理の新しいデファクト ツールになるのに十分な革新的技術を備えていたからです。 しばらくは Apache Spark にこだわるべきでしょうか。 それとも、Apache Flink は新しいギミックに過ぎないのでしょうか。 この記事では、これらおよびその他の質問に対する回答を提供します。
過去数年間、岩の下で生活していない限り、Apache Spark について聞いたことがあるでしょう。 長い間、Spark はこの分野では最新かつ最高のツールでした。
- 印象的なスピード：データがディスク上で処理される場合はHadoopの10倍、メモリ上で処理される場合は最大100倍速くなります。 MapReduceフレームワークを用いてデータ処理ジョブを定義する代わりに、Sparkは複雑なデータ処理アルゴリズムを実装できるタスクのグラフを定義することができる。 Internet of Thingsのような新しい技術の出現により、単に膨大な量のデータを処理するだけでは十分ではなくなりました。 今、私たちは膨大な量のデータがリアルタイムに届くように処理する必要があります。 このため、Apache Spark は、潜在的に無限のデータのストリームを処理できるストリーム処理を導入しました。 Apache Spark は、そのコア機能に加えて、機械学習、グラフ処理、および SQL クエリの実行のための強力なライブラリを提供します。
ApacheSparkでのアプリケーションの書き方を知るために、テキスト文書でそれぞれの単語が何回使われたかをカウントする簡単な単語カウント アプリケーションを実装する方法を見ていきましょう。 まず、file/pathにあるファイルから行のリストを読み取ります。 このファイルはローカル ファイルでも HDFS や S3 にあるファイルでも構いません。
次に、スペース記号で文字列を単純に分割する flatMap メソッドを使用して、すべての行が単語のリストに分割されます。
最後のステップでは、同じ単語に関するすべてのペアの数字を合計することにより、各単語が何回使用されたかを単純にカウントします。 しかし、Apache Flink は何をもたらすのでしょうか。
一見したところ、多くの違いはないように見えます。 アーキテクチャ図は非常に似ています。
Apache Flink 用の単語数アプリケーションのコード例を見てみると、ほとんど違いがないことがわかります：
val file = env.readTextFile("file/path")val counts = file .flatMap(line => line.split(" ")) .map(word => (word, 1)) .groupBy(0) .sum(1)いくつか顕著な違いは、この場合、textFile メソッドの代わりに readTextFile メソッドを使う必要があること、メソッドのペアを使う必要があることです。 reduceByKey.
の代わりに groupBy と sum のペアを使用する必要があることです。
では、この騒動は何なのでしょうか。 Apache Flink は外見上、目に見える違いはないかもしれませんが、次世代のデータ処理ツールになるための十分な革新的技術を持っていることは間違いありません。 以下はその一部です。
- 実際のストリーミング処理を実装しています。 Apache Spark でストリームを処理する場合、多くの小さなバッチ問題として扱われるため、ストリーム処理は特殊なケースとなります。 これに対して、Apache Flink はバッチ処理を特別扱いし、マイクロバッチを使用しません。
- 周期的および反復的処理のサポートが強化されました。 Flink は、ストリーミング アプリケーションでサイクルを実装し、バッチ データでいくつかの反復処理を実行する必要があるアルゴリズムを可能にするいくつかの追加操作を提供します。 Apache Flink は Java アプリケーションですが、JVM ガーベッジコレクタに完全に依存するわけではありません。 それは、バイト配列で処理するデータを格納するカスタムメモリ・マネージャを実装しています。 これにより、ガベージコレクタの負荷を軽減し、パフォーマンスを向上させることができます。 このブログの記事で読むことができます。
- 低レイテンシーと高スループット。 サードパーティによる複数のテストによると、Apache Flink は競合製品よりもレイテンシーが低く、スループットが高いことが示唆されています。 データのストリームを処理する必要がある場合、ほとんどの場合、ストリーム内の要素の有限のグループに関数を適用する必要があります。 例えば、アプリケーションが5分間隔で何回クリックされたかを数える必要があったり、Twitterで10分間隔で最も人気のあるツイートが何であったかを知りたい場合があります。 Spark はこれらのユースケースのいくつかをサポートしていますが、Apache Flink はストリーム処理に対してより強力な演算子のセットを提供します。 これにより、Apache Flink は、Spark のようなマイクロバッチを使用せずに、ストリーム処理において低いオーバーヘッドと一度だけの処理の保証を提供することができます。 ypi は何を使うべきでしょうか。 Spark ですか？ Flink?
もちろん、ここに正しい答えや間違った答えはありません。 もし複雑なストリーム処理をする必要があるなら、Apache Flinkを使うことをお勧めします。 最先端のストリーム処理機能を必要とせず、安全側にいたいのであれば、Apache Spark にこだわる方がよいかもしれません。 これはより成熟したプロジェクトであり、より大きなユーザー ベース、より多くのトレーニング資料、およびより多くのサード パーティ ライブラリを持っています。 しかし、Apache Flinkはこの差を刻一刻と縮めていることを覚えておいてほしい。 より成熟したプロジェクトになるにつれて、より多くのプロジェクトが Apache Flink を選択しています。
その一方で、最新のテクノロジーを使って実験するのが好きな場合は、Apache Flink を試してみる必要があるのは間違いありません。 その答えは、あなたを驚かせるかもしれません。 Flink には印象的な機能がありますが、Spark は同じままでいるわけではありません。 例えば、Apache Sparkは2015年にプロジェクトTungstenのリリースでカスタムメモリ管理を導入し、それ以来、Apache Flinkが最初に導入した機能を追加し続けています。 勝者はまだ決まっていません。
今後のブログ記事では、Apache Flinkをバッチ処理やストリーム処理にどのように使用できるのかについて詳しく書きますので、お楽しみに！
ApacheFlinkについてもっと知りたい場合は、Apache Flinkについて詳しく説明している私のPluralsightコースを見てみてください。 このコースの短いプレビューはこちらです。