1. 概述
隨著互聯(lián)網(wǎng)的快速普及均澳，全球數(shù)據(jù)呈現(xiàn)出快速增長、海量集聚的特點。運用大數(shù)據(jù)技術(shù)對這些數(shù)據(jù)進(jìn)行分析仪糖，使得人們的生產(chǎn)生活方式都發(fā)生了許多變化。數(shù)據(jù)分析雖然隱藏在業(yè)務(wù)系統(tǒng)背后迫肖，但是其在大數(shù)據(jù)技術(shù)體系中具有非常重要的作用锅劝，數(shù)據(jù)分析的結(jié)果對公司決策、業(yè)務(wù)發(fā)展蟆湖、企業(yè)戰(zhàn)略定位有著舉足輕重的作用故爵。隨著大數(shù)據(jù)技術(shù)的發(fā)展，數(shù)據(jù)挖掘隅津、數(shù)據(jù)分析與數(shù)據(jù)探索等關(guān)注度越來越高诬垂，但是在Hadoop劲室、Spark、Storm等大數(shù)據(jù)應(yīng)用與分析平臺之前结窘，數(shù)據(jù)分析工作已經(jīng)經(jīng)歷了比較長時間的發(fā)展和變化很洋，尤其是以商業(yè)智能（BI：Business Intelligence，以下簡稱為BI系統(tǒng)）系統(tǒng)為主的數(shù)據(jù)分析隧枫，已經(jīng)具備非常成熟和穩(wěn)定的解決方案和業(yè)務(wù)生態(tài)系統(tǒng)喉磁，常用的BI系統(tǒng)有Microsoft PowerBI、Oracle BI官脓、Informatica协怒、Pentaho BI Server、FineBI等卑笨，對于BI系統(tǒng)來說斤讥，大概的架構(gòu)圖如下：
可以看到在BI系統(tǒng)里面，核心的模塊是Cube模塊湾趾，Cube模塊在BI系統(tǒng)中是一個更高層的業(yè)務(wù)模型抽象芭商，在Cube之上可以進(jìn)行多種操作，例如上鉆（Drill UP）搀缠、下鉆（Drill Down）铛楣、切片（Sharding）等操作。大部分商業(yè)智能（BI）系統(tǒng)都基于關(guān)系型數(shù)據(jù)庫（如Oracle艺普、DB2簸州、MySQL、SQLServer等）歧譬，關(guān)系型數(shù)據(jù)庫使用SQL語句進(jìn)行操作岸浑，但是SQL在多維操作和分析的表示能力上相對較弱，所以Cube有自己獨有的查詢語言MDX(Multi Dimensional Expressions: 多維表達(dá)式)瑰步，MDX表達(dá)式具有更強的多維表現(xiàn)能力矢洲，所以以Cube為核心的分析系統(tǒng)基本占據(jù)著數(shù)據(jù)統(tǒng)計分析的半壁江山，大多數(shù)的數(shù)據(jù)庫服務(wù)廠商直接提供了BI套裝軟件服務(wù)缩焦，輕易便可搭建出一套OLAP（Online Analysis Processing读虏， 聯(lián)機分析處理）分析系統(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)行了強綁定袜炕，通常需要一個專門的ETL團隊去和業(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ù)庫的設(shè)計范式等的規(guī)則約束，傳統(tǒng)關(guān)系型數(shù)據(jù)庫主要用于解決數(shù)據(jù)冗余的問題纫溃，是為了保障數(shù)據(jù)的一致性腰涧，但對于數(shù)據(jù)倉庫來說，我們并不需要保障數(shù)據(jù)的一致性，原則上來說數(shù)據(jù)倉庫的原始數(shù)據(jù)都是只讀的，所以關(guān)系型數(shù)據(jù)庫的這些約束反而會成為影響性能的因素绩卤。
ETL操作需要對數(shù)據(jù)進(jìn)行預(yù)先假設(shè)和處理外驱，導(dǎo)致機器學(xué)習(xí)部分獲取到的數(shù)據(jù)為假設(shè)后的數(shù)據(jù)，因此機器學(xué)習(xí)的效果不太理想瓣喊，學(xué)習(xí)結(jié)果偏離實際的應(yīng)用情況。如果需要使用數(shù)據(jù)倉庫對異常數(shù)據(jù)進(jìn)行挖掘，則在數(shù)據(jù)未經(jīng)ETL操作前就需要明確定義待提取的特征數(shù)據(jù)箍铲，否則無法結(jié)構(gòu)化入庫，然而大多數(shù)情況是需要基于異構(gòu)數(shù)據(jù)才能提取出特征鬓椭。
在上述所陳述的問題下虹钮，以Hadoop體系為首的大數(shù)據(jù)技術(shù)平臺逐漸表現(xiàn)出其在數(shù)據(jù)挖掘、數(shù)據(jù)分析和數(shù)據(jù)存儲方面的優(yōu)越性膘融，圍繞Hadoop體系的大數(shù)據(jù)生態(tài)系統(tǒng)也在不斷的擴大芙粱，對于Hadoop系統(tǒng)來說，從根本上解決了傳統(tǒng)數(shù)據(jù)倉庫的性能瓶頸的問題氧映，但是也給企業(yè)帶來一定的困惑：
從傳統(tǒng)的數(shù)據(jù)倉庫架構(gòu)升級到大數(shù)據(jù)架構(gòu)春畔，由于數(shù)據(jù)存儲架構(gòu)、數(shù)據(jù)分析架構(gòu)、數(shù)據(jù)應(yīng)用架構(gòu)等結(jié)構(gòu)的異同律姨，決定了應(yīng)用之間的過渡需要一個演進(jìn)過程振峻，數(shù)據(jù)倉庫可以做為數(shù)據(jù)源到大數(shù)據(jù)體系中的分布式系統(tǒng)中做計算，分布式系統(tǒng)作為數(shù)據(jù)倉庫的計算引擎為數(shù)據(jù)分析提供計算择份，分布式系統(tǒng)將聚合數(shù)據(jù)/計算結(jié)果導(dǎo)出到數(shù)據(jù)倉庫中 扣孟。
大數(shù)據(jù)體系下的分布式存儲強調(diào)數(shù)據(jù)的只讀性而忽略了數(shù)據(jù)的可寫性，所以類似于Hive荣赶、HDFS凤价、HBASE這些存儲方式都不支持更新操作，如HDFS的寫操作不支持并行寫操作拔创，這些特性導(dǎo)致其具有一定的局限性利诺。
基于大數(shù)據(jù)架構(gòu)的數(shù)據(jù)分析平臺側(cè)重于從以下幾個維度去解決傳統(tǒng)數(shù)據(jù)倉庫做數(shù)據(jù)分析面臨的瓶頸：
分布式存儲：所謂的分布式存儲，指的是將一個大的文件拆成N個小文件剩燥，并將小文件存儲在不同的存儲單元中慢逾，因此這就涉及到文件的副本、分區(qū)灭红、分片以及管理等操作侣滩，分布式存儲主要優(yōu)化的動作都在文件的分布式管理上。
分布式計算：分布式計算的核心思想是讓多個計算節(jié)點并行計算变擒，從而提高數(shù)據(jù)計算的效率胜卤，分布式計算強調(diào)數(shù)據(jù)的本地性，即計算的數(shù)據(jù)來自于本地存儲的數(shù)據(jù)赁项，盡可能的減少數(shù)據(jù)的傳輸葛躏，減少網(wǎng)絡(luò)帶寬資源的消耗，例如Spark通過RDD的形式來表現(xiàn)數(shù)據(jù)的計算邏輯悠菜，可以在RDD上做一系列的優(yōu)化舰攒，以此來減少數(shù)據(jù)的傳輸。
檢索和存儲的結(jié)合：在早期的大數(shù)據(jù)應(yīng)用組件中悔醋，存儲和計算組件相對比較單一摩窃，但如今更多的應(yīng)用方向是在數(shù)據(jù)存儲上提供更多的應(yīng)用功能，讓查詢和計算更加便捷芬骄、高效猾愿，對于計算來說高效不外乎就是數(shù)據(jù)檢索效率高、讀取速度快账阻，所以目前的數(shù)據(jù)存儲不單單的存儲數(shù)據(jù)內(nèi)容蒂秘，同時會添加很多元數(shù)據(jù)信息，例如索引信息淘太。
數(shù)據(jù)路由：分區(qū)分庫分表等分布式存儲操作之后姻僧，記錄這些結(jié)構(gòu)信息规丽，并做高可用管理，提供給應(yīng)用程序的是路由功能撇贺。使得應(yīng)用系統(tǒng)進(jìn)來的查詢請求得以分配到合理的數(shù)據(jù)節(jié)點上計算赌莺。
2. 常見的大數(shù)據(jù)架構(gòu)
總的來說，目前圍繞Hadoop體系的大數(shù)據(jù)架構(gòu)大概有以下幾種：
下面將對這五種常見的大數(shù)據(jù)架構(gòu)進(jìn)行介紹松嘶。
傳統(tǒng)大數(shù)據(jù)架構(gòu)
我們之所以稱之為傳統(tǒng)大數(shù)據(jù)架構(gòu)艘狭，是因為其目標(biāo)定位是為了解決傳統(tǒng)BI所存在的問題，簡單來說翠订，基本的數(shù)據(jù)分析業(yè)務(wù)沒有發(fā)生任何本質(zhì)上的變化巢音，但是因為數(shù)據(jù)量越來越大、性能越來越低等問題導(dǎo)致BI系統(tǒng)無法正常使用蕴轨，因此需要進(jìn)行升級改造港谊，那么傳統(tǒng)的大數(shù)據(jù)架構(gòu)便是為了解決這些問題（大數(shù)據(jù)量存儲骇吭、提高應(yīng)用系統(tǒng)等）橙弱。可以看到燥狰，其依然保留了ETL（抽取棘脐、轉(zhuǎn)換、加載）的動作龙致，將數(shù)據(jù)經(jīng)過ETL數(shù)據(jù)采集操作進(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ù)流的方式進(jìn)行處理致燥，所以在數(shù)據(jù)接入端沒有了ETL操作登疗，轉(zhuǎn)而替換為數(shù)據(jù)通道（Data Channel）。經(jīng)過流處理加工后的數(shù)據(jù)嫌蚤，通過消息中間件（如Kafka）以消息的形式直接推送給了消費者辐益。雖然有一個存儲部分，但是該存儲更多的以窗口的形式進(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)部處理的邏輯卻是相同毕籽，因此有大量榮譽和重復(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)锭硼，將機器學(xué)習(xí)和數(shù)據(jù)處理揉為一體房资，從核心上來說，Unifield依舊以Lambda為主檀头，不過對其進(jìn)行了改造轰异，在流處理層新增了機器學(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ù)分析和機器學(xué)習(xí)結(jié)合的架構(gòu)方案嗤朴，非常好的解決了機器學(xué)習(xí)如何與數(shù)據(jù)平臺進(jìn)行結(jié)合的問題配椭。
缺點：Unifield架構(gòu)實施復(fù)雜度更高，對于機器學(xué)習(xí)架構(gòu)來說雹姊，從軟件包到硬件部署都和數(shù)據(jù)分析平臺有著非常大的差別股缸，因此在實施過程中的難度系數(shù)更高。
適用場景：有著大量數(shù)據(jù)需要分析吱雏，同時對機器學(xué)習(xí)方便又有著非常大的需求或者有規(guī)劃敦姻。
3. 總結(jié)
以上幾種架構(gòu)為目前數(shù)據(jù)處理領(lǐng)域使用比較多的幾種架構(gòu)瘾境，當(dāng)然還有非常多其他架構(gòu)，不過其思想都會或多或少的類似镰惦。數(shù)據(jù)領(lǐng)域和機器學(xué)習(xí)領(lǐng)域會持續(xù)發(fā)展迷守，以上幾種思想或許終究也會變得過時。
個人聲明：本文來源于ThoughtWorks微信公眾號旺入， 僅用于個人學(xué)習(xí)與研究盒犹， 不做任何商業(yè)用途， 在原有文章的觀點的基礎(chǔ)上補充了一些自己的觀點眨业， 如有侵犯之處急膀， 請及時聯(lián)系， 我將第一時間進(jìn)行刪除龄捡。
