工控網(wǎng)首頁(yè)
>

新聞中心

>

業(yè)界動(dòng)態(tài)

>

大數(shù)據(jù),光鮮之下隱憂重重

大數(shù)據(jù),光鮮之下隱憂重重

2016/6/1 15:37:28

昨天剛說(shuō)完,大數(shù)據(jù)工業(yè)4.0時(shí)代企業(yè)決策的隱形推手。今天繼續(xù)深扒大數(shù)據(jù)。雖然大數(shù)據(jù)應(yīng)用前景光明,是資本和市場(chǎng)的寵兒,但哪些深藏于光鮮之下的不完美和隱憂也同樣不容忽視。


大數(shù)據(jù)痛點(diǎn)一號(hào):GPU編程仍未得到普及

  CPU的使用成本仍然較為昂貴,至少與GPU相比要貴得多。如果我們能夠面向GPU開(kāi)發(fā)出更理想的執(zhí)行標(biāo)準(zhǔn)以及更多表現(xiàn)出色的驅(qū)動(dòng)程序,那么相信 一個(gè)新的市場(chǎng)將由此誕生。就目前來(lái)講,GPU的使用成本優(yōu)勢(shì)并沒(méi)能得到很好的體現(xiàn),這是因?yàn)槲覀冸y以針對(duì)其進(jìn)行編程,而且?guī)缀鯖](méi)辦法在不建立特定模型的前 提下完成這項(xiàng)任務(wù)。

  這種情況類(lèi)似于,有些人希望編寫(xiě)出類(lèi)似于ODBC或者JDBC的代碼來(lái)處理某些高強(qiáng)度工作,并說(shuō)服AMD或者英偉達(dá)將業(yè)務(wù)著眼點(diǎn)放在顯卡產(chǎn)品之 外。假設(shè)我們?cè)疽呀?jīng)習(xí)慣了使用Spark實(shí)現(xiàn)各類(lèi)計(jì)算任務(wù),而且壓根不覺(jué)得這么做有什么問(wèn)題; 但仿佛在一夜之間,其他人都開(kāi)始構(gòu)建所謂“GPGPU”集群,這自然會(huì)讓我們有點(diǎn)措手不及之感。

  不少技術(shù)人員都開(kāi)始在這方面做出探索,但要想真正讓成果實(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)工具,其中包含各類(lèi)不同優(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í)慣了編寫(xiě)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)然,我也可以編寫(xiě)Chef自動(dòng)化方案,但恕我仍對(duì)此無(wú)法認(rèn)同。


大數(shù)據(jù)痛點(diǎn)四號(hào):查詢(xún)分析器/修復(fù)器

  當(dāng)初在使用JBoss的時(shí)候,我曾經(jīng)對(duì)Hibernate以及后來(lái)的JPA/EJB3進(jìn)行過(guò)大量調(diào)試。具體來(lái)講,主要工作包括查看日志記錄、找出存在n+1類(lèi)查詢(xún)的位置、將其納入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ù)太多、要么是查詢(xún)太過(guò)復(fù)雜,有時(shí)候我們的索引無(wú) 法與where子句(即范圍合并)相匹配。簡(jiǎn)而言之,我們將大量精力投入到了糟糕或者復(fù)雜查詢(xún)的優(yōu)化當(dāng)中,但除了開(kāi)發(fā)者培訓(xùn)課程、我們似乎從來(lái)不會(huì)對(duì)這些 查詢(xún)本身提出質(zhì)疑。這套系統(tǒng)似乎有種魔性,它同用戶的關(guān)系類(lèi)似于:“嘿,你發(fā)來(lái)了這些查詢(xún),我認(rèn)為它們看起來(lái)應(yīng)該像這樣……”

好吧,我猜很多從業(yè)者都以完成這些本可以通過(guò)自動(dòng)化方式實(shí)現(xiàn)的工作為生。必須承認(rèn),我很慶幸自己已經(jīng)渡過(guò)了基層工作時(shí)期,再也不用為這些瑣事煩惱了。


大數(shù)據(jù)痛點(diǎn)五號(hào): 分布式代碼優(yōu)化

  我估計(jì)Spark當(dāng)中的大量小功能及小設(shè)定會(huì)帶來(lái)第四點(diǎn)里提到的各類(lèi)問(wèn)題。在編譯器方面,大家可以編寫(xiě)優(yōu)化器來(lái)檢測(cè)循環(huán)內(nèi)的非依賴(lài)性操作,同時(shí)自 動(dòng)對(duì)其進(jìn)行提取與并行化調(diào)整。我在分布式計(jì)算領(lǐng)域經(jīng)常會(huì)見(jiàn)到這類(lèi)情況。所謂“數(shù)據(jù)科學(xué)家”們編寫(xiě)出的Python代碼相當(dāng)垃圾,根本沒(méi)辦法有效進(jìn)行問(wèn)題分 配,而且會(huì)造成大量不必要的內(nèi)存浪費(fèi)。在這種情況下,需要由技術(shù)從牛挺身而出,嘗試?yán)斫馇懊婺俏弧翱茖W(xué)家”的想法并進(jìn)行優(yōu)化。

問(wèn)題在于,上述狀況幾乎跟大家在編譯原理書(shū)里看到的反而實(shí)例一模一樣。我猜隨著技術(shù)的不斷發(fā)展,未來(lái)Zeppelin甚至是Spark本身會(huì)站出來(lái)幫助大家修復(fù)糟糕的代碼,并保證其與集群順暢協(xié)作。


大數(shù)據(jù)痛點(diǎn)六號(hào):分布式名不副實(shí)

  我得承認(rèn),我對(duì)Hadoop的第一印象就是在Hive當(dāng)中輸入select count(*) from somesmalltable。我覺(jué)得這種使用方式真的非常差勁。大家會(huì)發(fā)現(xiàn)其中存在問(wèn)題,并意識(shí)到其分布效果并不理想。有些朋友甚至不必參考其它數(shù)據(jù) (例如行數(shù))就能發(fā)現(xiàn)我們沒(méi)辦法實(shí)現(xiàn)負(fù)載分布。通常來(lái)講,這些只是整體工作當(dāng)中的一部分(例如查找表),但無(wú)論我們實(shí)際使用的是Hive、Spark、 HDFS還是YARN,其都會(huì)首先假設(shè)所有問(wèn)題都已經(jīng)得到切實(shí)分發(fā)。其中部分工作需要盡可能避免被分發(fā),因?yàn)檫@樣能使其運(yùn)行速度更快。最讓我受不了的就是用select * from thousandrowtable這樣的操作拖慢MapReduce任務(wù)的運(yù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ù)太多、要么是查詢(xún)太過(guò)復(fù)雜,有時(shí)候我們的索引無(wú) 法與where子句(即范圍合并)相匹配。簡(jiǎn)而言之,我們將大量精力投入到了糟糕或者復(fù)雜查詢(xún)的優(yōu)化當(dāng)中,但除了開(kāi)發(fā)者培訓(xùn)課程、我們似乎從來(lái)不會(huì)對(duì)這些 查詢(xún)本身提出質(zhì)疑。這套系統(tǒng)似乎有種魔性,它同用戶的關(guān)系類(lèi)似于:“嘿,你發(fā)來(lái)了這些查詢(xún),我認(rèn)為它們看起來(lái)應(yīng)該像這樣……”

  好吧,我猜很多從業(yè)者都以完成這些本可以通過(guò)自動(dòng)化方式實(shí)現(xiàn)的工作為生。必須承認(rèn),我很慶幸自己已經(jīng)渡過(guò)了基層工作時(shí)期,再也不用為這些瑣事煩惱了。

  

大數(shù)據(jù)痛點(diǎn)七號(hào):機(jī)器學(xué)習(xí)映射

  在具體實(shí)例當(dāng)中,我們都能輕松分清集群化問(wèn)題、聚類(lèi)問(wèn)題或者其它一些歸類(lèi)工作。但似乎沒(méi)人愿意解決真正有難度的部分——對(duì)業(yè)務(wù)體系中的常見(jiàn)部分進(jìn)行映射、描述問(wèn)題并通過(guò)描述映射找到應(yīng)當(dāng)使用的具體算法。

除了金融行業(yè)之外,只有10%到30%的企業(yè)能夠保持有不同于行業(yè)常規(guī)情況的特色——換言之,我們可以將銷(xiāo)售、市場(chǎng)推廣、庫(kù)存、勞動(dòng)力等因素映射 至一套通用模型,而后描述出適合使用的算法。這項(xiàng)工作不僅會(huì)改變我們處理業(yè)務(wù)的方式,同時(shí)也能極大擴(kuò)展市場(chǎng)的整體規(guī)模。我們可以將其視為一種面向大數(shù)據(jù)的 設(shè)計(jì)模式,只不過(guò)其更多是在強(qiáng)調(diào)業(yè)務(wù)方面的內(nèi)容。


大數(shù)據(jù)痛點(diǎn)八號(hào):安全性

  首先,為什么我們只能通過(guò)Kerberos實(shí)現(xiàn)單點(diǎn)登錄?云Web環(huán)境之下根本沒(méi)有類(lèi)似于Kerberos的方案可用。

其次,廠商之間奇怪的競(jìng)爭(zhēng)方式對(duì)Hadoop造成了極大的扭曲,而這對(duì)任何人都不是件好事。在涉及到基礎(chǔ)性身份驗(yàn)證及授權(quán)層面時(shí),我們不得不使用 兩套完全不同的堆棧,才能為Hadoop的全部組成部分提供安全性支持。加密方面的產(chǎn)品競(jìng)爭(zhēng)我還可以理解(各類(lèi)方案都在以更小、更快、更強(qiáng)為發(fā)展目標(biāo)), 但無(wú)論是選擇Ranger、Sentry或者是其它什么方案,為什么我們就不能擁有一套足以涵蓋全部Hadoop項(xiàng)目的驗(yàn)證機(jī)制?公平地講,大數(shù)據(jù)領(lǐng)域目 前的狀況比NoSQL還要糟糕; 隨便拉來(lái)一家宣稱(chēng)“我們熱愛(ài)開(kāi)源”的企業(yè)都能在自己“企業(yè)級(jí)”專(zhuān)用版本的LDAP集成部分當(dāng)中塞進(jìn)幾百行開(kāi)源代碼。


大數(shù)據(jù)痛點(diǎn)九號(hào):提取、轉(zhuǎn)換與加載

  提取、轉(zhuǎn)換與加載(簡(jiǎn)稱(chēng)ETL)可以說(shuō)是每個(gè)大數(shù)據(jù)項(xiàng)目當(dāng)中悄無(wú)聲息的預(yù)算殺手。我們都很清楚自己到底需要利用大數(shù)據(jù)技術(shù)做些什么,但相較于將注 意力集中在業(yè)務(wù)需求身上,現(xiàn)在我們首先得搞定Flume、Oozie、Pig、Sqoop以及Kettle等等。之所以面臨這樣的情況,是因?yàn)槲覀兊脑?數(shù)據(jù)往往處于混亂的狀態(tài)。但真正令人驚訝的是,沒(méi)有哪家廠商愿意拿出一套無(wú)縫化處理方案來(lái)。雖然解決這類(lèi)問(wèn)題沒(méi)辦法讓你拿到諾貝爾獎(jiǎng),但卻能夠切實(shí)幫助到 廣大大數(shù)據(jù)技術(shù)用戶。


審核編輯(
王靜
)
投訴建議

提交

查看更多評(píng)論
其他資訊

查看更多

直播定檔!見(jiàn)證西門(mén)子與中科摩通聯(lián)手打造汽車(chē)電子智能制造新范式

重磅議程搶先看|揭秘行業(yè)熱點(diǎn),引領(lǐng)技術(shù)潮流

光亞論壇·2024 智能產(chǎn)業(yè)聚合高峰論壇舉辦!

新訊受邀參加華為Redcap產(chǎn)業(yè)峰會(huì),并榮獲RedCap生態(tài)合作獎(jiǎng)!

2024年斯凱孚創(chuàng)新峰會(huì)暨新產(chǎn)品發(fā)布會(huì)召開(kāi),以創(chuàng)新產(chǎn)品矩陣重構(gòu)旋轉(zhuǎn)