Lambda架构

借用Jay Kreps的一张图来看，Lambda架构主要由这几部分构成：数据源（Kafka），数据处理（Storm，Hadoop），服务数据库（Serving DB）。其中数据源和服务数据库是整个架构数据的入口和出口。数据处理则是分为在在线处理和离线处理两部分。

当数据通过kafka消息中间件，进入Lambda架构后，会同时进入离线处理（Hadoop）和实时处理（Storm）两个处理模块。离线处理进行批计算，将大量T+1的数据进行汇总。而实时处理则是进行流处理或者是微批处理，计算秒级、分钟级的结果。最后都录入到服务数据库（Serving DB）中进行汇总，暴露给上层服务调用。

Lambda架构的好处是：架构简单，很好的结合了离线批处理和实时流处理的优点，稳定且实时计算成本可控。

此外，它对数据订正也很友好。如果后期数据统计口径变更，重新运行离线任务，则可以很快的将历史数据订正为最新的口径。

然而，Lambda也有很多问题。

其中Jay Kreps认为最突出的问题就是需要同时维护实时处理和离线处理两套代码的同时还要保证两套处理结果保持一致。这无疑是非常让人头疼的。

Kappa架构

Jay Kreps认为通过非常，非常快地增加并行度和重播历史来处理重新处理实时数据，避免在实时数据处理系统上再“粘粘”一个离线数据处理系统。于是，他提出了如上的框架。

Kafka或者其他消息中间件，具备保留多日数据的能力。正常情况下kafka都是吐出实时数据，经过实时处理系统，进入服务数据库（Serving DB）。

当系统需要数据订正时，重放消息，修正实时处理代码，扩展实时处理系统的并发度，快速回溯过去历史数据。

这样的架构简单，避免了维护两套系统还需要保持结果一致的问题，也很好解决了数据订正问题。

但它也有它的问题：

1、消息中间件缓存的数据量和回溯数据有性能瓶颈。通常算法需要过去180天的数据，如果都存在消息中间件，无疑有非常大的压力。同时，一次性回溯订正180天级别的数据，对实时计算的资源消耗也非常大。

2、在实时数据处理时，遇到大量不同的实时流进行关联时，非常依赖实时计算系统的能力，很可能因为数据流先后顺序问题，导致数据丢失。

例如：一个消费者在淘宝网上搜索商品。正常来说，搜索结果里，商品曝光数据应该早于用户点击数据产出。然而因为可能会因为系统延迟，导致相同商品的曝光数据晚于点击数据进入实时处理系统。如果开发人员没意识到这样的问题，很可能会代码设计成曝光数据等待点击数据进行关联。关联不上曝光数据的点击数据就很容易被一些简单的条件判断语句抛弃。

对于离线处理来说，消息都是批处理，不存在关联不上的情况。在Lambda架构下，即使实时部分数据处理存在一定丢失，但因为离线数据占绝对优势，所以对整体结果影响很小。即使当天的实时处理结果存在问题，也会在第二天被离线处理的正确结果进行覆盖。保证了最终结果正确。

混合架构

Kafka传入的消息是这套架构的ODS层，这一点上跟Lambda和Kappa架构是保持一致的。

数据进入数仓后，数据会被Schema Register中注册的规则提取出来，产出一个个对应的schema。即对应DWD层。

有了schema后，数据进入处理加工逻辑。即System部分。这里需要针对实时和离线数仓分别产出对应的加工代码，并执行具体的加工。此处对应的是DWS层。

最后，将加工后产出的schema和table Register系统结合，产出最终的ADS层的数据。

这套架构的好处是通过ECS设计模式的思想，将数据处理过程拆分成：数据声明（Schema Register，Table Register），数据处理（System）和结果拼接（Table Creater）三个流程。在这三个过程中，将Flink、Max Compute视为计算资源，将整体数据加工处理的逻辑独立在底层中间件之上，与开发环境解耦。从而实现工程化的管理数据仓库里的数据和加工过程。

但这套架构也存在一定的问题。例如，实时数据和离线数据是不互通的。如果统计过去180天UV总数时，需要离线和实时数据合并去重的处理就会遇到麻烦。

实时数仓

实时数仓，也是基于分层的模型 ods/dwd/dws/，业务数据和日志数据,事实数据存储在 kafka 中，维度数据存储在 Hbase/Tair 中，dm 层的数据最终导出到 mq/olap/rds/kv 中。ad-hoc  查询基于 Flink 来做。

实时数仓的存储需考虑支持数据重放，方便支持任务重跑。选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列，根据需求设置历史数据保存的时长，比如 Kafka，可以保存全部历史数据。

个人认为：实时也是在离线的基础上搞出来的，把离线做好了待遇也不会差的。离线尤其是建模的思想、还有多维分析、用户画像里面水也很深的。把离线搞清楚，离线的思维和实时思维方法是通的，离线会了就是想往实时转应该方便些。

数据湖

数据量爆发式增长的今天，数字化转型成为IT行业的热点，数据需要更深度的价值挖掘，因此需要确保数据中保留的原始信息不丢失，应对未来不断变化的需求。当前以Oracle为代表的数据库中间件已经逐渐无法适应这样的需求，于是业界也不断地产生新的计算引擎，以便应对大数据时代的到来。企业开始纷纷自建开源Hadoop数据湖架构，原始数据统一存放在HDFS系统上，引擎以Hadoop和Spark开源生态为主，存储和计算一体。缺点是需要企业自己运维和管理整套集群，成本高且集群稳定性较差。

数据湖是一种在系统或存储库中以自然格式存储数据的方法，它有助于以各种模式和结构形式配置数据，通常是对象块或文件。 数据湖的主要思想是对企业中的所有数据进行统一存储，从原始数据（源系统数据的精确副本）转换为用于报告、可视化、分析和机器学习等各种任务的目标数据。

总结

Kappa对比Lambda架构

在真实的场景中，很多时候并不是完全规范的Lambda架构或Kappa架构，可以是两者的混合，比如大部分实时指标使用Kappa架构完成计算，少量关键指标（比如金额相关）使用Lambda架构用批处理重新计算，增加一次校对过程。

这两个架构都是实时架构，都是对离线架构的扩展。

实时数仓与离线数仓的对比

离线数据仓库主要基于sqoop、hive等技术来构建T+1的离线数据，通过定时任务每天拉取增量量数据导⼊到hive表中，然后创建各个业务相关的主题维度数据，对外提供T+1的数据查询接口。

实时数仓当前主要是基于实时数据采集工具，如canal等将原始数据写⼊入到Kafka这样的数据通道中，最后⼀一般都是写 入到类似于HBase这样存储系统中，对外提供分钟级别、甚⾄至秒级别的查询⽅方案。

希望大家可以关注下公众号，会定期分享自己从业经历、技术积累及踩坑经验，支持一下，鞠躬感谢~

关注公众号回复：“资料全集”