Hadoop與NoSQL最近一段時間已經成為網(wǎng)絡行家最為青睞的技術選擇方案，但根據(jù)某位開發(fā)人員兼技術撰稿人的觀點，許多企業(yè)在此類技術的投入方面“熱情過高”——事實上優(yōu)秀的在線SQL方案也完全能夠達到同樣的效果。
自從雅虎技術團隊以Hadoop為武器、一舉將谷歌拉下神壇以來，眾多企業(yè)相繼把這項技術引入業(yè)務流程當中。但相對于高昂的資金投入、巨大的精力消耗，Hadoop技術所帶來的優(yōu)勢卻顯得微乎其微。Tim O’Brien在本周三于圣克拉拉市舉行的O’Reilly Strata大會上表達了以上觀點。
“大家可能都有這種感覺，當我們在議程中談到此類技術時，最終都將歸結于其帶來的巨大開支，”他指出。
鑒于大數(shù)據(jù)技術對人力成本的極高要求(我們需要高薪聘請懂得如何使用Hadoop的相關人才)、實施流程的昂貴投入(我們需要將數(shù)據(jù)遷移至NoSQL或 HDFS當中，否則將毫無可靠性可言)以及意外狀況發(fā)生之頻繁(用戶可能不完全了解自己正在使用什么)，O’Brien對技術行業(yè)及其擁躉的極高熱情潑下一盆無情的冷水。
大數(shù)據(jù)是規(guī)模化的必然解決方案：如果大家需要監(jiān)控所有橫跨大陸的電話通話，MapReduce能幫上忙……如果大家需要以毫秒為單位搜索整個互聯(lián)網(wǎng)內容，MapReduce能幫上忙;如果大家需要運行全球最大的社交網(wǎng)絡，MapReduce能幫上忙;即使上述任務都引不起大家的興趣，大數(shù)據(jù)技術在數(shù)據(jù)庫擴展方面也能起到作用。
眾多企業(yè)對“大數(shù)據(jù)”技術的追捧可謂不遺余力卻又不辨是非，包括 MongoDB、Hadoop與Impala在內的全方位大數(shù)據(jù)方案導致公司技術堆棧既難于維護又不便理解，O’Brien表示。“我曾被無數(shù)次要求為生產流程提供幫助……但我甚至弄不清這些客戶到底用了多少套數(shù)據(jù)庫。”
對于某些大型企業(yè)，“大數(shù)據(jù)”產品的確是必要的;但對于其它規(guī)模較小的企業(yè)，大數(shù)據(jù)只能算是“實用性工具”;而另有一些企業(yè)只會在使用過程中“逐步被技術推向自己并不適合的解決方向，”他解釋道。
如果大家只有10TB甚至更少的數(shù)據(jù)需要加以分析，那么Postgres或其它一些典型處理系統(tǒng)就完全能夠搞定。但如果大家需要記錄的數(shù)據(jù)已經以PB為單位，那么盡快向Hadoop或其它同類方案傾斜吧。“別再等了，這是惟一的出路，”他建議稱。
位于金字塔頂部的技術驅動著80%的市場份額，O’Brien指出。“我并不是說新興企業(yè)就一定不該使用Hadoop，但就我所經歷的眾多項目來看，小規(guī)模公司最好先從MySQL開始——畢竟大部分用戶的有價值數(shù)據(jù)也就在GB級別。
即使是像谷歌這樣的業(yè)界巨頭也開始放下大數(shù)據(jù)前續(xù)技術BigTable與GFS學術論文的飄渺光環(huán)，由NoSQL及Hadoop社區(qū)的先驅者轉向如今的“Spanner”數(shù)據(jù)庫。
Spanner比其它同類產品更接似于SQL類關系型數(shù)據(jù)庫，這一次谷歌算是相時而動。眾多企業(yè)都已經開始選擇這條道路，像TransLattice這類對Spanner架構進行重新實現(xiàn)的方案受到廣泛關注。
也許NoSQL與Hadoop已經將不少企業(yè)帶入了死胡同?隨著營銷預算的緊縮與O’Brien的指導性意見，企業(yè)在技術普及方面的過度膨脹問題已經凸顯出來，剛剛接觸到大數(shù)據(jù)技術的入門用戶也開始抱持謹慎的態(tài)度。此類技術也許確實前景廣闊，但其最終成效還是要以企業(yè)用戶的聰明才智而定。
京公網(wǎng)安備 11010502049343號