如今,大資料已經成為時代的主題,企業對大資料的應用也愈加深入,隨著大資料的普及,有很多大資料的觀念需要被質疑,首先一點就是人們普遍認為你可以簡單地利用Hadoop,並且Hadoop便於使用。
問題是,Hadoop是一項技術,而大資料和技術無關。 大資料是和HTTP://www.aliyun.com/zixun/aggregation/12445.html">業務需求有關的。 事實上,大資料應該包括Hadoop和關聯式資料庫以及任何其它適合於我們手頭任務的技術。
例如,在Hadoop中對一個資料集做廣泛並且探索性的分析是很有意義的,但關聯式存儲對於那些尚未發現的東西進行運行分析則更好。 Hadoop對於在一個資料集中尋找最低水準的細節也很好用,但關聯式資料庫對於資料的存儲轉換和匯總則更有意義。 因此底線是,對於你的任何需求,要使用正確的技術。
對於Hadoop如何組合和處理大資料的技巧和方法,資料專家Anoop曾經在另一篇文章中提到過,一般情況下,為了得到最終的結果,資料需要加入多個資料集一起被處理和聯合。 Hadoop中有很多方法可以加入多個資料集。 MapReduce提供了Map端和Reduce端的資料連線。 這些連接是非平凡的連接,並且可能會是非常昂貴的操作。 Pig和Hive也具有同等的能力來申請連接到多個資料集。 Pig提供了複製連接,合併連接和傾斜連接(skewed join),並且Hive提供了map端的連接和完整外部連接來分析資料。
在大資料/Hadoop的世界,一些問題可能並不複雜,並且解決方案也是直截了當的,但面臨的挑戰是資料量。 在這種情況下需要不同的解決辦法來解決問題。 一些分析任務是從日誌檔中統計明確的ID的數目、在特定的日期範圍內改造存儲的資料、以及網友排名等。 所有這些任務都可以通過Hadoop中的多種工具和技術如MapReduce、Hive、Pig、Giraph和Mahout等來解決。 這些工具在自訂常式的説明下可以靈活地擴展它們的能力。
Hadoop是一個框架,不是一個解決方案,在解決大資料分析的問題上人們誤認為Hadoop可以立即有效工作,而實際上對於簡單的查詢,它是可以的。 但對於難一些的分析問題,Hadoop會迅速敗下陣來,因為需要你直接開發Map/Reduce代碼。 出於這個原因,Hadoop更像是J2EE程式設計環境而不是商業分析解決方案。 」所謂框架意味著你一定要在之上做個人化和業務相關的開發和實現,而這些都需要成本。
Hadoop是一個用來做一些非常複雜的資料分析的傑出工具。 但是具有諷刺意味的是,它也是需要大量的程式設計工作才能得到這些問題的答案。 這一點不止在資料分析應用方面,它其實反映了目前使用開源框架時候不得不面對的選型平衡問題。 當你在選型開源框架或代碼的時候,既要考慮清楚它能夠幫到你多少,節省多少時間和成本,提高多少效率。 也要知道由此而產生多少新增的成本,比如工程師的學習成本、開發和維護成本,以及未來的擴充性,包括如果使用的框架升級了,你和你的團隊是否要做相應的升級;甚至還要有安全性方面的考慮,畢竟開源框架的漏洞也是眾所周知的。
評論:
在大資料時代下,很多人都認為Hadoop便於使用,因此在大資料的應用過程中,Hadoop也是衝鋒陷陣,然而,Hadoop也會面臨不能解決的問題,Hadoop並非無所不能,因此,使用者在運用Hadoop過程中,應當量力而為。