Lambda架构
在Lambda架构中，为了计算一些实时指标，就在原来的离线数仓基础之上增加了一个实时计算的链路，并对数据源做流式改造：把消息发送到消息队列中(大数据中常用Kafka)，实时计算去消费消息队列中的数据，完成实时指标计算，推送到下游的数据服务中去，由数据服务层完成离线与实时结果的合并。
Lambda架构中数据从底层的数据源开始，经过各种各样的格式进入大数据平台，在大数据平台中经过Kafka、Flume等数据组件进行收集，然后分成两条线进行计算。一条线是进入流式计算平台(例如 Storm、Flink或者Spark Streaming)，去计算实时的一些指标，保证数据实时性;另一条线进入批量数据处理离线计算平台(例如Mapreduce、Hive，Spark SQL)，去计算T+1的相关业务指标，这些指标需要隔日才能看见，保证数据有效、准确性。
根据实时业务统计的复杂程度Lambda架构也分为以下两种情况。
离线数据+实时处理链路(传统实时开发)
根据实时链路中实时指标计算的复杂程度，开始实时业务不复杂，都是“烟囱(cong)式”开发设计，不需要构建实时数仓，我们可以选择不分层，这种场景下Lambda架构中是由离线数仓和实时业务处理部分组成，这部分实时还达不到叫做实时数仓阶段，只能叫做实时处理链路，其结构如下：
注意：“烟囱式”开发：在一个有一定规模的企业中，通常都会存在各种各样的应用系统，它们分别由企业的各个不同部门、在各种不同历史时期、为满足各种不同业务目的而开发。由于数据格式没有统一规范，相互之间没有联通、数据更没有整合，像一个个烟囱，因此称其为“烟囱式系统”。同样，在数据处理过程中，各个数据处理程序之间不能很好做到数据规范统一、处理数据流程统一、数据复用，各自独立，叫做“烟囱式”开发。
