大數(shù)據(jù)無法落地 有九大痛點(diǎn)

盡管在Hadoop與NoSQL部署方面做足了準(zhǔn)備，同樣的問題仍然一次又一次反復(fù)出現(xiàn)?，F(xiàn)在業(yè)界是時候盡快搞定這些麻煩事了。

    有時候一艘巨輪的側(cè)方出現(xiàn)了破洞，但業(yè)界卻決定坐等船體下沉、并把希望寄托在銷售救生艇身上。

    也有些時候，這些問題似乎并沒到要鬧出人命的地步——類似我家里浴室的狀況，只有往一邊擰龍頭才會出水。過一陣子我可能會找機(jī)會修理一下，但事實(shí)上這個問題已經(jīng)存在了12年之久了。

    而在面對大數(shù)據(jù)業(yè)務(wù)時，我可以列出九個長久以來一直令人頭痛的問題，時至今日它們依然存在著并困擾著無數(shù)用戶。

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

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

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

    不少技術(shù)人員都開始在這方面做出探索，但要想真正讓成果實(shí)現(xiàn)市場化，我們至少需要搞定兩大競爭對手——AMD以及英偉達(dá)，也許再加上英特爾。除非它們愿意聯(lián)手合作，否則如果繼續(xù)像現(xiàn)在這樣把技術(shù)保密看作市場成功的實(shí)現(xiàn)途徑，那么問題永遠(yuǎn)也找不到理想的答案。

    大數(shù)據(jù)痛點(diǎn)二號:多工作負(fù)載縮放

    我們擁有Docker。我們擁有Yarn。我們還擁有Spark、Tez、MapReduce以及未來可能出現(xiàn)的一系列技術(shù)方案。我們還擁有多種資源池化實(shí)現(xiàn)工具，其中包含各類不同優(yōu)先級及其它設(shè)定。如果大家選擇部署一個Javawar文件，則可以在PaaS上進(jìn)行“自動伸縮”。但如果大家希望在Hadoop上實(shí)現(xiàn)同樣的效果，那么情況就不太一樣了。

    再有，存儲與處理體系之間的交互該如何處理?有時候大家需要以臨時性方式對存儲資源進(jìn)行擴(kuò)展與分發(fā)。我應(yīng)該有能力運(yùn)行自己的“月末統(tǒng)計”批量任務(wù)并將Docker鏡像自動部署到任意指定位置。而在我的任務(wù)完成之后，系統(tǒng)應(yīng)當(dāng)對其進(jìn)行反部署，并將資源重新分配給其它工作負(fù)載。應(yīng)用程序或者工作負(fù)載應(yīng)該根本不需要在這方面浪費(fèi)太多精力。

    但目前這些要求尚無法實(shí)現(xiàn)。我希望大家習(xí)慣了編寫Chef方案與腳本，因?yàn)檫@是達(dá)到以上目標(biāo)的惟一辦法。

    大數(shù)據(jù)痛點(diǎn)三號:NoSQL部署更令人頭痛

    為什么我已經(jīng)能夠利用ssh與sudo將鏡像導(dǎo)入Linux設(shè)備、為其指定Ambari并安裝像Hadoop這樣復(fù)雜度極高的項(xiàng)目，但卻仍然需要在MongoDB以及大部分其它數(shù)據(jù)庫的部署工作中浪費(fèi)時間與精力?當(dāng)然，我也可以編寫Chef自動化方案，但恕我仍對此無法認(rèn)同。

大數(shù)據(jù)痛點(diǎn)四號：查詢分析器/修復(fù)器

    當(dāng)初在使用JBoss的時候，我曾經(jīng)對Hibernate以及后來的JPA/EJB3進(jìn)行過大量調(diào)試。具體來講，主要工作包括查看日志記錄、找出存在n+1類查詢的位置、將其納入join并移除可能影響運(yùn)行效果的糟糕緩存配置。

    但有時候情況又完全相反：我們可以將每一套需要的表添加到系統(tǒng)當(dāng)中，但其返回速度卻慢得讓人抓狂。有時候，我打算在復(fù)雜程度更高的系統(tǒng)之上查看OracleEnterpriseManager及其分析結(jié)果，但返回的報告卻完全是一堆胡言亂語——這意味著其中存在問題。不過我可以同時著眼于兩套始終共同協(xié)作的表，并據(jù)此找到分析當(dāng)中存在的規(guī)律。我甚至考慮過利用編程方式解決問題。

    而現(xiàn)在，每次對NoSQL系統(tǒng)進(jìn)行調(diào)整時，我都會發(fā)現(xiàn)上述問題以不同形式表現(xiàn)出來：要么是跳轉(zhuǎn)次數(shù)太多、要么是查詢太過復(fù)雜，有時候我們的索引無法與where子句(即范圍合并)相匹配。簡而言之，我們將大量精力投入到了糟糕或者復(fù)雜查詢的優(yōu)化當(dāng)中，但除了開發(fā)者培訓(xùn)課程、我們似乎從來不會對這些查詢本身提出質(zhì)疑。這套系統(tǒng)似乎有種魔性，它同用戶的關(guān)系類似于：“嘿，你發(fā)來了這些查詢，我認(rèn)為它們看起來應(yīng)該像這樣……”

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

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

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

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

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

    我得承認(rèn)，我對Hadoop的第一印象就是在Hive當(dāng)中輸入selectcount(*)fromsomesmalltable。我覺得這種使用方式真的非常差勁。大家會發(fā)現(xiàn)其中存在問題，并意識到其分布效果并不理想。有些朋友甚至不必參考其它數(shù)據(jù)(例如行數(shù))就能發(fā)現(xiàn)我們沒辦法實(shí)現(xiàn)負(fù)載分布。通常來講，這些只是整體工作當(dāng)中的一部分(例如查找表)，但無論我們實(shí)際使用的是Hive、Spark、HDFS還是YARN，其都會首先假設(shè)所有問題都已經(jīng)得到切實(shí)分發(fā)。其中部分工作需要盡可能避免被分發(fā)，因?yàn)檫@樣能使其運(yùn)行速度更快。最讓我受不了的就是用select*fromthousandrowtable這樣的操作拖慢MapReduce任務(wù)的運(yùn)行速度。

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

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

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

    大數(shù)據(jù)痛點(diǎn)八號：安全性

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

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

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

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