Skip to content

meeting_20191114

Jump to bottom
Takatomo Fujisawa edited this page Nov 24, 2019 · 26 revisions

meeting_20191114

資料

今年度（後半）キックオフ

参加: 真島、児玉、福田、岡別府、藤澤
日時: 2019-11-14 15:00-@2Fリフレ

アジェンダ

  • DDBJ登録系サービスの最新情報確認、共有
  • Locus_tag prefixに対する仕様および対応方針の確認
  • 今年度のValidation API開発内容の確認
  • 案件化とスケジュール

DDBJ validator/validation API開発項目

  • validation API開発
    • コンテナ化、残置ノード移行
    • validation APIサービス（限定公開）
    • IdPクライアント化
  • validator
    • BioSample validatorルール拡張／機能拡張
    • BioProject validator残開発・運用化
    • DRA validator残開発・運用化
    • Trad validator開発
    • GEA validator組込み
    • JGA validator移行／組込み
    • JVar validator開発

前回4月の submission api 開発会議からの変化

大

  • Submission api
  • Update api
  • 認証連携
  • OpenIDM アカウント同期 docker でできた（運用チーム）
  • MetaboBank 連携 - BioProject/BioSample 連携は櫻井さん開発待ち、D-way 共用のための同期の準備はできつつある
  • trad rule のリストアップ、途上
  • D-FAST 連携 - 関係者で話し合っただけ、UMSS にそのまま流すなどのゲノム処理効率化、アカウント連携
  • BioProject/BioSample/DRA/trad 入力項目の再利用、入力の手間軽減
  • JGA エンハンス - 新グループアカウント導入、NBDC 申請管理システムとの統合、暗号化フロー変更、仮想化と新スパコンへの移行（運用T四人かかりっきり）

中

  • BioProject/DRA への validator 導入、登録現場の効率化
  • BioProject 導入先行させたいが D-way 側の簡素化、locus tag 予約ステップの BioSample への移行が先
  • 短時間雇用 高木、シニアキュレータ　秦　着任

小

locus tag 予約チェック機能の実装

岡別府さん提案処理フロー
Locus_tag_prefix.pdf
別の submission との prefix 重複は R0102 ではなく R0103 でお願いします。

  • prefix は submission ではなく 1 prefix - 1 biosample record とリンクして管理する
  • D-way で submit 成功したタイミングで attrDB に属性が書き込まれる（たしか → でした）
  • accession 発行前に登録者が間違ったので更新、はあり得る

のでおそらく更新の意図検知は、

  • 当該 sample の prefix が既に attrDB に登録されており、かつ登録済みの prefix と input された XML に記載されている prefix が
    • 異なるとき - 更新意図あり
    • 同じとき - 更新意図なし
      になると思います。

この機会に prefix 予約機能を D-way に実装したいのですが運用チームの工数がまったくとれないので、

validator で availability check 済み biosample が D-way で submit される
↓
accession 自動発行フローから除外される
↓
キュレータは手動で内部 cgi で予約

のフローをまずは予定しています。

  • 400/500番台だと
    「private comments to DDBJ staff に希望する prefix 書いて prefix 属性は空にしてとりあえず submit してください（とにかく投げちゃいたい人が多そうなので）/後でお試しください or DDBJ に連絡してください」あたりでしょうかね。
  • eOK はランダムな文字列 + 1, 2, 3 とかで実際に取っちゃってもよいかと。

追加: haploid genome 対応で locus tag prefix 属性は 1 biosample に複数書かれることを想定する必要がある
https://github.com/ddbj/ddbj_validator/issues/67

  • JPA、JPB、JPC、JPD、JPE1～9999 を auto-generate locus tag prefix で使う予定

NCBI locus tag prefix api

児玉自作 cgi

  • 200 タグの予約実行 5分36秒（1タグ1.7秒）

Sample scope choices

  • onoisolate: a single animal, cultured cell-line, inbred population (or possibly a heterogeneous population when a single genome assemby is generated from the pooled sample; not preferred).
  • Multiisolate: multiple individuals, a population (representative of a species). To be used for variation or other sequence comparison projects, not when multiple genomes will be annotated. Make separate monoisolate projects when more than one genome will be annotated.
  • Multi-species: sample represents multiple species.
  • Environment: the species content of the sample is not known.
  • Synthetic: the sample is synthetically created by a machine.
  • Other: specify the sample scope that was used.

メモ

locus tag 予約チェック機能の実装

  • locus_tag_prefixが必要そうなpackageであっても、annotationデータがあるか否かはsampleだけでは判断できないので必須項目にはできない。 将来必須になった場合、空で入力されるケースでは自動付与も検討する。
  • 任意:必要なのに取らない（ナビゲーション、マニュアル改訂）、必須:不要なのに取らないといけない（自動発行）、のトレードオフがあり、軽減策として () 内の施策とセットで実装
  • 自動付与は JPA/B/C/D/E/F1～9999 を submit 時に連番アサインして登録者に選択の余地を与えない方が欠番が生じず管理しやすい
  • package(MIxSのbacteria/eu)によって、locus_tag_prefixがない場合は "annotated genome を登録するときは必要ですよ？" というようなwarningを出す。ルールを追加。TODO 児玉 BS_R0109 追加
  • 運用上、公開済みのもののprefix更新は断るが（強く希望されたら受け付ける）、公開前は受け付けてSSMで処理を行う。更新系はSSMからのみ。
  • 更新時(SSUB IDがsampleDBに存在するかで判定)に新しく予約するべきlocus_tag_prefixがあった場合にはwargningを出す（追加、更新 prefix が予約済みの場合は R0103 ルールでチェック、ignore error）。ルールを追加。TODO 児玉 BS_R0108 追加
    • 更新判定は submission 単位で DB に記録されている prefix と incoming の prefix を集合で差分をとって追加と更新対象 prefix
    • 児玉追記: 間違え修正で sample 間で prefix を交換することも生じ得る。追加・更新 prefix で予約されていない prefix のみ warning 表示だとサイレントになるので「追加・更新された prefix がある（内予約されていないもの a b c 予約されているもの d e f）」 のような両方併記の方が良い
    • 児玉追記: accession 発行前でも SSM で sample_name の変更が可能であった。おそらく上からの順番で対象 sample を判定している
      を判定する TODO 児玉 SQL 提供
      submission id で登録されている locus tag prefix 値を取得する SQL
      RDB は XML で最新含めた履歴を保持し、最新の属性値を sample の primary key である smp_id にリンクして attribute_key = 属性名、attribute_value = 属性値、として attribute table で保持している、smp_id で sample、submission_id で submission table に join して取得できる。新規のときや tsv up しただけで submit 未だなど d-way で submit される前の submission は submission id あるけど attribute table に値がないので結果が返ってこない
SELECT submission_id, attribute_value FROM mass.sample JOIN mass.submission USING(submission_id) JOIN mass.attribute USING(smp_id) WHERE attribute_name = 'locus_tag_prefix' AND submission_id = 'SSUB002717';
submission_id attribute_value
SSUB002717 PPS01S
SSUB002717 PST01S
SSUB002717 PSY01S
SSUB002717 COX01S
SSUB002717 SAD01S
SSUB002717 PAL02S
SSUB002717 PAZ01S
SSUB002717 PCH04S
SSUB002717 PFL01S
SSUB002717 PFR01S
SSUB002717 PIN01S
SSUB002717 PJI01S
SSUB002717 PLU01S
SSUB002717 PMA01S
SSUB002717 PMI01S
SSUB002717 PMU01S
SSUB002717 PNI01S
SSUB002717 POL01S

  • prefix が記載されている（or tax id 未アサイン）の新規 submission は accession 自動発行されないのでそれをフラグにキュレータがチェックしている

  • prefix は児玉作成の内部 cgi でキュレータが手動で予約する、更新時は validation のみ実行 - 「予約すべき prefix あるよ」 validator warning（SSM に工数避けないので更新自体は実行する） みて cgi 予約 - validation & update で更新 warning なし - OK という作業フロー

  • SSM での更新時に意図していない更新がないかどうかのリマインド、チェックは XML diff を出力するような general なやり方で対応するのが良い

  • prefix 予約、記載漏れチェックのため児玉が定期的に biosample db, prefix 予約 db を定期的に突合する todo 児玉

  • 実際に genome annotation に使われた prefix は trad db パースして抽出するしかないが、パースして格納されておらず時間かかる処理が必要、将来 trad genome で使われた bioproject - biosample - prefix - trad entry accession をペアで管理できるようにする必要がある（これができると genome 公開時に biosample-prefix ペアを bioproject xml に機械的に追記できるようになる）

  • haploid genome のとき 1 biosample - 2 prefixes になるので複数属性考慮した validation 必要、影響はユニークネスチェックくらいか？

  • 登録システムでの影響調査と対応は工数不明だが運用チームに余裕がでてから依頼する。validator だけ先行して複数対応する

  • prefix submit、更新 submit 時の予約、連番発行機能、validator warning みての SSM 挙動は運用チーム担当

  • 半手動だがこれで prefix 記載を bioproject から biosample に移しておくと、validator の bioproject への導入が容易になる

  • prefix 対応で運用チームが必要なのは bioproject prefix 予約の口を閉じる、d-way に必要な注意書き追加なので工数小さい

  • ユーザが submit した tsv は submission_form table の attribute_file_name と attribute_file カラムにファイル名とファイルの内容が保持されている。キュレータが upload する tsv は保持されない

  • D-FAST が prefix 自動取得することを見据えると DDBJ で locus tag prefix api(予約チェックと連番自動発行、last number 管理)をする api を整備した方が良い（藤澤）

  • prefix の管理システムが必要であるが biosample attribute table に登録されている prefix = ddbj から予約した全 prefix としたい。過去の trad genome entry と bioproject を漁ってレトロフィットが必要。実際に使われたかどうかは trad genome entry をパースして管理する必要がある（児玉）

  • 児玉追記: 運用の話し。prefix 記載された submission で予約される前に cancel する場合は prefix を消してから cancel する。予約した後であれば消さない。こういう運用にして biosample に記載されている prefix は全て予約されていることを担保する

コンテナ化

ノードを頂いているので、コンテナ化を最優先とする。年末ぐらいまでが目処。TODO 岡別府

  • docker 停止・起動があるので downtime ゼロは難しくなるかも。load balance、切り替え etc 対策ないか引き続き検討する todo 岡別府、藤澤

今年度仕様とこれから

今年度仕様

  • 残置からの移行、コンテナ化（新スパコンへの移行だけでなくコンテナ配布を意識しておく）
  • biosample ルール追加、更新対応

↑アクシオアカウント統合案件とあわせて仕様書作成 todo 藤澤

以下は仕様書には書かない

  • bioproject validator api 完成（運用直前までもっていく）
  • dra validator api 完成（未実装ルールの実装、テスト）、bioproject - biosample - DRA submission, experiment, run, analysis 全部揃っている、project/sample 外部参照のコンビネーション

gea, trad validator ラップは次年度以降

これから

  • trad はそもそも今の postgres x 3、数億件でどんどん増え続けるレコード、というのが持続可能ではなく根本的にどうするか？という設計が先
    • バックボーン json にする? (ASN.1 アプローチ) annotation file tsv にする？（登録形式と同じというメリットあり）
    • bioruby object でデータモデル表現？bioruby に ddbj ff 対応でコミット？誰が？location とか複雑でゼロから開発はしんどい
    • trad validator つくるにしてもゼロからは非現実的で既存 jparser ume ラップと手動でしかチェックできていないルールの新規実装の組み合わせ
    • 既存チェッカーコンテナ化、並列化による UMSS 高速化は db load など律速が他にもあり happy になりそうにない、のと shell uge array job とかで対応できるかも（菊 wgs とか一エントリが長大だとメモリーが落ちる、残置で max memory 割り当てで回避している）
    • UMSS 育てていって tsunami 脱却？
  • JVar dbvar xml ではなく json にしてバックボーンは xml 辞める、交換用にxml生成するだけにする
    • EVA/DGVa は json + mongoDB だが Ensembl 仕様で ncbi と座標、normalization が違っている
    • Jvar は human のみなので clustering は dbSNP 依存（なので ncbi と大きくズレると大変かも）
    • dbsnp は SPDI という新しい記法に移行済み、なのでfomatは少し様子を見たい
    • いずれにせよjvar はまだ着手しない, validation rule 整備、vcf checker もらう、accession 発行とか検討しておく todo 児玉
  • JGA はエンハンス後は大きく手を入れない方が良い
  • Metabobank が今年度、次年度 bioproject biosample 連携をいつどこまでやるのか櫻井さんに確認 todo 藤澤、児玉
  • bioproject tax 任意化:project only のとき生物名で検索できなくなる、必須: multi-species のとき適切か？を「気にする」、というトレードオフあり。今考えてるのは web IF で multi のとき tax description だけにして入力させない ncbi 方式

業務システムがオンプレにあるメリットが乏しい、クラウドでよくね？データは割引ないのであれば SINET5 L2VPN でオンプレストレージと接続 文科省が許すかどうか不明だが省庁がクラウド移行するのであればそういう流れになると思われる
全省庁にクラウド 来秋から 採用基準、安保に配慮　2019/11/10付日本経済新聞　朝刊

仕様書開発項目（案）

ver. 2019-11-24 -tf

  1. 開発内容

2.1. dockerコンテナ開発およびコンテナネットワーク構築

APIサーバを含むメインアプリケーションのdockerコンテナ開発する。さらにメインアプリケーション、Virtuoso、PostgreSQLおよびnginxの各コンテナを構成し、ネットワーク上のリソースおよび関連サービス構成を考慮したdocker-compose定義ファイルを開発し、dockerコンテナネットワークを構築する。サービスおよびコンテナ構成については、DDBJ担当者と協議の上、冗長化および環境への最適化を検証し、現在運用稼働中の環境と同等なデータバリデーション統合環境を新たに整備する。また、メインアプリケーションについては、コマンドライン上からもコンテナ内のバリデーション実行の動作を確認する。

2.2. 現行運用環境からの移行作業

運用移行時点におけるDDBJ共有リソースおよびサービスへの参照先を切り替え、データログ情報の移行を含む、2.1において構築した環境への運用切替に伴う作業を実施する。合わせて、DDBJ Validation APIサーバが参照し、Web UIを提供するためのNucleotideおよびTaxonomyのOWL形式およびHTML形式を生成するコンバーターおよびウェブサイトの移行も実施する。環境移行に伴う各種変更についてはDDBJ担当者と協議し、スパコンチーム、運用チームと協力して運用の移行を実施する。

2.3. バリデーション定義およびルールの追加および更新に伴う開発作業

MetaboBankおよびlocus_tagの取り扱い変更に伴うバリデーション定義およびルール追加、更新に伴う開発作業を実施する。また、ステージング環境および本番環境に対してデプロイ作業を実施する。

次回

submission/validation api

Clone this wiki locally