大數(shù)據基礎架構總結

大多數(shù)的技術突破來源于實際的產品需要，大數(shù)據最初誕生于谷歌的搜索引擎中。隨著web2.0時代的發(fā)展，互聯(lián)網上數(shù)據量呈獻爆炸式的增長，為了滿足信息搜索的需要，對大規(guī)模數(shù)據的存儲提出了非常強勁的需要?；诔杀镜目紤]，通過提升硬件來解決大批量數(shù)據的搜索越來越不切實際，于是谷歌提出了一種基于軟件的可靠文件存儲體系GFS，使用普通的PC機來并行支撐大規(guī)模的存儲。存進去的數(shù)據是低價值的，只有對數(shù)據進行過加工才能滿足實際的應用需要，于是谷歌又創(chuàng)造了MapReduce這一計算模型，該模型能夠利用集群的力量將復雜的運算拆分到每一臺普通PC上，計算完成后通過匯總得到最終的計算結果，這樣就能夠通過直接增加機器數(shù)量就獲得更好的運算能力了。

有了GFS和MapReduce之后，文件的存儲和運算得到了解決，這時候又出現(xiàn)了新的問題。GFS的隨機讀寫能力很差，而谷歌有需要一種來存放格式化數(shù)據的數(shù)據庫，原本通過單機的數(shù)據庫就能解決的問題到了谷歌那里就悲劇了，于是神器的谷歌就又開發(fā)了一套BigTable系統(tǒng)，利用GFS的文件存儲系統(tǒng)外加一個分布式的鎖管理系統(tǒng)Chubby就設計出來了BigTable這樣一個列式的數(shù)據庫系統(tǒng)。

在谷歌完成了上述的系統(tǒng)后，就把其中的思想作為論文發(fā)布出來了，基于這些論文，出現(xiàn)了一個用JAVA寫的類GFS開源項目Hadoop，最開始hadoop的贊助人是yahoo，后來這個項目成了Apche的頂級項目。

大數(shù)據的解決方案：

谷歌的那一套系統(tǒng)是閉源的，開源的Hadoop于是就廣泛傳播開來了。

和谷歌那套系統(tǒng)類似，Hadoop的最核心的存儲層叫做HDFS，全稱是Hadoop文件存儲系統(tǒng)，有了存儲系統(tǒng)還要有分析系統(tǒng)，于是就有了開源版本的MapReduce，類似的參照BigTable就有了Hbase。一開源之后整個系統(tǒng)用的人就多了，于是大家都像要各種各樣的特性。facebook的那些人覺得mapreduce程序太難寫，于是就開發(fā)了Hive，Hive就是一套能把SQL語句轉成Mapreduce的工具，有了這套工具只要你會SQL就可以來Hadoop上寫mapreduce程序分析數(shù)據了。對了，參考chubby，我們有了開源的ZooKeeper來作為分布式鎖服務的提供者。

由于Hadoop最開始設計是用來跑文件的，對于數(shù)據的批處理來說這沒什么問題，有一天突然大家想要一個實時的查詢服務，數(shù)據這么大，要滿足實時查詢首先要拋開的是mapreduce，因為它真的好慢。2008年的時候一家叫Cloudera的公司出現(xiàn)了，他們的目標是要做hadoop界的redhat，把各種外圍系統(tǒng)打包進去組成一個完整的生態(tài)系統(tǒng)，后來他們開發(fā)出來了impala，impala的速度比mapreduce在實時分析上的效率有了幾十倍的提升，后來hadoop的創(chuàng)始人Doug Cutting也加入了cloudera。這時候學院派也開始發(fā)力了，加州大學伯克利分校開發(fā)出來了Spark來做實時查詢處理，剛開始Spark的語法好詭異，后來慢慢出現(xiàn)了Shark項目，漸漸的使得Spark向SQL語法靠近。

未來的發(fā)展趨勢：

時代的發(fā)展決定了未來幾乎就要變成數(shù)據的時代了，在這樣的一個時代，大數(shù)據的需求越來越深，摒棄過去的抽樣調查，改為全量的統(tǒng)計分析，從一些原本無意義的數(shù)據中挖掘價值。當前大數(shù)據已經開始逐漸服務于我們的生活，搜索、科學、用戶分析。。。

為了進一步提供大數(shù)據的分析能力，內存計算的概念在未來還會持續(xù)很長的時間，通過內存計算，摒棄磁盤IO對性能的天花板作用，將運算的結果以實時的方式呈獻在我們面前。