Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等についての座談会（第4回）

marble @marblejenka

#hadoopmodeling 結局DiskとCPUが電気を使う。Diskは回転によって消費電力が変わるが、CPUはアイドルでも消費電力が変わらない。このあたりから議論できるかも？

Sadayuki Furuhashi @frsyuki

一つのジョブの個々のタスクを見て動的にやるのは厳しい気がするけど、多数のジョブをぐるんぐるん回し続けるマルチテナントな環境なら、単純に全体のロードを見て動的にノード数を増やしたり減らしたりするのは簡単そうな。 #hadoopModeling

十級呪物disktnk @disktnk

なるほど。理解できそうです。 RT @cocoatomo: #hadoopmodeling もしかして E(X) と E(X^2) を計算するようにバラすのか? どうやらそうらしい.

NAO @nemoton

Hadoop使いも省電力化は免れない。。。「俺たちは、このままでいいのか？」。「電力モデルをきちんと確立できるのか？」。「ディスクのスピンとCPU、に注意する・・・」 #hadoopmodeling

marble @marblejenka

#hadoopmodeling MRの性能問題。Map OutputのIOとShuffleのIOのコスト。まずは前者をMap Multi-Reduceで考えてみる。Combinerより前でCombineすればMap OutputのIOは減る。

Jun Ohtani @johtani

あぁ、行きたかった… #hadoopmodeling

marble @marblejenka

#hadoopmodeling pushdownとは。処理の意味が変わらないようにデータ量を減らす。projectionをなるべく実行の早い段階でやる。

tomo🐧@learning @cocoatomo

#hadoopmodeling pushdown = 事前に絞る

close_yutori @kimukou2628

( #hadoopModeling live at http://ustre.am/hx3O ) Map Multi Reduce ・・ワードカウント、sum等では減る。avg等では減らないケースも

close_yutori @kimukou2628

( #hadoopModeling live at http://ustre.am/hx3O ) pushdown・・DBで使われている技術 select * from A,B selectionをテーブル側(A,B)に持って行く select <= * <= A , B

Hidenori nhide Nakamura @nhide

Hadoopで早くできる処理：合計値、カウント。向かない処理：平均値など、全体を処理しないと結果が出ない処理。 #hadoopmodeling

close_yutori @kimukou2628

( #hadoopModeling live at http://ustre.am/hx3O ) * <=JOIN<= select A ,select B なイメージ。Conbinerを普通自作して作るがそれを自動的にやるという話

marble @marblejenka

#hadoopmodeling Record Reduce。Map OutputをHashに詰めとけばCombiner起動前にCombineできる。Hadoperは割と普通にやるけど、これを自動的にやってくれたりする。

tomo🐧@learning @cocoatomo

#hadoopmodeling local-reduce Mapper-side Join みたいなもの? なんでパフォーマンスが出てこないそうだが, 何故なんだろう? worker が重い?

marble @marblejenka

#hadoopmodeling P Join。OLAP的なものをつくるときの話。クロス分析的なことをやるので、JoinとかAggregatonがおおい。取り扱うデータ量もおおい。

Ransui Iso @ransui

結局のところ、「集める」っていう部分をいかに上手くやってやるかってとこに集約されるわけだ。 #hadoopmodeling

marble @marblejenka

#hadoopmodeling MRだとJoinがおもい。TPC-HというOLAPのベンチマークだと、スタースキーマに売上を地域とか商品とか注文とかの構成でだしてく。ので、結合がいる。

marble @marblejenka

#hadoopmodeling MRだとなんでJoinが重いか。Reduce Side Joinでやるなら、全データをShuffleする必要がある。ので、IOもたくさん。

tomo🐧@learning @cocoatomo

#hadoopmodeling そもそも重たい join が多い OLAP を高速化するには? projection がほとんどと read > write という仮定の下, できるだけ手前でデータ量を減らす.

tomo🐧@learning @cocoatomo

#hadoopmodeling semi-join は filter と同等?

close_yutori @kimukou2628

( #hadoopModeling live at http://ustre.am/hx3O ) ・事前に疑似JOIN（semi-join）が作成される ＝＞検索時に処理数が減らせる ・semi-join：必要なカラムのみJOIN?

marble @marblejenka

#hadoopmodeling で、semi-joinを使ってみる。必要な結合なカラムだけリモートから取ってきて結合していって、結合のキー以外の対象データはヒットしたのだけリモートからとる。

tomo🐧@learning @cocoatomo

#hadoopmodeling natural-join = semi-join -> natural-join

marble @marblejenka

#hadoopmodeling で、semi-joinの結合対象となるデータを結合するkeyでパーティショニングしておく。あらかじめShuffleしているかのような効果が。

Hidenori nhide Nakamura @nhide

中心テーブルに対して検索条件を絞り込むためにJoinするテーブルが取り巻いている場合のMapReduceの最適化。全体をJoinせず、semi-joinすることで、全体のデータ量を抑える。 #hadoopmodeling