CDH大資料平臺實施經驗總結2016

2016年負責實施了一個生產環境的大資料平臺，用的CDH平臺+docker容器的方式，過了快半年了，現在把總結髮出來。

1. 平臺規劃注意事項

1.1 業務資料全部儲存在datanode上面，所以datanode的儲存空間必須足夠大，且每個datanode的儲存空間儘量保持一致。

1.2 管理節點/namenode對儲存空間要求不高，主要儲存各計算節點datanode的後設資料資訊，以3個datanode為例，每個datanode儲存2T的資料，namenode才耗費80G的空間。

1.3 由於hadoop有資料副本機制，預設為3個副本，因此datanode節點，系統盤做raid 1，資料盤做raid 0；namenode做raid 5,不管系統盤還是資料盤，都可以直接更換，保證資料不丟失；

1.4 計算節點datanode依靠的是數量優勢，除了儲存空間足夠大之外，對機器配置要求不高，但是安裝spark和impala的話對記憶體的要求較高，單節點2T的資料配置64G的單機記憶體有點吃力。

1.5 但是namenode要跟所有的datanode互動，接收處理各種請求，對機器配置要求較高，以的測試資料來看，namenode存放80G的後設資料時，64G的記憶體已經有點緊張了，開始使用交換記憶體了。

1.6 namenode和Secondary namenode需要各自獨立的兩個節點，即相互獨立部署，這樣即使namenode機器掛了，也可以手動從secondary namenode恢復一下。在Hadoop 2高可靠性下可以配置兩個namenode，保證一個namenode出現問題可以自動切換至另一個。

1.7 由於secondary namenode的是週期性的合併日誌檔案，因此單獨部署時對機器壓力較小，空間使用也只勉強是namenode的一半，因此可以把諸如hive/hbase等的伺服器端安裝在snn所在的伺服器上，這樣可以使機器資源得到最大化利用。

1.8 hdfs空間不夠開始報警，但是df –h命令下檢視就會發現其實空間餘額還有好幾T，這種情況是由於non dfs used空間膨脹導致的，non dfs used和remaining一起構成了hdfs的可用空間容量，兩者呈現此消彼長的關係。Non dfs used從字面理解來看是非hadoop檔案佔用的空間，實際上是某些檔案刪除之後，hadoop的元件沒有釋放對其引用導致的，從的情況來看，單個節點2T的資料執行一個月會產生600G的non dfs used空間，最笨的辦法就是重啟CDH，一下子佔用就到1G以下了。

2. docker中沒有CDH執行環境

專案採取docker來發布、執行程式，docker例項無狀態，停止服務即銷燬，無法直接安裝軟體，而程式採用命令列的方式編寫，必須依賴CDH環境執行，兩者出現矛盾，三種方案解決：
2.1.所有程式基於API來開發，改程式
未採用，一來程式改動量太大，影響里程碑計劃；二來CDH的有些元件對命令列的支援比對API的支援要好，比如sqoop。
2.2.製作一個CDH的映象，不改程式
未採用，需要開發人員重新部署、學習docker技術，測試程式，成本較大；
2.3.用jsch方式遠端連線CDH節點來執行命令，改程式
已採用，程式改動量較小，半天即可完成，已測試通過

3. sqoop注意事項

3.1.Oracle中是區分使用者的，一般給sqoop提供的賬號都是Oracle中的查詢賬號，通過同義詞等形式來查詢資料，所以sqoop命令中一定要帶上使用者，此使用者跟Oracle提供給sqoop查詢許可權使用者名稱不同(除非給sqoop提供的是生產庫的業務原始賬號，生產資料表都在此賬號下面)，sqoop命令中的賬號是源資料表的owner使用者，只有這樣才能通過查詢許可權的使用者去抽取同義詞等模式的生產資料。

3.2.由於一般給sqoop提供的賬號都是Oracle中的查詢賬號，如果需要通過訪問Oracle的資料字典來獲取源資料表結構，請使用dba_開頭的系統表，因為源資料表結構的資訊是在業務表的owner使用者下面的user_開頭的系統表中才有，查詢使用者下面的user_表中沒有。需要的dba_開頭的表包括：dba_tab_comments，dba_cons_columns，dba_constraints，dba_ind_columns ，dba_tab_columns，dba_col_comments

3.3. sqoop命令中，源資料庫為rac叢集的情況下，連線資料庫某個節點時，命令中Oracle IP、埠號、SID之間一律使用冒號，而不是斜槓，只有在非叢集模式或者scan ip的情況下才可以使用斜槓。

3.4.sqoop成功執行需要驅動包，在以下目錄新增2個jar包/opt/cloudera/parcels/CDH-5.5.2-1.cdh5.5.2.p0.4/lib/sqoop/lib：
mysql-connector-java-5.1.38-bin.jar
ojdbc14-10.2.0.4.jar

3.5.sqoop命令中併發引數 –m 屬性，一定要放在table屬性之後，否則命令無法識別

3.6.採用jsch遠端呼叫模式時，在sqoop命令沒有執行完成之前不能關閉遠端連線，否則即使已經提交了yarn也會中斷執行。

3.7．sqoop預設會把Oracle中number和date型別轉換為double和string型別，需要在sqoop命令中指定一下型別的轉換規則。

3.8 sqoop增量抽取時，where條件使用雙引號而非單引號，在Java程式碼遠端呼叫ssh時，儘量使用between and，否則必須得轉義<、>才能使用。

3.9 sqoop先建立表，後插入資料時容易跟對應的欄位錯位，需要設定分隔符引數 –fields-terminated-by “\001”，另外插入資料的順序一定要與建立表的欄位的順序一致。

5. spark與docker容器結合

5.1.在程式中採用URL方式連線spark的master節點時必須用別名，IP地址無效。

5.2.應用部署於docker容器中，呼叫spark元件的時候應用會莫名的重啟，後來排查發現是docker裡需要維護hosts,不然 new javaSparkContext()會導致應用服務重啟。但由於docker機制決定了，即使註冊了也無法持久化存在，應用重啟之後就還原了，所以直接在Java程式中完成，應用啟動的時候註冊到docker的hosts中。

5.3.應用部署於docker之中，呼叫spark元件的時候，spark的master和worker節點需要返回訊息給sparkdriver，即需要訪問部署應用的docker容器，如下圖所示：

而docker的原有機制決定了，只能由部署於docker中的應用去訪問叢集中的物理節點，而外面的物理節點無法訪問docker中的私網。
此外還有2個限制條件，第一：sparkdriver不支援對映地址和埠，必須是應用程式所在的IP；第二：docker容器的私網地址隨著應用重啟而在某個網段變化，如果固定為物理IP，將無限制的浪費物理IP地址，客戶不會同意；
最終通過開啟docker伺服器的路由轉發功能，在spark的master和worker節點上配置靜態的路由資訊得以實現由物理IP節點去訪問docker容器內部的私網地址的功能，也就是說開啟docker伺服器的路由轉發功能之後，其他機器發往172私網號段的請求，全部發給docker伺服器。
命令：ip route add <目標網段>/<掩碼> via

6. hive操作注意事項

6.1 hive中sql沒有像Oracle那樣進行自動優化，sql的優化非常重要，比如：同一業務邏輯，採用join方式一分鐘搞定，但是如果採用等值連線的方式，2小時都沒出結果。

6.2 hive中不支援join…on…or的形式，可以轉換成union all的方式，此外hive也不支援on後面不相等的條件，只支援相等條件。

6.3 hive的儲存方式一般有textfile、sequencefile、rcfile等三種，其中textfile即是文字格式，hive的預設儲存格式，資料不做壓縮，磁碟開銷大，資料解析開銷大，查詢的效率最低，可以直接儲存，但載入資料的效率最高；sequencefile，是Hadoop提供的一種二進位制檔案格式是Hadoop支援的標準檔案格式，可壓縮、可切片，查詢效率高，但需要通過text檔案轉化來載入；TEXTFILE和SEQUENCEFILE的儲存格式都是基於行儲存的，而rcfile 是一種行列儲存相結合的儲存方式，先將資料按行分塊再按列式儲存，保證同一條記錄在一個塊上，避免讀取多個塊，有利於資料壓縮和快速進行列儲存，具備相當於行儲存的資料載入和負載適應能力，掃描表時避免不必要的列讀取，而使用列維度的壓縮，能有效提升儲存空間利用率，因此儲存空間最小，查詢的效率最高 ，但需要通過text檔案轉化來載入，載入的速度最低，但是由於hdfs一般都是一次寫入多次讀取，所以載入的速度較慢可以接受；目前大資料平臺中hive的儲存格式採用的是普通的textfile，後續還有很大的優化提示空間。

7. CM管理頁面操作

7.1 有元件報錯或者無法啟動時，先檢視相應日誌，如果error的地方是關於時間的，ntp同步伺服器時間，然後重啟該元件；如果error的地方是關於客戶端連線問題的，重啟hostMonitor服務，如果不行就重啟agent服務；絕大多數情況下通過上述兩步就可成功，極少數情況下，那就刪除角色重新新增該服務，必要的時候可以調整一下該服務的各種角色所在的節點位置。

7.2 如果伺服器硬碟故障更換硬碟之後，各種元件啟動報錯，提示無法連線到cm，如果重啟hostMonitor服務無效的話，可以先把該節點移除出伺服器，然後配置角色模板，再新增進叢集中來。

7.3 CM主機頁面中會時常顯示實體記憶體還有剩餘，但是交換記憶體卻用了好多，導致CDH報警；這個從Linux機制的角度來看，可以忽略不管，Linux系統會不時的進行頁面交換操作，以保持儘可能多的空閒實體記憶體，即使並沒有什麼需要記憶體，Linux也會交換出暫時不用的記憶體頁面，這樣的可以避免等待交換所需的時間。如果非要消除這個報警，那就調整Linux中swappiness引數的值為0即可。