私はカスケーディングを試してきましたが、ジョブを作成するための従来の map reduce アプローチに勝る利点は見当たりません。
Map Reduce ジョブは私に自由を与えてくれますが、Cascading は多くの障害をもたらしているようです。
シンプルなものをシンプルに、しかし複雑なものにするのに良い仕事をするかもしれません..私はそれらが非常に難しいと思います.
私が欠けているものはありますか？従来のアプローチよりもカスケードの明らかな利点はありますか?
どのシナリオで、従来のアプローチよりもカスケードを選択する必要がありますか? 使って幸せな人いますか？
私がCascadingの作者であることを心に留めておいてください...
私の提案は、Pig または Hive が問題に適している場合、特に Pig を使用することです。
しかし、データのビジネスに携わっていて、洞察を得るためにデータを調べているだけではない場合、カスケーディング アプローチはほとんどの問題に対して生の MapReduce よりもはるかに理にかなっていることがわかります。
未加工の MapReduce に関する最初の障害は、MapReduce で考えることです。MapReduce では些細な問題は単純ですが、問題のドメインにより簡単にマップできるモデル (これをフィルター処理し、解析し、並べ替え、残りを結合するなど) を使用できれば、複雑なアプリケーションの開発がはるかに簡単になります。
次に、Hadoop の通常の作業単位が複数の MapReduce ジョブで構成されていることに気付くでしょう。ジョブを連鎖させることは解決可能な問題ですが、アプリケーション ドメイン レベルのコードに漏れてはならず、隠して透過的にする必要があります。
さらに、マッパーとリデューサーの間で関数を継続的に移動する必要がある場合、リファクタリングと再利用可能なコードの作成が非常に難しくなります。またはマッパーから前のリデューサーへの最適化を取得します。これは、もろさの問題につながります。
カスケードは、できるだけ早く失敗することを信じています。プランナーは、Hadoop クラスターが作業を開始する前に、これらすべてのフィールド名間の依存関係を解決して満たそうとします。これは、すべての問題の 90% 以上が、実行中にジョブが見つかるのを何時間も待たずに見つかることを意味します。
Person や Document などのドメイン オブジェクトを作成することにより、未加工の MapReduce コードでこれを軽減できますが、多くのアプリケーションでは、下流のすべてのフィールドは必要ありません。すべての男性の平均年齢が必要かどうかを検討してください。バイナリの性別と数値の年齢だけが必要な場合、ネットワーク全体で Person 全体を渡すという IO ペナルティを支払いたくありません。
フェイル ファスト セマンティクスとシンクとソースのレイジー バインディングにより、カスケーディング フロー (多くの Hadoop MapReduce ジョブになる) を作成するフレームワークをカスケーディング上に構築することが非常に簡単になります。私が現在関わっているプロジェクトでは、1 回の実行で数百の MapReduce ジョブが発生し、その多くは処理中のデータからのフィードバックに基づいて実行中にオンザフライで作成されます。Cascalogを検索して、複雑なプロセスを簡単に作成するための Clojure ベースのフレームワークの例を確認してください。または、 Nutchよりもはるかにカスタマイズしやすい Web マイニング ツールキットおよびフレームワークの Bixo です。
最後に、Hadoop は単独で使用されることはありません。つまり、データは常に何らかの外部ソースから取得され、処理後に別のソースにプッシュされます。Hadoop に関する汚い秘密は、それが非常に効果的な ETL フレームワークであるということです (そのため、ETL ベンダーがツールを使用して Hadoop にデータをプッシュ/プルすることについて話しているのを聞くのはばかげています)。カスケードは、統合エンドポイントから独立して操作、アプリケーション、および単体テストを作成できるようにすることで、この問題をいくらか緩和します。カスケードは、Membase、Memcached、Aster Data、Elastic Search、HBase、Hypertable、Cassandra などのシステムをロードするために本番環境で使用されます (残念ながら、すべてのアダプターが作成者によってリリースされているわけではありません)。
よろしければ、インターフェースで発生している問題のリストを私に送ってください。私は常に API とドキュメントを改善するためのより良い方法を探しており、ユーザー コミュニティは常に助けてくれます。
私はカスケーディングを数年間使用しています。私はそれが非常に役立つと思います。最終的には、生産性の向上についてです。単純な Java コードと比較して、M/R ジョブの作成と保守をはるかに効率的に行うことができます。いくつかの理由を次に示します。
一緒に構成できるビルド済みのコンポーネントがたくさんありますが、処理ロジックの特定のセクションを直接 Java で記述した方が簡単だと思われる場合は、いつでもそれをラップするカスケード関数を作成できます。これにより、カスケーディングの利点を得ることができますが、非常にカスタムな操作をそのままの Java 関数 (カスケーディング インターフェイスを実装する) として記述することができます。
私は Bixo で Cascading を使用して、大規模なソーシャル ネットワーク用の完全なスパム対策リンク分類パイプラインを作成しました。
カスケード パイプラインの結果、27 の MR ジョブが発生しましたが、プレーンな MR で維持するのは非常に困難でした。以前に MR ジョブを作成したことがありますが、Cascading のようなものを使用すると、Assembler から Java (insert_fav_language_here) に切り替えるように感じます。
Hive または Pig IMHO に対する大きな利点の 1 つは、Cascading が単一の jar であり、それをジョブにバンドルできることです。Pig と Hive はより多くの依存関係 (MySQL など) を持っているか、埋め込みが容易ではありません。
免責事項:個人的には Chris Wensel のことは知っていますが、Cascading は素晴らしい ** だと思います。その複雑さを考えると、これを使用しているバグが 1 つも見つかっていないことは非常に印象的です。
私は Scale Unlimited の Hadoop Boot Camp コースを教えています。また、Bixo で Cascading を多用し、Bixo Labs で Web マイニング アプリを構築しています。そのため、両方のアプローチを高く評価していると思います。
Cascading の最大の利点は、データ処理ワークフローをフィールドの操作の観点から考えることができ、(ほとんどの場合) この世界観をキー/バリュー モデルに転置する方法について心配する必要がなくなることです。 map-reduce 実装の本質的な一部です。
Cascading の最大の課題は、それがデータ処理ワークフローについての別の考え方であり、すべてが意味をなすようになる前に乗り越えなければならない対応する概念的な「こぶ」があることです。さらに、エラー メッセージは lex/yacc からの出力の 1 つを思い起こさせます ("conflict in shift/reduce") :)
-- ケン
Cascading の利点が現れ始めるのは、ソース コードではすべて分離しておく必要がある単純な関数の山がある場合ですが、これらはすべてマッパーまたはリデューサーで構成にまとめることができる場合だと思います。それらを一緒にすると、基本的な map-reduce コードが読みにくくなり、それらを分離すると、プログラムが非常に遅くなります。Cascading のオプティマイザーは、それらを個別に記述しても、それらをまとめることができます。Pig とある程度は Hive もこれを行うことができますが、大規模なプログラムの場合、Cascading には保守性の利点があると思います。
数か月のうちに、Plume は表現力の競争相手になるかもしれませんが、本番環境で作成して実行する実際のプログラムがある場合は、Cascading がおそらく最善の策です。
カスケードを使用すると、Hadoopが提供するプリミティブ型の代わりに、単純なフィールド名とタプルを使用できます。これは、「...さまざまな開発者間で共有できる高度で構成性の高いコードを作成するには、粒度が間違っている傾向があります」（Tom White、Hadoop The Definitive Guide）。カスケードは、これらの問題を解決するために設計されました。Cascading、Hive、Pigなどの一部のアプリケーションは並行して開発されており、同じことを行う場合があることに注意してください。カスケードが気に入らない場合や混乱を招く場合は、他のものを使用したほうがよいでしょうか。
あなたはすでにこれを持っていると確信していますが、ここにユーザーガイドがあります：http：//www.cascading.org/1.1/userguide/pdf/userguide.pdf。これは、典型的なカスケードアプリケーションでのデータフローの適切なウォークスルーを提供します。
Cascading は、Hadoop との間でタップとシンクを提供する Hadoop のラッパーです。
すべてのタスクに対して Mapper と Reducer を記述するのは面倒です。Cascading ジョブを 1 つ作成してみてください。そうすれば、マッパーとリデューサーを作成する必要がなくなります。
また、カスケード タップとスキームも確認します (これは、カスケード処理ジョブにデータを入力する方法です)。
この 2 つ、つまり、アドホックな Hadoop マッパーを Reducer で作成することを回避する機能と、さまざまなデータ ソースを使用する機能により、多くのデータ処理を非常に高速かつ効果的に解決できます。
カスケードは、hadoop の単純なラッパー以上のものです。私は答えを単純にしようとしています。たとえば、カスケーディング jdbc タップを使用して、テラバイト単位のデータを含む巨大な mysql データベースをログ ファイルに移植しました。