前言 儘管在Hadoop與NoSQL部署方面做足了準備，同樣的問題仍然一次又一次反覆出現。現在業界是時候儘快搞定這些麻煩事了。 有時候一艘巨輪的側方出現了破洞，但業界卻決定坐等船體下沉、並把希望寄托在銷售救生艇身上。 也有些時候，這些問題似乎並沒到要鬧出人命的地步——類似我家裡浴室的狀況，只有往一邊 ...
前言
儘管在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等等。之所以面臨這樣的情況，是因為我們的原始數據往往處於混亂的狀態。但真正令人驚訝的是，沒有哪家廠商願意拿出一套無縫化處理方案來。雖然解決這類問題沒辦法讓你拿到諾貝爾獎，但卻能夠切實幫助到廣大大數據技術用戶。
