1. 五種主流的大資料架構
1.1 傳統大資料架構
之是以叫傳統大資料架構，是因為其定位是為了解決傳統BI的問題，簡單來說，資料分析的業務沒有發生任何變化，但是因為資料量、性能等問題導緻系統無法正常使用，需要進行更新改造，那麼此類架構便是為了解決這個問題。可以看到，其依然保留了ETL的動作，将資料經過ETL動作進入資料存儲。
優點：簡單，易懂，對于BI系統來說，基本思想沒有發生變化，變化的僅僅是技術選型，用大資料架構替換掉BI的元件。
缺點：對于大資料來說，沒有BI下如此完備的Cube架構，雖然目前有kylin，但是kylin的局限性非常明顯，遠遠沒有BI下的Cube的靈活度和穩定度，是以對業務支撐靈活度不夠，是以對于存在大量報表，或者複雜的鑽取的場景，需要太多的手工定制化，同時該架構依舊以批處理為主，缺乏實時的支撐。
适用場景：資料分析需求依舊以BI場景為主，但是因為資料量、性能等問題無法滿足日常使用
1.2 流式架構
在傳統大資料架構的基礎上，流式架構非常激進，直接拔掉了批處理，資料全程以流的形式處理，是以在資料接入端沒有了ETL，轉而替換為資料通道。經過流處理加工後的資料，以消息的形式直接推送給了消費者。雖然有一個存儲部分，但是該存儲更多的以視窗的形式進行存儲，是以該存儲并非發生在資料湖，而是在外圍系統。
優點：沒有臃腫的ETL過程，資料的實效性非常高。
缺點：對于流式架構來說，不存在批處理，是以對于資料的重播和曆史統計無法很好的支撐。對于離線分析僅僅支撐視窗之内的分析。
适用場景：預警，監控，對資料有有效期要求的情況
1.3 Lambda架構
Lambda架構算是大資料系統裡面舉足輕重的架構，大多數架構基本都是Lambda架構或者基于其變種的架構。Lambda的資料通道分為兩條分支：實時流和離線。實時流依照流式架構，保障了其實時性，而離線則以批處理方式為主，保證了最終一緻性。流式通道處理為保障實效性更多的以增量計算為主輔助參考，而批處理層則對資料進行全量運算，保障其最終的一緻性，是以Lambda最外層有一個實時層和離線層合并的動作，此動作是Lambda裡非常重要的一個動作，大概的合并思路如下：
優點：既有實時又有離線，對于資料分析場景涵蓋的非常到位。
缺點：離線層和實時流雖然面臨的場景不同，但是其内部處理的邏輯卻是相同，是以有大量榮譽和重複的子產品存在。
适用場景：同時存在實時和離線需求的情況
1.4 Kappa架構
Kappa架構在Lambda的基礎上進行了優化，将實時和流部分進行了合并，将資料通道以消息隊列進行替代。是以對于Kappa架構來說，依舊以流處理為主，但是資料卻在資料湖層面進行了存儲，當需要進行離線分析或者再次計算的時候，則将資料庫的資料再次經過消息隊列重播一次即可。
優點：Kappa架構解決了Lambda架構裡面的備援部分，以資料可重播的超凡脫俗的思想進行了設計，整個架構非常簡潔。
缺點：雖然Kappa架構看起來簡潔，但是實施難度相對較高，尤其是對于資料重播部分。
使用場景：和Lambda類似，該架構是針對Lambda的優化
1.5 Unifield架構
以上的種種架構都圍繞海量資料處理為主，Unifield架構則更激進，将機器學習和資料處理揉為一體，從核心上來說，Unifield依舊以Lambda為主，不過對其進行了改造，在流處理層新增了機器學習層。可以看到資料在經過資料通道進入資料庫後，新增了模型訓練部分，并且将其在流式層進行使用。同時流式層不單使用模型，也包含着對模型的持續訓練。
優點：Unifield架構提供了一套資料分析和機器學習結合的架構方案，非常好的解決了機器學習如何與資料平台進行結合的問題。
缺點：Unifield架構實施複雜度更高，對于機器學習架構來說，從軟體包到硬體部署都和資料分析平台有着非常大的差别，是以在實施過程中的難度系數更高。
适用場景：有着大量資料需要分析，同時對機器學習友善又有着非常大的需求或者有規劃
2. 收集各大網際網路公司大資料平台架構
1. 酷狗音樂的大資料平台架構：
https://www.infoq.cn/article/kugou-big-data-platform-restructure
2. 滴滴大資料離線和實時平台架構和實踐：
https://myslide.cn/slides/15307
3. 美圖大資料平台lamda架構
https://www.infoq.cn/article/QycsTZSz0REAFTgmh_J0