2

スライド36と37のこのプレゼンテーションで、Cascalogの作成者は、次のような名前と年齢のデータセットが与えられた場合、平均年齢よりも大きいすべての結果を返すクエリは300行のPIGであると主張します。

これは有効なアサーションですか？本当に何行のPIGですか？

それとも、彼が説明している問題は、私が説明した問題よりも大きいのでしょうか。

（免責事項-私はネイサンの作品、ClojureとCascalogの大ファンです-私はいくつかの事実をまっすぐにしようとしています）。

4

4 に答える 4

5

あなたは彼がこのプレゼンテーションで言っていることを誤解しました。彼が意味するのは、PIGでの「平均」の実装はJavaコードで300行であるのに対し、マクロ述語機能によって実装された5行のcascalogです。彼は作曲の力を強調したいと思っています。

PD：英語が下手でごめんなさい、私は学んでいます;-)

于 2013-01-26T12:10:48.777 に答える
2

PIGでは300行のコードになるとは思いません。PIGにはすでにフィルター構造とAVG評価機能があります。PIGのコードは次のようになります。

A = LOAD 'student.txt' AS (name:chararray, age:int);
B = FILTER A BY age > AVG(A.age);

注：マシンにPIGが設定されていないため、このコードは試していません。

于 2013-01-26T07:32:15.747 に答える
1

通常のSQLでは簡単です-selectcount（*）from TableName where age>（select avg age from TableName）
ただし、基盤となるエンジンが最新のselectが独立したサブクエリであることを検出できる必要があります（そうでない場合は永久に機能します）。
それを2つの演算子に分割するのは簡単なはずです-1つは平均年齢を選択し、2つ目はそれらをその上に数えます。

于 2013-01-26T07:28:16.077 に答える
0

PIGにすでに実装されている集約操作を選択すると、メッセージが混乱する可能性があります。

@ marivas11が指摘したように、これらのスライドの1つのテーマは、述語の構成可能性が、他のHadoop抽象化で人気のあるユーザー定義関数（UDF）のアプローチの強力な代替手段であるということです。

構成可能性の利点は、コードボリュームの相対的な違いをはるかに超えています。

  1. 述語の構成可能性により、Moseley / Marks 2006で定義されている「偶発的な複雑さ」が軽減され、ソフトウェアエンジニアリングのコストにメリットがあります。

  2. 結果として得られる簡潔なコードも、規定された要件に非常に近いものです。これは、Cascalogサブクエリが効果的にテストステートメントになるため、テスト駆動開発（TDD）の実践からほぼ直接得られます。SamRitchieによるCascalog-Midjeのファクトとモックの追加は非常に優れています。

  3. UDFを取り除くことで、複雑なワークフローを開発する必要があるデータチームの非常に厄介な問題が軽減されます。JavaからPigのDMLに、そしてJavaに戻る言語の境界を越えることは、例外処理、通知、およびその他のインストルメンテーションが非常に困難になることを意味します。 -大規模なクラスターでとにかくトラブルシューティングが難しいスケールアプリ...Cascalogでは、すべての拡張機能が同じ言語内にとどまるため（LeiningenビルドスクリプトもClojureにあります）、コンパイラーはワークフローの完全なビューを持ち、 PIGよりも早く問題を推測します。

後者の点は微妙ですが、実際には$$に変換されます。PIGでは、アプリがクラスターで実行されるまで、多くの問題を見つけることはできません。大規模なアプリの場合、コンパイル時または送信前にHadoopクライアントで推測された可能性のあるバグをテストするためにお金を燃やすことを意味します。

于 2013-02-02T04:18:59.823 に答える