Agile Cat — in the cloud

Hadoop モデリング座談会 – Twitter Live 速報 [ #hadoopmodeling ]

Posted in Events, Hadoop, NoSQL by Agile Cat on July 26, 2010

みなさんの Twitter Live を集めてみました ・・・

image

Link :osacaz4 さんの togetter

Link:kazunori_279 さんの UST

 

Hadoop Logo

___space 

① shot6 さん ーーーーーーーー

Hadoop座談会始まった。まずは @shot6 さん。NoSQL な話、本当の使い勝手をベースに。

組み合わせについて、RDB+NoSQL まずはデータ特性を見た上で、ACIDで保護する必要性を見極めること。

 CQRSパターンとかそれっぽい。

HBaseは一貫性重視、Casandraは可用性重視

一貫性保証の実装をアプリごとでやるのはいけてないけど、CAPのどれをとるかとかはアプリで考えたりするので、どういう一貫性でやるかはアプリから指定したりとか。

CQRSパターン (Command Query Responsibility Segregation)。更新系と参照系を明確に分離。

三つとも使ってみる: 更新要求は RDBMS に原本を保存。ビューを Hadoop で作る。結果を NoSQL にマテリアライズ。参照要求は NoSQL 側へ。

書き込みRDB→Hadoop→viewはNoSQLのアーキテクチャ案

アプリケーション側で一貫性を実装するんじゃなくて、アプリケーション側から一貫性を指定できると良いのか

一貫性保証の実装をアプリごとでやるのはいけてないけど、CAPのどれをとるかとかはアプリで考えたりするので、どういう一貫性でやるかはアプリから指定したりとか

データのexport/importとかはデータストアネイティブな形式で取れないと遅くて困ったり。

範囲検索はなるべく使わない

基本的に書き込み頑張れ系の想定か。ちょいめんどくさそう。keyの設計というのはappengineだったらentity groupの設計という感じか。

RDBMS は読み込み重視で、NoSQL は書き込み重視で、それを逆に使うのか…?

RDMSは一貫性、Hadoopは非同期。テータは非正規化,力技View構築(転置Index)

課題 1: 1A. RDBMS→Hadoop (SQL ではナンセンス), 1B. Hadoop→NoSQL , 1C. NoSQLへの直接接続 (物理位置の抽象化)。

課題2: 2A. データ構造のポータビリティ, 2B. フェイルオーバ, 2C. 設定によるバランシング, 2D. 単純・拘束・堅牢なキュー, 2E.ビューの作り方

キューもやっぱ重要。今、そこの部分設計中。来月には実装だ。間に合うのか。。。?

shotさんのおはなしがおわり、

___space

② 佐藤先生 ーーーーーーーーーーーーーー

HadoopはRDBとNoSQLのハブになる

続いて佐藤先生

佐藤先生 話しがうまい。つかみは、OK。みたいな。上野の博物館の話しから… W

プロセス代数のはなしじゃなくなったらしい。自重するとあらかわ先生がお怒りになられるかも。

計算モデルの込み入った話をすると付いて来れない人が出てしまいそうなので、演目を変える → 『分散システムの研究者からみた MapReduce / Hadoop』」 (^^;

上野の科学博物館でのセンサー設置の泥臭い話。NIIオープンの時もおもろかった。

会場いっぱいです。

Googleの10年前の状態から

第一印象: 何が新しいの? 1990’s の並列LISP の MR との違いは並列数: タスク数 > ノード数でのスケジューリング → タスク数 < ノード数。単純化しただけという見方がある。当時の知見を利用可能。

20年前のmapreduce. 当時でもそれほど目新しいものではなかったとか。taskがプロセッサよりかなりおおいケースとかの研究成果はあったりするらしい。

そう!それ凄く重要!タスクの数

意外とLISP知ってる人いるもんだ。MapReduceの所感、1990年前後での並列LISPの話の中で。

USTのひときたのでもうちょっとしたらUST開始されると思いますよ。

どこまでMapReduceするかでアプリケーションの範囲が限定されてくる(フロント、中間、バックエンド)

Hadoop は、大量データの最終処理までやるのに向いてるかは分からない。中間処理にとどめたほうが幸せかも

これ、今お世話になってる教授も同じ事を言ってます。Hadoopの導入の容易さは魅力だとか。

自身がすでに持っているデータに対してHadoopが適合するかを判断した方が良い

あくまでバッチ処理向けのもの、それ以外は考えない方がいい

MR の特性に合ってるものなら分散性を意識しないですむ。Hadoop に向いてないのに、Hadoop を使いたいがためにアプリを作ってしまうことがあるだろうけど、全くお薦めしない。」 .o(全く同意。適材適所で使い分けるべき。

割りきってどう使うか?はまらないところにはめようとするのはダメ。。。癖が強い、バッチ処理強し。適材適所で。きちんと自分のもっているデータを見極めたうえで。目的と手段がアベコベにならんように。

アプリケーションに向けてDSLを作るべき。Hadoop/MapReduceのためにDSLをつくるのは本末転倒なのでは

DSLってふつうアプリごとにつくるもの。対象を限定することによって開発能力を向上させる的な。ただ、hadoopに関していえば、分散システムであることを隠蔽する非機能要件的なDSLがいるかもね。

BOOM(USB) http://boom.cs.berkeley.edu/

1990’s の並列LISP って何を指してたんだろ。

DSL。必要だが、アプリに応じて設計されるべきで、MR/Hadoop に対して DSL を設計すべき出はない。対象を限定することで、簡単にかけることが DSL のポイント。例えば、分散システムの難しい部分の隠蔽 (e.g. BOOM)。

なんじゃこりゃ!Datalogがでてきたぞ RT @did2memo: BOOM(USB) http://bit.ly/bGPlZD
BooM(UCB) DSL for Hadoop プロトコル、投機実行制御記述できる

電力とHadoop

test (#hadoopModeling live at http://ustre.am/hx3O )

MR用のDCは消費電力が均一化できないのでよろしくない。GoogleはGmailとかいろいろ処理をちりばめることで均一化している

BOOM(UCB) バークレイかと思います RT @kibayos: なんじゃこりゃ!Datalogがでてきたぞ RT @did2memo: BOOM(USB) http://bit.ly/bGPlZD

研究のトレンド。DCでは、消費電力の変動が大きいので、Hadoop ラスタと物理的に対応する専用システムはNG。複数の Hadoop クラスタを混合して実行して平準化すべき。Hadoop では、消費電力の予想は困難。DC向けでないと見られている。

Google は多分もうデータセンターに興味がないと思う

Datacenter as a Computing 翻訳が、今月末には、でるはず。

DCの1番の問題は消費電力。だけどMapreduce/Hadoopは平準化できないため消費電力観点だとお勧めできない。消費電力は予測できない。

Google 様はコアな技術は明かさないので、そんな本が出版されたのはもうデータセンターに興味がない証拠 (サードパーティ製に乗り換えてく?)

DC as a Computer。DC 運用のための OS が必要 (e.g. Mesos プロジェクト@UCB)。有休資源を Hadoop などのアプリに割り当てる。1990’s の分散 OS の失敗を繰り返さない程度の仕組みになるだろう。

インタラクティブなデータ解析 (e.g. Hive, Pig)。.o(いわゆるアドホック問合せ)。リアルタイム処理化。ストリーム処理。

DC as a Computer。DC 運用のための OS が必要 (e.g. Mesos プロジェクト@UCB)。有休資源を Hadoop などのアプリに割り当てる。1990’s の分散 OS の失敗を繰り返さない程度の仕組みになるだろう。

MR/Hadoop が行き着く先: 長期的には、所有せずに外部提供のサービスを利用。提供側と利用側のどちらに立つのかメリットとリスクが異なる。データのセキュリティとか。

ユーザーがhadoopをつかったサービスを提供しだすとこわい?ちょっと何言ってるかわからない。個別企業のパワーバランスの問題ということか。似たようなことはクラウドに限らず商売してたら考えると思うけど。

データセキュリティについては。DC 側で読めない形で預けたり、DaaS 間で実データをやり取りしないで所印したりする方法の検討は、DB系の学会でしばしば目にする。

行き着く先:従量課金が予想できる言語=良い言語。正直そこまで考えたこと無かった。

___space

③ あらかわ先生 ーーーーーーーーーー

サービス提供側はユーザ側のデータ見れてしまう危険性がある(<国単位でも>手動権が握れる)

クラウドは従量課金が基本

前半はデータフロー。後半は今の問題意識。

あらかわ先生のhadoop+データフロー話 (#hadoopModeling live at http://ustre.am/hx3O )

hadoopはデータのあるところで計算しますよ、というのが基本なので。それと関連して、レプリケーションしたらその分そこで計算できたりしますよ。あと、中間データもレプリケーションしますよ。それも並列にできますよ。

HDFS と Mapper の関係。データに対してプログラムを送る。ファイルを複製し、ファイルのスプリットという単位で一部のみ処理することで多重度を上げる。データ損失対策 + 次段の処理での利用が可能。

Hadoopは計算ノードとストレージノード分けてやってない。計算プログラム投げつけてやらせる感じ、データにMapper渡す。こういうのが話に入ってないのは、怪しい話だと思った方がいい。。。なんちゃってでやってるのを判別できるね。

多段 MR をシーケンス図で描くと残念なことに ^^;。グラフ (DAG) で描いてはどうか。スケジューリングも簡単で、前段のノードでデータが揃ったら次。」.o(データフロー図みたいなもの。「スケジューリング」??

なるほど、左から右へ見るのか。上から下に見ていて???だったよ…>DAGの図

まとめ: シーケンス図と DAG: どうやってモデリングする? スケジューリングのクリティカルパス分析が必要になる。

ふつうの実装だと段階的詳細化による変更影響の局所化ができるけど、MRのアウトプットを変えるとなるとchain全体に影響するおそれもあるかもしれない。とか。

DAGで、バックトラック可能かどうか気になったりしてます。その場合、別の仕組みも必要になりそうな。

データ工学屋的にはむしろ自然。問合せ最適化とかその辺りにも通じる。適用できるアルゴリズムとか、データ特性とかは違うけれど。知見は活かせると思っている。

耐変更性。影響範囲が後続のどの範囲に影響するか。フロー全体で静的型の共通モデルを強要する → 動的型へ?

変更耐性を考える。DAG Predecessor , Successor。 対処法(モデル)について、フロー全体で共通のモデル(静的型)を共用か、動的か、…

中間データをtupleとして取り扱うようにすればいいんじゃない説も。scalaとか使うならいいかもしれない。結局、ドメインモデルがドメインモデルとして機能しなかったりするので。

部分問合せの共有実行みたいな。半構造 DBMS とかの緩い構造での問合せ処理で、似たような問題を扱ってないかな。

多段MRで、まえのreduceでできることはあとのmapでやるよりパフォーマンスがよい。どうやって最適化するか、変更が入ったときどうするか、というのを考えると思うけど、MRでなくてMR DSL的なものが必要に。

(途中聴いてなかった)「再利用性: 多段 MR の境界。共通化できるフィルタを前段に挿入することで性能向上の可能性。後段への伝播。共通部分を持たない場合に手書き? → 高級言語を用意する。アセンブリ言語のように扱う。

これは、データフローモデルと多段MRとDAGについて、あらかわさんからくわしーく聞かないと。。

併合。エロい。 もはやMRコンパイラつくる前提。

一連の処理の原子化は、論理的に多段スケジューラを用意するか。バッチ処理の部分的併合は可能か。どこを併合化すべきか。

併合化で、入力のフォーマットだけ異なるけど中の処理は同じ場合とか、併合化したい要求があったり。

原始化、そして併合化。畳み込みできたら楽なんだろうけど、どう同じものを判別してどう併合してどう出力させるか…。どうくりゃ幸せにならるんだ???

バッチとかだとall or nothingになってれば再実行ですましたりできるので、結構重要なトピックだと思うけどね。ないと、中途半端なデータで翌日業務開始、を許容することになるかも。

ゴールベースな表現にすれば必要なデータフローの自動抽出や共通化ができるという話と、全域で共有するデータバス・プールがあるとシンプルかつ頑健な計算モデルになる、という二本立て趣旨かな

___space

④ ここからは座談会  ーーーーーーーーー

司会は okachimachiorz さん

image

共通部分の括出しや併合は、プリミティブな命令体系よりも、代数演算系のようにデータ特性・演算特性の論理的な単位があった方が処理戦略の自動最適化をしやすい。関係代数やその拡張で DBMS (!=RDBMS) が語られることが多い理由の一つ。

すごく、ばらばらな、服装です。座談会のみなさん。w

多段についちゃ、あまりやりすぎると一貫性の確保が逆に大変になりそうな気がしている。ストレージとコンピューティングで分けるといった、役割でクラスタ群を分割する程度が限度かもしれない、といってみるテスト。

BASEと比較するならトランザクションと言うよりは特に分散トランザクションを持ってこないと、レイヤーが合わないんじゃないかなぁ。

Hadoopを中心とした分散環境での開発方法論・モデリング・設計手法等について」 見てる
テーマは、クラウドOS, トランザクション (ACID vs BASE から違った次元で語られるようになってた?), プログラミングパラダイム。

べつに一貫性を担保、というわけではない。Reduceの際にうまくやらないと、計算がかち合う可能性があるためだ。まあこれはMRの実装設計の問題ではあるのだが。

登壇者は、左から萩原さん、shot6さん、佐藤先生

image

まだ成果物じゃないからだしていいらしいけど、USTされてるんじゃないか疑惑。

既存業務をDAGに落としてる。スゲェな

タスクツリーの末端で、本当は根元で共通化した方がいい処理がされてる時、実行順序入れ替えとかマージで再編成できる条件てどんなものかなー

座談本番スタート。じゃあどうよ? ・クラウドOS(オペレーティングシステムのような存在)、・クラウド時代におけるトランザクション(CQRSとの関係ってどうよ?など) とかとか

やっぱりレプリケーションしてローカリティ確保して並列分散処理って当たり前の話なのか。論文を探してみよう。1990年前後あたりかな?

OS: 消費電力を少なくするように配分する必要がある。DC 内・DC 間の二つの問題が存在。」「基幹系では、DC もクラウドの一部と考える。複数のクラウド群にまたがる必要がある。

クラウドOS(サーバ向け)は今年になってから。今は省電力(非同期性を確保しつつ)をかなり重視

佐藤先生、クラウドOSはまだまだ研究もこれからだが、リソース配分最適化、スケジューリング、そして電力消費最適化効率化が主な仕事になるのでは?レンジとしてはDC内に閉じたものでなく、DC間も含めて。時間を入れ込んだ計算モデルは力業、頑張って…orz

プログラムパラダイムの変革は難しい問題。しかし1番の問題はNWの通信遅延。

演算を定義するのか、MやR にデータ特性や演算特性を注釈付けして、それに基づいて処理戦略を立てる、というのはできないだろうか、と考えてる。特性だけで、処理内容はプログラムに任せて。可能だろうか。問題が難しくなり過ぎるかしら、と。

議論がハイレベルすぎてよく分からなくなってきた… ( ̄▽ ̄)

開発者としてはなにやったらいいのか難しいところ。あれやこれや新しもの出てるし。

1ラックで 1000コアくらい。いろいろできる。40分が 40秒でできるようになる。もはや戻れない。

クラウド全体で最適になっていけるアーキテクチャ。人間の認知に関わってくる問題もある。例えば、認識では関心に応じてスコープが変わってフィルタがかかる。そういう仕組みが必要では。MR で発散させて収束させるのも類似。

多段MRにDSLが合うかどうかは分からないけど、結局はいい感じのフレームワークがあるかないかに落ち着くような。

現在はユースケースモデリングのように、特定のインスタンスレベルのデータ特性に応じて最適化している。そうでなく、ドメインモデルなど全体像に適した最適化が必要。CSP での最適化も前者。後者に挑戦しているが、単純なモデルを作らねばならない。

ドメインモデルをつかった並列処理の最適化ができるかもね、という。うーん、イメージがわかない。。

認知とかと対応付けて考えるのはどうなんだろう。いまいち違和感を感じてしまう。抽象化し過ぎてみると、なんでも類似して見えてしまいかねない問題。

MSの萩原さん。 CMUでの人間の脳の処理の研究にあるように、コンピュータでの並列処理もそれにならうような感じになっていくのでは。やっぱ「脳」か。分析はシンプルにやっていかないと、複雑にやっても分析結果がわからない。

「ユースケースモデリング的な方法もドメインモデル的な方法も考えなければならないのではないか。」「UML でモデリングするけど同じような考え方をしている。その実現レベルへの落とし方は、また考えなければならないと感じる。」

マルチパラダイムを認識して、マルチに組み合わせて、結局色々とやっていく感じにならざるおえない…

だめだ。DBMS の問合せ処理アーキテクチャで考えてしまう。それ、似たような話がなくない? とか。プログラムモデリング的な考え方より、データモデリング/データ処理システム的な考え方とか。

G社でのホットトピック:DC間連携、データモデル(メタデータ分析)

「Google(?) は、どこに興味を持っているのか」「メタデータ抽出と推論的検索」.o(セマンティックウェブ的な話だね

吉岡さんから質問、Googleで一番ホットな取り組みは?A: 佐藤先生、最近GoogleのVPと別件で会話したときは、DC間連携とメタデータ活用した検索などについて…

Google 様にとって、個々のデータセンターはもはやコモディティ。センター間の連携にとても興味をもってるみたい。

みんなで位相幾何やればいいんじゃね?。「あの計算は同位相だから、同じホモロジー群にまとめて、とっとと境界写像定義しちゃおうよ」みたいな(テキトー)。ワタシはもちろんドロップアウト。

ご苦労様でした。助かりました。

ーーーーー

仕事が忙しくて参加できないはずでしたが、結局は Twitter と UStream にかじりついてしまいました orz —-  最後になりますが、UStream を頑張ってくれた kazunori_279 さん、有難うございました。 みなさん、第二部で、あまり飲みすぎないようにね ーーー A.C.

ーーーーー

<関連>
Cloudera – Hadoop Webinar のお知らせです
Hadoop Summit – Jun 29 2010
Hadoop で スマートグリッドを、図とデータで見る!
Microsoft readying Hadoop for Windows Azure の対訳
Hadoop による Web 広告システムの構築と運用 :ヨーロッパでの事例

Tagged with: , ,
%d bloggers like this: