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