1、Lambda架構
Lambda架構是大數據平台里最成熟、最穩定的架構，它的核心思想是：將批處理作業和實時流處理作業分離，各自獨立運行，資源互相隔離。
標准的Lambda架構有如下幾個層次：
（1）Batch Laye：主要負責所有的批處理操作，支撐該層的技術以Hive、Spark-SQL或MapReduce這類批處理技術為主。另外，數據處理依賴的主數據也是在該層維護的。
（2）Serving Layer：以Batch Layer處理的結果數據為基礎，對外提供低延時的數據查詢和ad-hoc查詢（即席查詢）服務，Serving Layer可以認為是對Batch Layer數據訪問能力上的延伸或增強。因為批處理本身是比較慢的，無法支撐實時的查詢請求，從Serving Layer的角度看，Batch Layer的工作本質是一種“預計算”，即預先對大體量數據集進行處理，得到相對較小的結果集，然后由Serving Layer接手，提供實時的數據查詢服務。Serving Layer既可以使用包括關系型數據庫在內的傳統技術，也可以使用Kylin、Presto、Impala或Druid等大數據OLAP產品。
（3）Speed Layer：使用流式計算技術實時處理當前數據。Speed Layer區別於Batch Layer的地方在於它能以實時或近似實時的方式處理大量的數據，但是它的局限在於只能處理當前新生成的數據，無法對全部歷史數據進行操作，因為流式計算只能針對當前產生的“熱數據”進行處理。Speed Layer經常使用Storm、Spark Streaming或Flink等大數據流計算框架。
2、Kappa架構
Kappa架構可以認為是對Lambda架構的一種簡化，它使用流計算技術來統一批處理和實時處理兩條通道,這樣，無論從開發和維護的工作量方面，還是從數據存儲方面都比Lambda架構節約很多成本。
Kappa架構在技術選型上往往需要這些組件:
消息隊列：Kafka/Pulsar
流計算框架：Flink/Spark Streaming/Storm
完全使用流計算處理所有的數據對開發和數據分析的方方面面都有影響。例如，在Kappa架構下，所有的數據以流計算的方式處理之后，都將以一種追加的方式寫入目標位置，而之前寫入的數據也沒有機會再被改動，因而變成不可變的。這種處理模式和Kafka對待數據的方式是完全一致的，本質上都是受流計算這種計算模式的影響。Kappa架構在技術選型上與Lambda架構在Speed Layer上選型是類似的，都以流計算框架為主。
3、SMACK架構
SMACK架構是最近兩三年興起的一種新的架構，S、M、A、C、K分別代表了這個架構使用的5種技術:Spark、Mesos、Akka、Cassandra和Kafka。SMACK成功地融合了批處理和實時處理，但是它的融合方式與Kappa有很大的差別。SMACK架構的成功之處在於它充分而巧妙地利用了選型組件的特性，用一種更加自然和平滑的方式統一了批處理和實時處理。
SMACK架構使用Akka進行數據采集(Akka可以應對高並發和實時性要求很高的場景，非常適合IOT領域)，然后將數據寫入Kafka,接着使用Spark Streaming進行實時流處理，處理的結果和原始數據都寫入Cassandra。到這里，所有的做法和Kappa架構是一樣的。不同於Kappa架構的地方在於，SMACK架構依然保留了批處理能力，它巧妙地利用了Cassandra的多數據中心(Multiple Datacenters)特性將數據透明地冗余到兩個Cassandra集群（集群1用來接收流處理結果，集群2用於批處理分析，供Spark(Spark Core或Spark SQL)讀寫。
SMACK架構之所以可行，關鍵是利用了相關產品的特性保證了以下重要的三點:
（1）利用Cassandra的多數據中心機制透明地實現數據冗余，為實時處理和批處理配置專門
的存儲資源，互不影響;
（2）利用Spark-Cassandra連接器的“本地數據感知”能力，在批處理時讓Spark盡量讀取
Cassandra上本地節點的數據，避免數據的網際傳輸;
（3）利用Mesos的Marathon和Chronos來配合流式作業和批處理作業。
原文鏈接：https://blog.csdn.net/weixin_41507897/article/details/112567486