【中國智能制造網(wǎng) 市場分析】大數(shù)據(jù)是工業(yè)4.0時代企業(yè)決策的隱形推手。雖然大數(shù)據(jù)應(yīng)用前景光明，是資本和市場的寵兒，但哪些深藏于光鮮之下的不和隱憂也同樣不容忽視。　　
　　大數(shù)據(jù)痛點一號：GPU編程仍未得到普及
　　
　　CPU的使用成本仍然較為昂貴，至少與GPU相比要貴得多。如果我們能夠面向GPU開發(fā)出更理想的執(zhí)行標(biāo)準(zhǔn)以及更多表現(xiàn)出色的驅(qū)動程序，那么相信一個新的市場將由此誕生。就目前來講，GPU的使用成本優(yōu)勢并沒能得到很好的體現(xiàn)，這是因為我們難以針對其進(jìn)行編程，而且?guī)缀鯖]辦法在不建立特定模型的前提下完成這項任務(wù)。
　　
　　這種情況類似于，有些人希望編寫出類似于ODBC或者JDBC的代碼來處理某些高強度工作，并說服AMD或者英偉達(dá)將業(yè)務(wù)著眼點放在顯卡產(chǎn)品之外。假設(shè)我們原本已經(jīng)習(xí)慣了使用Spark實現(xiàn)各類計算任務(wù),而且壓根不覺得這么做有什么問題；但仿佛在一夜之間，其他人都開始構(gòu)建所謂“GPGPU”集群，這自然會讓我們有點措手不及之感。
　　
　　不少技術(shù)人員都開始在這方面做出探索，但要想真正讓成果實現(xiàn)市場化，我們至少需要搞定兩大競爭對手——AMD以及英偉達(dá)，也許再加上英特爾。除非它們愿意聯(lián)手合作，否則如果繼續(xù)像現(xiàn)在這樣把技術(shù)保密看作市場成功的實現(xiàn)途徑，那么問題永遠(yuǎn)也找不到理想的答案。
　　
　　數(shù)據(jù)痛點二號：多工作負(fù)載縮放
　　
　　我們擁有Docker。我們擁有Yarn。我們還擁有Spark、Tez、MapReduce以及未來可能出現(xiàn)的一系列技術(shù)方案。我們還擁有多種資源池化實現(xiàn)工具，其中包含各類不同優(yōu)先級及其它設(shè)定。如果大家選擇部署一個Javawar文件，則可以在PaaS上進(jìn)行“自動伸縮”。但如果大家希望在Hadoop上實現(xiàn)同樣的效果，那么情況就不太一樣了。
　　
　　再有，存儲與處理體系之間的交互該如何處理？有時候大家需要以臨時性方式對存儲資源進(jìn)行擴(kuò)展與分發(fā)。我應(yīng)該有能力運行自己的“月末統(tǒng)計”批量任務(wù)并將Docker鏡像自動部署到任意指定位置。而在我的任務(wù)完成之后，系統(tǒng)應(yīng)當(dāng)對其進(jìn)行反部署，并將資源重新分配給其它工作負(fù)載。應(yīng)用程序或者工作負(fù)載應(yīng)該根本不需要在這方面浪費太多精力。
　　
　　但目前這些要求尚無法實現(xiàn)。我希望大家習(xí)慣了編寫Chef方案與腳本，因為這是達(dá)到以上目標(biāo)的惟一辦法。
　　
　　大數(shù)據(jù)痛點三號：NoSQL部署更令人頭痛
　　
　　為什么我已經(jīng)能夠利用ssh與sudo將鏡像導(dǎo)入Linux設(shè)備、為其指定Ambari并安裝像Hadoop這樣復(fù)雜度極高的項目，但卻仍然需要在MongoDB以及大部分其它數(shù)據(jù)庫的部署工作中浪費時間與精力？當(dāng)然，我也可以編寫Chef自動化方案，但恕我仍對此無法認(rèn)同。
　　
　　大數(shù)據(jù)痛點四號：查詢分析器/修復(fù)器
　　
　　當(dāng)初在使用JBoss的時候，我曾經(jīng)對Hibernate以及后來的JPA/EJB3進(jìn)行過大量調(diào)試。具體來講，主要工作包括查看日志記錄、找出存在n 1類查詢的位置、將其納入join并移除可能影響運行效果的糟糕緩存配置。
　　
　　但有時候情況又完全相反：我們可以將每一套需要的表添加到系統(tǒng)當(dāng)中，但其返回速度卻慢得讓人抓狂。有時候，我打算在復(fù)雜程度更高的系統(tǒng)之上查看OracleEnterpriseManager及其分析結(jié)果，但返回的報告卻完全是一堆胡言亂語——這意味著其中存在問題。不過我可以同時著眼于兩套始終共同協(xié)作的表，并據(jù)此找到分析當(dāng)中存在的規(guī)律。我甚至考慮過利用編程方式解決問題。