前言

数据仓库在整个数据平台中的地位。

那么什么是数仓，数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策，数据仓库在数据平台中的建设有两个环节：一个是数据仓库的构建，另外一个就是数据仓库的应用。

数据仓库是伴随着企业信息化发展起来的，在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据量变的越来越大，数据格式越来越多，决策要求越来越苛刻，数据仓库技术也在不停的发展 这就是架构升级的原因。

离线数仓(离线大数据架构)

离线大数据架构，使用hadoop平台的hive做数据仓库，报表层数据保存在mysql中，使用tableau做报表系统，这样不用担心存储问题、计算速度也大大加快了。

优点：数据类型支持丰富，支持海量运算，机器配置要求低，时效性低，容错

缺点：不支持实时；运维复杂；查询优化器不如MPP，响应慢

选型依据：不支持实时；运维复杂，不符合人员精简配置原则；性能差

Lambda架构

后来随着网络技术、通信技术的发展，使得终端数据的实时上报传输成为可能，从而业务实系统发生变化，进而导致了我们对需求的时性要求的不断提高。为了应对这种变化，开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，然后和离线计算进整合从而给用户一个完整的实时计算结果，这便是Lambda架构。

为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。

需要注意的是流处理计算的指标批处理依然计算，最终以批处理为准，即每次批处理计算后会覆盖流处理的结果（这仅仅是流处理引擎不完善做的折中），Lambda架构是由Storm的作者Nathan Marz提出的一个实时大数据处理框架。Marz在Twitter工作期间开发了著名的实时大数据处理框架Storm，Lambda架构是其根据多年进行分布式大数据系统的经验总结提炼而成。Lambda架构的目标是设计出一个能满足实时大数据系统关键特性的架构，包括有：高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算，融合不可变性（Immunability），读写分离和复杂性隔离等一系列架构原则，可集成Hadoop，Kafka，Storm，Spark，Hbase等各类大数据组件。

如果抛开上面的Merge 操作，那么Lambda架构就是两条完全不同处理流程，就像下面所示。

优点是：离线和实时分开计算，使用两套框架，架构稳定

缺点是：离线和实时数据很难保持一致性，运维人员需要维护两套框架三层架构，开发人员需要写三套代码

选型依据：数据一致性不可控；运维、开发工作量大，不符合人员精简配置的原则；

Kappa架构

再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的Kappa架构。当然这不要实现这一变化，还需要技术本身的革新——Flink，Flink 的出现使得Exactly-Once 和状态计算成为可能，这个时候实时计算的结果保证最终结果的准确性。

Lambda架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着Flink等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的Jay Kreps提出了Kappa架构。

Kappa架构可以认为是Lambda架构的简化版（只要移除lambda架构中的批处理部分即可）。在Kappa架构中，需求修改或历史数据重新处理都通过上游重放完成。

Kappa架构的重新处理过程

选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列，根据需求设置历史数据保存的时长，比如Kafka，可以保存全部历史数据,当然还有后面出现的Pulsar，以及专门解决实时输出存储的Pravega。

当某个或某些指标有重新处理的需求时，按照新逻辑写一个新作业，然后从上游消息队列的最开始重新消费，把结果写到一个新的下游表中。

当新作业赶上进度后，应用切换数据源，使用新产生的新结果表。停止老的作业，删除老的结果表。

存在的问题

Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。

优点是：单数据流处理框架

缺点是：虽然它的架构相对lamabda架构简单，但是流式处理框架的设置和维护相对复杂，不具备真正意义上的离线数据处理能力；流平台中存储大数据成本高昂

选型依据：离线数据处理能力需要保留，控制成本

实时数仓

实时数仓不应该成为一种架构，只能说是是Kappa架构的一种实现方式，或者说是实时数仓是它的一种在工业界落地的实现，在Kappa架构的理论支持下，实时数仓主要解决数仓对数据实时化的需求，例如数据的实时摄取、实时处理、实时计算等。

其实实时数仓主主要解决三个问题 1. 数据实时性 2. 缓解集群压力  3. 缓解业务库压力。

第一层DWD公共实时明细层 实时计算订阅业务数据消息队列，然后通过数据清洗、多数据源join、流式数据与离线维度信息等的组合，将一些相同粒度的业务系统、维表中的维度属性全部关联到一起，增加数据易用性和复用性，得到最终的实时明细数据。这部分数据有两个分支，一部分直接落地到ADS，供实时明细查询使用，一部分再发送到消息队列中，供下层计算使用。

第二层DWS公共实时汇总层 以数据域+业务域的理念建设公共汇总层，与离线数仓不同的是，这里汇总层分为轻度汇总层和高度汇总层，并同时产出，轻度汇总层写入ADS，用于前端产品复杂的olap查询场景，满足自助分析；高度汇总层写入Hbase，用于前端比较简单的kv查询场景，提升查询性能，比如产出报表等。

实时数仓的的实施关键点

1. 端到端数据延迟、数据流量的监控；

2. 故障的快速恢复能力 数据的回溯处理理，系统支持消费指定时间端内的数据；

3. 实时数据从实时数仓中查询，T+1数据借助离线通道修正；

4. 数据地图、数据⾎血缘关系的梳理理；

5. 业务数据质量量的实时监控，初期可以根据规则的方式来识别质量量状况；

数据保障

• 大促期间流量与数据量都会暴增。实时系统要保证实时性，相对离线系统对数据量要更敏感，对稳定性要求更高。所以为了应对这种场景，还需要在这种场景下做两种准备：1.大促前的系统压测；2.大促中的主备链路保障。

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

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

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

扩展：数据湖

最开始的时候，每个应用程序会产生、存储大量数据，而这些数据并不能被其他应用程序使用，这种状况导致数据孤岛的产生。随后数据集市应运而生，应用程序产生的数据存储在一个集中式的数据仓库中，可根据需要导出相关数据传输给企业内需要该数据的部门或个人，然而数据集市只解决了部分问题。剩余问题，包括数据管理、数据所有权与访问控制等都亟须解决，因为企业寻求获得更高的使用有效数据的能力。

为了解决前面提及的各种问题，企业有很强烈的诉求搭建自己的数据湖，数据湖不但能存储传统类型数据，也能存储任意其他类型数据(文本、图像、视频、音频)，并且能在它们之上做进一步的处理与分析，产生最终输出供各类程序消费。而且随着数据多样性的发展，数据仓库这种提前规定schema的模式显得越来难以支持灵活的探索&分析需求，这时候便出现了一种数据湖技术，即把原始数据全部缓存到某个大数据存储上，后续分析时再根据需求去解析原始数据。简单的说，数据仓库模式是schema  on  write，数据湖模式是schema on read。

参考：
原文地址：20年数仓5大架构演进