JVOプロトタイプ システムの開発 DEWS2004 ２００４年 ３月 ５日 田中 昌宏、白崎 裕治、 本田 敏志、 大石 雅寿、 水本 好彦 (国立天文台)、 安田 直樹 (東大宇宙線研)、 増永 良文 (お茶の水大)、 富士通、 セック DEWS2004　２００４年 ３月 ５日 国立天文台の田中と申します 先ほどの話は天文DBの検索言語についてですが、 この検索言語が実際に動作する 次世代の天文データベースである JVOプロトタイプの開発について発表します。 この開発は、富士通、セックの方々にもご協力いただいています。

序 ― 天文学データベース 天体カタログ 昔： メシエ (1771年)、NGC (1888年)、... 最近： など多数 画像 序　―　天文学データベース 天体カタログ 昔： メシエ (1771年)、NGC (1888年)、... 最近：　 など多数 画像 DSS,　HST,　すばる, ... アーカイブされた天文データの活用は、天文学研究に不可欠 天体カタログ 天体数 データ量 USNO B1.0 10億 80GB GSC 2.2 4.8億 40GB 2MASS 4.7億 43GB まず天文データベースについて簡単に紹介します 天体カタログとしては、よく知られている メシエカタログ、NGCカタログが昔からあり、 最近のカタログとしては このように天体数で１０億や５億という膨大な量になってきています。 他にもカタログは膨大な種類があり、いちいち挙げているときりがありません。 画像データとしては、 デジタルスカイサーベイ、ハッブル望遠鏡、すばる望遠鏡、等の観測データがあり、 これらはアーカイブされ、一般に利用できるようになっており、 こうしたデータを活用することは天文学研究には不可欠になってきています。

国立天文台の データアーカイブ 野辺山宇宙電波観測所アーカイブ SMOKA： すばる・岡山・木曽観測所アーカイブ SMOKA: すばる望遠鏡 野辺山宇宙電波観測所アーカイブ SMOKA： すばる・岡山・木曽観測所アーカイブ ここで国立天文台が提供しているデータアーカイブについて簡単に紹介します。 野辺山の電波望遠鏡のデータを提供するシステムのほかに、 SMOKAという すばる、岡山、木曽観測所で観測したデータを提供するシステムがあります。 左の画面はSMOKAで観測データを検索するインタフェースです。 ここに天球座標や観測時刻や装置を入力すると、観測データの一覧が得られます。 そして右図のようにサンプル画像を表示することができます。 ここまではだれでも検索できるようになっていますが、 実際のデータを取得するには申請が必要です。 SMOKA: http://smoka.nao.ac.jp/

天文データアーカイブ利用の問題 天文研究、特に多波長データを用いた研究には、 観測データは、観測所によって管理される 異なる観測データの組み合わせが必要 観測データは、観測所によって管理される データアーカイブは分散配置される データアーカイブ間での連携が考えられていない 利用者が各自で、データダウンロード、フォーマット変換 →　多波長データなどの解析にとって、大きなハードル このように天文データアーカイブシステムは便利になってきているのですが、 かならずしも十分とは言えません。というのは、 十分な天文学的な成果を挙げるには 単独の観測データだけですむということはなく、 異なる観測データを組み合わせることが必要とされるからです。 しかしアーカイブデータは 観測データは観測所が把握し管理するため、 たいてい観測所ごとに分散配置されます。 そこで問題となるのが、データアーカイブ間での連携は これまではほとんど考えられていない、ということです。 そこで、異なる観測データを組み合わせた研究をおこなうには 自分でデータを取ってきて、フォーマットをそろえなければなりません。 これは必ずしも計算機に習熟していない天文研究者には大きなハードルになります。

バーチャル天文台 Virtual Observatory (VO) 概念 計算機に保存された天文観測データを再観測 いつでも（昼でも雨でも）、どこでも（ネットワークがあれば） 観測が可能 実現するには・・・ 分散データベース連携が鍵 そこで登場したのが、 こういうハードルをなくすことを目指すものが virtual observatory voです。 VOの概念としては、 計算機に保存された天文観測データを再観測するというもので、 いつでも（昼でも雨でも）、どこでも（ネットワークがあれば） 観測が可能なもの、 VOを実現するには、 天文データの分散データベース連携

JVO (Japanese Virtual Observatory) 国立天文台のバーチャル天文台計画 日本の天文観測データアーカイブの連携 国立天文台のすばる、ALMAなどの観測データ JAXA/ISASの天文衛星データ 外国のVOとの連携 IVOA（国際バーチャル天文台連盟）に参加 世界中の天文データの相互利用を目指す 国際規格の１つ（VOQL）のとりまとめ 国立天文台では、 日本のバーチャル天文台として、 Japanese Virtual Observatory JVO　計画を進めています JVOでは、日本の天文観測データアーカイブの連携を目指しています それには、 国立天文台のすばる、ALMAなどの観測データ JAXA/ISASの天文衛星データ を含みます さらにJVOの活動として、外国のVOとの連携があります。 世界中の天文データの相互利用を可能にするため、 IVOA（国際バーチャル天文台連盟）に参加し 国際規格の１つ（VOQL）のとりまとめ をおこなっています。

JVOシステムの開発要素 分散DB連携 クロスマッチ検索 解析サービス ユーザーインタフェース 検索言語、メタデータ検索、遠隔実行、... 天体カタログ間で対応天体を探す 解析サービス 観測データから物理量に変換 ユーザーインタフェース 検索実行支援、結果表示、... バーチャル天文台を実現するためには、さまざまな開発要素があります。 その中で大きなものは、分散DB連携です ここには、検索言語、メタデータ検索、遠隔実行が含まれます。 そのほかに、発表では触れませんが、以下のような開発要素があります。 クロスマッチ検索 天体カタログ間で対応天体を探す 解析サービス 観測データから物理量に変換 ユーザーインタフェース 検索実行支援、結果表示

JVOプロトタイプの目的 我々が定義したJVOQLの機能を確認 本運用システムに向けて、採用した技術の有効性を確認 2002年度（昨年度）　プロトタイプ１の開発 2003年度（本年度）　プロトタイプ２の開発 JVOでは本システム構築の前段階として、プロトタイプの開発をおこなっています。 プロトタイプの主な目的は、 我々が定義したJVOQLの機能を確認すること、 本運用システムに向けて、採用した技術の有効性を確認することです。 昨年度　 今年度　

JVOプロトタイプ構成 実行制御 利用者 JSP 利用技術 開発要素 サーブレット Grid ポータルサーバ 検索 サービス Grid Solaris レジストリサーバ UDDI 　or Grid メタデータ Linux データベースサーバ 検索 サービス RDB 天体カタログ Grid Linux データベースサーバ 検索・解析 サービス RDB 天体カタログ Grid プロトタイプの構成を図示したものです。 プロトタイプはポータルサーバ、 レジストリサーバ、 データおよびサービスサーバからなります。 黄色で示したところが利用技術 ピンクで示したところが開発した部分です。 この図はまた後で説明します。 利用技術 開発要素

遠隔実行制御 実行制御： 遠隔実行： Globus Toolkit JVOQLをパースして、実行スケジュールを生成 レジストリからデータサーバを引き当てる 遠隔実行： Globus Toolkit プロトタイプ１：　ver. 2　(GRAM) プロトタイプ２：　ver. 3　(Grid Service) まず遠隔実行制御について。 JVOシステムは検索言語JVOQLをパースして、 遠隔実行のスケジュールを作成します このときレジストリからデータサーバを引き当てます。 遠隔実行のミドルウェアにはGlobusToolkitを採用しました。 プロトタイプ１ではGlobusToolkit バージョン２、 プロトタイプ２ではバージョン３のグリッドサービスを利用しました。

メタデータ データサーバ・解析サーバの情報 天文データについての情報 実装方法 観測装置、波長、時刻、天域、... プロトタイプ１：　UDDI プロトタイプ２：　XMLDB メタデータについては、 データや解析サービスがどのサーバにあるかという情報 天文データについてのメタデータ、たとえば 観測装置、波長、時刻、天域、といった情報があります。 どうやって検索するか方法 プロトタイプ１：　Webサービスを検索するためのUDDIを流用、 プロトタイプ２：　それを見直してXMLDBを採用しました

分散サーバ間のデータフォーマット VOTable （天体カタログ） FITS （画像など） XML形式のテーブルフォーマット テーブルデータ本体と、カラムの情報を表現 国際的なVOで標準となる見込み FITS （画像など） 画像などのバイナリデータを交換するための、天文学標準のフォーマット 分散サーバ間でやりとりするデータのフォーマットとしては２種類あり、 １つは、VOTable 、これは天体カタログのデータフォーマットですが、 　欧米のVOチームで策定されたXML形式のフォーマットで、 テーブルデータ本体と、カラムが何を意味しているかとか単位などの情報を含むこととができます。 国際的なVOで標準となる見込みとなっています FITS （画像など） 画像などのバイナリデータを交換するための、 古くから天文学標準となっているフォーマット

検索指示の例 select i.ra, i.dec, i.iband, z.ra, z.dec, z.zband from naoj.i.sdf as i naoj.z.sdf as z where XMATCH(i,z) < 10 arcsec NEAREST and BOX(POINT(201, 27.4), 0.1, 0.1) これは前の白崎の発表にありました、検索言語JVOQLで書かれた検索条件の例です。 from phraseでは２つのテーブルを指定しています where phraseには、前の白崎の発表でありましたように、 ２つのテーブルでのクロスマッチ条件と、 領域条件を指定しています。 これをJVOシステムに渡されると、 分散サーバにどうアクセスするか、説明します。

JVOプロトタイプ動作 実行制御 ポータルサーバに JVOQLを送信 ログイン 利用者 実行開始 クロスマッチ 結果 JSP VOTable Grid JSP サーブレット Solaris レジストリサーバ UDDI 　or Grid メタデータ Linux データベースサーバ 検索 サービス RDB 天体カタログ 利用者 JVOQLを送信 実行開始 クロスマッチ 結果 VOTable 利用者に表示 ２つの データベースサーバに 個数検索実行命令 JVOQLをパースして、 データがどのサーバにあるか レジストリに問い合わせ VOTtableと データベースで クロスマッチ検索 ヒット数が少ない方の データベースサーバ から検索実行 検索結果 VOTable クロスマッチ 結果 VOTable

プロトタイプ１と２の比較 プロト1 利用 技術 評価 プロト２ 遠隔実行 GRAM (Globus Tk2) 1 Step 20数秒 　大部分は実処理以外 　ポーリングの待ち時間 Grid Service (Globus Tk3) 1 Step 2-3秒 　大部分は実処理時間 　オーバヘッドは平均30ms メタデータ検索 UDDI サービス提供サーバのみ引き当て XMLDB （カレアレア） メタデータを検索して天体カタログを見つけることが可能に 以上の動作をするプロトタイプを実装しました。 プロトタイプ１と２の比較について述べます。 プロトタイプ１では遠隔実行にglobus toolkit version2を使いましたが、 １ステップの実行時間が２０数秒かかりました。 これは大部分が実処理以外のポーリング待ち時間でした 一方プロと２では、globus toolkit version 3のグリッドサービスを用いており、 これによって１ステップの実行時間が２－３秒程度、 オーバーヘッドは３０ｍｓ程度と実用上問題ない程度になりました。 一方メタデータ検索については、 プロトタイプ１では、Webサービスの検索のためのUDDIを用いたため、 サービス提供サーバのみ引き当てることができました。 一方プロトタイプ２では、XMLDBを用いことにより、 メタデータを検索して分散データサーバに保管された天体カタログを見つけることが持つことが可能になりました。

インタラクティブセッション I-9 No.5 本田他 実装した 解析サービス 重力レンズ天体候補探し 2重像天体を自動検出 人力では数時間かかっていた解析が、数分で可能に 詳細・デモンストレーションは、 インタラクティブセッション　I-9 No.5 本田他 をご覧ください JVOプロトタイプでこれまでに実装した解析サービスは、 重力レンズ天体候補探しです これは重力レンズによって2重像となった天体を、膨大なデータから自動検出するためのサービスです。 人力でデータの用意からおこなうと数時間かかっていた解析が、 JVOによって数分でおこなうことが可能になりました。 この詳細およびJVOデモンストレーションを インタラクティブセッション　I-9 No.5 本田他 でおこなっていますので、 ご覧ください

課題 検索・解析サービスの構築が難しい グリッドサービスはJavaで書く必要がある 天文用解析ツールは、他の言語で書かれていたり、コマンドになっていたりする そういうツールを簡単にサービスに組み込みたい 何らかの変換のための仕組みが必要

まとめ JVOプロトタイプを開発し、我々が定義したJVOQLによる、分散データサーバ間での連携検索を実証した。 プロトタイプ１での問題点を、プロトタイプ２では グリッドサービスにより、遠隔実行のオーバーヘッドを解消した XMLDBにより、テーブル検索を可能にした 今後、機能拡充し、本運用システムの開発をおこなう。