為什麼你的大資料項目瞬間就”涼”了？

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

企業正努力在産品中部署大資料，這一點是毋庸置疑的。但是，根據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、不能管理端到端的生産工作量

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

因為上述五大技術原因，導緻很多大資料項目并沒有如期與我們見面。

Bingdata優網助幫彙聚多平台采集的海量資料,通過大資料技術的分析及預測能力為企業提供智能化的資料分析、營運優化、投放決策、精準營銷、競品分析等整合營銷服務。

北京優網助幫資訊技術有限公司（簡稱優網助幫）是以大資料為基礎，并智能應用于整合營銷的大資料公司，隸屬于亨通集團。Bingdata是其旗下品牌。優網助幫團隊主要來自阿裡、騰訊、百度、金山、搜狐及移動、電信、聯通、華為、愛立信等著名企業的技術大咖，兼有網際網路與通信營運商兩種基因，為大資料的算法分析提供強大的技術支撐。