2011年度生物データベース論　2日目木構造データ

生物データベース論
Lecture - Biological Databases: Structured Data Processing

 講義：生物データベース論２日目
 2011年9月14日
 担当：斉藤太郎（森下研究室） leo@xerial.org

 構造を持ったデータの扱い
 テーブル構造データ（有田先生）
 関係代数、関数従属性（FD）、SQL
 木構造データ（今回の講義の内容）
 XML, JSONなどが有名
 生物のゕノテーション、ゲノムデータ、プログラミング言語で使うオブジェクトなど、あらゆる種類のデータがここに
含まれる
 講義の内容
 木構造データの例
 XML, JSON, その他ゲノム情報処理で使われるデータ形式について
 木構造データのデータベース作成
 木構造データの索引 (interval encoding, ORDPATH)
 木構造データの検索
 親子、祖先子孫関係の判定
 木構造データの字句解析・構文解析（JSONを例に）
 木構造データのストリーム処理
 木構造データの直列化（Serialization）とその復元（Deserialization）
 木構造データを敢えてフラットに表現する
 テーブルに分解（データモデリング）、木構造データでの関数従属性

1

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通信
染色体名のリストをDASから、XMLで取得した例
 リモートのサーバー上から
メールのデータをブラウザに送信する
 GMailのメール表示が高速なのは、あらかじめメールのデータをブラウザに読み込ませているため
 XMLの中に、serialize (後で説明）されたオブジェクトデータを埋め込んで通信している

2

XMLデータは木構造を持つ

customer <customer id=“J-001”>
<name> Jeffrey </name>
name id <city> New York </city>
“Jeffrey” <order oid=“3”>
“J-001”
<item> Notebook </item>
city <date> 2002/02/11 </date>
“New York” order order <num> 50 </num>
</order>
oid oid <order oid=“1”>

item “3 “1” <item> Blank Label </item>
num
” <date> 2002/02/10 </date>
item num
“Notebook” “50 <num> 100 </num>
” “100”
date “Blank Label” <status> delivered </status>
status </order>
“2002/02/13” date “delivered” </customer>

“2002/02/10”

3

ゲノム情報処理で使われる木構造データフォーマット

 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

ショートリード用のデータフォーマット

 FASTQ フォーマット
 リード名、塩基配列、+、各塩基のQuality valueのASCII値
@SAMPLE1.L1.5449
 次世代シーケンサー ATGGAGGTCATCACCTACAAGCTCGTCACACCATCCGTCGTCTCTGAACGTCTGAAGGTTCGTGCTTCATTGGCCA
+
Illumina Hiseq2000では、 IIIIIIIHIIIIIIIIIIIIIIIIIIIIIIIIIHIIIGIIEHHHFHHIIIFIHHGGHHDEIGDGGGEGEGEDDGFI
1runで数億本ものリードが読まれる @SAMPLE1.L1.5450
GTTAAAAAGCCCGTAGTTGGATCTAGGTTACGTGCCGCAGTTCGCAATTTGCGTCAACTGTGGTCGTGACTTCTAA
+
HHHHHGGHHHHHHHHHHHHHDHHHHHHHHHHHDHHHHHHHBGGEGFFHHHHHHGHEEFHHBHF<EECE@BECBEA@
@SAMPLE1.L1.5451
CAGAATGACTGTCGCTCACATGTGGTACGATGAAACCATCCATGAGTGTGATACCACCGAAACTCAAACCAGCCAG
+
 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

5


SAMフォーマットで表現されたショートリードゕラ゗ンメントの可視化の例
UTGB (University of Tokyo Genome Browser) より http://utgenome.org/

6

木構造データをデータベースに格納する

 様々なフォーマットのデータがあるが、どれも木構造として考えることができる

 木構造データのデータベース化
 用途によって様々なゕプローチがある

 木構造専用のnative databaseを使う、あるいは自作する（今回は説明しない）
 既存のnative XML databaseを利用
 あまりこれといったものが見当たらないのが難点

 関係データベース relational databaseに格納する
 木構造をテーブル型に変換する
 interval encoding
 ORDPATH

 木構造をオブジェクトにマッピングする
 木構造データの構文解析ー＞ストリーム処理－＞オブジェクトへのマッピング
 オブジェクトー＞テーブルに分解－＞RDBに保存

 あるいは、オブジェクトをserialize（直列化。バ゗ナリー形式に変換）してcolumnに保存する

7

木構造の区間表現

 Interval Encoding
 木構造を枝を使わずに表現する手法
 各ノードを(start, end)の区間で表す
10 1000
 区間の包含関係
20 100 120 190 230 300  Ancestor－Descendantの関係に対応
 Parent-Childの対応を見るためには、階層の深さ
(level)の情報も保持する

 タグの種類ごとにノードを分類しておけば、
特定の子孫のノードをすばやく検索できる
Root
level 0  例
(10, 1000)
 Root以下のCノードの検索
 Aノードの子孫であるDノードの検索
level 1 A B A
(20, 100) (120, 190) (230, 300)
 利点
 SQLで検索できる
C D C  startの値が、深さ優先順になっている
level 2
(30, 35) (40, 50) (240, 260)  B+-treeに格納しやすい
 endの値は、post orderになっている

 欠点
 ノードを追加していくと、区間が枯渇してしまう

8

更新に強い木構造のencoding

Root  ORDPATH
1  更新に対応したラベルの付け方
 各ノードに対し、階層上での位置がわかるラベルを付ける

A B A
1.1 1.3 1.5  ラベルの付け方
 兄弟ノードに奇数を左から順に割り当てていく
 子のラベルは
C D C  「親のラベル . 兄弟間でのラベル」の形式で連結する
1.1.1 1.1.3 1.5.1  親のラベルがprefixになる
 親子関係、祖先ー子孫関係の判定がラベル同士の比較で可能
 ORDPATHの連結の段数が、ノードの深さに対応
 新しいノードを挿入するとき
 挿入したい位置に奇数がもうないときは、間の偶数を一
Root
段はさんで、奇数を１から割り振る
1
 ノードの深さを調べる場合、偶数の段はスキップする

A B A
1.1 1.3 1.5  ORDPATHの利点
 ラベルの付け方が明確（区間表現は任意性がある）
 更新が容易
C C D C  ノード間の全順序が保たれる
1.1.1 1.1.2.1 1.1.3 1.5.1  深さ優先探索順
 次に説明するprefix free encodingで、B+-treeに格納
 ORDPATHの欠点
 階層が深くなると、各ノードのラベルサ゗ズが大きくなりす
ぎる
 SQLだけで階層構造の検索が記述できない場合がある
9

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

木構造のデータをrelational databaseに格納する

 木の各ノードを１レコードに対応させる

 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

参考：B+-treeを使って多次元データを検索する

 空間充填曲線（space-filling curve）を用いると
XMLの(start, end, level, tag) など多次元の情報
を１つのB+-treeで検索できるようになる
 XMLの場合には、z-curveが使いやすい
 bit-interleave 操作で空間充填曲線上の゗ンデックス(z-
order) が計算できる
 z-orderをキーにして、B+-treeに各ノードのデータを格
納
 (start, end)の区間を2次元にマップすると
 子孫ノードは右下、祖先ノードは左上の長方形領域に包含
される
 B+-treeのリーフを飛び飛びにscanして、多次元
領域検索を行える

multidimensional range query
z-curve and z-order
end

start bit interleave function

12

木構造データの汎用性

 BED, WIG, FASTQ, SAMのデータはすべて木構造で表現できる
 それなのに、なぜXML以外のフォーマットが使われるのか？

 現実的な課題
 処理速度
 XMLより、タブ区切りデータの方が速く読み書きできる
 データをコンパクトに表現できるか？
 XMLは次世代シーケンサーのように大きなデータのやり取りには全く使われていない
 記述、出力のしやすさ
 タブ区切り形式でデータを出力するのは簡単。ただし、同時に含めるべき情報（サンプル名、更新履歴、どのような処
理で生成されたデータなのか、などの重要な情報）が欠落している弊害も
 構文解析のしやすさ
 lexer/parserを書く必要があるか、splitするだけで使えるか

 共同作業のしやすさ
 様々なプログラミング言語で扱えるか？（仕様がシンプルだと、実装者が現れやすい）
 XMLは複雑な仕様にも関わらず、時代の波にうまく乗れたため、各言語で構文解析器が実装されてきた（1997年以降～）
 可読性
 フラットなフォーマットだと、一画面に情報を詰め込みやすい
 コマンドラ゗ンでの扱いやすさ

 この講義での目的
 様々なフォーマットで記述されていても、すべて木構造データとして汎用的に扱う枠組み
13

参考：コマンドラインでのデータ処理の例

 例１：SAM フォーマット中のリードの検索
 SAMフォーマットではデータがタブ区切りで記述されている

 マップされたリードのうち、mapping quality > 0 かつ、chr22にマップされたものを取り出す

 cat sample.sam | grep –v “^@” | awk ‘$5 > 0 && $3 ~ /chr22/’

 @で始まる行は、ヘッダ行なので取り除く

 BAM fileの場合
 catの代わりに、samtools viewコマンドを使う

 例２：特定の名前のリードを、gzip圧縮されたfastqフゔ゗ルから取り出す
 zcat sample.fastq.gz | grep –w –A 3 “SAMPLE1.L1.5449”

 -w は単語単位でのマッチ、-A 3は、マッチした箇所の後の3行分まで表示するオプション

 例３：タブ区切りデータのテーブルの第4列に含まれる値の種類を調べる
 cat input.tab | awk ‘{ print $4; }’ | sort | uniq
 awk（あるいはcut）で4列目のデータを取り出し、ソートして重複除去をおこなう

14

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

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

Lexerの実装

 テクニック
 string中以外の空白 [ ¥t¥n¥r]+ (white space token)は読み飛ばす

 正しくないデータが入力されたときのために、データをどこまで読んだか（行、列番号）を管理しておく
 改行文字 ¥n (LF. Unix), ¥r¥n (CR+LF, Windows), ¥r (CR, 昔のMac) が出現したら、行番号を+1
 改行文字が多様なのはタ゗プラ゗ター時代の名残
 LF: line feed （１行分紙を巻く）、CR: carriage return （行頭までヘッドを移動）

 字句解析では正規表現に対応するオートマトンを作って考える
 練習問題
 テキストフゔ゗ルの内容を入力文字列として受け取り、３種類の改行文字の出現を認識できる決定性オートマトンを作成せよ
 改行コードを認識する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

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

再帰下降型構文解析器 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

構文木の作成

 {“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 exon

array

object object

start:11617 end:11589 start:16472 end:16804

20

構文解析の参考資料

 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

ストリーム処理

 再帰下降型構文解析では難しいケース
 データが巨大な場合
 例：5千万エントリを含むSAMフゔ゗ル
 構文パターン SAM := Header* ReadAlignment*
 SAMオブジェクトの配下に、ReadAlignmentのオブジェクトが5千万個。構文木がメモリに収まりきらない
 参考：次世代シーケンサー (Illumina Hiseq2000) では、１runで数億本のリードが読める
 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

ストリーム処理の２つの形態：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

ストリーム処理の２つの形態：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

参考：MapReduce

 Proposed by Google [SOSP2004]
 An open-source implementation: Apache Hadoop
Split the data file into several chunks
 Map
 Apply the function f to each chunk of the input input file
records
 Function f produces (key, value) pairs
 Gives program semantics for parallelization
 The evaluation order of the records does not matter Map f f f
hashing records
 Reduce
 Receives the sorted output from the map function.
pull model chr1 chr2 chr1
 chr2 chr3 chr2
chr3 chr3

sort and merge …

Reduce chr1 chr2 chr3

output file (s)

25

木構造からオブジェクトへのマッピング

 プログラミング言語で使うオブジェクトと木構造を対応付ける（Object-Tree Mapping)

Gene
class Gene {
int id object
string name
string chr
int start
int end id:1 start:11617 end:16804 exon
List<Exon> exon
}

array
class Exon {
int start
int end Exon Exon
} object object


26

オブジェクトストリームの生成

class Gene { Gene
int id object
string name
string chr
int start
int end id:1 start:11617 end:16804 exon
List<Exon> exon
}

array
class Exon {
int start
int end Exon Exon
} object object

 startObject g = new Gene()
 key:id, value:1 g.id = 1 start:11617 end:11589 start:16472 end:16804
 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

オブジェクトの直列化

 生物情報学では解析の数だけオブジェクト（型定義）があるといっても過言ではない
class Gene {
 プログラムの解析結果をいかに保存するか？ int id
string name
string chr
 Object Serialization int start
 オブジェクトのデータをバ゗ト列に変換する int end
List<Exon> exon
 主な用途 }
 デゖスク・ネットワークにデータを書き出す
 データベースに保存する

 簡単な方法: オブジェクト -> 木構造データに変換（XML/JSON など） class Exon {
int start
 オブジェクトの各パラメータごとにノードを出力 int end
 構造を持った型のパラメータは、再帰的に処理 }
 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

スキーマを使ったオブジェクトの直列化

 JSONに出力する形式 class Gene {
 オブジェクト毎に、毎回同じパラメータ名を出力しており冗長 int id
string name
 よりコンパクトに表現できないか？ string chr
int start
int end
 オブジェクトの型定義からスキーマを構成 List<Exon> exon
}
 Gene (id:int, name:string, chr:string, start:int, end:int, exon:Exon*)
 Exon (start:int, end:int)

class Exon {
 パラメータ名を出力せずにデータを連結したレコードを作成 int start
int end
 | type id | param1 | param2 | … | param k | }
 各パラメータは型ごとにシリゕラ゗ズ
 int -> 4 bytes or 可変長整数表現（固定長レコード）
 string -> 文字列の長さ、バ゗ト列（可変長レコード）
 配列 -> 配列の長さ、各エントリのレコード …

 参考
 serializationのためのツールはいくつかある
 Google Protocol Buffers, MessagePack, Boost::Serialize、Ruby on Railsなど

29

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

木構造を持ったデータをフラットに表現する

Gene
object

id:1 start:11617 end:16804 exon

array

Exon Exon
object object


 木構造データを敢えてテーブルで表現することで、SQLによる検索が行えて便利な場合がある

 練習問題
 上のデータを、geneとexonの２つのテーブルを用いて表現せよ
 geneが複数ある場合でも、geneとexonの対応関係が正しくなるように注意
 それらのテーブルを用いて、各gene中のexonの数、exonの長さの平均値を求めるSQL文を作成せよ
 group by文を使うとよい。Excelのピボットテーブルも同等の機能

31

区間の交差判定

 問題： n本のショートリードを重なりがないように並べよ

32

区間の交差判定

 ゲノム情報処理で頻出する問題
L5  重なっているショートリードを列挙する
L4  区間が遺伝子領域と重なっているか？
L1 L2 L3
 単純な実装
1 2 3 4 5 6 7 8
 全リードとの交差を調べる O(N)
start
 区間を2次元にマップする
 区間の始まりをｙ軸、区間の終わりをｘ軸とし
た2次元平面上の点に区間を対応させる
8

L3
7

(4, 6)  例えば、区間L2 [4, 6]と交差する区間は、左図
の、[4, N] × [-∞, 6]の領域を調べれば数え上
6

げられる
5

L2
4

L5  Priority Search Treeで高速に列挙できる
3

L4
2

L1
1

0 1 2 3 4 5 6 7 8 end
33

Priority Search Tree

 Priority search tree
Y  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)
0  構築時間 O(n log n)
X

 [x1, x2] x [0, y] の範囲のrange query
 O(log n + k) で検索できる
 kは領域に含まれるノード数
 [x1, x2] の区間に含まれる部分木は高々2log n個
34
34

まとめ

 木構造データは汎用的
 XML/JSON/Object その他、種々の生物情報のデータフォーマットを含む

 木構造データを関係データベースに格納する手法
 interval encoding / ORDPATH

 木構造データの処理
 構文解析
 ストリーム処理
 オブジェクトへのマッピング（Deserialization)
 オブジェクトのSerialization
 巨大データの分割
 木構造データを、フラットに表現する

 区間データの扱い
 Priority search tree
 遺伝子領域、ゲノム上のゕノテーション、リードゕラ゗ンメントの交差判定

発展：木構造の組み方には任意性がある

object class Gene {
int id
string name
chr:22 gene string chr
int start
int end
array List<Exon> exon
}

object object

id:1 start:11617 end:16804 id:1 start:11617 end:16804

 遺伝子、ショートリードなど同じ染色体上にあるものが多い
 chrの情報は上位のノードに配置する方が、小さなデータとして表現できる
 しかし、オブジェクトの定義と、木構造の階層が一致しなくなる

 構造の組み方が多様な場合
 どのようにオブジェクトにマッピングするか？
 オブジェクトに対応するノード数最小の木構造を生成するゕルゴリズム

36

2011年度生物データベース論　2日目木構造データ

Recommended

Recommended

More Related Content

Similar to 2011年度生物データベース論　2日目木構造データ

Similar to 2011年度生物データベース論　2日目木構造データ (20)

More from Taro L. Saito

More from Taro L. Saito (20)

Recently uploaded

Recently uploaded (6)