最も一般的な7つのHadoopおよびSparkプロジェクト

このような古い公理があります。誰かに完全なサポートと財政的支援を提供して、別の革新的なことを行うと、彼らは他の人がしていることをやることになります。

つまり、Hadoop、Spark、およびStormに対応します。誰もがこれらの新しいビッグデータテクノロジーで何か特別なことをしていると思っていますが、同じパターンに何度も遭遇するのにそれほど時間はかかりません。特定の実装は多少異なる場合がありますが、私の経験に基づいて、ここに7つの最も一般的なプロジェクトがあります。

プロジェクト1:データ統合

これを「エンタープライズデータハブ」または「データレイク」と呼びます。アイデアは、異なるデータソースがあり、それら全体で分析を実行したいということです。このタイプのプロジェクトは、すべてのソースから(リアルタイムまたはバッチとして)フィードを取得し、それらをHadoopにプッシュすることで構成されます。これが「データ主導の企業」になるための第一歩となることもあります。時々あなたは単にきれいなレポートが欲しいです。データレイクは通常、HDFS上のファイルおよびHiveまたはImpalaのテーブルとして具体化されます。大胆で新しい世界があり、その多くがHBaseに表示されます。将来的には、Hiveが遅いため、Phoenixも表示されます。

営業担当者は「既読のスキーマ」のようなことを言うのが好きですが、実際に成功するには、ユースケースがどうなるかをよく理解している必要があります(Hiveスキーマはあなたが行うものとそれほど異なって見えないでしょうエンタープライズデータウェアハウス)。データレイクの本当の理由は、水平方向のスケーラビリティと、TeradataやNetezzaよりもはるかに低いコストです。「分析」のために、多くの人がフロントエンドにTableauとExcelをセットアップしました。「実際のデータサイエンティスト」(悪いPythonを書く数学オタク)を持つより洗練された企業は、フロントエンドとしてZeppelinまたはiPythonノートブックを使用しています。

プロジェクト2:専門的な分析

多くのデータ統合プロジェクトは実際にはここから始まります。ここでは、特別なニーズがあり、1種類の分析を行うシステムに1つのデータセットを取り込みます。これらは、銀行での流動性リスク/モンテカルロシミュレーションなど、非常にドメイン固有である傾向があります。これまで、このような特殊な分析は、データのようにスケールアップできず、限られた機能セットに悩まされることが多かった時代遅れの独自のパッケージに依存していました(ソフトウェアベンダーが機関ほどドメインについて知ることができなかったためです)。それに浸る)。

HadoopとSparkの世界では、これらのシステムはデータ統合システムとほぼ同じように見えますが、多くの場合、HBase、カスタム非SQLコードが多く、データソースが少なくなっています(1つだけではない場合)。ますます、それらはSparkベースです。

プロジェクト3:サービスとしてのHadoop

「特殊な分析」プロジェクト(および皮肉なことに1つまたは2つの「データ統合」プロジェクト)を持つ大規模な組織では、必然的に、いくつかの異なる構成のHadoopクラスターを管理することの「喜び」(つまり、苦痛)を感じ始めます。ベンダー。次に、ノードの半分を半分の時間アイドル状態にするのではなく、「これを統合してリソースをプールする必要があるかもしれません」と言います。彼らはクラウドに行くことができますが、多くの企業は、多くの場合、セキュリティ(内部政治と雇用保護)の理由で、できないか、できないかのどちらかです。これは通常、多くのChefレシピと、現在はDockerコンテナパッケージを意味します。

私はまだ使用していませんが、Blue Dataは、ここですぐに使用できるソリューションに最も近いもののようです。これは、Hadoopをサービスとしてデプロイするための手段がない小規模な組織にもアピールします。

プロジェクト4:ストリーミング分析

多くの人がこれを「ストリーミング」と呼びますが、ストリーミング分析はデバイスからのストリーミングとはかなり異なります。多くの場合、ストリーミング分析は、組織がバッチで行ったことのよりリアルタイムなバージョンです。マネーロンダリング防止または不正検出を行う:サイクルの終わりではなく、トランザクションベースでそれを実行し、発生したときにそれをキャッチしてみませんか?同じことが在庫管理やその他にも当てはまります。

場合によっては、これは、データを分析システムに並行してシャントするときに、データを少しずつ分析する新しいタイプのトランザクションシステムです。このようなシステムは、通常のデータストアとしてHBaseを使用したSparkまたはStormとして現れます。ストリーミング分析は、すべての形式の分析に取って代わるわけではないことに注意してください。それでも、過去の傾向を明らかにしたり、過去のデータを調べて、考えたことのないものを探したりする必要があります。

プロジェクトNo.5:複合イベント処理

ここでは、サブ秒が重要なリアルタイムのイベント処理について説明します。ハイエンドの取引システムなどの超低遅延(ピコ秒またはナノ秒)アプリケーションにはまだ十分な速度ではありませんが、ミリ秒の応答時間が期待できます。例としては、電話会社の通話データレコードのリアルタイム評価やモノのインターネットイベントの処理などがあります。そのようなシステムがSparkとHBaseを使用しているのを目にすることもありますが、通常はそれらが顔に当たって、LMAX交換によって開発されたDisruptorパターンに基づくStormに変換する必要があります。

これまで、このようなシステムは、カスタマイズされたメッセージングソフトウェア(または高性能の既製のクライアントサーバーメッセージング製品)に基づいていましたが、今日のデータ量はどちらにも多すぎます。これらのレガシーシステムが作成されて以来、取引量と携帯電話を持っている人の数は急増しており、医療および産業用センサーはあまりにも多くのビットを送り出します。まだ使用していませんが、Apexプロジェクトは有望に見え、Stormよりも高速であると主張しています。

プロジェクトNo.6:ETLとしてのストリーミング

ストリーミングデータをキャプチャして、どこかに保管したい場合があります。これらのプロジェクトは通常、No。1またはNo. 2と一致しますが、独自の範囲と特性を追加します。(4番または5番をやっていると思う人もいますが、実際にはディスクにダンプして後でデータを分析しています。)これらはほとんどの場合KafkaおよびStormプロジェクトです。Sparkも使用されますが、メモリ内分析は実際には必要ないため、正当化されません。

プロジェクトNo.7:SASの交換または拡張

SASは問題ありません。SASは素晴らしいです。SASも高価であり、データサイエンティストやアナリスト全員がデータを「試す」ことができるように、ボックスを購入しているわけではありません。さらに、SASが実行できるのとは異なることを実行したり、よりきれいなグラフを生成したりしたいと考えていました。これがあなたの素晴らしいデータレイクです。これがiPythonNotebook(現在)またはZeppelin(後で)です。結果をSASにフィードし、SASからの結果をここに保存します。

他のHadoop、Spark、またはStormプロジェクトを見たことがありますが、これらは「通常の」日常的なタイプです。Hadoopを使用している場合は、おそらくそれらを認識しています。私が何年も前に実装したこれらのシステムのユースケースのいくつかは、他のテクノロジーと連携しています。

ビッグデータの「ビッグ」やHadoopの「実行」をあまりにも恐れているベテランの場合は、そうしないでください。より多くのものが変化すればするほど、それらは同じままです。デプロイに使用したものと、Hadooposphereの周りを渦巻く流行に敏感なテクノロジーとの間には多くの類似点があります。