這些毫無根據(jù)的印象涉及所需技能儲(chǔ)備、技術(shù)方案類型以及技術(shù)匹配方式等多個(gè)層面，盲目偏信只會(huì)將大家引入歧途。

[[137548]]

大數(shù)據(jù)分析目前已經(jīng)成為技術(shù)業(yè)界的主流趨勢(shì)，每一家企業(yè)都開始將此類方案視為實(shí)現(xiàn)自身差異化優(yōu)勢(shì)的核心甚至是求得生存的關(guān)鍵所在。有鑒于此，關(guān)于大數(shù)據(jù)的各種誤解也開始不斷涌現(xiàn)。這些誤區(qū)不僅可能將大家引入歧途，甚至?xí)尭魑话褜氋F的資源投入到根本走不通的發(fā)展路線當(dāng)中。另外，此類誤區(qū)的存在當(dāng)然也會(huì)導(dǎo)致大家錯(cuò)過將預(yù)算資源投向更具意義的業(yè)務(wù)實(shí)踐方法的機(jī)會(huì)。

在今天的文章中，我們將一同了解九大千萬不可輕易著道的大數(shù)據(jù)與Hadoop相關(guān)認(rèn)識(shí)誤區(qū)。

誤區(qū)一：我們能夠輕松雇用到數(shù)據(jù)科學(xué)家

最近，我們公司某合作企業(yè)的一位售前工程師提到了尋找一位數(shù)據(jù)科學(xué)家到底有多困難。出于好奇，我詳細(xì)詢問了他們列出的合格人員條件，但答案實(shí)在是……他們需要需要一位數(shù)學(xué)博士，擁有計(jì)算機(jī)科學(xué)與MBA教育背景，此外還需要在這幾大領(lǐng)域當(dāng)中擁有實(shí)踐經(jīng)驗(yàn)?？吹竭@里我不禁要問：“你們要招的這位得有多大年紀(jì)，九十歲？”

下面來看實(shí)際情況：

•    優(yōu)秀的數(shù)學(xué)家往往傾向于使用Python，而且通常需要業(yè)務(wù)人士為其提供幫助。

•    優(yōu)秀的計(jì)算機(jī)科學(xué)人才確實(shí)擁有一定程度的數(shù)學(xué)認(rèn)知。

•    優(yōu)秀的計(jì)算機(jī)科學(xué)人才在處理一定數(shù)量的問題后能夠理解企業(yè)業(yè)務(wù)。

•    業(yè)務(wù)型人才了解數(shù)學(xué)知識(shí)。

•    專業(yè)人士往往擁有很強(qiáng)的知識(shí)指向性。

•    領(lǐng)導(dǎo)者應(yīng)負(fù)責(zé)將上述人才匯聚起來并協(xié)同工作。

由于前面提到的這家企業(yè)找不到合適的數(shù)據(jù)科學(xué)家人選，因此只能建立起擁有跨學(xué)科專業(yè)知識(shí)的工作小組。而這也是大部分企業(yè)必須采取的解決思路。

誤區(qū)二：關(guān)于大數(shù)據(jù)的一切都是新生事物

技術(shù)人員總是喜歡拋棄過去，而他們所宣揚(yáng)的首選工具要么前所未見、要么會(huì)產(chǎn)生大量后續(xù)問題。但這種印象與實(shí)際情況并不相符。

舉例來說，Kafka分布式消息系統(tǒng)被廣泛描述為一款大數(shù)據(jù)必需的新型工具產(chǎn)品。不過與其它消息系統(tǒng)比較起來，它的功能集顯得非常孱弱而且還遠(yuǎn)稱不上成熟。要說其中真正的新生事物，Kafka在架構(gòu)方面專門針對(duì)Hadoop平臺(tái)而且在設(shè)計(jì)思路中引入了大量分布式概念。如果能夠接受其種種缺陷，那么Kafka確實(shí)具備相當(dāng)?shù)膶?shí)用性。

也就是說，有時(shí)候我們需要使用更為復(fù)雜的路由及保障手段。在這類情況下，我們可以使用ActiveMQ或者其它更為穩(wěn)定可靠的選項(xiàng)。

誤區(qū)三：機(jī)器學(xué)習(xí)才是解決問題的正道

我估計(jì)約有85%的朋友會(huì)將機(jī)器學(xué)習(xí)視為一種簡單統(tǒng)計(jì)方案。但事實(shí)上，我們的常見問題往往只需要通過簡單的數(shù)學(xué)與分析機(jī)制即可解決，因此不要好高騖遠(yuǎn)、先從這里起步比較好。

誤區(qū)四：你很特別

正如哲學(xué)家Dirden曾經(jīng)說過，“你沒什么特別。你并不像雪花那樣精致而且獨(dú)一無二。”這里要向大家公布了項(xiàng)調(diào)查結(jié)果。目前技術(shù)業(yè)界當(dāng)中，約有半數(shù)從業(yè)者忙于編寫同樣的ETL腳本，旨在為大部分同類數(shù)據(jù)源進(jìn)行同樣的自定義分析處理。而且在任何規(guī)模的企業(yè)當(dāng)中，都有很多部門可能在重復(fù)著這方面的工作。

不用說，好好咨詢一下是著手推進(jìn)大數(shù)據(jù)工作的最佳前提。

誤區(qū)五：Hive速度極快

Hive速度并不快。它并不能在速度上給人留下深刻的印象。沒錯(cuò)，其新版本已經(jīng)得到了顯著改善，但它仍然沒辦法帶來良好的性能水平。它的規(guī)模擴(kuò)展能力出色，不過大家可能需要準(zhǔn)備好多種工具來將Hadoop與SQL加以匹配。

誤區(qū)六：我們可以使用少于十二節(jié)點(diǎn)的集群

Hadoop 2+幾乎已經(jīng)能夠運(yùn)行在十二節(jié)點(diǎn)集群之上——但如果節(jié)點(diǎn)數(shù)量進(jìn)一步減少，那么大家恐怕會(huì)面臨漫長到令人抓狂的啟動(dòng)時(shí)間。另外，我們?cè)谄渖线\(yùn)行的任何任務(wù)都會(huì)極為緩慢——有時(shí)候甚至根本無法完成。（當(dāng)然，在十二節(jié)點(diǎn)集群上運(yùn)行個(gè)‘hello world’還是不成問題的。）Hadoop 2運(yùn)行所需要的線程更多，這意味著我們需要為其提供更多節(jié)點(diǎn)與更大內(nèi)存容量。

由于可以將數(shù)據(jù)集駐留在內(nèi)存當(dāng)中，Spark能夠?qū)DFS載入時(shí)間控制在最低水平。

誤區(qū)七：數(shù)據(jù)節(jié)點(diǎn)的解決方案在于虛擬化

來自供應(yīng)商的答案是“錯(cuò)”。IT團(tuán)隊(duì)亦會(huì)在這個(gè)問題上猶豫不決。在這里我們要強(qiáng)調(diào)，不，大家不能在SAN上部署數(shù)據(jù)節(jié)點(diǎn)。而且如果將管理節(jié)點(diǎn)放在虛擬機(jī)系統(tǒng)當(dāng)中，那么日志寫入、任何記錄延遲狀況乃至數(shù)據(jù)節(jié)點(diǎn)的低IOPS或高延遲都有可能成為整套體系的性能瓶頸。

也就是說，Amazon Web Services以及其它同類方案能夠在解決這些問題的同時(shí)，繼續(xù)保持管理工作擁有合理的性能水平與可擴(kuò)展能力。當(dāng)然，大家也可以或者說需要將其從內(nèi)部文件服務(wù)器及外部企業(yè)宣傳網(wǎng)站當(dāng)中剔除出去，同時(shí)有效管理自己的硬件與虛擬化資源。

請(qǐng)記?。和掏履芰εc延遲呈正比關(guān)系。HDFS會(huì)在不同場(chǎng)景下對(duì)二者作出權(quán)衡。

誤區(qū)八：每個(gè)問題都屬于大數(shù)據(jù)問題

如果大家打算在數(shù)TB級(jí)別的數(shù)據(jù)集當(dāng)中將數(shù)個(gè)字段與數(shù)條狀態(tài)進(jìn)行匹配，那么這并不能算是大數(shù)據(jù)問題。千萬不要把每一種分析需求都先入為主地劃分到大數(shù)據(jù)范疇當(dāng)中。

誤區(qū)九：我們沒有什么大數(shù)據(jù)

盡管大數(shù)據(jù)在定義上確實(shí)是對(duì)龐大數(shù)據(jù)機(jī)進(jìn)行處理——不太準(zhǔn)確，但也可以這么表達(dá)——但大數(shù)據(jù)解決方案對(duì)于小規(guī)模數(shù)據(jù)集也同樣擁有良好的處理效果。因此，千萬不要在處理小數(shù)據(jù)時(shí)想當(dāng)然地將大數(shù)據(jù)分析機(jī)制排除在外。大家完全可以在面對(duì)數(shù)GB規(guī)模的數(shù)據(jù)時(shí)，仍然享受到Hadoop或者其它大數(shù)據(jù)技術(shù)成果所帶來的便利——當(dāng)然，具體情況要具體分析。

此外，我們往往擁有著一些自己并不知曉的大數(shù)據(jù)資產(chǎn)。很多在習(xí)慣上會(huì)被企業(yè)直接丟棄的數(shù)據(jù)當(dāng)中，實(shí)際包含有大量有價(jià)值信息。任何一家員工在五十名或者以上的企業(yè)都有可能擁有大數(shù)據(jù)——即使是規(guī)模更小的公司，也可以利用大數(shù)據(jù)思路進(jìn)行資產(chǎn)管理（例如財(cái)務(wù)數(shù)據(jù)等）。

原文鏈接：

http://www.infoworld.com/article/2936947/big-data/debunked-9-big-data-and-hadoop-myths.html