父輩婚姻長(cháng)久的比率高，老一輩人處理問(wèn)題的態(tài)度是積極改進(jìn)而不是拋棄不顧，這或許也是他們能夠維持婚姻長(cháng)久的原因之一。
處理問(wèn)題的態(tài)度除了積極應對、拋棄不顧當然還有一種態(tài)度是長(cháng)久的隱忍，在問(wèn)題發(fā)生后的很長(cháng)一段時(shí)間后才進(jìn)行處理。
從婚姻聯(lián)想到大數據，大數據運用同樣存在很多問(wèn)題，但很多專(zhuān)家抱著(zhù)卻置之不理的態(tài)度，聽(tīng)之任之。針對大數據運用上的問(wèn)題我們應該正視。只有正視的態(tài)度方能換回解決的方案。
面對大數據業(yè)務(wù)時(shí)，我們可以列出九個(gè)長(cháng)久以來(lái)一直令人頭痛的問(wèn)題，時(shí)至今日它們依然存在著(zhù)并困擾著(zhù)無(wú)數用戶(hù)。
一號痛點(diǎn)：查詢(xún)分析器/修復器
我們可以將每一套需要的表添加到系統當中，但其返回速度卻慢得讓人抓狂。有時(shí)候，我們打算在復雜程度更高的系統之上查看 Oracle Enterprise Manager及其分析結果，但返回的報告卻完全是一堆胡言亂語(yǔ)——這意味著(zhù)其中存在問(wèn)題。
我們將大量精力投入到了糟糕或者復雜查詢(xún)的優(yōu)化當中，但除了開(kāi)發(fā)者培訓課程、我們似乎從來(lái)不會(huì )對這些查詢(xún)本身提出質(zhì)疑。這套系統似乎有種魔性，它同用戶(hù)的關(guān)系類(lèi)似于：“嘿，你發(fā)來(lái)了這些查詢(xún)，我認為它們看起來(lái)應該像這樣……”
二號痛點(diǎn)：GPU編程仍未得到普及
CPU的使用成本仍然較為昂貴，至少與GPU相比要貴得多。如果我們能夠面向GPU開(kāi)發(fā)出更理想的執行標準以及更多表現出色的驅動(dòng)程序，那么相信一個(gè)新的市場(chǎng)將由此誕生。就目前來(lái)講，GPU的使用成本優(yōu)勢并沒(méi)能得到很好的體現，這是因為我們難以針對其進(jìn)行編程，而且幾乎沒(méi)辦法在不建立特定模型的前提下完成這項任務(wù)。
不少技術(shù)人員都開(kāi)始在這方面做出探索，但要想真正讓成果實(shí)現市場(chǎng)化，我們至少需要搞定兩大競爭對手——AMD以及英偉達，也許再加上英特爾。除非它們愿意聯(lián)手合作，否則如果繼續像現在這樣把技術(shù)保密看作市場(chǎng)成功的實(shí)現途徑，那么問(wèn)題永遠也找不到理想的答案。
三號痛點(diǎn)：分布式名不副實(shí)
我們得承認，對Hadoop的使用的第一印象就像在Hive當中輸入select count(*) from somesmalltable。我覺(jué)得這種使用方式真的非常差勁。大家會(huì )發(fā)現其中存在問(wèn)題，并意識到其分布效果并不理想。有些朋友甚至不必參考其它數據(例如行數)就能發(fā)現我們沒(méi)辦法實(shí)現負載分布。通常來(lái)講，這些只是整體工作當中的一部分(例如查找表)，但無(wú)論我們實(shí)際使用的是Hive、Spark、 HDFS還是YARN，其都會(huì )首先假設所有問(wèn)題都已經(jīng)得到切實(shí)分發(fā)。其中部分工作需要盡可能避免被分發(fā)，因為這樣能使其運行速度更快。最讓我受不了的就是用select * from thousandrowtable這樣的操作拖慢MapReduce任務(wù)的運行速度。
四號痛點(diǎn): 多工作負載縮放
我們擁有Docker。我們擁有Yarn。我們還擁有Spark、Tez、MapReduce以及未來(lái)可能出現的一系列技術(shù)方案。我們還擁有多種資源池化實(shí)現工具，其中包含各類(lèi)不同優(yōu)先級及其它設定。如果大家選擇部署一個(gè)Java war文件，則可以在PaaS上進(jìn)行“自動(dòng)伸縮”。但如果大家希望在Hadoop上實(shí)現同樣的效果，那么情況就不太一樣了，因為在目前這些要求尚無(wú)法實(shí)現。我們智能寄希望大家習慣了編寫(xiě)Chef方案與腳本，因為這是達到以上目標的惟一辦法。
五號痛點(diǎn)：安全性
首先，為什么我們只能通過(guò)Kerberos實(shí)現單點(diǎn)登錄?云Web環(huán)境之下根本沒(méi)有類(lèi)似于Kerberos的方案可用。
其次，廠(chǎng)商之間奇怪的競爭方式對Hadoop造成了極大的扭曲，而這對任何人都不是件好事。在涉及到基礎性身份驗證及授權層面時(shí)，我們不得不使用兩套完全不同的堆棧，才能為Hadoop的全部組成部分提供安全性支持。加密方面的產(chǎn)品競爭我還可以理解(各類(lèi)方案都在以更小、更快、更強為發(fā)展目標)，但無(wú)論是選擇Ranger、Sentry或者是其它什么方案，為什么我們就不能擁有一套足以涵蓋全部Hadoop項目的驗證機制?公平地講，大數據領(lǐng)域目前的狀況比NoSQL還要糟糕; 隨便拉來(lái)一家宣稱(chēng)“我們熱愛(ài)開(kāi)源”的企業(yè)都能在自己“企業(yè)級”專(zhuān)用版本的LDAP集成部分當中塞進(jìn)幾百行開(kāi)源代碼。
六號痛點(diǎn): 分布式代碼優(yōu)化
在編譯器方面，大家可以編寫(xiě)優(yōu)化器來(lái)檢測循環(huán)內的非依賴(lài)性操作，同時(shí)自動(dòng)對其進(jìn)行提取與并行化調整。所謂“數據科學(xué)家”們編寫(xiě)出的Python代碼相當垃圾，根本沒(méi)辦法有效進(jìn)行問(wèn)題分配，而且會(huì )造成大量不必要的內存浪費。在這種情況下，需要由技術(shù)從牛挺身而出，嘗試理解前面那位“科學(xué)家”的想法并進(jìn)行優(yōu)化。
問(wèn)題在于，上述狀況幾乎跟大家在編譯原理書(shū)里看到的反而實(shí)例一模一樣。我猜隨著(zhù)技術(shù)的不斷發(fā)展，未來(lái)Zeppelin甚至是Spark本身會(huì )站出來(lái)幫助大家修復糟糕的代碼，并保證其與集群順暢協(xié)作。
七號痛點(diǎn)：機器學(xué)習映射
在具體實(shí)例當中，我們都能輕松分清集群化問(wèn)題、聚類(lèi)問(wèn)題或者其它一些歸類(lèi)工作。但似乎沒(méi)人愿意解決真正有難度的部分——對業(yè)務(wù)體系中的常見(jiàn)部分進(jìn)行映射、描述問(wèn)題并通過(guò)描述映射找到應當使用的具體算法。
除了金融行業(yè)之外，只有10%到30%的企業(yè)能夠保持有不同于行業(yè)常規情況的特色——換言之，我們可以將銷(xiāo)售、市場(chǎng)推廣、庫存、勞動(dòng)力等因素映射至一套通用模型，而后描述出適合使用的算法。這項工作不僅會(huì )改變我們處理業(yè)務(wù)的方式，同時(shí)也能極大擴展市場(chǎng)的整體規模。我們可以將其視為一種面向大數據的設計模式，只不過(guò)其更多是在強調業(yè)務(wù)方面的內容。
八號痛點(diǎn)：提取、轉換與加載
提取、轉換與加載(簡(jiǎn)稱(chēng)ETL)可以說(shuō)是每個(gè)大數據項目當中悄無(wú)聲息的預算殺手。我們都很清楚自己到底需要利用大數據技術(shù)做些什么，但相較于將注意力集中在業(yè)務(wù)需求身上，現在我們首先得搞定Flume、Oozie、Pig、Sqoop以及Kettle等等。之所以面臨這樣的情況，是因為我們的原始數據往往處于混亂的狀態(tài)。但真正令人驚訝的是，沒(méi)有哪家廠(chǎng)商愿意拿出一套無(wú)縫化處理方案來(lái)。雖然解決這類(lèi)問(wèn)題沒(méi)辦法讓你拿到諾貝爾獎，但卻能夠切實(shí)幫助到廣大大數據技術(shù)用戶(hù)。
    這些痛點(diǎn)我們避無(wú)可避，也是大數據本身無(wú)法落地的幾大重要原因。這些痛點(diǎn)無(wú)法解決就無(wú)法改變大數據被架空，留著(zhù)空洞的概念而無(wú)法落到實(shí)處的局面。 相關(guān)熱詞搜索：大數據時(shí)代數據空大數據分析海量信息