記一次處理bug經歷

    此次問題設計組件稍複雜，這裏大體說一下，我們是作過車信息查詢的。負責大數據模塊，有另一個組專門負責卡口，數據是由他們從各卡口抽取，而後插入到hbase中。再經過協處理器，將數據在寫進hbase以前發送到AMQ消息隊列，而後再消費創建solr索引，架構基本就是這樣的。

    基於這個，在元旦先後，數據出現點小問題。在元旦前高速卡口上的數據都是能夠經過solr查詢到的，而元旦以後的數據沒法查詢到的。當時發現問題時咱們自信的認爲確定是抽數據那塊出現問題了，後來經查，高速卡口的數據確實抽取到數據了。而後咱們逐個組件查找問題，首先咱們從hbase開始。因爲抽數據那邊不確卻的知道具體是那些數據丟失，只知道卡口有個編號這些編號都屬於高速上的，給咱們查詢帶來一些不便。我首先想到一個簡便的方法查詢，就是經過hive建一個外部表而後映射到hbase中我須要查詢的表，這裏能夠選擇新的只用映射幾個我須要知道的字段。

    映射語句以下：

CREATE EXTERNAL TABLE xx(
rowkey string, 
aa string, 
bb string) 
STORED BY 'org.apache.hadoop.hive.hbase.HBaseStorageHandler'
WITH SERDEPROPERTIES ("hbase.columns.mapping" = "
:key,
cf:aa,
cf:bb")
TBLPROPERTIES("hbase.table.name" = "table");

    而後，咱們就能夠通hive很容易就查出咱們須要的數據。

    在hbase這確實查到有高速卡口的數據。而後咱們有想到，消費AMQ中數據的程序是咱們本身寫的，可不多是在消費的時候出現問題。經查看咱們消費程序的日誌，沒有異常日誌。爲了確認不是在消費這個節點上出現問題，我現場在代碼中加入一個條件，若是遇到高速卡口的數據就日誌打印出來。重啓消費程序後，驗證結果是始終沒有高速卡口的數據出現。

    至此基本把問題縮小到協處理器和AMQ上。當時當時負責協處理器的同事當時不在，一時半會也沒法經過代碼驗證。而後只有硬着頭皮先去查看協處理器的日誌，這一看日誌，果然發現有問題，發現咱們RS有一節點上的日誌中有協處理器的幾條日誌，日誌是咱們本身定義的，大體意思就是協處理器在region上沒有掛載成功。問題是找到了，當時該如何解決。繼續在日誌裏面查找，發現有報找不到類的異常，缺乏AMQ的jar包，由於協處理器中是把數據發送到AMQ的，因此須要AMQ相關的包鏈接AMQ。而後咱們添加上AMQ相關包，重啓該節點上的RegionServer,OK了，solr中能查到高速卡口的數據。

    至此問題解決了，經過此次查找問題，一個是經驗積累。另外一方面也明白了，規範的重要性，之全部出現這樣的狀況時由於，元旦前添加了個節點，也就是出問題的節點。咱們有添加節點的文檔，可是很零散。一旦有遺漏就是給本身挖了一大坑，因此把流程規範是不可或缺的。