相信很多人都有這樣一個(gè)疑問(wèn)"為什么別人家的大數(shù)據(jù)戰(zhàn)略都成功了，就我家失敗了呢?"為了解答大家的疑問(wèn)，我們和來(lái)自21家公司的22位高管進(jìn)行了交談，通過(guò)他們幫助客戶(hù)管理優(yōu)化數(shù)據(jù)、提升業(yè)務(wù)價(jià)值的經(jīng)驗(yàn)，來(lái)告訴大家為什么你的大數(shù)據(jù)戰(zhàn)略失敗了。 

傳統(tǒng)技術(shù)

取決于傳統(tǒng)的系統(tǒng)。這是很基礎(chǔ)也是很現(xiàn)實(shí)的問(wèn)題，想要充分利用大數(shù)據(jù)系統(tǒng)，就必須具備主演的知識(shí)。所以，如何讓現(xiàn)有員工學(xué)會(huì)使用這些數(shù)據(jù)是有條不紊實(shí)施大數(shù)據(jù)戰(zhàn)略的先決條件。

無(wú)法處理遺留系統(tǒng)和新軟件的流沙和技術(shù)債務(wù)。

愿意擁抱云。雖然有很多方法可以擁抱云，但是繼續(xù)支持遺留企業(yè)系統(tǒng)是不可行的，他們不能隨著數(shù)據(jù)的流入而擴(kuò)大規(guī)模。

建立正確的骨干基礎(chǔ)設(shè)施(即存儲(chǔ)，傳輸，計(jì)算，故障轉(zhuǎn)移)。從服務(wù)器獲取數(shù)據(jù)進(jìn)行分析。如何處理數(shù)據(jù)集。Scale, complexity, modeling。

當(dāng)企業(yè)試圖構(gòu)建大型數(shù)據(jù)項(xiàng)目時(shí)，往往無(wú)法成功地執(zhí)行。當(dāng)然，這里面的原因也有很多，例如成本受到限制，缺乏合適的人才、想要重用現(xiàn)有的基礎(chǔ)設(shè)施而忽略了敏捷過(guò)程。因此依賴(lài)大數(shù)據(jù)基礎(chǔ)的業(yè)務(wù)通常在業(yè)務(wù)區(qū)域性或范圍內(nèi)的實(shí)現(xiàn)，最終很難實(shí)現(xiàn)回報(bào)投資或者是需要花費(fèi)更多的時(shí)間來(lái)獲得回報(bào)。而且有時(shí)候主觀的活動(dòng)也會(huì)受到思想和資源的限制，一個(gè)新的想法從誕生到執(zhí)行也會(huì)經(jīng)歷冗長(zhǎng)的拖延。除了之外，企業(yè)也常常因?yàn)閺?fù)雜性而無(wú)法分析大數(shù)據(jù)，當(dāng)然這也和缺乏數(shù)據(jù)分析師和其他IT專(zhuān)業(yè)人員解釋數(shù)據(jù)有關(guān)。

缺少知識(shí)

他們不了解云。雖然他們會(huì)采用"基礎(chǔ)設(shè)施即服務(wù)"的方式，但是他們由于不了解效益，所以效率并沒(méi)有提高。而且很多企業(yè)會(huì)選擇放棄自己的IT部門(mén)，將云管理外包給第三方提供商。例如Salesforce使用云實(shí)現(xiàn)可擴(kuò)展性、性能和存儲(chǔ)節(jié)省。彈性云支持伸縮，所以需要使用SQL servid4r network以及其它組件來(lái)即時(shí)擴(kuò)展，現(xiàn)在大部分公有云廠商都提供cognitive 和 AI/ML。

雖然大數(shù)據(jù)的潛在利益會(huì)讓每個(gè)人或每個(gè)公司感到興奮，但是有一些共同問(wèn)題確確實(shí)實(shí)在阻礙公司大數(shù)據(jù)發(fā)展：

技術(shù)很多，難以抉擇。

缺乏技術(shù)人才。

采用通用數(shù)據(jù)格式的組織障礙。我們對(duì)早期采用大數(shù)據(jù)企業(yè)的建議是要時(shí)刻關(guān)注最新的技術(shù)，尤其是像Apache Flink這樣的數(shù)據(jù)流技術(shù)，避免因?yàn)椴捎昧诉^(guò)時(shí)的大數(shù)據(jù)技術(shù)而掉隊(duì)。

企業(yè)更相信大數(shù)據(jù)的某些承諾，而對(duì)具體用例的理解不夠，不同的業(yè)務(wù)部門(mén)或者特定的業(yè)務(wù)驅(qū)動(dòng)程序都缺乏對(duì)業(yè)務(wù)的支持。對(duì)于數(shù)據(jù)湖、平臺(tái)、云或者軟件的選擇是一個(gè)很復(fù)雜的決定，并且每天都會(huì)有新的解決方案出來(lái)。公有云中的工具集、技能集并不是最重要的，你可以根據(jù)用例和實(shí)現(xiàn)目標(biāo)選擇最佳工具。

客戶(hù)了解大數(shù)據(jù)潛在好處的渠道可能大部分來(lái)自于競(jìng)爭(zhēng)對(duì)手，但是如果大家都使用相同的工具、數(shù)據(jù)源、知識(shí)，那么誰(shuí)都不會(huì)有所進(jìn)步。所以挖掘新的人才和工具才是解決問(wèn)題的關(guān)鍵。我看到很多這樣的情況，因?yàn)轫?xiàng)目進(jìn)展不順利，公司就放棄了大數(shù)據(jù)計(jì)劃。想要成功實(shí)現(xiàn)大數(shù)據(jù)項(xiàng)目，首先就要戰(zhàn)勝未知的恐懼，其次才是戰(zhàn)勝其它的問(wèn)題，例如，確保數(shù)據(jù)分析符合道德要求、法律的監(jiān)管，發(fā)展數(shù)據(jù)科學(xué)領(lǐng)域的才能等等。

業(yè)務(wù)問(wèn)題

從應(yīng)用程序和用例開(kāi)始你就是思考數(shù)據(jù)，不能把數(shù)據(jù)當(dāng)成是事后處理。其實(shí)，成功的關(guān)鍵就是為應(yīng)用奠定堅(jiān)實(shí)的數(shù)據(jù)，注意底層數(shù)據(jù)存儲(chǔ)和數(shù)據(jù)結(jié)構(gòu)。

技術(shù)和解決方案的擴(kuò)散。從Hadoop開(kāi)始，你需要了解不同的存儲(chǔ)和流，在某些地方配置和管理開(kāi)源組件可能會(huì)損壞項(xiàng)目的ROI，隨意這里一定要了解問(wèn)題的最佳解決方案是什么，開(kāi)箱即用的解決方案可以減少配置和管理時(shí)間。

不了解大數(shù)據(jù)分析，所以一定要選擇和應(yīng)用衡量結(jié)果的工具和技術(shù)。對(duì)于可衡量的結(jié)果，公司必須對(duì)文檔進(jìn)行足夠的嚴(yán)格性，并分析所要達(dá)到的目標(biāo)。然后根據(jù)它們的能力來(lái)選擇工具和技術(shù)，以滿(mǎn)足或超過(guò)預(yù)期的結(jié)果。我看過(guò)太多沒(méi)有事先準(zhǔn)備而盲目選擇，最終導(dǎo)致失敗。

數(shù)據(jù)質(zhì)量和管理

有能力了解數(shù)據(jù)。根據(jù)需要將數(shù)據(jù)從存儲(chǔ)移到計(jì)算。

缺乏對(duì)元數(shù)據(jù)的關(guān)注——不全面地看待問(wèn)題。

用于記錄數(shù)據(jù)的系統(tǒng)。沒(méi)有簡(jiǎn)單的方法來(lái)獲得數(shù)據(jù)進(jìn)行比較，數(shù)據(jù)孤島、系統(tǒng)和模式中的不一致，這一切都要求我們規(guī)范化我們規(guī)范化所有系統(tǒng)和模式的數(shù)據(jù)。

最大的挑戰(zhàn)之一是他們使用所有數(shù)據(jù)的能力，移動(dòng)數(shù)據(jù)是非常昂貴和耗時(shí)的，因?yàn)槿绾螌?shù)據(jù)扶植到分析的地方是個(gè)大難題。

無(wú)組織或非結(jié)構(gòu)化的數(shù)據(jù)收集和處理。對(duì)于NLG，特別是敘述性的輸出往往局限于數(shù)據(jù)輸入的清潔。

在Hadoop中無(wú)法同時(shí)擴(kuò)展。帶有單線程的查詢(xún)引擎。安全性符合GDPR的能力。處理技術(shù)以刪除記錄。把數(shù)據(jù)放在適當(dāng)?shù)牡胤剑胤焦芾韱T可以了解當(dāng)?shù)氐姆?，防止可能觸犯法律的查詢(xún)。

緩慢的、手工的和一次性的工作會(huì)被丟棄，例如花費(fèi)太多時(shí)間來(lái)查找數(shù)據(jù)，沒(méi)有權(quán)威共同的數(shù)據(jù)集，因?yàn)闇?zhǔn)備和清理數(shù)據(jù)的時(shí)間太長(zhǎng)導(dǎo)致分析時(shí)間不足等等。

其他

復(fù)雜的技術(shù)堆棧，比如零售商需要考慮來(lái)自購(gòu)物車(chē)的實(shí)時(shí)信息和用戶(hù)之前12個(gè)月的購(gòu)買(mǎi)歷史記錄，甚至需要將三、四個(gè)系統(tǒng)整合在一起。越多的移動(dòng)部件約會(huì)導(dǎo)致更多的破壞和延遲，所以簡(jiǎn)化數(shù)據(jù)管道并獲得更高可用性也是企業(yè)面臨的大難題。

零售商需要來(lái)自購(gòu)物車(chē)的實(shí)時(shí)信息和12個(gè)月的購(gòu)買(mǎi)歷史記錄。將三個(gè)或四個(gè)系統(tǒng)縫合在一起。更多的移動(dòng)部件導(dǎo)致更多的機(jī)會(huì)破壞和延遲。幫助簡(jiǎn)化數(shù)據(jù)管道以獲得更高的可用性。數(shù)據(jù)架構(gòu)師企業(yè)，以便它能夠和準(zhǔn)備擴(kuò)展。

以上言論綜合了下面22位企業(yè)高管的意見(jiàn)：

• Emma McGrattan, S.V.P. of Engineering,
• Neena Pemmaraju, VP, Products,
• Tibi Popp, Co-founder and CTO,
• Laura Pressman, Marketing Manager,
• Sébastien Vugier, SVP, Ecosystem Engagement and Vertical Solutions,
• Kostas Tzoumas, Co-founder and CEO,
• Shehan Akmeemana, CTO,
• Peter Smails, V.P. of Marketing and Business Development,
• Tomer Shiran, Founder and CEO and Kelly Stirman, CMO,
• Ali Hodroj, Vice President Products and Strategy,
• Flavio Villanustre, CISO and V.P. of Technology,
• Fangjin Yang, Co-founder and CEO,
• Murthy Mathiprakasam, Director of Product Marketing,
• Iran Hutchinson, Product Manager and Big Data Analytics Software/Systems Architect,
• Dipti Borkar, V.P. of Products,
• Adnan Mahmud, Founder and CEO,
• Jack Norris, S.V.P. Data and Applications,
• Derek Smith, Co-founder and CEO,
• Ken Tsai, Global V.P., Global Vice President, Head of Database and Data Management Product Marketing,
• Clarke Patterson, Head of Product Marketing,
• Seeta Somagani, Solutions Architect,