最近の更新履歴 radmonitor311

Loading....

Loading....

Loading....

Loading....

Loading....

全文

(1)

Radmon311Strategy20110406C To: radmonitor311@googlegroups.com From: 峠 暢一、 一宮 亮 Subject: radmonitor311の今後の活動展開流れとデータ共通フォーマット策定について

0.

はじめに

2011/3/11の東北関東大震災と付随する東京電力福島原子力発電所の事故発生以来、 ネットワーク上のボランティアによって環境放射線強度や関連するデータの電子化、 グラフ化が非常に活発に進められてきました。データ集積のために立ち上げられたサ イト https://sites.google.com/site/radmonitor311/home は、現在、情報・データレポジト リとして、極めて重要な役目を果たしています。 一方、動機を同じうしつつも、自然発生的に「思い思いに」行われてきたデータ電子 化・グラフ化の作業は、そのフォーマット選択、拡張性の別、入出力プロセスの雑多 性などの側面で、現在、属人的な要素を色濃くもっています。すなわち、「定型業 務」フローとして、 (1) 入力帳票 → (2) データ入力業務 → (3) DB→ (4) データ出力業務 → (5) 出力帳票 というように描きますと、(1) への元データについては除外するとして、(2), (3), (4), (5) の全てが複線化している、ということです。そのため、諸作業間のデータ共有の 点で多少難点も見受けられる場合があり、また、少人数チームでは、数ヶ月の中長期 の活動持続にむけて懸念を感ずる場合もあります。考えますに、  関係各位の多大な努力によってここまで積み上げられてきた電子データ資産を有 効に活かし、  適切な拡張可能性、データ集積作業の(半)自動化、集積データの幅広い長期的 な共有を担保するためには、 (a) radmonitor311 周りの有志の間で(2)~(5)を今後どうしていくのか?について中長 期的な活動展望の共有を図り、 (b) そのさい(2)→(3) (および場合によっては (3)→(4) も、でしょうか)の作業上、中 間データの若干の構造共通化も行うこと、 がこのさい必要か、と考えられます。 (5)については、これまでどおり作成される人の数だけ種類があって良いと思います が、本メモで提示するデータベースと連携してグラフ作成を行うサンプルが幾つか 提示されることは意味があると思います。 本メモ Radmon311Strategy20110406C は、radmonitor311 の今後のワークフロー整備、 中間データ構造の共通化、システム開発・維持上のリソース、の三点について提案を 提出させていただき、大方のご批判を仰ぎつつ、今後の活動方向性の議論の活性化と 実装作業の立ち上がりに資することを目指すものです。なお、本メモの作成時に何人

(2)

かの方々にご相談に乗って頂き、多くのご意見を取り入れましたが、文責は、峠 暢 一, 一宮 亮にあります。

1. radmonitor311

の今後のワークフロー整備(案)

「はじめに」で述べましたように、radmonitor311 周りの有志の間で、そろそろ中長 期的な活動展望の共有を図る必要が出てきているように見えます。そこで、叩き台と して、私たちの「業務」ワークフローの整備を以下のように二段階で行うことを提案 いたしたいと思います。

1.1

フェーズ 1 - データベース化まで

◆目標  放射線データを一括で取得できるユニークなサイトとしての、機能強化と認知度 向上  共通データ構造化による、図表作成コストの低減  外部の情報提供サイト充実による、最終利用者利便性の向上 ◆概要  データ取得:現状の手動コピー&ペースト中心のデータの取得は一部継続。共通 データ構造(次項に記載)への入力は、皆様が個別にご使用の電子ファイルから 変換スクリプトを経由してもよいし、直接そのフォーマットで入力されたものを 提供して下さるのでもよい。  データ集積場所:中間データ置き場として googleSpreadSheet を継続利用。 googleSpreadSheetから googleDocAPI を利用したデータ取得を行い、整形したのち、 RDBMSに格納。 ※サイトからの自動取得プログラム開発は一旦脇に置いておくので良いか。もし くは並行作業??  データ公開方法:RDBMS から API によるデータ公開。形式は JSON,JSONP,XML,CSV,TSVに対応。前節のメタ方式についても、並行して検討。API に不慣れな人のために、フォームを作成し、取得しやすいようにする。  視覚化: API 公開による、外部 IT 技術者の参加促進研究者による学術的知見の 入ったグラフ、図表等の提供 API ※ があれば、視覚化は容易なので、興味と技術がある方にお願いする。

(3)

 データ取得先サイト:現在 googleSpreadSheet にデータ集積しているサイト。 ◆考察 / ToDo  体制再構築:あまり堅苦しくする必要はないか、と思われますが、全体の進捗管 理やリソース管理等誰がやる?くらいは決めるべきでしょうか。ここで上手にタ スクを切り分けられたら、各人の負担も少なくできましょう。  サーバー確保:(次々項に記載)  開発環境構築:複数人で開発していくのであれば、ルール、バージョン管理、進 捗管理等も必要。ご提案?  公開用 API 開発:googleSpreadSheet からデータを取得するシステムの開発。 googleDocAPIでデータ取得は可能ですが、各シートでフォーマットが異なるため に、シート毎にデータ処理が必要です。 ※作業的には、ここが一番重たいかと思います。各シート毎に上手に分担できれ ばと思います。 ◆補足 現在の googleSpreadSheet 方式は、極力、コピー&ペーストでミスが少なく行えるよう に考えられています。手動で行う以上は、この方式がベストかと思われます。本来は、 コピペの部分まで自動化したいところですが、マンパワー的にいきなりそこを目指 すと時間がかかるかと思われるので、フェーズ1はデータ取得部分はコピペの継続、 とする案になっています。 ◆参考 https://spreadsheets.google.com/feeds/cells/tSc4EaYnOD5AD8fW3yHugKg/ody/private/values ↑↑ googleDocAPIによる取得用 URL サンプル https://spreadsheets.google.com/feeds/worksheets/tSc4EaYnOD5AD8fW3yHugKg/private/basi c ↑↑↑

各シートの API 公開 URL 等のデータ取得用 URL

1.2

フェーズ 2 - データの自動取得まで

◆概要

 データ取得:システムによる自動取得がメインとして運用可能なところまで持っ ていく。ただし、一部不可能な部分は手動更新による。

(4)

 データ集積場所:手動の場合には、中間データ置き場として googleSpreadSheet の 継続利用。スクレイピングプログラムが整ったサイトは直接 RDBMS に。ほかは フェーズ1に同じ。 ◆Todo  データ取得先一覧の作成:現在 googleSpreadSheet にデータ取得していないサイト でも、信頼できるデータがあれば、検討対象に。  開発者応募呼びかけ なお、フェーズ1とフェーズ2の分け方は便宜的なもので、実際には参加者のスキル によって、並行して開発していくこともあるかと思います。

2.

中間データ構造の共通化について(案)

2.1

提案骨子:

radmonitor311 で扱う大方の測定情報は、東電、文科省、etc を問わず、また、放射線 量 Sv/h、Bq/kg、風速、etc を問わず、ある物理量の時系列配列です。従って、これら の情報は原則として、 - 測定された物理量毎、測定者ごとに、 - ヘッダ部分のメタデータ、および - それに引き続く時刻-数値の配列 として整理しなおすことが可能です。このように単純化したデータ構造は、グラフ化 のさい前提とする書式として有効で、プロットソフトや解析ソフトの構成の論理化上 も有利となります。蛇足ながら、これは、高エネルギーや原子核物理でいう、 DST(Data SummaryTape) に近い、まとめデータの概念です。

2.2

データ構造概念:

たとえば、以下のようなデータ構造が考えられます。 項目 個数 値 (コメント) ---タイトル 1 文字列 出典 1 文字列 (データのオリジナル提供者情報) 出典 URI 1 文字列 データ種 ID 1 データ種別 ID データ名 1 文字列 データ単位 1 文字列

(5)

観測局名 1 文字列 観測局 ID 1 測定値 ID 観測局情報 2 緯度・経度 更新情報 n 更新者-更新年月日時刻-URI-入力者 データ n 時刻-測定値 データ例: ========= タイトル: 福島第一原発正門前放射線量 出典: 東京電力 出典 URI: http://www.tepco.co.jp/cc/press/index-j.html データ種 ID: 放射線量 データ名: 福島第一原発正門前放射線量 データ単位: microSv/h 観測局名: 福島第一原発正門前 観測局 ID: FukushimaNPS1-Seimon 観測局情報: xxx.xxx, yyy.yyy 更新情報: 2011/3/18 05:30 http://www.tepco..., dokozo_no_dareka 入力 データ: 2011/3/12 4:00 0.069 2011/3/12 4:40 0.866 2011/3/12 4:50 1.002 2011/3/12 5:00 1.307 2011/3/12 5:10 1.59 2011/3/12 6:30 4.92 2011/3/12 7:50 4.97 2011/3/12 8:00 4.89 2011/3/12 8:10 5.08 2011/3/12 8:20 4.77 ... 注記事項:  上記のデータ構造は、測定された物理量ごと、また測定地ごとに、一つ一つ独立 したデータブロックとして扱うものです。実際には、たとえば、東電サイトから は、第一原発の放射線量測定値として正門前、事務本館北などからのものが、混 在したかたちで提供されています。本提案は、これらは分離し、それぞれ、単一 の物理測定量として扱える一つ一つにバラして提供できるようにする、というも のです。こうした方針で想定できるメリット・デメリットを付録 1 に書いておき ました。  上記にかんしては、色々なご意見を伺う必要があろうか、と思います。たとえば、 同一地点にて、線量および風向・風速など、複数の物理量が同時に測定されてお り、それらを統合したデータ構造にすることが望まれる場合があります。データ

(6)

取得時間が非同期的であって、敢えて統合することは避けたほうが良い場合もあ り得ます。ご意見、ご提案を求めます。  こうした構造をもつ共通フォーマットデータが、最終的には RDBS または XML DBSの形で格納されることは、おおいに想定できるところです。たとえば、対応 する正規化済みのデータ構造例は、https://spreadsheets.google.com/ccc? key=0AtZFn4ZUF2Z6dFZuT0Q5M3Q2dG5XeTFMSHUydERYcHc&hl=jaに見ることが出来 ます。 ただし、そうした具体的格納方法の決定詳細は、どちらかと言えば、システム実 装詳細に属する問題ですので、その方面の専門担当者の判断にお任せすべきか、 と思われます。データベースへの入データと出データのデータ構造に関しては、 色々なスキル背景をお持ちの方達の幅広い参入を促すために、必ずしも正規化に はこだわらないほうが好ましい、ということもありましょう。出力時のデータ構 造さえ決まっていれば、データベース内部の実装はブラックボックスでも、極端 な場合複数通りあっても構わない、という視点です。  現時点でより大切なのは、 - データ構造の基本概念について基幹的な部分をツメ、合意し、 - データベース管理責任者は適切と考える DBS に入出力するシステムを作れば よく、 - 入力作業支援者は、それに従った Excel テンプレートなどを使って元データ の提供をすれば良く、 - プロット作業者においては、あらゆるデータは基本的に上のデータ構造概念 に準拠したフォーマットで提供される、ということを前提に、データ受け取 り上のインタフェースを整合させ、 という前提を各作業の境界毎に確立し、それによって今後、通常業務の負担のた めに、ボランティアの皆様のどこかの部分で入力、データ整理作業の継続が一部 維持難しくなるようなことが起こっても、比較的容易に作業能力を補填できるよ うなシステムを担保する、というところにある、というように考えます。  放射線量以外の物理量は、上記と基本的に同じ構造のデータとして扱うことが可 能です。物理量以外のデータ、たとえば、インシデント記録(炉の水素爆発、ベ ント、水散布開始・停止など)は、上記フォーマットの比較的ストレートな拡張 で扱うことは可能でしょう。  念のため、ですが、上記の「データ構造」共通化は、グラフ・プレゼンテーショ ンまたはデータ解析手法の、単一標準化 (データ解析のビッグブラザー化?) を推 進することを目的として行うものでは、全くありません。プロッティングやデー タ解析については、ひきつづき複数の手法による分析・グラフ化が並列して続行 することを前提とし、それらを強くエンカレッジ(推奨)することを主眼として います。

(7)

 なお、出データについては、複数のフォーマッタを用意し、xml、json、csv、tsv の 他に、提案のあった web 経由の API を用意することによって、互換性を維持 しつつ自動化しやすい環境が実現できるのではないか、と考えます。  また、データの構造は、いつも必ず絶対に上の共通データ概念に従わなければな らない、ということでなく、共通データ概念をサポートしつつ、よりファイング レイン(小さなスケールの)なデータや、あるいは複数種類のデータを同時にま とめて提供するような API が存在して良い、と考えます。

3.

システム開発・維持上のリソースについて

いくつかのご提案が ML radmonitor311 上に提出されています。また、ML 以外の通信 で伺ったご意見もあります。若干繰り返しになりますが、それらのなかで有望と思わ れますものを、下に簡単にまとめました。

 ソフトウェアエンジニアリング:矢野さんご提案の hack for japan 

http://googledevjp.blogspot.com/2011/03/hack-for-japan-hackathon.htmlまたは、 SourceForge http://sourceforge.jp/ などで、他の(技術を持つ)協力者を募っておこ なう、開発体制整備。  データベースサーバ:長い期間維持しようとすると、属人的な努力に依存するの では無理がありますから、個々人が可能な範囲で貢献できるプラットホームを採 るべきでしょう。計算機資源としてはどの程度が必要となるのか、大雑把な見積 もりが必要。計算機への要求仕様の原案を付録 2 に記載しました。 UNIX系 OS,Apache,PHP,Perl,Ruby,MySQL が稼働するサーバ(サーバー構成は専門家 が沢山居られそうなので、適宜議論にて)が良かろう、とのご意見が多いようで す。旧国立研究所などでホスト可能との情報あり。あるいは、外部の安いサーバ を借りてしまうのも一法か。サクラ VPS など。綿村さんからのご提案ですと、さ くらの VPS 512(メモリ 512、HDD 20GB、OS 標準 Red Hat EnterpriseLinux ベースの CentOS5)が提供可能。「カスタム OS」では、Ubuntu、FreeBSD、Debian、Fedora が利用できるほか、各 OS の 32bit/64bit 版の選択も可能。ただし、システム管理 担当に助力必要の由。なお、震災時特例として無料提供されている商用 VPS を利 用する場合、無償期間が過ぎた後の出口戦略を考えておく必要がある。(事故が 十分沈静化した後でも、アーカイブとしてデータは残す必要があるため。) ほかにご意見、ご提案?

(8)

付録 1:データ構造共通化にまつわるメリットとデメリッ

トについての考察

メリット:

 負担軽減その 1: データプロットの開発者・担当者は、オリジナル提供者からのデ ータ書式の変更に追従してその都度データを整形入力する負担から解放される。  負担軽減その 2: オリジナル提供者からのデータの入力作業は、原理的にはデータ 項目ごと一点に集約される。重複した入力作業の排除。  解析の利便その 1: 必ずしも完全には同期して収録されていないデータの時系列表 示が容易になる。  解析の利便その 2: 共通化したデータ書式の採用により、当初想定していなかった 物理測定量の間の相関分析により柔軟に対応できる。特定の優れたプロットソフ トにおいて、これが当初対応を前提していなかった物理量のプロットにも容易に 対応できる。

デメリット:

 起動時のオーバーヘッド:移行に伴い、過去のプロット作成用スクリプトと互換 性を持たせるために 幾つかの異なった形式のフォーマッタを用意する必要があ る。これらのフォーマッタの整備、データ変換のために、(希望的観測としては 一過性ではあるが)時間的オーバーヘッドが発生する。  ワークフローリスク:共通フォーマットでのデータ入力作業時点でエラーがあっ た場合、その被害は「下流」のすべてのプロット担当者に及ぶ。したがって、デ ータ入力の正確を期す労力が大切となる(もっとも、これは現時点でも同じ留意 点ではある)。

 データの冗長化:もともとオリジナル提供者から time vs data1, data2, data3 ... の ような形で与えられているデータについては、若干のデータ冗長性が発生する。

(9)

付録 2:データベースサーバの要求仕様(原案)

ハードウェア:

 Linuxを走ることのできるコンピュータ。  CPU: Core2Duo 2GB程度相当以上、メモリ:512MB 程度以上、HDD 容量:512GB 程 度以上。RAID5 相当以上による HDD データ保護を有すること。  ネットワーク幅:GbE 相当の LANWAN 接続を有し、日間数千件程度以上のアク セスに耐えること。ただし、アクセス数が増大した時にキャッシュサーバ、ロー ドバランサなどの追加が技術的に可能なこと(費用については別途相談)。

ソフトウェア:

 Redhat Enterpriseまたはこれと同等の CentOS 等が動作。  httpd、ftpd、sshd が走ること。  MySQLもしくは PostgreSQL など、採用合意されたデータベースソフトが走ること。  付随して、適切なネットセキュリティ対策を装備すること。  必要に応じて、java ほかの装備可能であること。

運用要件:

 Radmon311のニーズに対応のため、ご相談のうえ機能増強など技術的に対応して 頂くことに加え、数年以上にわたる運用サポートが可能であること。または、こ れよりも短期のホスティングに留まる場合、ホスト移転のさいの支援が可能であ ること。  開発者(数人程度を想定)の個人アカウントを作り、ssh でログインできることが可 能なこと。  運用は、web ベースの管理用インタフェースを用い、radmonitor311 メンバーが webインタフェース経由で更新する。 以上。

Updating...

関連した話題 :