技術探討聯絡方式：QQ:272428027

由於本人第一次寫部落格，不喜勿噴，本文章內容只是一個hadoop遷移的心得體會，具體技術問題會在另一篇部落格當中詳細給出。
本週重點工作就是Hadoop叢集遷移，遷移過程中的各種坑都已經一一解決，在踩坑的過程中對於Hadoop的架構，元資料的儲存，配置檔案的組織等等都有進一步的瞭解，本週的心得有必要分享一下：
剛開始接到Hadoop遷移這個任務的時候自己心裡是沒有底氣的，因為自我感覺這項任務要比重新搭建一個新叢集更有挑戰，一開始自己制訂了兩套技術方案。一、叢集整體克隆 二、重新搭建新叢集，然後資料一一遷移。第一套方案一旦成功，資料遷移就會很輕鬆的完成，第二套方案肯定能成功，但是比較麻煩，為了省事，果斷先試試第一種方案，有句話說得好：“萬一一不小心就成功了呢”。叢集克隆以後發現各種遺留的配置資訊導致叢集根本就沒法正常啟動，還有各種莫名奇妙的問題，甚至克隆叢集有些自啟動的程序依然回去請求原來的叢集導致老叢集也執行異常，影響線上叢集這可就嚇死寶寶了，由於自己也不知道問題出在哪裡，只能先把機器關閉，後來自己通過埠排查，竟然發現有一個很難發現的程序在跟線上叢集通訊，kill 執行緒問題就解決了。
接下來就是存在資料庫裡面的配置資訊修改，剛開始自己都不知道這裡面設計到幾個資料庫，幾個資料庫裡面有幾張表，自己根本就無從下手，主要是因為自己不瞭解CDH的配置原理，一旦有一條記錄弄錯，就有可能導致機毀人亡，重新再來，謹慎再謹慎，從網上找了好多資料發現有用的庫有兩個，一個是ClouderManager 叢集、監控等等配置資訊，另一個就是hive源資料表metastrore資料庫，庫明確了，再就是表，首先到網上查沒一張表儲存的內容以及每個欄位的含義，配置資訊可能設計那幾張表，剛開始手動修改，後來索性就全down下來，檔案批量修改，然後在匯入到mysql，好久沒用mysql了，基本的命令還需要重新拾起，特別是每次遇到每次頭痛的遠端登陸許可權問題，又加上網路的各種限制，mysql遠端登陸只能試了一邊又一遍，因為自己根本就不確定是自己配置的問題還是網路的問題，還好這些問題都統統幹掉了。Hadoop元資料修改也就告一段落了。
走到這裡，叢集應該已經可以病殃殃的起來了，不過很不健康，各種監控報警，接下來就要一一解決這些告警，印象最深的就是ntp時間伺服器異常，按照網上資料跟以往經驗感覺ntp配置是沒有問題的，但就是不能通過檢測，這個問題困擾了兩天，後來看到有一個命令是這樣的“ntpdc -xx loopxxx”，一看到loop 我就聯想到輪詢自檢，會不會是localhost主機對映搞錯了，然後在/etc/hosts裡面配置了127.0.0.1 localhost對映，我的天啊，bug就這樣解決了，困擾了兩天，這個純屬巧合，踩了狗屎。至於解決告警還有很多坑就不一一列舉，方法可謂是卑鄙下流，無所不用啊。。。。。
接下來就到了Hive了，啟動hive，報錯，找不到hdfs服務，找不到hdfs服務，給出的節點資訊竟然是原來的namenode，這個就簡單了，肯定是那個配置沒有改過來，找了兩天，整整兩天啊終於找到了，就一個配置，差點讓我放棄了，原因很簡單，就是自己在本地配置了一個url覆蓋了CDH自己的配置資訊，真是天坑，歡天喜地的來到hive cli，執行一個簡單查詢沒啥問題，恩，很開心，接著來一個一個複雜的，突然發現跑不出結果，看日誌，結果網路不允許，網上找了半天也沒有找到結果，最終發現是hadoop的一個bug，需要重新修改原始碼打包覆蓋，但是苦於沒有修改class檔案的過人本事，這個問題遲遲不能解決，困了兩天，又兩天啊，要放棄了。眯了一小會，突然想到，hadoop報錯是因為空指標導致的異常，為什麼不繞過去，讓他不報空指標錯誤呢？然後就跟蹤了一下原始碼，自我感覺是因為一個配置沒找到導致的，然後趕緊去找這個配置項應該出現在那個配置檔案裡面，系統有幾個這樣的配置檔案，全都翻出來，結果出乎意料，真的又一個歷史配置還是線上叢集的資訊，長舒一口氣，這個問題又要解決了，驗證了一下，果然沒錯。就在下班前，任務算是圓滿解決，整整一週。
自我感覺本週最大的收穫就是排查問題的能力有所進步，每次想放棄的時候總會有驚喜，每次面對問題迷茫，徘徊過後都會有不一樣的收穫，苦逼的一週，收穫滿滿的一週。

技術探討聯絡方式：QQ:272428027