Hadoop = Hard to doop：數據縮水！揭常見 Hadoop 爛尾因素

大多數企業 big data 應用案例還處於實驗和測試階段，對於少數首次在生產環境部署 Hadoop 系統的用戶來說，最常遇到的就是擴展問題，此類問題往往導致中途爛尾，令 big data 項目無法持之以恆。部署和擴展 Hadoop 系統是一件高度復雜的事情，如果用戶能提前考慮到 Hadoop 擴展時會遇到的問題和對危險信號有所了解，就能避免很多爛尾情況了。

以下是 Altiscale 的 Raymie Stata 早前曾總結出來的 Hadoop big data 七大危險信號，大家「中」了幾多？

危險信號一：永遠未進入生產階段

big data 應用從概念到生產環境是一個巨大的變化，Hadoop 系統的可擴展性將面臨巨大的挑戰。生產環境的數據規模所產生的問題在實驗環境是很難遇到的。另外數據本身也存在差異，概念驗證階段使用的測試數據往往是不真實的，或者是類型單一。在進入生產環境前，big data 團隊需要對 Hadoop 系統進行模擬真實數據規模的壓力測試，此類測試能夠檢驗 big data 應用的可擴展性和相容性能，還能幫你做出更加準確的性能(資源需求)規劃模型。

危險信號二：分析任務不斷超時

當 Hadoop 中運行的 big data 應用很少或者只有一筆時，一切都會按部就班，但是隨著 Hadoop Computer cluster 增長，數據分析任務的運行時間變得難以預測。一開始，只是有零星的超時現像，問題容易被忽視，但隨著時間久了，超時問題會越來越嚴重，最後導致危機發生。在危機爆發前，你必須提前採取行動，根據任務的程度來調整計算性能的規劃模型。

危險信號三：你開始告訴人們不要保留所有數據

危機出現的另一個征兆是數據保留時間不斷縮水。一開始你想保留 13 個月的數據進行年度分析。但是由於空間限制，你開始減少保留數據的月份數。到最後，你的 Hadoop 系統因為沒有足夠多的數據而從 BID DATA 變成 SMALL DATA 系統。數據保留導致空間縮水是因為存儲的擴展性遇到問題，這與前面的運算性能問題類似。當你的容量 Prediction Model 出現問題時，需要盡快調整。

危險信號四: Data scientist 被「餓死」

任務負荷過重的 Hadoop Computer cluster 會扼殺創新，因為 Data scientist 將沒有足夠的運算資源來開展大型任務，也沒有足夠的空間來存儲中間結果。性能和容量規劃通常會忽略或者低估 Data scientist 的需求，之前提到對生產環境任務的估計不足，會嚴重限制 Data scientist 的創新性工作。

危險信號五：Data scientist 開始查看 Stack Overflow

在 Hadoop 系統部署的早期，運行和營業團隊與科學家緊密協作。運行和營業團隊隨時為 Data scientist 提供支持，但是當 Hadoop 系統成功上線後，系統的運行維護和擴展任務就會讓運行和營業的團隊疲於奔命，這時候 Data scientist 遇到 Hadoop 問題就只好自己解決，例如去 Stack Overflow 查看問題帖子。

危險信號六：Data Center 越來越熱

Data Center 伺服器的電力都不是按伺服器的功率配置的，但是一個 Hadoop Computer cluster 運行任務的時候經常會連續開啟數小時，會燒壞不匹配的供電線路，同樣的問題也存在於制冷系統中。部署 Hadoop 系統時請確保 Data Center 能頂得住長時間全速運行的 Hadoop….。

危險信號七：費用超支

基於 IaaS 的 Hadoop 部署，例如 AWS，在支出上是無法控制的。一個月的費用很有可能是上個月的三倍，遠遠超出你的預算。性能規劃對於基於 IaaS 的 Hadoop 部署來說也是非常重要的，但是好的性能規劃只是開始，如果你需要擴展 IaaS 上的 Hadoop 系統，在成本監控和優化系統上投入大量資金是必然的，假如你自問資金不足，那就切勿隨意嘗試大數據 Hadoop。