ストームまたはスパーク:リアルタイムの武器を選択してください

リアルタイムのビジネスインテリジェンスのアイデアはしばらく前からありました(2006年に始まったトピックに関するウィキペディアのページを参照してください)。しかし、人々がこのアイデアについて何年も話している間、私は多くの企業が実際にビジョンを採用しているのを見たことがなく、ましてやそれがもたらすメリットを認識していません。

その理由の少なくとも一部は、BIと分析をリアルタイムで実装するためのツールが不足していることです。従来のデータウェアハウス環境は、非常に待ち時間の長いバッチ操作、非常に高価なもの、またはその両方を重視していました。

これを変えるために、強力で使いやすいオープンソースプラットフォームが数多く登場しています。最も注目すべきものの2つは、ApacheStormとApacheSparkです。これらは、はるかに幅広い潜在的なユーザーにリアルタイム処理機能を提供します。どちらもApacheSoftware Foundation内のプロジェクトであり、2つのツールは重複する機能を提供しますが、それぞれに特有の機能と役割があります。

ストーム:リアルタイム処理のHadoop

イベントストリーム処理の分散計算フレームワークであるStormは、2011年にTwitterに買収されたマーケティングインテリジェンス企業であるBackTypeのプロジェクトとして始まりました。Twitterはすぐにプロジェクトをオープンソース化し、GitHubに配置しましたが、Stormは最終的にApacheIncubatorに移行しました。 2014年9月にApacheのトップレベルプロジェクトになりました。

Stormは、リアルタイム処理のHadoopと呼ばれることもあります。Stormのドキュメントは、「Stormを使用すると、無制限のデータストリームを簡単に確実に処理でき、Hadoopがバッチ処理で行ったのと同じようにリアルタイムで処理できます」と同意しているようです。

この目的を達成するために、Stormは大規模なスケーラビリティを実現するように設計されており、プロセスへの「フェイルファスト、自動再起動」アプローチによるフォールトトレランスをサポートし、すべてのタプルが処理されることを強力に保証します。Stormは、デフォルトでメッセージに対して「少なくとも1回」の保証を設定しますが、「正確に1回」の処理を実装する機能も提供します。

Stormは主にClojureで記述されており、トポロジと呼ばれる有向非巡回グラフ(DAG)として、「スパウト」(入力ストリームを考える)と「ボルト」(処理および出力モジュール)の配線をサポートするように設計されています。 Stormトポロジーはクラスター上で実行され、Stormスケジューラーは、トポロジー構成に基づいて、クラスター周辺のノードに作業を分散します。

トポロジは、HadoopのMapReduceジョブにほぼ類似していると考えることができますが、Stormがリアルタイムのストリームベースの処理に重点を置いている場合、トポロジはデフォルトで永久に実行されるか、手動で終了するまで実行されます。トポロジが開始されると、スパウトはデータをシステムに取り込み、データをボルトに渡します(次に、データを後続のボルトに渡します)。そこで、主要な計算作業が行われます。処理が進むにつれて、1つまたは複数のボルトがデータベースまたはファイルシステムにデータを書き出したり、別の外部システムにメッセージを送信したり、その他の方法で計算結果をユーザーが利用できるようにしたりする場合があります。

Stormエコシステムの強みの1つは、あらゆる種類のソースからデータを受信することに特化した、利用可能な多数の注ぎ口です。高度に専門化されたアプリケーション用にカスタムスパウトを作成する必要があるかもしれませんが、TwitterストリーミングAPIからApache Kafka、JMSブローカー、その間のすべてに至るまで、非常に多種多様なソースの既存のスパウトを見つけることができる可能性があります。

アダプターは、HDFSファイルシステムとの統合を容易にするために存在します。つまり、Stormは必要に応じてHadoopと簡単に相互運用できます。 Stormのもう1つの強みは、多言語プログラミングのサポートです。 Storm自体はClojureに基づいており、JVMで実行されますが、スパウトとボルトは、stdin / stdoutを介してJSONを使用してコンポーネント間で通信するプロトコルを利用する非JVM言語を含め、ほぼすべての言語で記述できます。

つまり、Stormは、分散計算用の非常にスケーラブルで高速なフォールトトレラントなオープンソースシステムであり、特にストリーム処理に重点を置いています。Stormは、イベント処理と漸増計算に優れており、データストリーム全体でローリングメトリックをリアルタイムで計算します。Stormは、汎用分散RPCを有効にするプリミティブも提供し、理論的にはほとんどすべての分散計算ジョブをアセンブルするために使用できますが、その強みは明らかにイベントストリーム処理です。

Spark:すべての人のための分散処理

リアルタイム分散計算に適した別のプロジェクトであるSparkは、カリフォルニア大学バークレー校のAMPLabのプロジェクトとして始まり、Apache Incubatorに参加し、最終的に2014年2月にトップレベルプロジェクトとして卒業しました。Stormと同様に、Sparkはストリームをサポートします。指向の処理ですが、それはより汎用的な分散コンピューティングプラットフォームです。

そのため、SparkはHadoopのMapReduce関数の潜在的な代替と見なすことができますが、Sparkは、リソースのスケジューリングをYARNに依存して、既存のHadoopクラスター上で実行する機能を備えています。 Hadoop YARNに加えて、SparkはMesosの上に階層化してスケジュールを設定したり、組み込みのスケジューラーを使用してスタンドアロンクラスターとして実行したりできます。 SparkをHadoopで使用しない場合でも、クラスターで実行する場合は、何らかのタイプのネットワーク/分散ファイルシステム(NFS、AFSなど)が必要であるため、各ノードは基になるデータにアクセスできます。

SparkはScalaで記述されており、Stormと同様に多言語プログラミングをサポートしていますが、SparkはScala、Java、およびPythonに対してのみ特定のAPIサポートを提供します。Sparkには「スパウト」の特定の抽象化はありませんが、HDFSファイル、Cassandra、HBase、S3などのさまざまなソースに保存されているデータを処理するためのアダプターが含まれています。

Sparkが優れているのは、複数の処理パラダイムとサポートライブラリのサポートです。はい、Sparkはストリーミングモデルをサポートしていますが、このサポートは、SQLアクセス、グラフ操作、機械学習、およびストリーム処理用の専用モジュールを含む、いくつかのSparkモジュールの1つによってのみ提供されます。

Sparkは、ScalaまたはPython APIを使用して、リアルタイムで迅速かつダーティなプロトタイピングと探索的データ分析を可能にする非常に便利なインタラクティブシェルも提供します。インタラクティブシェルで作業すると、SparkとStormのもう1つの大きな違いにすぐに気付きます。Sparkには「機能的な」フレーバーがあり、APIの操作は、連続するメソッド呼び出しをチェーンしてプリミティブ操作を呼び出すことによって促進されます。ストームモデル。クラスの作成とインターフェイスの実装によって駆動される傾向があります。どちらのアプローチも良くも悪くもありませんが、あなたが好むスタイルは、どちらのシステムがあなたのニーズにより適しているかについてのあなたの決定に影響を与えるかもしれません。

Stormと同様に、Sparkは大規模なスケーラビリティを実現するように設計されており、Sparkチームは、数千のノードを持つ本番クラスターを実行しているシステムのユーザーを文書化しています。さらに、Sparkは最近の2014 Daytona GraySortコンテストで優勝し、100TBのデータの並べ替えで構成される負担のかかるワークロードに最適な時期を迎えました。Sparkチームは、数ペタバイトの範囲の本番ワークロードでのSparkETL操作も文書化します。

Sparkは、高速でスケーラブルで柔軟なオープンソースの分散コンピューティングプラットフォームであり、HadoopおよびMesosと互換性があり、ストリーミング、グラフ中心の操作、SQLアクセス、分散機械学習など、いくつかの計算モデルをサポートします。Sparkは非常に優れた拡張性を備えていることが文書化されており、Stormと同様に、リアルタイムの分析およびビジネスインテリジェンスシステムを構築するための優れたプラットフォームです。

あなたの決定をする

StormとSparkのどちらを選択しますか?

要件が主にストリーム処理とCEPスタイルの処理に焦点を当てており、プロジェクト専用のクラスターを使用してグリーンフィールドプロジェクトを開始する場合、特に統合要件に一致する既存のStormスパウトが利用可能な場合は、Stormをお勧めします。 。これは決して厳格なルールではありませんが、そのような要因は少なくともStormから始めることを示唆しています。

一方、既存のHadoopまたはMesosクラスターを活用している場合、および/または処理のニーズにグラフ処理、SQLアクセス、またはバッチ処理の実質的な要件が含まれている場合は、最初にSparkを確認することをお勧めします。

考慮すべきもう1つの要素は、2つのシステムの多言語サポートです。たとえば、RまたはSparkでネイティブにサポートされていない他の言語で記述されたコードを活用する必要がある場合、Stormには幅広い言語サポートの利点があります。同様に、API呼び出しを使用したデータ探索用のインタラクティブシェルが必要な場合、SparkはStormにはない機能を提供します。

最終的には、最終的な決定を下す前に、両方のプラットフォームの詳細な分析を実行することをお勧めします。両方のプラットフォームを使用して小さな概念実証を構築することをお勧めします。次に、どちらかに完全にコミットする前に、予想されるワークロードを可能な限り忠実に反映するワークロードで独自のベンチマークを実行します。

もちろん、どちらかまたは両方を決定する必要はありません。ワークロード、インフラストラクチャ、および要件によっては、理想的なソリューションがStormとSparkの組み合わせであり、Kafka、Hadoop、Flumeなどの他のツールと一緒になっている場合があります。そこにオープンソースの美しさがあります。

どちらのルートを選択しても、これらのツールは、リアルタイムBIゲームが変更されたことを示しています。かつてはエリートにしか利用できなかった強力なオプションが、今ではすべてではないにしてもほとんどの中規模から大規模の組織の手の届くところにあります。それらを利用してください。