在大數(shù)據(jù)環(huán)境中，數(shù)據(jù)源非常豐富，數(shù)據(jù)類型也多種多樣。存儲和分析的數(shù)據(jù)量巨大，對數(shù)據(jù)表示的要求很高，并且高度重視數(shù)據(jù)處理的效率和可用性。因此需要一些數(shù)據(jù)分析技術來完成。那么大數(shù)據(jù)有哪些關鍵技術大數(shù)據(jù)處理數(shù)據(jù)的基本處理流程與傳統(tǒng)數(shù)據(jù)處理沒有太大區(qū)別。主要區(qū)別在于：由于大數(shù)據(jù)必須處理大量的非結構化數(shù)據(jù)，因此可以在每個處理鏈接中使用MapReduce和其他方法進行并行處理。

　　1.數(shù)據(jù)系統(tǒng)的架構

大數(shù)據(jù)處理系統(tǒng)不管結構如何復雜，采用的技術千差萬別，但是總體上總可以分為以下的幾個重要部分。

從數(shù)據(jù)處理的一般流程可以看到，在大數(shù)據(jù)環(huán)境下需要的關鍵技術主要針對海量數(shù)據(jù)的存儲和海量數(shù)據(jù)的運算。傳統(tǒng)的關系數(shù)據(jù)庫經(jīng)過近40年的發(fā)展已經(jīng)成為了一門成熟同時仍在不斷演進的數(shù)據(jù)管理和分析技術，結構化查詢語言（SQL）作為存取關系數(shù)據(jù)庫的語言得到了標準化，其功能和表達能力也得到的不斷增強。但是，關系數(shù)據(jù)管理系統(tǒng)的擴展性在互聯(lián)網(wǎng)環(huán)境下遇到了前所未有的障礙，不能勝任大數(shù)據(jù)分析的要求。關系數(shù)據(jù)管理模型追求的是高度的一致性和正確性。縱向擴展系統(tǒng)，通過增加或者更換CPU、內存、硬盤以擴展單個節(jié)點的能力，終會遇到“瓶頸”。

　　2.分布式文件系統(tǒng)

文件系統(tǒng)是支持大數(shù)據(jù)應用的基礎。Google是有史以來唯一需要處理如此海量數(shù)據(jù)的大公司。對于Google而言，現(xiàn)有的方案已經(jīng)難以滿足其如此大的數(shù)據(jù)量的存儲，為此Google提出了一種分布式的文件管理系統(tǒng)——GFS。

GFS與傳統(tǒng)的分布式文件系統(tǒng)有很多相同的目標，比如，性能、可伸縮性、可靠性以及可用性。但是，GFS的成功之處在于其與傳統(tǒng)文件系統(tǒng)的不同。GFS的設計思路主要基于以下的假設：對于系統(tǒng)而言，組件失敗是一種常態(tài)而不是異常。GFS是構建于大量廉價的服務器之上的可擴展的分布式文件系統(tǒng)，采用主從結構。通過數(shù)據(jù)分塊、追加更新等方式實現(xiàn)了海量數(shù)據(jù)的高效存儲，所示給出了GFS體系結構。但是隨著業(yè)務量的進一步變化，GFS逐漸無法適應需求。Google對GFS進行了設計，實現(xiàn)了Colosuss系統(tǒng)，該系統(tǒng)能夠很好地解決GFS單點故障和海量小文件存儲的問題。

除了Google的GFS，眾多的企業(yè)和學者也從不同的方面對滿足大數(shù)據(jù)存儲需求的文件系統(tǒng)進行了詳細的研究。微軟開發(fā)的Cosmos支撐其搜索、廣告業(yè)務。HDFS、FastDFS、OpenAFS和CloudStore都是類似GFS的開源實現(xiàn)。類GFS的分布式文件系統(tǒng)主要針對大文件而設計，但是在圖片存儲等應用場景中，文件系統(tǒng)主要存儲海量小文件，F(xiàn)acebook為此推出了專門針對海量小文件的文件系統(tǒng)Haystack，通過多個邏輯文件共享同一個物理文件，增加緩存層、部分元數(shù)據(jù)加載到內存等方式有效地解決了海量小文件存儲的問題。Lustre是一種大規(guī)模、安全可靠的，具備高可靠性的集群文件系統(tǒng)，由SUN公司開發(fā)和維護。該項目主要的目的就是開發(fā)下一代的集群文件系統(tǒng)，可以支持超過10 000個節(jié)點，數(shù)以拍字節(jié)的數(shù)量存儲系統(tǒng)。

　　3.分布式數(shù)據(jù)處理系統(tǒng)

大數(shù)據(jù)的處理模式分為流處理和批處理兩種。流處理是直接處理，批處理采用先存儲再處理。

流處理將數(shù)據(jù)視為流，源源不斷的數(shù)據(jù)形成數(shù)據(jù)流。當新的數(shù)據(jù)到來即立即處理并返回所需的結果。大數(shù)據(jù)的實時處理是一個極具挑戰(zhàn)性的工作，數(shù)據(jù)具有大規(guī)模、持續(xù)到達的特點。因此，如果要求實時的處理大數(shù)據(jù)，必然要求采用分布式的方式，在這種情況下，除了應該考慮分布式系統(tǒng)的一致性問題，還將涉及到分布式系統(tǒng)網(wǎng)絡時延的影響，這都增加了大數(shù)據(jù)流處理的復雜性。目前比較有代表性的開源流處理系統(tǒng)主要有：Twitter的Storm、Yahoo的S4以及Linkedin的Kafka等。

　　4.分布式數(shù)據(jù)庫系統(tǒng)

傳統(tǒng)的關系模型分布式數(shù)據(jù)庫難以適應大數(shù)據(jù)時代的要求，主要的原因有以下幾點：

1）規(guī)模效應帶來的壓力。大數(shù)據(jù)時代的數(shù)據(jù)遠遠超出單機處理能力，分布式技術是必然的選擇。傳統(tǒng)的數(shù)據(jù)庫傾向于采用縱向擴展的方式，這種方式下性能的增加遠低于數(shù)據(jù)的增加速度。大數(shù)據(jù)采用數(shù)據(jù)庫系統(tǒng)應該是橫向發(fā)展的，這種方式具有更好的擴展性。

2）數(shù)據(jù)類型的多樣性和低價值密度性。傳統(tǒng)的數(shù)據(jù)庫適合結構清晰，有明確應用目的的數(shù)據(jù)，數(shù)據(jù)的價值密度相對較高。在大數(shù)據(jù)時代數(shù)據(jù)的存在的形式是多樣的，各種半結構化、非結構化的數(shù)據(jù)是大數(shù)據(jù)的重要組成部分。如何利用如此多樣、海量的低價值密度的數(shù)據(jù)是大數(shù)據(jù)時代數(shù)據(jù)庫面臨的重要挑戰(zhàn)之一。

3）設計理念的沖突。關系數(shù)據(jù)庫追求的是“一種尺寸適用所有”，但在大數(shù)據(jù)時代不同的應用領域在數(shù)據(jù)理性、數(shù)據(jù)處理方式以及數(shù)據(jù)處理時間的要求上千差萬別。實際處理中，不可能存在一種統(tǒng)一的數(shù)據(jù)存儲方式適應所有場景。

　　5.大數(shù)據(jù)系統(tǒng)的開源實現(xiàn)平臺

除了商業(yè)化的大數(shù)據(jù)處理方案，還有一些開源的項目也在積極的加入到大數(shù)據(jù)的研究當中。Hadoop是一個開源分布式計算平臺，它是MapReduce計算機模型的載體。借助于Hadoop，軟件開發(fā)者可以輕松地編出分布式并行程序，從而在計算機集群上完成海量數(shù)據(jù)的計算。

主要結合大數(shù)據(jù)的產(chǎn)生背景、需求和系統(tǒng)結構，介紹了當前全球在大數(shù)據(jù)技術方面的進展情況。從分析可以看到，大數(shù)據(jù)系統(tǒng)的解決方案必將落地于現(xiàn)有的云計算平臺。云計算平臺的分布式文件系統(tǒng)、分布式運算模式和分布式數(shù)據(jù)庫管理技術都為解決大數(shù)據(jù)問題提供了思路和現(xiàn)成的平臺。

上述就是關于大數(shù)據(jù)有哪些關鍵技術的全部內容，想了解更多關于大數(shù)據(jù)的信息，請繼續(xù)關注中培偉業(yè)。