-
1 # IT技術管理那些事兒
-
2 # 加米穀大資料
BI系統，大概的架構圖如下：
核心的模組是Cube，Cube是一個更高層的業務模型抽象，在Cube之上可以進行多種操作。大部分BI系統都基於關係型資料庫，關係型資料庫使用SQL語句進行操作，但是SQL在多維操作和分析的表示能力上相對較弱，所以Cube有自己獨有的查詢語言MDX，MDX表示式具有更強的多維表現能力，所以以Cube為核心的分析系統基本佔據著資料統計分析的半壁江山，大多數的資料庫服務廠商直接提供了BI套裝軟體服務，輕易便可搭建出一套Olap分析系統。
以Hadoop體系為首的大資料分析平臺：Hadoop體系的生態圈也不斷的變大，目前圍繞Hadoop體系的大資料架構大概有以下幾種：
傳統大資料架構
其定位是為了解決傳統BI的問題，簡單說，資料分析的業務沒有發生任何變化，依然保留了ETL的動作，將資料經過ETL動作進入資料儲存。
適用場景：
資料分析需求依舊以BI場景為主，但是因為資料量、效能等問題無法滿足日常使用。
流式架構
在傳統大資料架構的基礎上，流式架構非常激進，直接拔掉了批處理，資料全程以流的形式處理，所以在資料接入端沒有了ETL，轉而替換為資料通道。經過流處理加工後的資料，以訊息的形式直接推送給了消費者。雖然有一個儲存部分，但是該儲存更多的以視窗的形式進行儲存，所以該儲存並非發生在資料湖，而是在外圍系統。
適用場景：
預警，監控，對資料有有效期要求的情況。
Lambda架構
Lambda架構算是大資料系統裡面舉足輕重的架構，大多數架構基本都是Lambda架構或者基於其變種的架構。Lambda的資料通道分為兩條分支：實時流和離線。實時流依照流式架構，保障了其實時性，而離線則以批處理方式為主，保障了最終一致性。流式通道處理為保障實效性更多的以增量計算為主輔助參考，而批處理層則對資料進行全量運算，保障其最終的一致性，因此Lambda最外層有一個實時層和離線層合併的動作，此動作是Lambda裡非常重要的一個動作，大概的合併思路如下：
適用場景：
同時存在實時和離線需求的情況。
Kappa架構
Kappa架構在Lambda 的基礎上進行了最佳化，將實時和流部分進行了合併，將資料通道以訊息佇列進行替代。因此對於Kappa架構來說，依舊以流處理為主，但是資料卻在資料湖層面進行了儲存，當需要進行離線分析或者再次計算的時候，則將資料湖的資料再次經過訊息佇列重播一次則可。
適用場景：
和Lambda類似，改架構是針對Lambda的最佳化。
Unifield架構
Unifield架構更激進，將機器學習和資料處理揉為一體，從核心上來說，Unifield依舊以Lambda為主，不過對其進行了改造，在流處理層新增了機器學習層。可以看到資料在經過資料通道進入資料湖後，新增了模型訓練部分，並且將其在流式層進行使用。同時流式層不單使用模型，也包含著對模型的持續訓練。
適用場景：
有著大量資料需要分析，同時對機器學習方便又有著非常大的需求或者有規劃。
相關：
輿情大資料系統架構設計與實現：https://www.toutiao.com/i6537119210336682510/
大資料架構的分析應用：https://www.toutiao.com/i6613946595891216910/
回覆列表
首先從企業資訊化發展階段時，資料平臺結構的程度來看。個人依照企業資訊化，將資料平臺階段劃分為：只有業務資料庫——>中間庫——>完善資料倉庫（DW）——>資料集市（Data Mart），順序與階段並不絕對正確，可能有組合，可能所在階段不完全一致。以下先看各個資料平臺階段特點，再看對應階段資料分析工具選型的考慮吧。
1.業務資料庫
一個企業IT資訊化建設最初的階段，業務庫中資料量不大，要分析展示下資料情況啦，不慌，問題不大，這時候OLTP結構下也可以寫寫SQL快速展現，隨便玩玩office工具也沒問題。
但是隨著時間的推移，各種問題開始出現：
（1）查詢和寫入頻率越來越高，高頻write和和長時間read衝突越來越嚴重。而資料分析要耗費大量計算資源，不能動不動掛業務系統吧。
（2）資料量越來越大，歷史業務資料啦，新業務資料激增啦，第一要務就是要解決業務應用效率問題了，誰管資料分析裡的問題呢。
（3）業務越來越多，表結構越來越複雜。業務系統數量的越來越多，導致資料孤島開始形成。
這種情況下，企業面臨資料展示與資料平臺建設的階段了要怎麼處理。這種情況下要做資料分析就麻煩了，要人為去各個系統取數，人力是一個方面。各個系統口徑命名啥都有差異，人為的處理出錯率高就是另一方面。
2.中間庫
由於上述問題，就要引入中間庫來處理。左圖結構解決了高頻write和read衝突問題，以及單資料庫伺服器效能問題，順手也搞定了資料備份。這種情況下呢簡單查詢還是可以的，但是在轉換聚合等需要多表關聯、以及大資料量等業務複雜度高的情況下，其處理效能就不容樂觀了。
此時就開始考慮可以利用空閒時間的伺服器效能來做預先處理呢。右圖這種T+n的預處理離線計算的架構就出現了，引入獨立的任務排程和計算引擎：計算壓力可以交給資料庫處理，也可交給ETL處理，展現效能初步解決。
但是這種情況下，資料庫表結構實在太過複雜，每做一個分析，就要理一次業務邏輯、寫一段sql，還沒法進行歷史追溯，以及資料整理成果的複用，so sad。
那有沒有理一次之後，後續能夠省點事的方式呢？這時候數倉的概念就可以使用上了。
3.完善資料倉庫（DW）
把業務庫資料整理成星型結構，保證了事實的積累和維度的追溯。自由選擇需要的維度和相關事實進行篩選計算，麻麻再也不用擔心每次寫sql都要去看“蜘蛛網”了。還有索引、結果表、分割槽分表等等黑科技來保證每次查旬需掃描的資料量最小，解決資料庫效能問題。
當然這種架構方式的缺點也很明顯，不是企業內一致的資料（多系統，多主題資料不一致），就會產生資訊孤島。當然，如果客戶企業就是很小，就一個系統，不用整合，一個數據集市足以的情況下采用這種方式也可以。常見情況是會在各個獨立的DW間建立一些對照表，可實現資料交換。如果多個DW間沒有物理隔絕，也可以形成EDW。
4.完善數倉+資料集市（Data Mart）
為了實現各個業務系統取數分析，或者做更多操作，就實現中心資料倉庫EDW從各個源系統收集資料，再將資料提供給各個資料集市和挖掘倉庫使用。這也被稱為企業資訊工廠架構（CIF），一般情況下，大型企業會花費許多精力實現這類架構。
業務複雜度的提高與資料量級的增大以及對這些資料的應用，促成了各個大資料平臺的繁榮，這個放到另一篇文章陳述。
無論是以什麼架構存在，資料展示的需求都必不可少。分析工具選擇必不可少，要在以上階段以一款工具涵蓋，那必然需要一款既可以做敏捷資料集市建模，又可以做資料展示分析的工具來處理。這種工具可對業務資料進行簡單、快速整合，實現敏捷建模節省時間，並且可以大幅度提升資料的展示速度，可對接前端的資料分析展示層，實現自由資料展示與OLAP分析，典型如各類BI分析工具。
資料分析也很考驗分析工具資料讀取、運算的效能，但擁有大資料量計算引擎的BI分析工具並不多。像FineBI（www.finebi.com）與其高效能資料引擎在以上幾個階段均可在不同程度解決很多場景。
（1）業務資料庫階段，此階段已經陳述過，重點問題就是計算效能影響大，以及資料孤島問題。建立數倉的過程相對敏捷資料集市而言，時間還是久的。這個時候就看看建立個常規意義的數倉和資料展示需求誰更緊急啦，或者可能有的也沒建資料平臺的意識也說不準。此時快速的資料展示需求，就可以透過將資料放到FineBI的資料引擎中支撐實現。
（2）中間庫與完善數倉階段，此階段其實主要就是計算效能問題了，使用者的資料量級也一定挺大了。正好藉助於FineBI的分散式引擎，完成資料加速計算工作。此引擎屬hadoop生態，核心計算引擎利用的spark，藉助了alluxio作為記憶體加速計算，處理了大資料計算問題，也很好闡釋了“大資料”。這個在接下來的文章中也會說到，這裡先埋個伏筆，暫不贅述。
此階段呢，肯定有一些響應時間要求較高的展示需求，多次作業同步可能帶來延遲影響。而FineBI的引擎擴充套件了kettle的外掛，實現資料可以直接load到引擎中，倒是將麻煩的作業處理工作解決了。
（3）完善數倉+資料集市階段，這種階段資料平臺建設已經很完善了，各業務部門資料量級，業務複雜度都很高。
底層技術上雖然資料集市是建立在整合的中心資料倉庫EDW上，但是這些資料集市之間還是不能進行資料交換的，大家建立的方法和ETL程式都會不同，各個資料集市之間的資料不見得的是一致，且平臺架構超級複雜，擴充套件以及再為各業務部門設計計算層結果表之類都相對麻煩。此時可考慮部分需整合資料放到敏捷資料集市處理，可直接對接的再直接對接處理。FineBI的引擎恰好都滿足這樣的場景需求，前端OLAP分析恰好也有，簡單處理整合展示一站式解決。