一 引言

1.1編寫目的

進行該測試以及撰寫此報告有以下幾個目的

1.通過對測試結(jié)果的分析，得到對軟件質(zhì)量的評價；

2.分析在Illumina測序平臺下，MapSplice能夠獲得最大junction數(shù)目以及mapping率的參數(shù)；

3.分析在ionproton測序平臺下，MapSplice能夠獲得最大junction數(shù)目以及mapping率的參數(shù)；

4.嘗試找到參數(shù)與測序長度的經(jīng)驗性關系。

1.2背景

MapSplice是一個RNA-seq數(shù)據(jù)分析工具，其核心程序是bowtie.可以快速的確認exon-exon剪切拼接。主要功能和Tophat差異不大。

與Tophat不同的是，MapSplice并沒有針對某一種測序平臺而開發(fā)，所以對于75bp以下的短序列以及75bp以上的長序列reads都可以使用。目前，全球最大的癌癥研究項目TCGA（The Cancer Genome Atlas）正在主要推崇使用這個軟件。

Ionproton屬于二代測序中較新的平臺，可以認為是二點五代測序平臺，其測序長度平均在100個bp以上。目前我們公司使用的就是這個平臺的進行二代測序分析。

鑒于之前使用Tophat進行參數(shù)優(yōu)化以后發(fā)現(xiàn)結(jié)果并不是很理想，所以決定跟換軟件進行測試，尋找更好的結(jié)果。因此，提出此次工作內(nèi)容，探索更好的參數(shù)配置，提高mapping率以及junction數(shù)目。

1.3用戶群

主要讀者：公司研發(fā)部，公司管理人員。

其他讀者：項目及銷售相關人員。

1.4 數(shù)據(jù)對象：

1.5 測試階段

軟件測試

1.6測試工具

Samtools version：0.1.18；

IGV version：2.3.18；

Awk；

1.7 參考資料

MapSplice userguide

Wang K, Singh D, Zeng Z, et al. MapSplice: accurate mapping of RNA-seq reads for splice junction discovery[J]. Nucleic acids research, 2010, 38(18): e178-e178.

Trapnell C, Pachter L, Salzberg S L. TopHat: discovering splice junctions with RNA-Seq[J]. Bioinformatics, 2009, 25(9): 1105-1111.

二 測試概要

關于MapSplice參數(shù)測試從2013年9月19日開始到2013年9月26日結(jié)束，共持續(xù)7天，一共25個測試用例。

主要測試內(nèi)容如下：

1. 軟件安裝以及依賴性測試。

2. 文件分割以后查找junction數(shù)目以及不進行分割查找junction數(shù)目的差異大小，能否接受，為今后并行化文件回帖提供依據(jù)。

3. Segment參數(shù)進行優(yōu)化工作。

4. 針對Illumina測序平臺數(shù)據(jù)以及ionproton測序平臺數(shù)據(jù)的mapping能力差異。

5. 簡要測試MapSplice檢測融合基因的能力

2.1工作計劃進展

測試內(nèi)容	計劃開始時間	實際開始時間	計劃完成時間	實際完成時間	工作完成情況
軟件安裝	2013年9月19日	2013年9月19日	2013年9月19日	2013年9月23日	本地安裝受阻，服務器端安裝正常。
軟件依賴性查找	2013年9月24日	2013年9月24日	2013年9月24日	2013年9月24日	順利
不同測序平臺回帖能力	2013年9月24日	2013年9月24日	2013年9月24日	2013年9月24日	順利
文件分割與否回帖差異	2013年9月25日	2013年9月25日	2013年9月25日	2013年9月25日	順利
Segment參數(shù)優(yōu)化	2013年9月26日	2013年9月26日	2013年9月26日	2013年9月26日	順利
融合基因檢測	2013年9月26日	2013年9月26日	2013年9月27日	2013年9月27日	順利

2.2測試執(zhí)行

此次測試嚴格按照項目計劃和測試計劃執(zhí)行，按時完成了測試計劃規(guī)定的測試對象的測試。針對測試計劃制定規(guī)定的測試策略，依據(jù)測試計劃和測試用例，將網(wǎng)絡數(shù)據(jù)以及我們觀測的關鍵參數(shù)進行了完整的測試。

2.3測試用例

2.3.1功能性

1.測試主要實現(xiàn)，包括較高的mapping率以及較多的junction數(shù)目。

2.測試junction數(shù)目與文件分割與否的相關性大小。

三 測試環(huán)境

3.1軟硬件環(huán)境

四 測試結(jié)果

4.1 軟件安裝

安裝中，我們使用的軟件版本是MapSplice 2.1.5。在本地進行測試的時候由于當時未知的軟件依賴關系，并沒有安裝成功。軟件提示報錯為本地bowtie沒有在系統(tǒng)中找到，于是在本地安裝了與軟件要求對應的bowtie 0.12.7 。本地可以使用bowtie，但是MapSplice仍然報這個錯誤，于是放棄在本地進行安裝。在服務器的安裝很順利，很快就測試通過。

4.2文件分割mapping與未分割mapping

進行文件分割運行的最主要的考慮是為了嘗試能否進行分布式的計算，所以我們在這一部分的工作中將文件分割成4份分開進行運算，然后將這4個文件運行出的junction數(shù)目相加比較與未分割情況下的junction數(shù)目差異。為了得到更加準確的效果，在本次測試中，我們使用了3個測序深度的ionproton測序平臺得出的reads，分別是20萬個reads，200萬個reads以及整個文件（一共33926644個reads）進行分析。文件統(tǒng)一分割為4個文件。測試結(jié)果如下：

表 20萬個reads運行所得結(jié)果及差值

表 200萬個reads運行所的結(jié)果及差值

表 所有reads運行所有的結(jié)果及差值

通過上述結(jié)果可以知道分開以后與未分開時相差大約5%以上（占未分開的junction數(shù)目）所以可以認為并不是很適合將reads分開以后進行mampping。

4.3 segment參數(shù)優(yōu)化

由于在Tophat參數(shù)探索的過程中，我們通過分析發(fā)現(xiàn)在所有參數(shù)中，segment_length是對junction影響最顯著的參數(shù)，所以我們在對MapSplice進行分析時，主要也是分析這個參數(shù)。在測試過程中我們發(fā)現(xiàn)當這個參數(shù)大于30的時候就會報錯，而軟件參數(shù)中segment_length的下限值限定為18，軟件說明中推薦對于50bp以上的reads文件，建議使用25這個長度，而根據(jù)文獻中算法設計的思路可以知道，當這個數(shù)據(jù)越大的時候，整個junction的敏感度就會越低，而對應的程序運行時間就會越短，與之相反，當這個數(shù)據(jù)越小的時候，整個junction的敏感度就越高，而對應程序的運行時間就會越長。在本次測試中，我們對這個數(shù)值從18到28進行了抽樣實驗，實驗結(jié)果如下：

表 segment_length數(shù)值與junction數(shù)目關系表（以上ratio省略%）

從上述表格中可以看出對于不同的segment_length而言，junction數(shù)目的百分比確實是有變化的，總體趨勢是segment_length越長，junction的數(shù)目就越少，由于RNA-seq回帖率與測序深度正相關的關系，我們可以推測對于更多數(shù)目的數(shù)據(jù)而言，這個數(shù)值會有提高。在數(shù)據(jù)記錄中，我們同時也記錄了任務運行的總時間，與文獻符合的是，segment_length長度越短，運行時間就會越低，而且我們發(fā)現(xiàn)時間增長的速度是很夸張的。當segment_length為28的時候，運行時間是12分鐘12秒，而當segment_length為18的時候，運行時間是1小時7分45秒?？梢钥闯鲞@個時間差是很大的。綜考慮我們認為如果有需要，取20到22都是不錯的選擇。

4.4融合基因檢測參數(shù)測試

本實驗中，我們主要檢測了檢測融合基因以及檢測junction之間的關系。我們的檢測了在尋找融合基因情況下，junction數(shù)目的變化，全部結(jié)果如下所示：

指定參數(shù)non_canonical_fusion	500000
seg_length	18	19	20	22	28
junction_numbers	39786	40269	40203	39450	未測試
threads	20	20	23	20	未測試
time(min)			13:34
按照>10KB都過濾掉
	18	19	20	22	28
junctions_filted	36952	37399	37361	36621	未測試
junction_numbers	39786	40269	40203	39450	未測試
conseved_ratio	92.87689	92.87293	92.93088	92.8289
ratio	7.3904	7.4798	7.4722	7.3242
按照<20bp的都過濾掉
	18	19	20	22	28
junctions_filted	39775	40257	40191	39440	未測試
junction_numbers	39786	40269	40203	39450	未測試
conseved_ratio	99.97235	99.9702	99.97015	99.97465
ratio	7.955	8.0514	8.0382	7.888
按照<20bp以及>10Kb的都過濾掉
	18	19	20	22	28
junctions_filted	36941	37387	37349	36611	未測試
junction_numbers	39786	40269	40203	39450	未測試
conseved_ratio	92.84924	92.84313	92.90103	92.80355
ratio	7.3882	7.4774	7.4698	7.3222
mapping_ratio	41.7	41.8	41.54	40.92	未測試
real_junction_ratio	17.71751	17.88852	17.98219	17.89394	未測試

由于之前的測試，我們考慮的參數(shù)中已經(jīng)放棄了segment_length等于28這個參數(shù)，所以在這一步中，為了節(jié)約計算資源，我們并沒有計算segment_length等于28情況下的測試數(shù)據(jù)。從上表中可以很明顯的看出當檢測融合基因時，整體數(shù)據(jù)的mapping率明顯下降。因此導致的real_junction_ratio數(shù)目的提升并不能認為可能是真的提升。

五．測試結(jié)論與討論

5.1平臺差異

通過查閱已經(jīng)有的資料，我們知道Illumina測序平臺和ionproton平臺最直觀的差別在于后者的平均測序長度比前者長；在我們測試的例子中，Illumina的測序長度在50-97個bp之間，而ionproton的測序長度在50到235個bp之間。從此可以看出兩者的最合適參數(shù)應該是有差別的。通過上一次tophat與這一次MapSplice的比較，我們發(fā)現(xiàn)，無論如何提高tophat的參數(shù)，我們都很難接近MapSplice使用默認參數(shù)下的junction數(shù)目，所以我們認為對于公司ionproton測序平臺，我們使用MapSplice會更加適合。而在我們的測試結(jié)果中，對于Illumina測序平臺測試時，進行單端實驗的結(jié)果如下：

表 ionproton與Illumina單端結(jié)果計算junction百分數(shù)

5.2文件分割測試

通過這個測試的結(jié)果，我們可以看出分割前后運行得出的junction數(shù)目差距為5%（相比未分割的情況）以上，并且這個數(shù)目隨著我們的測序深度的提高而提高。所以從這個結(jié)果而言，我們認為不適合將文件分割進行處理。

5.3segment參數(shù)測試結(jié)果

在測試實驗中，我們發(fā)現(xiàn)segment_length參數(shù)從28向18變化的過程中，總體趨勢是由少變多變少，整體趨勢圖如下：

圖 segment_length與junction_ratio關系圖

從上圖中可以看出大約在20到22的時候是最好的。在官方說明文檔中，作者推薦當序列長度大于50的時候推薦使用參數(shù)25。下表是segment_length與測試時間之間的關系：

圖 segment_length與running_time關系圖

上圖中，我們計算時間是使用實際計算總時間乘以運行的CPU數(shù)目。其中在22這個長度上時運行的CPU數(shù)目是20個，所以時間有所波動，總體而言來看，在長度為20到28之間時間變化還是可以接受的，然后當長度繼續(xù)下降的時候，時間就開始指數(shù)級的上升的，這一點可以從圖中看出。

所以，綜合取舍junction率以及運行時間，我們認為使用默認參數(shù)是可以接受的，但是使用20至22也許會有更好的結(jié)果。

5.4融合基因檢測參數(shù)設置

在我們的測試數(shù)據(jù)中，我們可以很明顯的看出在各個segment_lengh情況下，mapping率都有下降，相比不做這一步檢測，mapping率下降了至少30%，我們一開始認為是把部分junction的數(shù)據(jù)被認為是融合基因，當我們檢測的時候才發(fā)現(xiàn)實際情況與我們的預測是不符合的。軟件找到的融合基因數(shù)目十分少，并且基本都是跨染色體的。因此我們提出了新的想法，程序在同時進行查找junction以及融合基因的時候，為了確保計算時間不會超過單查找junction時的時間太多，并且由于查找融合基因是比較消耗計算資源的，所以程序在查找junction的時候并沒有分配過多的資源，導致了更多的reads沒有被程序mapping上去，因此我們在此認為實際應用中，應該將查找融合基因以及查找junction分成兩步分開進行，如何能夠使得兩步的資源能更加節(jié)省，將是我們接下來的工作。

5.5 測試中的問題

在測試過程中我們發(fā)現(xiàn)了一個有趣的情況，如下圖所示：

圖 不同segment參數(shù)下查找junction數(shù)目的能力

上圖中，首先可以看到在參考基因組中這個部分是有junction的，中間的四個條帶從上到下依次是長度為18,19,22,28四個參數(shù)情況下的對應這個位置的回帖情況，可以很清楚的看到，在參數(shù)為18,28的時候是找到了這個區(qū)域的，但是在中間參數(shù)19,22的情況下，并沒有回帖到這個位置，由于這個部分并不是很短，我們可以認為這個部分在染色體上是唯一的，所以排除了這兩個參數(shù)情況下回帖到其他地方的可能性，確定這個部分對應的reads并沒有回帖上去。因為并不是當segment_length變小或變大的情況下才逐漸出現(xiàn)的，所以可以認為是隨機的結(jié)果，這暗示我們?nèi)绻骋淮蔚慕Y(jié)果不是很理想的情況下可以通過重復或更改參數(shù)重復來提高junction數(shù)目。

另外在測試中，我們找到了支持segment_length越短，查找的敏感性就越明顯的圖像證據(jù)，如下圖所示：

圖 不同segment_length下查找junction的敏感性

上圖中可以看出，在參考基因中，這個部分是有junction的，而在segment_length為19,22,28的時候，都沒有找到回帖上，我們認為這個結(jié)果對于文獻中提到的segment_length越短，敏感性越強這個說法。

六．測試總結(jié)

1.由于MapSplice在我們已經(jīng)配置好的服務器上能夠很流暢的直接使用，所以對于我們的hdfs而言，我們認為可以直接裝配使用。對于本地的軟件使用的可能需要復雜的軟件支持，由于在這一步我們花費了部分的時間，所以在此并沒有進行詳細的尋找軟件依賴關系。

2.綜合考慮junction查找能力以及運行時間，我們認為在一般情況下，默認參數(shù)就是可以的了。當有特殊需求時，可以考慮使用參數(shù)在20到22內(nèi)的任意值。

3.對于Illumina的單端數(shù)據(jù)而言，我們認為使用Tophat的效果比使用MapSplice的效果好，對于Illumina的雙端數(shù)據(jù)而言， 對于ionproton的數(shù)據(jù)而言，我們認為使用MapSplice的效果遠比使用Tophat好，不論是mapping率還是junction數(shù)都顯示使用MapSplice更加合適。

4.我們認為查找junction以及查找融合基因這兩個工作應該分開進行。由于時間關系，我們并沒有查找弱化junction數(shù)目查找情況下，對融合基因查找的影響。

5.鑒于MapSplice查找junction時存在一定幾率不能找全所有的junction，所以對于查找情況不好的數(shù)據(jù)，我們可以通過簡單的重復運行或更改參數(shù)運行來嘗試提高這個數(shù)據(jù)。

6.我們測試結(jié)果顯示回帖操作并不能通過將源文件分割分別回帖來實現(xiàn)分布式運行。

七．測試中使用的命令，參數(shù)及說明

測試的結(jié)果在/media/hdfs/nbCloud/public/test/Illuminaandionproton0906/MapSplice-v2.1.5文件夾中下。

測試中統(tǒng)計junction數(shù)目的命令為

awk -F"\t" '{if((($3-$2)>20)&&(($3-$2)<10000)){total+=$5}}END{print total}' ./split4_test_segment_length20_non_canonical/junctions.txt

分割文件使用的perl文件見附件

使用MapSplice命令如下

Python MapSplice1.py  -c /media/hdfs/nbCloud/public/nbcplatform/genome/human/hg19_GRCh37/ChromFa/sep \

-x /media/winE/genome/human/hg19_GRCh37/ChromFa/all/hg19_GRCh37_bowtie_index -o ./split4_test_segment_length25/ -1  ../split4.fq  -p 10 -s 25

Mapsplice參數(shù)說明

其中重要的參數(shù)是粗體表現(xiàn)。

必須參數(shù)：

-c 序列文件的文件夾，注意：文件必須是fasta格式，后綴是.fa文件。

-x       bowtie_index指定的路徑及前綴。注意：只支持bowtie1的索引，并不支持bowtie2的索引。如果沒有設定這個選項，或者指定的路徑?jīng)]有對應的索引，則會在結(jié)果輸出路徑下自動建立索引。

-1 FATSA格式或者是FASTQ格式。對于雙端的回帖，這對應編號為1的文件。多個文件用逗號隔開，文件名之間不能有空格

-2 FATSA格式或者是FASTQ格式。對于雙端的回帖，這對應編號為2的文件，并且兩個文件順序必須一致。多個文件用逗號隔開，文件名之間不能有空格

-p/--threads 線程數(shù)目，默認是1；

-o/--output 指定Mapsplice輸出文件夾，默認是./mapsplice_out/這個文件夾 沒有寫清楚輸出文件的具體樣式，譬如輸出文件前綴，文件名，輸出文件類型

--qual-scale 輸入文件的打分類型。默認是自動尋找，可以指定如下：phred33,phred64,solexa64

--bam 默認的輸出文件時SAM格式的文件，通過這個選項可以指定輸出BAM文件。

--keep-tmp 保存中間文件。

-s/--seglen 指定segment_length,通常默認是25，我們測試的結(jié)果暗示這個結(jié)果在20到22都是不錯的。最小值是18，目前測試的結(jié)果暗示最大值不要超過30.

--min-map-len 軟件只會記錄完全匹配或者匹配數(shù)目不小于這個參數(shù)的序列。默認參數(shù)是50.

-k/--max-hits 每個read的最大匹配數(shù)，大于這個數(shù)的序列都丟棄掉。默認參數(shù)是4.

-i/--min-intron 最小intron長度，默認是50

-I/--max-intron 最大intron長度，默認是300000

--non-canonical 同樣也搜索非經(jīng)典的junction，我們測試的結(jié)果是這個參數(shù)能夠提高junction數(shù)目，但是并不明顯。

-m/--splice-mis 允許第一以及最后一個部分的最大不匹配數(shù)目。允許范圍是0-2，默認參數(shù)是1。

--max-append-mis 允許匹配高出錯率片段以及鄰近的低出錯片段不匹配的數(shù)目。默認參數(shù)是3

--ins 最大插入長度，默認是6，范圍是0-10

--del 最大刪除長度，默認是6，范圍是0-10

--fusion| --fusion-non-canonical 查找融合（非經(jīng)典）基因

--filtering junctions過濾級別，取值為1,2.默認是2；1代表更高的敏感度。2是標準過濾。