大數(shù)據(jù)技術(shù)的實現(xiàn)離不開很多其他的技術(shù)，我們提到最多的就是Hadoop技術(shù)，其實就目前而言，Hadoop技術(shù)看似是自成一套體系，其實并不是這樣的，Hadoop和Spark以及分布式數(shù)據(jù)庫其實也是存在差異的，我們就在這篇文章中給大家介紹一下這些內(nèi)容。

首先我們說一說大數(shù)據(jù)分析，現(xiàn)在的大數(shù)據(jù)分析體系以Hadoop生態(tài)為主，而近年來逐漸火熱的Spark技術(shù)也是主要的生態(tài)之一。可以這么說，Hadoop技術(shù)只能算是以HDFS+YARN作為基礎(chǔ)的分布式文件系統(tǒng)，而不是數(shù)據(jù)庫。我們提到的Hadoop的歷史可以向前追溯10年，當(dāng)年谷歌為了在幾萬臺PC服務(wù)器上構(gòu)建超大數(shù)據(jù)集合并提供極高性能的并發(fā)訪問能力，從而發(fā)明了一種新的技術(shù)，而這個技術(shù)，也是Hadoop誕生的理論基礎(chǔ)。如果我們從Hadoop的誕生背景可以看出，其主要解決的問題是超大規(guī)模集群下如何對非結(jié)構(gòu)化數(shù)據(jù)進行批處理計算。實際上，在Hadoop架構(gòu)中，一個分布式任務(wù)可以是類似傳統(tǒng)結(jié)構(gòu)化數(shù)據(jù)的關(guān)聯(lián)、排序、聚集操作，也可以是針對非結(jié)構(gòu)化數(shù)據(jù)的用戶自定義程序邏輯。

那么Hadoop的發(fā)展道路是什么樣的呢。最開始的Hadoop以Big、Hive和MapReduce三種開發(fā)接口為代表，分別適用于腳本批處理、SQL批處理以及用戶自定義邏輯類型的應(yīng)用。而Spark的發(fā)展更是如此，最開始的SparkRDD幾乎完全沒有SQL能力，還是套用了Hive發(fā)展出的Shark才能對SQL有了一部分的支持。但是，隨著企業(yè)用戶對Hadoop的使用越發(fā)廣泛，SQL已經(jīng)漸漸成為大數(shù)據(jù)平臺在傳統(tǒng)行業(yè)的主要訪問方式之一。  

下面我們就說一說分布式數(shù)據(jù)庫，分布式數(shù)據(jù)庫有著悠久的歷史，從以O(shè)racle RAC為代表的聯(lián)機交易型分布式數(shù)據(jù)庫，到IBM DB2 DPF統(tǒng)計分析性分布式數(shù)據(jù)庫，分布式數(shù)據(jù)庫覆蓋了OLTP與OLAP幾乎全部的數(shù)據(jù)應(yīng)用場景。而大部分分布式數(shù)據(jù)庫功能集中在結(jié)構(gòu)化計算與在線增刪改查上。但是，這些傳統(tǒng)的分布式數(shù)據(jù)庫以數(shù)倉及分析類OLAP系統(tǒng)為主，其局限性在于，其底層的關(guān)系型數(shù)據(jù)庫存儲結(jié)構(gòu)在效率上并不能滿足大量高并發(fā)的數(shù)據(jù)查詢以及大數(shù)據(jù)數(shù)據(jù)加工和分析的效率要求。因此，分布式數(shù)據(jù)庫在近幾年也有著極大的轉(zhuǎn)型，從單一的數(shù)據(jù)模型向多模的數(shù)據(jù)模型轉(zhuǎn)移，將OLTP、聯(lián)機高并發(fā)查詢以及支持大數(shù)據(jù)加工和分析結(jié)合起來，不再單獨以O(shè)LAP作為設(shè)計目標(biāo)。同時，分布式數(shù)據(jù)庫在訪問模式上也出現(xiàn)了K/V、文檔、寬表、圖等分支，支持除了SQL查詢語言之外的其他訪問模式，大大豐富了傳統(tǒng)分布式數(shù)據(jù)庫單一的用途。一般來說，多模數(shù)據(jù)庫的主要目的是為了滿足具有高性能要求的操作型需求以及目標(biāo)明確的數(shù)據(jù)倉庫功能，而不是類似大數(shù)據(jù)深度學(xué)習(xí)等數(shù)據(jù)挖掘場景。這就是分布式數(shù)據(jù)庫的實際情況。

我們在這篇文章中給大家介紹了大數(shù)據(jù)分析以及分布式數(shù)據(jù)庫的相關(guān)知識，通過這些內(nèi)容相信大家已經(jīng)理解了其中的具體區(qū)別了吧，如果這篇文章能夠幫助到大家這就是我們最大的心愿。