資料分析工作雖然隐藏在業務系統背後，但是具有非常重要的作用，資料分析的結果對決策、對業務發展有着舉足輕重的作用。
随着大資料技術的發展，資料挖掘、資料探索等專有名詞的曝光度越來越高，但是在類似于Hadoop系列的大資料分析系統大行其道之前，資料分析工作已經曆了長足的發展，尤其是以BI系統為主的資料分析，已經有了非常成熟和穩定的技術方案和生态系統，對于BI系統來說，大概的架構圖如下：
可以看到在BI系統裡面，核心的子產品是Cube。Cube是一個更高層的業務模型抽象，在Cube之上可以進行多種操作，例如上鑽、下鑽、切片等操作。
大部分BI系統都基于關系型資料庫，而關系型資料庫使用SQL語句進行操作，但是SQL在多元操作和分析的表示能力上相對較弱，是以Cube有自己獨有的查詢語言MDX。
MDX表達式具有更強的多元表現能力，是以以Cube為核心的分析系統基本占據着資料統計分析的半壁江山，大多數的資料庫服務廠商直接提供BI套裝軟體服務，輕易便可搭建出一套OLAP分析系統，不過BI的問題也随着時間的推移逐漸暴露出來：
BI系統更多以分析業務資料産生的密度高、價值高的結構化資料為主，對于非結構化和半結構化資料的處理非常乏力。例如圖檔、文本、音頻的存儲、分析。
由于資料倉庫為結構化存儲，當資料從其它系統進入資料倉庫這個東西，我們通常叫做ETL過程，ETL動作和業務進行了強綁定，通常需要一個專門的ETL團隊去和業務做銜接，決定如何進行資料的清洗和轉換。
随着異構資料源的增加，例如如果存在視訊、文本、圖檔等資料源，要解析資料内容進入資料倉庫，則需要非常複雜的ETL程式，進而導緻ETL變得過于龐大和臃腫。
當資料量過大的時候，性能會成為瓶頸，在TB/PB級别的資料量上表現出明顯的吃力。
資料庫的範式等限制規則，着力于解決資料備援的問題，是為了保障資料的一緻性。但是對于資料倉庫來說，我們并不需要對資料做修改和一緻性的保障，原則上來說，資料倉庫的原始資料都是隻讀的，是以這些限制反而會成為影響性能的因素。
ETL動作對資料的預先假設和處理導緻機器學習部分擷取到的資料為假設後的資料，是以效果不理想。例如，如果需要使用資料倉庫進行異常資料的挖掘，那麼在資料入庫經過ETL的時候就需要明确定義需要提取的特征資料，否則無法結構化入庫，然而大多數情況是需要基于異構資料才能提取出特征。
在一系列的問題下，以Hadoop體系為首的大資料分析平台逐漸表現出優異性，圍繞Hadoop體系的生态圈也不斷變大，對于Hadoop系統來說，從根本上解決了傳統資料倉庫瓶頸的問題，但是也帶來一系列的新問題：
從資料倉庫更新到大資料架構，是不具備平滑演進的，基本等于推翻重做；
大資料下的分布式存儲強調資料的隻讀性質，是以類似于Hive、HDFS這些存儲方式都不支援update，HDFS的write操作也不支援并行，這些特性導緻其具有一定的局限性。
基于大資料架構的資料分析平台側重于從以下幾個次元去解決傳統資料倉庫做資料分析面臨的瓶頸：
分布式計算：分布式計算的思路是讓多個節點并行計算，并且強調資料本地性，盡可能的減少資料的傳輸，例如Spark通過RDD的形式來表現資料的計算邏輯，可以在RDD上做一系列的優化，來減少資料的傳輸。
分布式存儲：所謂的分布式存儲，指的是将一個大檔案拆成N份，每一份獨立的放到一台機器上，這裡就涉及到檔案的副本、分片以及管理等操作，分布式存儲主要優化的動作都在這一塊。
檢索和存儲的結合：在早期的大資料元件中，存儲和計算相對比較單一，但是目前更多的方向是在存儲上做更多的手腳，讓查詢和計算更加高效，對于計算來說高效不外乎就是查找資料快、讀取資料快，是以目前的存儲不單單的存儲資料内容，同時會添加很多元資訊，例如索引資訊。像類似于parquet和carbondata都是這樣的思想。
總的來說，目前圍繞Hadoop體系的大資料架構大概有以下幾種：
傳統大資料架構
之是以叫傳統大資料架構，是因為其定位是為了解決傳統BI的問題。簡單來說，資料分析的業務沒有發生任何變化，但是因為資料量、性能等問題導緻系統無法正常使用，需要進行更新改造，那麼此類架構便是為了解決這個問題。可以看到，其依然保留了ETL的動作，将資料經過ETL動作進入資料存儲。
優點：簡單、易懂，對于BI系統來說，基本思想沒有發生變化，變化的僅僅是技術選型，用大資料架構替換掉BI的元件。
缺點：對于大資料來說，沒有BI下如此完備的Cube架構，雖然目前有Kylin，但是Lylin的局限性非常明顯，遠遠沒有BI下Cube的靈活度和穩定度，是以對業務支撐的靈活度不夠，是以對于存在大量報表或複雜鑽取的場景，需要太多的手工定制化，同時該架構依舊以批處理為主，缺乏實時的支撐。
适用場景：資料分析需求依舊以BI場景為主，但是因為資料量、性能等問題無法滿足日常使用。
流式架構
在傳統大資料架構的基礎上，流式架構非常激進，直接拔掉了批處理，資料全程以流的形式處理，是以在資料接入端沒有了ETL，轉而替換為資料通道。經過流處理加工後的資料，以消息的形式直接推送給了消費者。雖然有一個存儲部分，但是該存儲更多以視窗的形式進行存儲，是以該存儲并非發生在資料湖，而是在外圍系統。
優點：沒有臃腫的ETL過程，資料的實效性非常高。
缺點：對于流式架構來說，不存在批處理，是以對于資料的重播和曆史統計無法很好的支撐。對于離線分析僅僅支撐視窗之内的分析。
适用場景：預警、監控、對資料有有效期要求的情況。
Lambda架構
Lambda架構算是大資料系統裡面舉足輕重的架構，大多數架構基本都是Lambda架構或者基于其變種的架構。
Lambda的資料通道分為兩條分支：實時流和離線。實時流依照流式架構，保障了其實時性，而離線則以批處理方式為主，保障了最終一緻性。
什麼意思呢？流式通道處理為保障實效性更多的以增量計算為主輔助參考，而批處理層則對資料進行全量運算，保障其最終的一緻性。是以，Lambda最外層有一個實時層和離線層合并的動作，此動作是Lambda裡非常重要的一個動作，大概的合并思路如下：
優點：既有實時又有離線，對于資料分析場景涵蓋的非常到位。
缺點：離線層和實時流雖然面臨的場景不相同，但是其内部處理的邏輯卻是相同，是以有大量備援和重複的子產品存在。
适用場景：同時存在實時和離線需求的情況。
Kappa架構
Kappa架構在Lambda的基礎上進行了優化，将實時和流部分進行了合并，将資料通道以消息隊列進行替代。是以對于Kappa架構來說，依舊以流處理為主，但是資料卻在資料湖層面進行了存儲，當需要進行離線分析或者再次計算的時候，則将資料湖的資料再次經過消息隊列重播一次則可。
優點：Kappa架構解決了Lambda架構裡面的備援部分，以資料可重播的超凡脫俗的思想進行了設計，整個架構非常簡潔。
缺點：雖然Kappa架構看起來簡潔，但是施難度相對較高，尤其是對于資料重播部分。
适用場景：和Lambda類似，該架構是針對Lambda的優化。
Unifield架構
以上的種種架構都圍繞海量資料處理為主，Unifield架構則更激進，将機器學習和資料處理揉為一體，從核心上來說，Unifield依舊以Lambda為主，不過對其進行了改造，在流處理層新增了機器學習層。可以看到資料在經過資料通道進入資料湖後，新增了模型訓練部分，并且将其在流式層進行使用。同時流式層不單使用模型，也包含着對模型的持續訓練。
優點：Unifield架構提供了一套資料分析和機器學習結合的架構方案，非常好的解決了機器學習如何與資料平台進行結合的問題。
缺點：Unifield架構實施複雜度更高，對于機器學習架構來說，從軟體包到硬體部署都和資料分析平台有着非常大的差别，是以在實施過程中的難度系數更高。
适用場景：有着大量資料需要分析，同時對機器學習友善又有着非常大的需求或者有規劃的情況。
總結
以上為目前資料處理領域使用較多的幾種架構，當然還有非常多其他架構，不過其思想都會或多或少的類似。資料領域和機器學習領域會持續發展，以上幾種思想或許終究會變得過時，我們隻能與時俱進，不斷更新自己的知識庫。
原文釋出時間為：2018-07-29
本文來自雲栖社群合作夥伴“
DBAplus社群”，了解相關資訊可以關注“DBAplus社群”。