報告 (2006/9/6) 高橋 慧
卒論 マイグレーションを支援する 分散集合オブジェクト 分散配列のような、インデックスで識別されるオブジェクトが書ける インデックス範囲を指定してメソッド呼び出し 動的に配分変更
フィンランドでしたこと 3Dプログラミング Neural Networkで制御 Eye Tracker (英語のプレゼン練習・作文練習)
今からすること グリッドスケジュラー (Scientific Workflow) 特徴 粒度の細かい逐次のジョブを並列に実行 必要なファイルを前もって転送 特徴 ジョブの依存性を解釈 大量のデータに対応 (Data Intensive) 賢いscheduling 設定簡単・その他使いやすくする工夫 Easy-Going Grid Scheduler : EGGS
対象とするタスク (Workflow) 依存性がある 多数の入力ファイル 条件判定・ループ (?) 中間出力 入力ファイル (たくさん) プロセス P プロセス Q 頻度集計 解析 Parser 構文木 Webページ
記述のイメージ データを基準に依存性を書く << pages[i] parser pages[i] parsed_words[i] >> parsed_words[i] << parsed_words[i] analyzer parsed_words[i] freq_result[i] >> result[i] parsed words[] pages[] (たくさん) freq_analysis parser analyzer
実行のイメージ システムが自動的に逐次のタスクを分配 Work Stealingより賢い戦略 実行前にファイルを別スレッドで転送 pages[] pages[] pages[] pages[] pages[] pages[] parsed words[] parsed words[] parsed words[] parsed words[] ソースのページを転送 各ホストでパージング 裏でファイル転送 処理中のタスクが終了すると、 すぐに次のタスクへ取りかかれる パイプライン的に 処理が進行
Data Intensiveな条件に対応 中間ファイル 各ノードのローカルディスクに保存 必要に応じて転送 不要になったら削除
賢いscheduling パイプライン的に、コマンド実行前に必要なファイルを転送 各ノードの負荷を考慮 ファイル転送時にはバンド幅を考慮 ファイルサイズから実行時間の予測 ファイル転送時にはバンド幅を考慮
使いやすくする工夫 GXPの真似 処理の途中経過を表示 Scpを用いた自己コピー 対話的なノード選択インターフェース 中間ファイルを簡単に(クラスタのローカルディスクから)取り出せる 処理の途中経過を表示 例えば10000ページ/1時間の分析なら、100ページ分析した中間結果を1分後に表示 失敗に早く気づける…?
関連研究 Dmake Map-Reduce Condor + DAGman GSFL系 Triana JOpera
Dmake – distributed make Sunが開発 ホスト名・起動する最大プロセス数を指定 Rshを利用して遠隔操作・デーモン不要 気軽に使える Data Intencive向けではない
Map-Reduce + GFS (Google) 複雑な処理を記述する自由度は低い 特定アプリでの性能は高いが、専用の記法
GSFL系 Grid Service Flow Language 並列処理を記述する言語 Globus/OGSAベース 性能はスケジュラーの実装に依存 Globus/OGSAベース スケジュラーの実装は色々 NAREGI projectのGrid Workflow 導入の手間が大きい
何が新しい? 既にあったもの 新しい、かもしれないもの ファイルの局所性を利用 パイプライン的転送 ファイルを処理した時の情報を利用して、動的再スケジューリング 時間制限付きで動的に資源を解放
進捗 今までしたこと これからすること Pythonの練習 Dumbな並列スケジュラーを書く タスク分配→パイプライン処理 コマンドをサーバーに投げて実行させる ファイルを投げる/受ける 依存性解析・DAG作って直列化 これからすること Dumbな並列スケジュラーを書く タスク分配→パイプライン処理 ジョブ記述の記法を考える サンプルアプリを考える