AZAREAの実行速度のブログにコメントが付いていたので、それに合わせて4種類の集計を行うサンプルを修正したら、ちゃんと動いた！
GroupSortのコーディング方法に問題があった。1レコードずつ処理する別メソッドを使ったら大丈夫になった。
（このメソッドは自動生成されるソースには出てこないので、気付かなかった＾＾； OSSじゃないから、親クラスがどんなコードになっているのか調べることも出来ないしorz）
あと、AZAREAのTipsについても（メールで）指摘された事項があったので、一部を修正した。
（白抜き矢印と黒矢印でポップアップメニューの内容が異なるとは思わなかった＾＾；）
AZAREAもAsakusa Frameworkも「大規模・複雑なアプリケーションの記述」を標榜しているけれども、「大規模」「複雑」ってどういう内容なのか、客観的な指標があるわけでもないので悩ましい。
実際に作られたアプリケーションが見られるといいんだけど、さすがに実業務のソースが公開されるわけも無いからなぁ(苦笑)
AZAREAの実行速度の計測結果を拝見しましたが、少々遅いようなので調査してみました。
フロー中で3箇所GroupSortが使われていますが、可能なものはGroup（＋Conversion）に変えることにより、実行速度が向上すると考えられます。
GroupSortはReducer側のみでグループ化を行うのに対し、GroupはMapper側でも可能な限りグループ化を行います。
従ってMapperからReducerへのデータ転送量が減少し、処理時間が短縮するはずです。
修正サンプルを以下に置きましたので、参考にして頂ければと思います。
https://s3-ap-northeast-1.amazonaws.com/azarea-cluster-jp/public/SalesFlow_2.txt
この辺りのノウハウも開発ガイドに記述するなどしてもう少し分かりやすくしたいと思います。
なお、処理が多くフロー図が煩雑になる場合は、エンティティフロークラスを分割するとシンプルにできます。
（アプリケーション全体のフロー図は相変わらず煩雑ですが、これは改善を検討中です）
「4種類の集計」の例では、集計の種類ごとに4つに分割するのがよいと思います。
エンティティフローはフレームワーク内で合成されるので、最適化結果は同じになります。
修正したところ、30秒ほど速くなり、HiveやCascadingと同程度の時間になりました。
なお、集計の種類毎にフローを分割する方式は、自分のリポジトリーの「azarea2」がそれに相当すると思います。