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