摘要：于是開始了長時間的排錯之旅。但是讀取的時候，出現(xiàn)問題一直報異常，而路徑并未出錯而且文件存在。由于錯誤定位在的構(gòu)造函數(shù)中上，便重新寫了一個類測試類的類，發(fā)現(xiàn)完全沒有問題，不是這出的錯誤。查看類構(gòu)造函數(shù)，其功能就是接受參數(shù)，調(diào)用的構(gòu)造函數(shù)。

在實現(xiàn)《Hadoop高級編程》一書中第9章的一個例子：將HBase用于圖片管理系統(tǒng)中，遇到了一個很讓人頭疼的問題：FileNotFoundException。雖然異常很簡單，但是文件確實存在那了。于是開始了長時間的排錯之旅。

該例子是將一堆小圖片文件合成一個大文件，并將各個小文件的位置索引存入HBase中。有一個DatedPhoto類，用于存放時間（long）以及圖片（byte[]）；還有一個PhotoLocation類，用于存放位置（long）、時間（long）和文件名（String）。位置是小文件在大文件中的字節(jié)位置，文件名是合成的大文件名，按序號命名。PhotoLocation類還提供了toBytes和fromBytes函數(shù)，用于將三種信息字節(jié)化后寫入HBase以及從HBase中讀出索引信息后還原成位置, 時間 和 文件名 信息。其余為寫入類，讀出類。整體非常簡單。

寫的時候完全沒有問題，文件成功生成，HBase中保存了索引。但是讀取的時候，出現(xiàn)問題：一直報FileNotFoundException異常，而路徑并未出錯而且文件存在。

這到底是怎么一回事呢？因為用的是SequenceFile中的內(nèi)部類Reader和Writer，而Hadoop 2.2.0的API中并沒有找到這兩個東西，便從源碼入手看看是不是這個類的問題。按照執(zhí)行流程過了一遍，任何問題都沒發(fā)現(xiàn)。由于錯誤定位在SequenceFile.Reader的構(gòu)造函數(shù)中getFileStatus上，便重新寫了一個類測試FileSystem類的getFileStatus類，發(fā)現(xiàn)完全沒有問題，不是這出的錯誤。

PhotoDataReader類是輔助讀出數(shù)據(jù)的類，被PhotoReader類調(diào)用。錯誤就定位在了該類的構(gòu)造上。查看PhotoDataReader類構(gòu)造函數(shù)，其功能就是接受參數(shù)，調(diào)用SequenceFile.Reader的構(gòu)造函數(shù)。輸出PhotoDataReader接收到的參數(shù)：file（String）、user（UUID）、conf（Configuration），三者都沒問題，但是出現(xiàn)了一個很奇怪的現(xiàn)象：

執(zhí)行

    System.out.println("file:"+ _file + "sadasdsasdssssss");

時，后面的那一串字符串居然不顯示！

看來問題就出現(xiàn)在_file參數(shù)上面。但是不管怎么輸出_file的值，的確就是我要的那個文件名的字符串。似乎這是個根本就不應(yīng)該出現(xiàn)的問題。然后輸出_file的字符串長度，明明只有1個字符的文件名，顯示的長度為112！看來問題就在這！

問題究竟出現(xiàn)在哪呢？繼續(xù)向上找，發(fā)現(xiàn)參數(shù)是PhotoReader傳給它的；PhotoReader又通過讀取HBase中的索引記錄得到后用PhotoLocation的fromBytes函數(shù)得到…… fromBytes函數(shù)？其實現(xiàn)的是將一個包含索引位置 、時間 與 文件名的128位字符數(shù)組分開然后生成三個值。索引位置與時間均為long型，字符數(shù)組均為8位，沒有問題。但是文件名為字符串，合成字符數(shù)組時用的length函數(shù)，但是還原時就把除索引位置與時間的16位排除后剩下的112位全部用來生成字符串了！生成字符串用Bytes.bytes()和 new String均無法生成原長度的字符串。

既然知道了原因，解決也好辦了。要么設(shè)個長度位，要么用定長字符串，要么干脆在HBase分開存儲?？磥恚袝r候報錯，問題往往出現(xiàn)在細(xì)節(jié)上，仔細(xì)思考每一處細(xì)節(jié)，可以減少很多的排錯時間。至少這次我花了不少時間。