2011年度 生物データベース論 2日目 木構造データ
Post on 15-Jan-2015
2.022 Views
Preview:
DESCRIPTION
TRANSCRIPT
Lecture - Biological Databases: Structured Data Processing
生物データベース論
講義:生物データベース論 2日目
2011年9月14日
担当:斉藤 太郎 (森下研究室) leo@xerial.org
構造を持ったデータの扱い
テーブル構造データ (有田先生)
関係代数、関数従属性(FD)、SQL
木構造データ (今回の講義の内容)
XML, JSONなどが有名
生物のゕノテーション、ゲノムデータ、プログラミング言語で使うオブジェクトなど、あらゆる種類のデータがここに含まれる
講義の内容
木構造データの例
XML, JSON, その他ゲノム情報処理で使われるデータ形式について
木構造データのデータベース作成
木構造データの索引 (interval encoding, ORDPATH)
木構造データの検索
親子、祖先 子孫関係の判定
木構造データの字句解析・構文解析 (JSONを例に)
木構造データのストリーム処理
木構造データの直列化 (Serialization) とその復元(Deserialization)
木構造データを敢えてフラットに表現する
テーブルに分解 (データモデリング)、木構造データでの関数従属性
1
Lecture - Biological Databases: Structured Data Processing
XML
XML (eXtensible Markup Language)
タグ <A> … </A> を使って、テキストデータに意味を持たせる
例:
<reference>D. melanogaster</reference>
各々のタグには、さらに属性 (attribute) を複数追加できる
例:
<A id=“1”> (Aはタグ名、idはattribute)
タグを入れ子にして階層構造を表す
XMLの活用例
RSS/Atom
Webページの更新情報を配信
例えば、Nature誌の更新情報などが自動的に届く
BioDAS
ゲノム情報の取得。
配列、遺伝子情報、各種ゕノテーション等
GMail
RPC通信
リモートのサーバー上から メールのデータをブラウザに送信する
GMailのメール表示が高速なのは、あらかじめメールのデータをブラウザに読み込ませているため
XMLの中に、serialize (後で説明)されたオブジェクトデータを埋め込んで通信している
染色体名のリストをDASから、XMLで取得した例
2
Lecture - Biological Databases: Structured Data Processing
XMLデータは木構造を持つ
city
name
“Jeffrey”
item
“J-001”
“New York”
“Notebook”
id
“2002/02/13”
“50
”
order
num
customer
order
date
“3
”
oid
item
“Blank Label”
“2002/02/10”
“100”
num
date
“1”
oid
status
“delivered”
<customer id=“J-001”>
<name> Jeffrey </name>
<city> New York </city>
<order oid=“3”>
<item> Notebook </item>
<date> 2002/02/11 </date>
<num> 50 </num>
</order>
<order oid=“1”>
<item> Blank Label </item>
<date> 2002/02/10 </date>
<num> 100 </num>
<status> delivered </status>
</order>
</customer>
3
Lecture - Biological Databases: Structured Data Processing
ゲノム情報処理で使われる木構造データフォーマット
BED format
主に遺伝子領域の記述に使われる
ヘッダー行 データの名前、説明など
データの行 空白区切りで、chr, start, end, name, score, strand, thickStart, thickEnd, rgb, blockCount, blockSizes, blockStartsの情報を記述
thickStart, thickEndは、CDSの開始・終了範囲、blockCount, blockSizesなどはexonの数、大きさの記述に使われる
WIG format
棒グラフなどのデータの記述に使われる
最近では、ChIP Seqのデータになど応用される
http://genome.ucsc.edu/FAQ/FAQformat.html より抜粋
4
Lecture - Biological Databases: Structured Data Processing
ショートリード用のデータフォーマット
FASTQ フォーマット
リード名、塩基配列、+、各塩基のQuality valueのASCII値
次世代シーケンサー Illumina Hiseq2000では、 1runで数億本ものリードが読まれる
SAMフォーマット
詳細は仕様に(5ページほどなので簡単)
http://samtools.sourceforge.net/SAM1.pdf
BAMフォーマット
SAMフゔルを圧縮したもの (5分の1程度に圧縮できる)
各リードがマッピングされた 染色体上の位置を表す
ゕランメントの状態をCIGAR文字列で表現
(塩基数)(タプ)の羅列
タプの種類
M: match or mismatch
I: insertion to reference sequence
D: deletion from reference sequence
S: soft-clipped
e.g., chimeric read, adapter sequence, etc.
N: gap
P: padding
H: hard-clipped
e.g., split alignment part
@SAMPLE1.L1.5449 ATGGAGGTCATCACCTACAAGCTCGTCACACCATCCGTCGTCTCTGAACGTCTGAAGGTTCGTGCTTCATTGGCCA + IIIIIIIHIIIIIIIIIIIIIIIIIIIIIIIIIHIIIGIIEHHHFHHIIIFIHHGGHHDEIGDGGGEGEGEDDGFI @SAMPLE1.L1.5450 GTTAAAAAGCCCGTAGTTGGATCTAGGTTACGTGCCGCAGTTCGCAATTTGCGTCAACTGTGGTCGTGACTTCTAA + HHHHHGGHHHHHHHHHHHHHDHHHHHHHHHHHDHHHHHHHBGGEGFFHHHHHHGHEEFHHBHF<EECE@BECBEA@ @SAMPLE1.L1.5451 CAGAATGACTGTCGCTCACATGTGGTACGATGAAACCATCCATGAGTGTGATACCACCGAAACTCAAACCAGCCAG +
5
Lecture - Biological Databases: Structured Data Processing
SAMフォーマットで表現されたショートリードゕランメントの可視化の例
UTGB (University of Tokyo Genome Browser) より http://utgenome.org/
6
Lecture - Biological Databases: Structured Data Processing
木構造データをデータベースに格納する
様々なフォーマットのデータがあるが、どれも木構造として考えることができる
木構造データのデータベース化
用途によって様々なゕプローチがある
木構造専用のnative databaseを使う、あるいは自作する (今回は説明しない)
既存のnative XML databaseを利用
あまりこれといったものが見当たらないのが難点
関係データベース relational databaseに格納する
木構造をテーブル型に変換する
interval encoding
ORDPATH
木構造をオブジェクトにマッピングする
木構造データの構文解析 ー> ストリーム処理 -> オブジェクトへのマッピング
オブジェクトー>テーブルに分解 ->RDBに保存
あるいは、オブジェクトをserialize(直列化。バナリー形式に変換)してcolumnに保存する
7
Lecture - Biological Databases: Structured Data Processing
木構造の区間表現
Interval Encoding
木構造を枝を使わずに表現する手法
各ノードを(start, end)の区間で表す
区間の包含関係
Ancestor-Descendantの関係に対応
Parent-Childの対応を見るためには、階層の深さ(level)の情報も保持する
タグの種類ごとにノードを分類しておけば、特定の子孫のノードをすばやく検索できる
例
Root以下のCノードの検索
Aノードの子孫であるDノードの検索
利点
SQLで検索できる
startの値が、深さ優先順になっている
B+-treeに格納しやすい
endの値は、post orderになっている
欠点
ノードを追加していくと、区間が枯渇してしまう
8
10 1000
20 100 120 190 230 300
A
(20, 100)
Root
(10, 1000)
B
(120, 190)
A
(230, 300)
C
(30, 35)
D
(40, 50)
C
(240, 260)
level 0
level 1
level 2
Lecture - Biological Databases: Structured Data Processing
更新に強い木構造のencoding
ORDPATH
更新に対応したラベルの付け方
各ノードに対し、階層上での位置がわかるラベルを付ける
ラベルの付け方
兄弟ノードに奇数を左から順に割り当てていく
子のラベルは
「親のラベル . 兄弟間でのラベル」の形式で連結する
親のラベルがprefixになる
親子関係、祖先ー子孫関係の判定がラベル同士の比較で可能
ORDPATHの連結の段数が、ノードの深さに対応
新しいノードを挿入するとき
挿入したい位置に奇数がもうないときは、間の偶数を一段はさんで、奇数を1から割り振る
ノードの深さを調べる場合、偶数の段はスキップする
ORDPATHの利点
ラベルの付け方が明確 (区間表現は任意性がある)
更新が容易
ノード間の全順序が保たれる
深さ優先探索順
次に説明するprefix free encodingで、B+-treeに格納
ORDPATHの欠点
階層が深くなると、各ノードのラベルサズが大きくなりすぎる
SQLだけで階層構造の検索が記述できない場合がある
9
A
1.1
Root
1
B
1.3
A
1.5
C
1.1.1
D
1.1.3
C
1.5.1
A
1.1
Root
1
B
1.3
A
1.5
C
1.1.1 D
1.1.3
C
1.5.1
C
1.1.2.1
Lecture - Biological Databases: Structured Data Processing
ORDPATHのprefix-free encoding
ORDPATH
各段のラベルを(Li, Oi) の組で表して連結
Li:次に続くbit stringの長さ
Oi: i段の番号を表すbit string (右表を使う)
例
1.1 = 01001 01001
1.3 = 01001 01011
1.1.3= 01001 01001 01011
1.9 = 01001 1000001
2.1 = 01010 01001
prefix free encoding
Liのbit stringが他のLi bit stringと 衝突しない
ORDPATHのbinary stringをソートすると、 木構造の深さ優先順と同じになる
10
Lecture - Biological Databases: Structured Data Processing
木構造のデータをrelational databaseに格納する
木の各ノードを1レコードに対応させる
ORDPATHの代わりにstart, end, depth を
列に使ってもよい
練習問題
階層構造を使った以下の検索をSQLで記述せよ
BOOKノード以下にあるTITLEノードをすべて取得する
解答
SELECT * FROM XMLTable t1, XMLTable t2 WHERE t1.TAG = “BOOK” AND t2.tag = “TITLE” AND t1.ORDPATH is_prefix_of t2.ORDPATH t1とt2は同じテーブル(右図)を参照している
ORDPATHでのancestor-descendant/parent-childの検索は、prefixの判定機能が実装されている(あるいは追加できる)DBMSでないと実行できない
(start, end, depth, tag)のテーブルを使った場合、SQL文はどのようになるか?
11
Lecture - Biological Databases: Structured Data Processing
参考:B+-treeを使って多次元データを検索する
空間充填曲線(space-filling curve)を用いるとXMLの(start, end, level, tag) など多次元の情報を1つのB+-treeで検索できるようになる
XMLの場合には、z-curveが使いやすい bit-interleave 操作で空間充填曲線上のンデックス(z-
order) が計算できる
z-orderをキーにして、B+-treeに各ノードのデータを格納
(start, end)の区間を2次元にマップすると 子孫ノードは右下、祖先ノードは左上の長方形領域に包含
される
B+-treeのリーフを飛び飛びにscanして、多次元領域検索を行える
12
start
en
d
z-curve and z-order
bit interleave function
multidimensional range query
Lecture - Biological Databases: Structured Data Processing
木構造データの汎用性
BED, WIG, FASTQ, SAMのデータはすべて木構造で表現できる
それなのに、なぜXML以外のフォーマットが使われるのか?
現実的な課題
処理速度
XMLより、タブ区切りデータの方が速く読み書きできる
データをコンパクトに表現できるか?
XMLは次世代シーケンサーのように大きなデータのやり取りには全く使われていない
記述、出力のしやすさ
タブ区切り形式でデータを出力するのは簡単。ただし、同時に含めるべき情報(サンプル名、更新履歴、どのような処理で生成されたデータなのか、などの重要な情報)が欠落している弊害も
構文解析のしやすさ
lexer/parserを書く必要があるか、splitするだけで使えるか
共同作業のしやすさ
様々なプログラミング言語で扱えるか?(仕様がシンプルだと、実装者が現れやすい)
XMLは複雑な仕様にも関わらず、時代の波にうまく乗れたため、各言語で構文解析器が実装されてきた (1997年以降~)
可読性
フラットなフォーマットだと、一画面に情報を詰め込みやすい
コマンドランでの扱いやすさ
この講義での目的
様々なフォーマットで記述されていても、すべて木構造データとして汎用的に扱う枠組み
13
Lecture - Biological Databases: Structured Data Processing
参考:コマンドラインでのデータ処理の例
例1:SAM フォーマット中のリードの検索
SAMフォーマットではデータがタブ区切りで記述されている
マップされたリードのうち、mapping quality > 0 かつ、chr22にマップされたものを取り出す
cat sample.sam | grep –v “^@” | awk ‘$5 > 0 && $3 ~ /chr22/’
@で始まる行は、ヘッダ行なので取り除く
BAM fileの場合
catの代わりに、samtools viewコマンドを使う
例2:特定の名前のリードを、gzip圧縮されたfastqフゔルから取り出す
zcat sample.fastq.gz | grep –w –A 3 “SAMPLE1.L1.5449”
-w は単語単位でのマッチ、-A 3は、マッチした箇所の後の3行分まで表示するオプション
例3:タブ区切りデータのテーブルの第4列に含まれる値の種類を調べる
cat input.tab | awk ‘{ print $4; }’ | sort | uniq
awk(あるいはcut)で4列目のデータを取り出し、ソートして重複除去をおこなう
14
Lecture - Biological Databases: Structured Data Processing
JSON
JSON (JavaScript Object Notation)
構造を持ったデータの通信フォーマットとして広く活用されている
多くのWebゕプリケーションの裏側で使われている
これも木構造
構文解析が容易。多くのプログラミング言語でparserが実装されている
JSONのフォーマット
Object
{ “key1”:value1, “key2”:value2, … }
波括弧で囲む. keyとvalueはコロンでつなぎ、key-valueの組はコンマで連結
Array
[value1, value2, … ]
鍵括弧で囲む. valueはコンマで連結
value type
string (文字列)
double quotation (“…”) で囲む
number
integer (整数), real (浮動小数点数)
boolean
true or false
null
Object, Arrayもvalueに成り得る
例:(遺伝子のエントリ)
{“id”:1, “gene name”:”gene A”, “strand”:”+”, “start”:11617, “end“:16804, “exon”:[{“start”:11617, “end”:11689}, {“start”:16472, “end“:16804}]}
15
Lecture - Biological Databases: Structured Data Processing
JSONの字句解析 (lexical analysis)
JSONデータを木構造に変換するためには、まずテキストデータの構文解析を行う
例: JSONの文字列
{“id”:1, “name”:”gene A”}
字句解析 (lexical analysis) - トークン(token)に分割
文字列 トークン型 パターン State
{ LBrace 一文字マッチ 初期状態 {か[のみを受理
“id” String ”[^”]*” (正規表現) key or end stringか}を受理
: Colon 一文字マッチ colon colonのみを受理
1 Integer value type全て value value typeなら受理
(integer/string/boolean/null/array/object)
, Comma 一文字マッチ next or end commaか}を受理
“name” String ”[^”]*” key stringのみを受理
: Colon 一文字マッチ colon
”gene A” String ”[^”]*” value
} RBrace 一文字マッチ next or end
トークン
トークン型
文字列
行番号、文字列のstart, end位置も保持しておくとデバッグに便利
16
Lecture - Biological Databases: Structured Data Processing
Lexerの実装
テクニック
string中以外の空白 [ ¥t¥n¥r]+ (white space token)は読み飛ばす
正しくないデータが入力されたときのために、データをどこまで読んだか(行、列番号)を管理しておく
改行文字 ¥n (LF. Unix), ¥r¥n (CR+LF, Windows), ¥r (CR, 昔のMac) が出現したら、行番号を+1
改行文字が多様なのはタプラター時代の名残
LF: line feed (1行分紙を巻く)、CR: carriage return (行頭までヘッドを移動)
字句解析では正規表現に対応するオートマトンを作って考える
練習問題
テキストフゔルの内容を入力文字列として受け取り、3種類の改行文字の出現を認識できる決定性オートマトンを作成せよ
改行コードを認識するstateに到達したら、改行tokenを出力
括弧の入れ子やdouble quotationなどの対応関係を見る必要がある場合、オートマトンの能力(正規表現と同等)を超えるので、括弧等をスタックに積む(push)、取り出す(pop)機能を付加したオートマトン (push down automaton)を使う
スタックの状態(空の場合とそうでない場合、など)に応じて、遷移先のstateを切り替えられる
練習問題
以下のScheme文法に従った文字列を受理する決定性プッシュダウンオートマトンを作成せよ
S := expr
expr := ‘(‘ op expr expr+ ‘)’ | number
op := ‘+’ | ‘-’ | ‘*’ | ‘/’
number := [1-9][0-9]*
入力文字列の例
(+ 1 (* 2 3) (/ 10 5))
JSONの場合、Stateを管理しなくてもlexerは実装できるが、凝った文法を扱う際には必要
XMLの場合: タグの中身か、それ以外で、文字列の認識パターンが変わる
各種プログラミング言語: コメント文の内部とそれ以外。 ポンタのマーク(*)なのか、掛け算operator(*)なのか。
17
Lecture - Biological Databases: Structured Data Processing
JSONの構文解析 (syntax analysis)
例: JSONの文字列の構文解析
{“id”:1, “name”:”gene A”}
構文解析 (parsing) – トークン列をパターンルールにマッチさせる
字句解析で得られるトークン列: LBrace, String(“id”), Colon, Integer(1), String(“name”), Colon, String(“gene A”), RBrace
JSONの構文パターンルール (抜粋) Object := LBrace (KeyValue (Comma KeyValue)*)? RBrace
Array := LBracket (Value (Comma Value)*)? RBracket
KeyValue := String Colon Value
Value := String | Integer | Boolean | null | Object | Array
18
Lecture - Biological Databases: Structured Data Processing
再帰下降型構文解析器 recursive descent parser
再帰下降型構文解析
実装が簡単
パターンごとに構文解析する関数を作成
parseObject, parseArray, parseKeyValue, parseValue, …
各関数で、再帰的に他のパターンの構文解析関数を呼び出す
parseObject
match(LBrace) // 次のトークンがLBraceでなければエラーを報告
loop:
parseKeyValue
if nextToken is Comma, consume(Comma), then continue loop
look aheadを使う
match(RBrace)
parseKeyValue
match(String)
match(Colon)
parseValue
構文解析では、どの関数を呼び出すか決めるために、1トークン先読み(look ahead)機能を実装する
matchではトークンを読み進めるが、look aheadでは読み進めない
19
Lecture - Biological Databases: Structured Data Processing
構文木の作成
{“id”:1, “start”:11617, “end“:16804, “exon”:[{“start”:11617, “end”:11689}, {“start”:16472, “end“:16804}]}
parseObject, parseArray では、各々が担当する部分木をreturn文で返す
object
id:1 start:11617 end:16804
array
exon
object
start:11617 end:11589
object
start:16472 end:16804
20
Lecture - Biological Databases: Structured Data Processing
構文解析の参考資料
Lexer/Parser生成器
Lex/Yacc
古くから使われている
Flex/Bison
Lex/YaccのC++対応版
ANTLR
多言語でlexer/parserを作れる。 便利だが、大規模データ用にはやや処理が遅い
参考図書
Compilers: Principles, Techniques, and Tools
Second Edition
The Definitive ANTLR Reference
ANTLR3で記述したJSON lexer/parserの例
21
Lecture - Biological Databases: Structured Data Processing
ストリーム処理
再帰下降型構文解析では難しいケース
データが巨大な場合
例:5千万エントリを含むSAMフゔル
構文パターン SAM := Header* ReadAlignment*
SAMオブジェクトの配下に、ReadAlignmentのオブジェクトが5千万個 。構文木がメモリに収まりきらない
参考: 次世代シーケンサー (Illumina Hiseq2000) では、1runで数億本のリードが読める
FASTQフゔルは1 run分で100GBほど。SAMフゔルは150GB程度になる
ストリーム処理
限られたバッフゔ上で、巨大な入力データを処理する
音楽、映像データなどのWeb配信などは基本的にストリームの形で処理される
例:SAMフゔルのストリーム処理
file reader -> parser -> object handler とデータが流れる
parser
SAMフゔルを一行ずつ読み込む -> Header または ReadAlignmentオブジェクトを出力(emit)
object handler
HeaderかReadAlignmentオブジェクトを受け取る関数を用意
handleHeader(…)
handleReadAlignment(…)
22
Lecture - Biological Databases: Structured Data Processing
ストリーム処理の2つの形態:Push Parser
Push Parser
parserが event handlerを呼び出す (前頁の形態)
parser –(pushes events to)-> event handler
プログラム例 parser.parse() {
void handleHeader(Header h) { // parserがこの関数を呼び出す
// ヘッダの処理
}
void handleReadAlignment(ReadAlignment r) { // parserがこの関数を呼び出す
// ゕランメントのデータを処理
}
}
利点:
複数のevent handlerをパプラン化して使う場合に、CPUの無駄が少ない parser -> handler1 -> handler2 -> … 各handlerが次のhandlerにデータを渡す
push modelは並列データベースでクエリの高速処理のためによく利用される
欠点:
parserの動きを制御するのがやや難しい。parserの動きを途中で止めたり、一部のデータを読み飛ばす(フゖルタリング、エラー処理時)など。
23
Lecture - Biological Databases: Structured Data Processing
ストリーム処理の2つの形態:Pull Parser
Pull Parser
データ処理側(event handler) がparser.next()を呼び出して、逐次データを取り出す
event handler <-(pulls events from)- parser
プログラム例 for(Event e; (e = parser.next()) != EOF; ) { // parserからデータを取り出す
// e を使って、何らかの処理を行う swtch(e.type) { case Header: … // ヘッダの処理 case ReadAlignment: … // ゕランメントのデータを処理
} }
利点:
Parserの動きを制御しやすい(再帰下降parserと組み合わせたり、一部のデータを読み飛ばすなど)
Pull parserがあればpush parserを実装するのは簡単
逆に、push parserをpull parserに変換するには、プログラムの並列化が必要 (練習問題)
欠点
複数の処理をパプラン化する際、event handlerごとにevent bufferを作り、各々pullする必要があるので無駄が多い
参考:
GoogleのMapReduce: 分散処理部分でpull model を使っている(詳しくは笠原先生の回に)
24
Lecture - Biological Databases: Structured Data Processing
参考:MapReduce
output file (s)
input file
f f f
chr1 chr2
chr3
chr2 chr3 chr1
chr2 chr3
hashing records
chr1 chr2 chr3
sort and merge
Split the data file into several chunks
Map
Reduce
…
25
Proposed by Google [SOSP2004]
An open-source implementation: Apache Hadoop
Map Apply the function f to each chunk of the input
records
Function f produces (key, value) pairs
Gives program semantics for parallelization
The evaluation order of the records does not matter
Reduce Receives the sorted output from the map function.
pull model
Lecture - Biological Databases: Structured Data Processing
木構造からオブジェクトへのマッピング
プログラミング言語で使うオブジェクトと木構造を対応付ける (Object-Tree Mapping)
object
id:1 start:11617 end:16804
array
exon
object
start:11617 end:11589
object
start:16472 end:16804
Gene
Exon Exon
26
class Gene { int id string name string chr int start int end List<Exon> exon }
class Exon { int start int end }
Lecture - Biological Databases: Structured Data Processing
オブジェクトストリームの生成
startObject g = new Gene()
key:id, value:1 g.id = 1
key:start, value:11617 g.start = 11617
key:end, value:16804 g.end = 16804
key:exon
startArray e = new List<Exon>()
startObject e0 = new Exon()
key:start, value:11617 e0.start = 11617
key:end, value:11689 e0.end = 11689
endObject e.add(e0) // 配列にExonを追加
startObject e1 = new Exon()
key:start, value:16472 e1.start = 16427
key:end, value:16804 e1.end = 16804
endObject e.add(e1)
endArray g.exon = e
endObject emit(g) // Gene オブジェクトを出力
27
object
id:1 start:11617 end:16804
array
exon
object
start:11617 end:11589
object
start:16472 end:16804
Gene
Exon Exon
class Gene { int id string name string chr int start int end List<Exon> exon }
class Exon { int start int end }
Lecture - Biological Databases: Structured Data Processing
オブジェクトの直列化
生物情報学では解析の数だけオブジェクト(型定義)があるといっても過言ではない
プログラムの解析結果をいかに保存するか?
Object Serialization
オブジェクトのデータをバト列に変換する
主な用途
デゖスク・ネットワークにデータを書き出す
データベースに保存する
簡単な方法: オブジェクト -> 木構造データに変換(XML/JSON など)
オブジェクトの各パラメータごとにノードを出力
構造を持った型のパラメータは、再帰的に処理
function toJSON(Object) { output “{“ for each parameter p in Object output “(p.name):” if p is primitive type // int, string, float, etc. output “(p.value)” else if p is array type output “ [”
for each element e in p { output(“, “) if e.index == 0; toJSON(e) } output “]”
else
toJSON(p)
output “}”
}
出力例
{“id”:1, “name”:”gene A”, … , “exon”:[{“start”:…, “end”:…}, {“start”:…, “end”:…} ] }
28
class Gene { int id string name string chr int start int end List<Exon> exon }
class Exon { int start int end }
Lecture - Biological Databases: Structured Data Processing
スキーマを使ったオブジェクトの直列化
JSONに出力する形式
オブジェクト毎に、毎回同じパラメータ名を出力しており冗長
よりコンパクトに表現できないか?
オブジェクトの型定義からスキーマを構成
Gene (id:int, name:string, chr:string, start:int, end:int, exon:Exon*)
Exon (start:int, end:int)
パラメータ名を出力せずにデータを連結したレコードを作成
| type id | param1 | param2 | … | param k |
各パラメータは型ごとにシリゕラズ
int -> 4 bytes or 可変長整数表現 (固定長レコード)
string -> 文字列の長さ、バト列 (可変長レコード)
配列 -> 配列の長さ、各エントリのレコード …
参考
serializationのためのツールはいくつかある
Google Protocol Buffers, MessagePack, Boost::Serialize、Ruby on Railsなど
29
class Gene { int id string name string chr int start int end List<Exon> exon }
class Exon { int start int end }
Lecture - Biological Databases: Structured Data Processing
Large Dataのデータベース化
WIGデータ
(ゲノム中の座標, value) の組がゲノムワドに存在
ヒトゲノムなら30億エントリが必要
これだけのデータをさばけるRDBMSは少ない
ゲノムをビンに分割
例えば、ヒトゲノム30億塩基を10kサズのビンに分割すると、30万エントリで済む
(bin start, [bin start, bin start + 10k) の区間にあるグラフデータ) の形でエントリを保存
bin startの列に対して、B+-treeの索引を構築
グラフのデータは圧縮するとさらに効率的
gzip (圧縮率が良いが、速度がやや遅い)
snappy (圧縮率は悪いが、伸長速度が高速。データベース向き)
デゖスクI/Oのコストと、CPUを使う圧縮・伸長計算コストとのトレードオフ
現在デゖスク(HDD, SSDなど)では、圧縮するのが良い戦略
30
Lecture - Biological Databases: Structured Data Processing
木構造を持ったデータをフラットに表現する
木構造データを敢えてテーブルで表現することで、SQLによる検索が行えて便利な場合がある
練習問題
上のデータを、geneとexonの2つのテーブルを用いて表現せよ
geneが複数ある場合でも、geneとexonの対応関係が正しくなるように注意
それらのテーブルを用いて、各gene中のexonの数、exonの長さの平均値を求めるSQL文を作成せよ
group by文を使うとよい。Excelのピボットテーブルも同等の機能
31
object
id:1 start:11617 end:16804
array
exon
object
start:11617 end:11589
object
start:16472 end:16804
Gene
Exon Exon
Lecture - Biological Databases: Structured Data Processing
区間の交差判定
問題: n本のショートリードを重なりがないように並べよ
32
Lecture - Biological Databases: Structured Data Processing
33
区間の交差判定
ゲノム情報処理で頻出する問題
重なっているショートリードを列挙する
区間が遺伝子領域と重なっているか?
単純な実装
全リードとの交差を調べる O(N)
区間を2次元にマップする
区間の始まりをy軸、区間の終わりをx軸とした2次元平面上の点に区間を対応させる
例えば、区間L2 [4, 6]と交差する区間は、左図の、[4, N] × [-∞, 6]の領域を調べれば数え上げられる
Priority Search Treeで高速に列挙できる
end
start
0
1 8 2 3 4 5 6 7
L1 L2
L4
L5
L3
1 8 2 3 4 5 6 7
1
8
2
3
4
5
6
7
(4, 6)
L1
L2
L3
L4
L5
Lecture - Biological Databases: Structured Data Processing
34
Priority Search Tree
X
Y
0
Priority search tree
rootは最小のyの値を持つノード
各ノードに対応する区間を[i, j]とすると
左の子は区間 [i, floor((i+j)/2)]
右の子は区間 [floor((i+j)/2 )+1, j] に対応する。
各ノードは、それぞれの領域で最小のyの値をもつノードとなる
性質
x方向にはbinary search tree
木の高さは、log n
y方向では、親ノードのyは必ず子ノードのyより小さい (heap)
記憶容量 O(n)
構築時間 O(n log n)
[x1, x2] x [0, y] の範囲のrange query
O(log n + k) で検索できる
kは領域に含まれるノード数
[x1, x2] の区間に含まれる部分木は高々2log n個
34
Lecture - Biological Databases: Structured Data Processing
まとめ
木構造データは汎用的
XML/JSON/Object その他、種々の生物情報のデータフォーマットを含む
木構造データを関係データベースに格納する手法
interval encoding / ORDPATH
木構造データの処理
構文解析
ストリーム処理
オブジェクトへのマッピング (Deserialization)
オブジェクトのSerialization
巨大データの分割
木構造データを、フラットに表現する
区間データの扱い
Priority search tree
遺伝子領域、ゲノム上のゕノテーション、リードゕランメントの交差判定
Lecture - Biological Databases: Structured Data Processing
発展:木構造の組み方には任意性がある
遺伝子、ショートリードなど同じ染色体上にあるものが多い
chrの情報は上位のノードに配置する方が、小さなデータとして表現できる
しかし、オブジェクトの定義と、木構造の階層が一致しなくなる
構造の組み方が多様な場合
どのようにオブジェクトにマッピングするか?
オブジェクトに対応するノード数最小の木構造を生成するゕルゴリズム
36
object
id:1 start:11617 end:16804
object
id:1 start:11617 end:16804
object
chr:22
array
gene
class Gene { int id string name string chr int start int end List<Exon> exon }
top related