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