數(shù)據(jù)分析工作雖然隱藏在業(yè)務(wù)系統(tǒng)背后，但是具有非常重要的作用，數(shù)據(jù)分析的結(jié)果對決策、業(yè)務(wù)發(fā)展有著舉足輕重的作用。隨著大數(shù)據(jù)技術(shù)的發(fā)展，數(shù)據(jù)挖掘、數(shù)據(jù)探索等專有名詞曝光度越來越高，但是在類似于Hadoop系列的大數(shù)據(jù)分析系統(tǒng)大行其道之前，數(shù)據(jù)分析工作已經(jīng)經(jīng)歷了長足的發(fā)展，尤其是以BI系統(tǒng)為主的數(shù)據(jù)分析，已經(jīng)有了非常成熟和穩(wěn)定的技術(shù)方案和生態(tài)系統(tǒng)，對于BI系統(tǒng)來說，大概的架構(gòu)圖如下：

可以看到在BI系統(tǒng)里面，核心的模塊是Cube，Cube是一個更高層的業(yè)務(wù)模型抽象，在Cube之上可以進(jìn)行多種操作，例如上鉆、下鉆、切片等操作。大部分BI系統(tǒng)都基于關(guān)系型數(shù)據(jù)庫，關(guān)系型數(shù)據(jù)庫使用SQL語句進(jìn)行操作，但是SQL在多維操作和分析的表示能力上相對較弱，所以Cube有自己獨有的查詢語言MDX，MDX表達(dá)式具有更強(qiáng)的多維表現(xiàn)能力，所以以Cube為核心的分析系統(tǒng)基本占據(jù)著數(shù)據(jù)統(tǒng)計分析的半壁江山，大多數(shù)的數(shù)據(jù)庫服務(wù)廠商直接提供了BI套裝軟件服務(wù)，輕易便可搭建出一套Olap分析系統(tǒng)。不過BI的問題也隨著時間的推移逐漸顯露出來：

• BI系統(tǒng)更多的以分析業(yè)務(wù)數(shù)據(jù)產(chǎn)生的密度高、價值高的結(jié)構(gòu)化數(shù)據(jù)為主，對于非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)的處理非常乏力，例如圖片，文本，音頻的存儲，分析。
• 由于數(shù)據(jù)倉庫為結(jié)構(gòu)化存儲，在數(shù)據(jù)從其他系統(tǒng)進(jìn)入數(shù)據(jù)倉庫這個東西，我們通常叫做ETL過程，ETL動作和業(yè)務(wù)進(jìn)行了強(qiáng)綁定，通常需要一個專門的ETL團(tuán)隊去和業(yè)務(wù)做銜接，決定如何進(jìn)行數(shù)據(jù)的清洗和轉(zhuǎn)換。
• 隨著異構(gòu)數(shù)據(jù)源的增加，例如如果存在視頻，文本，圖片等數(shù)據(jù)源，要解析數(shù)據(jù)內(nèi)容進(jìn)入數(shù)據(jù)倉庫，則需要非常復(fù)雜等ETL程序，從而導(dǎo)致ETL變得過于龐大和臃腫。
• 當(dāng)數(shù)據(jù)量過大的時候，性能會成為瓶頸，在TB/PB級別的數(shù)據(jù)量上表現(xiàn)出明顯的吃力。
• 數(shù)據(jù)庫的范式等約束規(guī)則，著力于解決數(shù)據(jù)冗余的問題，是為了保障數(shù)據(jù)的一致性，但是對于數(shù)據(jù)倉庫來說，我們并不需要對數(shù)據(jù)做修改和一致性的保障，原則上來說數(shù)據(jù)倉庫的原始數(shù)據(jù)都是只讀的，所以這些約束反而會成為影響性能的因素。
• ETL動作對數(shù)據(jù)的預(yù)先假設(shè)和處理，導(dǎo)致機(jī)器學(xué)習(xí)部分獲取到的數(shù)據(jù)為假設(shè)后的數(shù)據(jù)，因此效果不理想。例如如果需要使用數(shù)據(jù)倉庫進(jìn)行異常數(shù)據(jù)的挖掘，則在數(shù)據(jù)入庫經(jīng)過ETL的時候就需要明確定義需要提取的特征數(shù)據(jù)，否則無法結(jié)構(gòu)化入庫，然而大多數(shù)情況是需要基于異構(gòu)數(shù)據(jù)才能提取出特征。

[[225566]]

在一系列的問題下，以Hadoop體系為首的大數(shù)據(jù)分析平臺逐漸表現(xiàn)出優(yōu)異性，圍繞Hadoop體系的生態(tài)圈也不斷的變大，對于Hadoop系統(tǒng)來說，從根本上解決了傳統(tǒng)數(shù)據(jù)倉庫的瓶頸的問題，但是也帶來一系列的問題：

• 從數(shù)據(jù)倉庫升級到大數(shù)據(jù)架構(gòu)，是不具備平滑演進(jìn)的，基本等于推翻重做。
• 大數(shù)據(jù)下的分布式存儲強(qiáng)調(diào)數(shù)據(jù)的只讀性質(zhì)，所以類似于Hive，HDFS這些存儲方式都不支持update，HDFS的write操作也不支持并行，這些特性導(dǎo)致其具有一定的局限性。

基于大數(shù)據(jù)架構(gòu)的數(shù)據(jù)分析平臺側(cè)重于從以下幾個維度去解決傳統(tǒng)數(shù)據(jù)倉庫做數(shù)據(jù)分析面臨的瓶頸：

• 分布式計算：分布式計算的思路是讓多個節(jié)點并行計算，并且強(qiáng)調(diào)數(shù)據(jù)本地性，盡可能的減少數(shù)據(jù)的傳輸，例如Spark通過RDD的形式來表現(xiàn)數(shù)據(jù)的計算邏輯，可以在RDD上做一系列的優(yōu)化，來減少數(shù)據(jù)的傳輸。
• 分布式存儲：所謂的分布式存儲，指的是將一個大文件拆成N份，每一份獨立的放到一臺機(jī)器上，這里就涉及到文件的副本，分片，以及管理等操作，分布式存儲主要優(yōu)化的動作都在這一塊。
• 檢索和存儲的結(jié)合：在早期的大數(shù)據(jù)組件中，存儲和計算相對比較單一，但是目前更多的方向是在存儲上做更多的手腳，讓查詢和計算更加高效，對于計算來說高效不外乎就是查找數(shù)據(jù)快，讀取數(shù)據(jù)快，所以目前的存儲不單單的存儲數(shù)據(jù)內(nèi)容，同時會添加很多元信息，例如索引信息。像類似于parquet和carbondata都是這樣的思想。

總的來說，目前圍繞Hadoop體系的大數(shù)據(jù)架構(gòu)大概有以下幾種：

傳統(tǒng)大數(shù)據(jù)架構(gòu)

之所以叫傳統(tǒng)大數(shù)據(jù)架構(gòu)，是因為其定位是為了解決傳統(tǒng)BI的問題，簡單來說，數(shù)據(jù)分析的業(yè)務(wù)沒有發(fā)生任何變化，但是因為數(shù)據(jù)量、性能等問題導(dǎo)致系統(tǒng)無法正常使用，需要進(jìn)行升級改造，那么此類架構(gòu)便是為了解決這個問題。可以看到，其依然保留了ETL的動作，將數(shù)據(jù)經(jīng)過ETL動作進(jìn)入數(shù)據(jù)存儲。

• 優(yōu)點：簡單，易懂，對于BI系統(tǒng)來說，基本思想沒有發(fā)生變化，變化的僅僅是技術(shù)選型，用大數(shù)據(jù)架構(gòu)替換掉BI的組件。
• 缺點：對于大數(shù)據(jù)來說，沒有BI下如此完備的Cube架構(gòu)，雖然目前有kylin，但是kylin的局限性非常明顯，遠(yuǎn)遠(yuǎn)沒有BI下的Cube的靈活度和穩(wěn)定度，因此對業(yè)務(wù)支撐的靈活度不夠，所以對于存在大量報表，或者復(fù)雜的鉆取的場景，需要太多的手工定制化，同時該架構(gòu)依舊以批處理為主，缺乏實時的支撐。
• 適用場景：數(shù)據(jù)分析需求依舊以BI場景為主，但是因為數(shù)據(jù)量、性能等問題無法滿足日常使用。

流式架構(gòu)

在傳統(tǒng)大數(shù)據(jù)架構(gòu)的基礎(chǔ)上，流式架構(gòu)非常激進(jìn)，直接拔掉了批處理，數(shù)據(jù)全程以流的形式處理，所以在數(shù)據(jù)接入端沒有了ETL，轉(zhuǎn)而替換為數(shù)據(jù)通道。經(jīng)過流處理加工后的數(shù)據(jù)，以消息的形式直接推送給了消費者。雖然有一個存儲部分，但是該存儲更多的以窗口的形式進(jìn)行存儲，所以該存儲并非發(fā)生在數(shù)據(jù)湖，而是在外圍系統(tǒng)。

• 優(yōu)點：沒有臃腫的ETL過程，數(shù)據(jù)的實效性非常高。
• 缺點：對于流式架構(gòu)來說，不存在批處理，因此對于數(shù)據(jù)的重播和歷史統(tǒng)計無法很好的支撐。對于離線分析僅僅支撐窗口之內(nèi)的分析。
• 適用場景：預(yù)警，監(jiān)控，對數(shù)據(jù)有有效期要求的情況。

Lambda架構(gòu)

Lambda架構(gòu)算是大數(shù)據(jù)系統(tǒng)里面舉足輕重的架構(gòu)，大多數(shù)架構(gòu)基本都是Lambda架構(gòu)或者基于其變種的架構(gòu)。Lambda的數(shù)據(jù)通道分為兩條分支：實時流和離線。實時流依照流式架構(gòu)，保障了其實時性，而離線則以批處理方式為主，保障了最終一致性。什么意思呢?流式通道處理為保障實效性更多的以增量計算為主輔助參考，而批處理層則對數(shù)據(jù)進(jìn)行全量運算，保障其最終的一致性，因此Lambda最外層有一個實時層和離線層合并的動作，此動作是Lambda里非常重要的一個動作，大概的合并思路如下：

• 優(yōu)點：既有實時又有離線，對于數(shù)據(jù)分析場景涵蓋的非常到位。
• 缺點：離線層和實時流雖然面臨的場景不相同，但是其內(nèi)部處理的邏輯卻是相同，因此有大量榮譽(yù)和重復(fù)的模塊存在。
• 適用場景：同時存在實時和離線需求的情況。

Kappa架構(gòu)

Kappa架構(gòu)在Lambda 的基礎(chǔ)上進(jìn)行了優(yōu)化，將實時和流部分進(jìn)行了合并，將數(shù)據(jù)通道以消息隊列進(jìn)行替代。因此對于Kappa架構(gòu)來說，依舊以流處理為主，但是數(shù)據(jù)卻在數(shù)據(jù)湖層面進(jìn)行了存儲，當(dāng)需要進(jìn)行離線分析或者再次計算的時候，則將數(shù)據(jù)湖的數(shù)據(jù)再次經(jīng)過消息隊列重播一次則可。

• 優(yōu)點：Kappa架構(gòu)解決了Lambda架構(gòu)里面的冗余部分，以數(shù)據(jù)可重播的超凡脫俗的思想進(jìn)行了設(shè)計，整個架構(gòu)非常簡潔。
• 缺點：雖然Kappa架構(gòu)看起來簡潔，但是施難度相對較高，尤其是對于數(shù)據(jù)重播部分。
• 適用場景：和Lambda類似，改架構(gòu)是針對Lambda的優(yōu)化。

Unifield架構(gòu)

以上的種種架構(gòu)都圍繞海量數(shù)據(jù)處理為主，Unifield架構(gòu)則更激進(jìn)，將機(jī)器學(xué)習(xí)和數(shù)據(jù)處理揉為一體，從核心上來說，Unifield依舊以Lambda為主，不過對其進(jìn)行了改造，在流處理層新增了機(jī)器學(xué)習(xí)層。可以看到數(shù)據(jù)在經(jīng)過數(shù)據(jù)通道進(jìn)入數(shù)據(jù)湖后，新增了模型訓(xùn)練部分，并且將其在流式層進(jìn)行使用。同時流式層不單使用模型，也包含著對模型的持續(xù)訓(xùn)練。

• 優(yōu)點：Unifield架構(gòu)提供了一套數(shù)據(jù)分析和機(jī)器學(xué)習(xí)結(jié)合的架構(gòu)方案，非常好的解決了機(jī)器學(xué)習(xí)如何與數(shù)據(jù)平臺進(jìn)行結(jié)合的問題。
• 缺點：Unifield架構(gòu)實施復(fù)雜度更高，對于機(jī)器學(xué)習(xí)架構(gòu)來說，從軟件包到硬件部署都和數(shù)據(jù)分析平臺有著非常大的差別，因此在實施過程中的難度系數(shù)更高。
• 適用場景：有著大量數(shù)據(jù)需要分析，同時對機(jī)器學(xué)習(xí)方便又有著非常大的需求或者有規(guī)劃。

總結(jié)

以上幾種架構(gòu)為目前數(shù)據(jù)處理領(lǐng)域使用比較多的幾種架構(gòu)，當(dāng)然還有非常多其他架構(gòu)，不過其思想都會或多或少的類似。數(shù)據(jù)領(lǐng)域和機(jī)器學(xué)習(xí)領(lǐng)域會持續(xù)發(fā)展，以上幾種思想或許終究也會變得過時。

【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文