阻礙大數據發展的九大痛處（我的角度）

前言

儘管在Hadoop與NoSQL部署方面作足了準備，一樣的問題仍然一次又一次反覆出現。如今業界是時候儘快搞定這些麻煩事了。

有時候一艘巨輪的側方出現了破洞，但業界卻決定坐等船體下沉、並把但願寄託在銷售救生艇身上。

也有些時候，這些問題彷佛並沒到要鬧出人命的地步——相似我家裏浴室的情況，只有往一邊擰龍頭纔會出水。過一陣子我可能會找機會修理一下，但事實上這個問題已經存在了12年之久了。

而在面對大數據業務時，我能夠列出九個長久以來一直使人頭痛的問題，時至今日它們依然存在着並困擾着無數用戶。

分享以前我仍是要推薦下我本身建立的大數據學習交流Qun531629188

不管是大牛仍是想轉行想學習的大學生

小編我都挺歡迎，今天的已經資訊上傳到羣文件，不按期分享乾貨，

包括我本身整理的一份最新的適合2018年學習的大數據教程，歡迎初學和進階中的小夥伴。

大數據痛點一號：GPU編程仍未獲得普及

CPU的使用成本仍然較爲昂貴，至少與GPU相比要貴得多。若是咱們可以面向GPU開發出更理想的執行標準以及更多表現出色的驅動程序，那麼相信一個新的市場將由此誕生。就目前來說，GPU的使用成本優點並沒能獲得很好的體現，這是由於咱們難以針對其進行編程，並且幾乎沒辦法在不創建特定模型的前提下完成這項任務。

這種狀況相似於，有些人但願編寫出相似於ODBC或者JDBC的代碼來處理某些高強度工做，並說服AMD或者英偉達將業務着眼點放在顯卡產品以外。假設咱們本來已經習慣了使用Spark實現各種計算任務，並且壓根不以爲這麼作有什麼問題; 但彷彿在一晚上之間，其餘人都開始構建所謂「GPGPU」集羣，這天然會讓咱們有點措手不及之感。

很多技術人員都開始在這方面作出探索，但要想真正讓成果實現市場化，咱們至少須要搞定兩大競爭對手——AMD以及英偉達，也許再加上英特爾。除非它們願意聯手合做，不然若是繼續像如今這樣把技術保密看做市場成功的實現途徑，那麼問題永遠也找不到理想的答案。

大數據痛點二號: 多工做負載縮放

咱們擁有Docker。咱們擁有Yarn。咱們還擁有Spark、Tez、MapReduce以及將來可能出現的一系列技術方案。咱們還擁有多種資源池化實現工具，其中包含各種不一樣優先級及其它設定。若是你們選擇部署一個Java war文件，則能夠在PaaS上進行「自動伸縮」。但若是你們但願在Hadoop上實現一樣的效果，那麼狀況就不太同樣了。

再有，存儲與處理體系之間的交互該如何處理？有時候你們須要以臨時性方式對存儲資源進行擴展與分發。我應該有能力運行本身的「月末統計」批量任務並將Docker鏡像自動部署到任意指定位置。而在個人任務完成以後，系統應當對其進行反部署，並將資源從新分配給其它工做負載。應用程序或者工做負載應該根本不須要在這方面浪費太多精力。

但目前這些要求尚沒法實現。我但願你們習慣了編寫Chef方案與腳本，由於這是達到以上目標的唯一辦法。

大數據痛點三號: NoSQL部署更使人頭痛

爲何我已經可以利用ssh與sudo將鏡像導入Linux設備、爲其指定Ambari並安裝像Hadoop這樣複雜度極高的項目，但卻仍然須要在MongoDB以及大部分其它數據庫的部署工做中浪費時間與精力？固然，我也能夠編寫Chef自動化方案，但恕我仍對此沒法認同。

大數據痛點四號：查詢分析器/修復器

當初在使用JBoss的時候，我曾經對Hibernate以及後來的JPA/EJB3進行過大量調試。具體來說，主要工做包括查看日誌記錄、找出存在n+1類查詢的位置、將其歸入join並移除可能影響運行效果的糟糕緩存配置。

但有時候狀況又徹底相反：咱們能夠將每一套須要的表添加到系統當中，但其返回速度卻慢得讓人抓狂。有時候，我打算在複雜程度更高的系統之上查看Oracle Enterprise Manager及其分析結果，但返回的報告卻徹底是一堆胡言亂語——這意味着其中存在問題。不過我能夠同時着眼於兩套始終共同協做的表，並據此找到分析當中存在的規律。我甚至考慮過利用編程方式解決問題。

而如今，每次對NoSQL系統進行調整時，我都會發現上述問題以不一樣形式表現出來：要麼是跳轉次數太多、要麼是查詢太過複雜，有時候咱們的索引沒法與where子句（即範圍合併）相匹配。簡而言之，咱們將大量精力投入到了糟糕或者複雜查詢的優化當中，但除了開發者培訓課程、咱們彷佛曆來不會對這些查詢自己提出質疑。這套系統彷佛有種魔性，它同用戶的關係相似於：「嘿，你發來了這些查詢，我認爲它們看起來應該像這樣……」

好吧，我猜不少從業者都以完成這些本能夠經過自動化方式實現的工做爲生。必須認可，我很慶幸本身已經渡過了基層工做時期，不再用爲這些雜事煩惱了。

大數據痛點五號: 分佈式代碼優化

我估計Spark當中的大量小功能及小設定會帶來第四點裏提到的各種問題。在編譯器方面，你們能夠編寫優化器來檢測循環內的非依賴性操做，同時自動對其進行提取與並行化調整。我在分佈式計算領域常常會見到這類狀況。所謂「數據科學家」們編寫出的Python代碼至關垃圾，根本沒辦法有效進行問題分配，並且會形成大量沒必要要的內存浪費。在這種狀況下，須要由技術從牛自告奮勇，嘗試理解前面那位「科學家」的想法並進行優化。

問題在於，上述情況幾乎跟你們在編譯原理書裏看到的反而實例如出一轍。我猜隨着技術的不斷髮展，將來Zeppelin甚至是Spark自己會站出來幫助你們修復糟糕的代碼，並保證其與集羣順暢協做。

大數據痛點六號：分佈式名存實亡

我得認可，我對Hadoop的第一印象就是在Hive當中輸入select count(*) from somesmalltable。我以爲這種使用方式真的很是差勁。你們會發現其中存在問題，並意識到其分佈效果並不理想。有些朋友甚至沒必要參考其它數據（例如行數）就能發現咱們沒辦法實現負載分佈。一般來說，這些只是總體工做當中的一部分（例如查找表），但不管咱們實際使用的是Hive、Spark、HDFS仍是YARN，其都會首先假設全部問題都已經獲得切實分發。其中部分工做須要儘量避免被分發，由於這樣能使其運行速度更快。最讓我受不了的就是用select * from thousandrowtable這樣的操做拖慢MapReduce任務的運行速度。

大數據痛點七號：機器學習映射

在具體實例當中，咱們都能輕鬆分清集羣化問題、聚類問題或者其它一些歸類工做。但彷佛沒人願意解決真正有難度的部分——對業務體系中的常見部分進行映射、描述問題並經過描述映射找到應當使用的具體算法。

除了金融行業以外，只有10%到30%的企業可以保持有不一樣於行業常規狀況的特點——換言之，咱們能夠將銷售、市場推廣、庫存、勞動力等因素映射至一套通用模型，然後描述出適合使用的算法。這項工做不只會改變咱們處理業務的方式，同時也能極大擴展市場的總體規模。咱們能夠將其視爲一種面向大數據的設計模式，只不過其更可能是在強調業務方面的內容。

大數據痛點八號：安全性

首先，爲何咱們只能經過Kerberos實現單點登陸？雲Web環境之下根本沒有相似於Kerberos的方案可用。

其次，廠商之間奇怪的競爭方式對Hadoop形成了極大的扭曲，而這對任何人都不是件好事。在涉及到基礎性身份驗證及受權層面時，咱們不得不使用兩套徹底不一樣的堆棧，才能爲Hadoop的所有組成部分提供安全性支持。加密方面的產品競爭我還能夠理解（各種方案都在以更小、更快、更強爲發展目標），但不管是選擇Ranger、Sentry或者是其它什麼方案，爲何咱們就不能擁有一套足以涵蓋所有Hadoop項目的驗證機制？公平地講，大數據領域目前的情況比NoSQL還要糟糕; 隨便拉來一家宣稱「咱們熱愛開源」的企業都能在本身「企業級」專用版本的LDAP集成部分當中塞進幾百行開源代碼。

大數據痛點九號：提取、轉換與加載

提取、轉換與加載（簡稱ETL）能夠說是每一個大數據項目當中悄無聲息的預算殺手。咱們都很清楚本身到底須要利用大數據技術作些什麼，但相較於將注意力集中在業務需求身上，如今咱們首先得搞定Flume、Oozie、Pig、Sqoop以及Kettle等等。之因此面臨這樣的狀況，是由於咱們的原始數據每每處於混亂的狀態。但真正使人驚訝的是，沒有哪家廠商願意拿出一套無縫化處理方案來。雖然解決這類問題沒辦法讓你拿到諾貝爾獎，但卻可以切實幫助到廣大大數據技術用戶。