問題不在于缺少大數據分析或者是大量的數據科學實驗。真正的挑戰是缺乏大數據自動化能力，以便將實驗版本從沙箱推入功能齊全的生產環境中。
大多數人認為分析生產就是調整集群。當然，可以編寫一個sqoop腳本并將表格放入一次。但是，在不影響源系統的情況下多次實現則是一個挑戰。然后，必須確保構建的數據管道在由服務級別協議(SLA)設置的時間范圍內提供數據。此外，數據模型需要針對用戶當前正在使用的工具(如Tableau，Qlik等)進行優化，以達到用戶所期望的響應能力。
在Hadoop和Spark之上使用工具進行大量的努力和改進以對大型數據集進行快速原型設計。但原型是一回事，創建每天運行而不發生故障的數據工作流程，或者在數據流作業失敗時自動啟用恢復，又是另外一回事。
本文作者分析了五大大數據項目夭折最常見的技術原因：
1、無法快速加載數據以滿足SLA
雖然像sqoop這樣的工具支持數據讀取的并行化以從傳統數據源獲取數據到數據湖，但需要專家來使其正常工作。如何劃分數據?要運行多少個容器等問題都需要專家給出合適的解決方案。如果無法正確處理并行數據的讀取，則一個小時就可完成的任務甚至需要10到20倍的時間，因為大多數人不知道如何正確調整。
2、不能逐步加載數據以滿足SLA
大多數企業并未將整個操作轉移到大數據環境中。他們從現有的操作系統移動數據以執行新的分析或機器學習，這意味著需要在新數據到達時繼續加載。問題是這些環境不支持添加，刪除或插入的概念，這意味著必須重新加載整個數據集(請參閱上面的第1點)，否則必須圍繞一次更改捕獲問題編寫代碼。
3、不能以交互方式提供對數據報告的訪問權限
想象一下，如果有1000位商業智能分析師，他們都不想使用您的數據模型，因為他們需要很長時間才能查詢。這是Hadoop的一個經典問題，也是許多公司僅使用Hadoop進行預處理和應用特定機器學習算法，但隨后將最終數據集移回傳統數據倉庫以供BI工具使用的原因。無論如何，這個過程又為成功完成大數據項目增加了難度。
4、不能從測試遷移到生產
許多企業能夠確定沙箱環境中數據科學家的新見解的潛力。一旦他們確定采納新的分析方法，就需要從沙盒轉移到生產環境。從開發轉移到生產是一個完整的升降和換擋操作，通常是手動完成的。雖然它在開發集群上運行良好，但現在相同的數據管道必須在生產集群上重新優化。這種調整往往需要大量的返工才能有效執行。如果開發環境與生產環境有任何不同，則情況尤其復雜。
5、不能管理端到端的生產工作量
大多數企業都將注意力集中在工具上，因此他們的數據分析師和科學家可以更輕松地識別新的方法。但是，他們沒有投資類似的工具來運行生產環境中的數據工作流程，因此不得不擔心啟動、暫停和重新啟動過程，還必須擔心確保作業的容錯性，處理通知以及協調多個工作流以避免“沖突”。
因為上述五大技術原因，導致很多大數據項目并沒有如期與我們見面。
京公網安備 11010502049343號