盡管在Hadoop與NoSQL部署方面做足了準(zhǔn)備，同樣的問(wèn)題仍然一次又一次反復(fù)出現(xiàn)?，F(xiàn)在業(yè)界是時(shí)候盡快搞定這些麻煩事了。
有時(shí)候一艘巨輪的側(cè)方出現(xiàn)了破洞，但業(yè)界卻決定坐等船體下沉、并把希望寄托在銷售救生艇身上。
也有些時(shí)候，這些問(wèn)題似乎并沒到要鬧出人命的地步——類似我家里浴室的狀況，只有往一邊擰龍頭才會(huì)出水。過(guò)一陣子我可能會(huì)找機(jī)會(huì)修理一下，但事實(shí)上這個(gè)問(wèn)題已經(jīng)存在了12年之久了。
而在面對(duì)大數(shù)據(jù)業(yè)務(wù)時(shí)，我可以列出九個(gè)長(zhǎng)久以來(lái)一直令人頭痛的問(wèn)題，時(shí)至今日它們依然存在著并困擾著無(wú)數(shù)用戶。
大數(shù)據(jù)痛點(diǎn)一號(hào)：GPU編程仍未得到普及
CPU的使用成本仍然較為昂貴，至少與GPU相比要貴得多。如果我們能夠面向GPU開發(fā)出更理想的執(zhí)行標(biāo)準(zhǔn)以及更多表現(xiàn)出色的驅(qū)動(dòng)程序，那么相信一個(gè)新的市場(chǎng)將由此誕生。就目前來(lái)講，GPU的使用成本優(yōu)勢(shì)并沒能得到很好的體現(xiàn)，這是因?yàn)槲覀冸y以針對(duì)其進(jìn)行編程，而且?guī)缀鯖]辦法在不建立特定模型的前提下完成這項(xiàng)任務(wù)。
這種情況類似于，有些人希望編寫出類似于ODBC或者JDBC的代碼來(lái)處理某些高強(qiáng)度工作，并說(shuō)服AMD或者英偉達(dá)將業(yè)務(wù)著眼點(diǎn)放在顯卡產(chǎn)品之外。假設(shè)我們?cè)疽呀?jīng)習(xí)慣了使用Spark實(shí)現(xiàn)各類計(jì)算任務(wù)，而且壓根不覺得這么做有什么問(wèn)題; 但仿佛在一夜之間，其他人都開始構(gòu)建所謂“GPGPU”集群，這自然會(huì)讓我們有點(diǎn)措手不及之感。
不少技術(shù)人員都開始在這方面做出探索，但要想真正讓成果實(shí)現(xiàn)市場(chǎng)化，我們至少需要搞定兩大競(jìng)爭(zhēng)對(duì)手——AMD以及英偉達(dá)，也許再加上英特爾。除非它們?cè)敢饴?lián)手合作，否則如果繼續(xù)像現(xiàn)在這樣把技術(shù)保密看作市場(chǎng)成功的實(shí)現(xiàn)途徑，那么問(wèn)題永遠(yuǎn)也找不到理想的答案。
大數(shù)據(jù)痛點(diǎn)二號(hào): 多工作負(fù)載縮放
我們擁有Docker。我們擁有Yarn。我們還擁有Spark、Tez、MapReduce以及未來(lái)可能出現(xiàn)的一系列技術(shù)方案。我們還擁有多種資源池化實(shí)現(xiàn)工具，其中包含各類不同優(yōu)先級(jí)及其它設(shè)定。如果大家選擇部署一個(gè)Java war文件，則可以在PaaS上進(jìn)行“自動(dòng)伸縮”。但如果大家希望在Hadoop上實(shí)現(xiàn)同樣的效果，那么情況就不太一樣了。
再有，存儲(chǔ)與處理體系之間的交互該如何處理？有時(shí)候大家需要以臨時(shí)性方式對(duì)存儲(chǔ)資源進(jìn)行擴(kuò)展與分發(fā)。我應(yīng)該有能力運(yùn)行自己的“月末統(tǒng)計(jì)”批量任務(wù)并將Docker鏡像自動(dòng)部署到任意指定位置。而在我的任務(wù)完成之后，系統(tǒng)應(yīng)當(dāng)對(duì)其進(jìn)行反部署，并將資源重新分配給其它工作負(fù)載。應(yīng)用程序或者工作負(fù)載應(yīng)該根本不需要在這方面浪費(fèi)太多精力。
但目前這些要求尚無(wú)法實(shí)現(xiàn)。我希望大家習(xí)慣了編寫Chef方案與腳本，因?yàn)檫@是達(dá)到以上目標(biāo)的惟一辦法。
大數(shù)據(jù)痛點(diǎn)三號(hào): NoSQL部署更令人頭痛
為什么我已經(jīng)能夠利用ssh與sudo將鏡像導(dǎo)入Linux設(shè)備、為其指定Ambari并安裝像Hadoop這樣復(fù)雜度極高的項(xiàng)目，但卻仍然需要在 MongoDB以及大部分其它數(shù)據(jù)庫(kù)的部署工作中浪費(fèi)時(shí)間與精力？當(dāng)然，我也可以編寫Chef自動(dòng)化方案，但恕我仍對(duì)此無(wú)法認(rèn)同。
大數(shù)據(jù)痛點(diǎn)四號(hào)：查詢分析器/修復(fù)器
當(dāng)初在使用JBoss的時(shí)候，我曾經(jīng)對(duì)Hibernate以及后來(lái)的JPA/EJB3進(jìn)行過(guò)大量調(diào)試。具體來(lái)講，主要工作包括查看日志記錄、找出存在n 1類查詢的位置、將其納入join并移除可能影響運(yùn)行效果的糟糕緩存配置。
但有時(shí)候情況又完全相反：我們可以將每一套需要的表添加到系統(tǒng)當(dāng)中，但其返回速度卻慢得讓人抓狂。有時(shí)候，我打算在復(fù)雜程度更高的系統(tǒng)之上查看 Oracle Enterprise Manager及其分析結(jié)果，但返回的報(bào)告卻完全是一堆胡言亂語(yǔ)——這意味著其中存在問(wèn)題。不過(guò)我可以同時(shí)著眼于兩套始終共同協(xié)作的表，并據(jù)此找到分析當(dāng)中存在的規(guī)律。我甚至考慮過(guò)利用編程方式解決問(wèn)題。
而現(xiàn)在，每次對(duì)NoSQL系統(tǒng)進(jìn)行調(diào)整時(shí)，我都會(huì)發(fā)現(xiàn)上述問(wèn)題以不同形式表現(xiàn)出來(lái)：要么是跳轉(zhuǎn)次數(shù)太多、要么是查詢太過(guò)復(fù)雜，有時(shí)候我們的索引無(wú)法與where子句（即范圍合并）相匹配。簡(jiǎn)而言之，我們將大量精力投入到了糟糕或者復(fù)雜查詢的優(yōu)化當(dāng)中，但除了開發(fā)者培訓(xùn)課程、我們似乎從來(lái)不會(huì)對(duì)這些查詢本身提出質(zhì)疑。這套系統(tǒng)似乎有種魔性，它同用戶的關(guān)系類似于：“嘿，你發(fā)來(lái)了這些查詢，我認(rèn)為它們看起來(lái)應(yīng)該像這樣……”