為什麼很多大資料專案搞著搞著就黃了？

  大資料正在改變世界。但是，大多數大資料專案搞著搞著就黃了，很難成功。這是為什麼呢?

　　企業正努力在產品中部署大資料，這一點是毋庸置疑的。但是，根據Gartner在2016年下半年釋出的新聞稿：只有15%的企業將其大資料專案部署到生產中。”Gartner在選詞時非常謹慎，這並不意味著剩下的企業沒有實踐，或者資料科學家沒有發現使用大資料技術的優勢，只是剩下的85%的專案並沒有真正投入生產。

　　問題不在於缺少大資料分析或者是大量的資料科學實驗。真正的挑戰是缺乏大資料自動化能力，以便將實驗版本從沙箱推入功能齊全的生產環境中。

　　大多數人認為分析生產就是調整叢集。當然，可以編寫一個sqoop指令碼並將表格放入一次。但是，在不影響源系統的情況下多次實現則是一個挑戰。然後，必須確保構建的資料管道在由服務級別協議(SLA)設定的時間範圍內提供資料。此外，資料模型需要針對使用者當前正在使用的工具(如Tableau，Qlik等)進行最佳化，以達到使用者所期望的響應能力。

　　在Hadoop和Spark之上使用工具進行大量的努力和改進以對大型資料集進行快速原型設計。但原型是一回事，建立每天執行而不發生故障的資料工作流程，或者在資料流作業失敗時自動啟用恢復，又是另外一回事。

　　本文作者分析了五大大資料專案夭折最常見的技術原因：

　　1、無法快速載入資料以滿足SLA

　　雖然像sqoop這樣的工具支援資料讀取的並行化以從傳統資料來源獲取資料到資料湖，但需要專家來使其正常工作。如何劃分資料?要執行多少個容器等問題都需要專家給出合適的解決方案。如果無法正確處理並行資料的讀取，則一個小時就可完成的任務甚至需要10到20倍的時間，因為大多數人不知道如何正確調整。

　　2、不能逐步載入資料以滿足SLA

　　大多數企業並未將整個操作轉移到大資料環境中。他們從現有的作業系統移動資料以執行新的分析或機器學習，這意味著需要在新資料到達時繼續載入。問題是這些環境不支援新增，刪除或插入的概念，這意味著必須重新載入整個資料集(請參閱上面的第1點)，否則必須圍繞一次更改捕獲問題編寫程式碼。

　　

　　3、不能以互動方式提供對資料包告的訪問許可權

　　想象一下，如果有1000位商業智慧分析師，他們都不想使用您的資料模型，因為他們需要很長時間才能查詢。這是Hadoop的一個經典問題，也是許多公司僅使用Hadoop進行預處理和應用特定機器學習演算法，但隨後將最終資料集移回傳統資料倉儲以供BI工具使用的原因。無論如何，這個過程又為成功完成大資料專案增加了難度。

　　4、不能從測試遷移到生產

　　許多企業能夠確定沙箱環境中資料科學家的新見解的潛力。一旦他們確定採納新的分析方法，就需要從沙盒轉移到生產環境。從開發轉移到生產是一個完整的升降和換擋操作，通常是手動完成的。雖然它在開發叢集上執行良好，但現在相同的資料管道必須在生產叢集上重新最佳化。這種調整往往需要大量的返工才能有效執行。如果開發環境與生產環境有任何不同，則情況尤其複雜。

　　5、不能管理端到端的生產工作量

　　大多數企業都將注意力集中在工具上，因此他們的資料分析師和科學家可以更輕鬆地識別新的方法。但是，他們沒有投資類似的工具來執行生產環境中的資料工作流程，因此不得不擔心啟動、暫停和重新啟動過程，還必須擔心確保作業的容錯性，處理通知以及協調多個工作流以避免“衝突”。

　　因為上述五大技術原因，導致很多大資料專案並沒有如期與我們見面。當然，如果你有更棒的見解，歡迎在評論區留言。