数据仓库架构-实时数仓演进

1 L离线数仓架构

数据仓库从模型层面分为三层：

• ODS，操作数据层，保存原始数据；
• DW，数据仓库明细层，根据主题定义好事实与维度表，保存最细粒度的事实数据；
• DM，数据集市/轻度汇总层，在DWD层的基础之上根据不同的业务需求做轻度汇总；

典型的数仓存储是HDFS/Hive，ETL可以是MapReduce脚本或HiveSQL。

2 Lambda架构

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

注：流处理计算的指标批处理依然计算，最终以批处理为准，即每次批处理计算后会覆盖流处理的结果。（这仅仅是流处理引擎不完善做的折中）

Lambda架构问题：

• 1.同样的需求需要开发两套一样的代码
  这是Lambda架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。
• 2.资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分）
  

3 Kappa架构

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

Kappa架构可以认为是Lambda架构的简化版（只要移除lambda架构中的批处理部分即可）。

在Kappa架构中，需求修改或历史数据重新处理都通过上游重放完成。

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

由于我们汇总层业务要求为5分钟粒度计算，可以接受5分钟延迟。为了代码复用和中间结果保存。对实时计算内部分层进行了改进。

 

转存失败重新上传取消

 

 

架构的重新处理过程

重新处理是人们对Kappa架构最担心的点，但实际上并不复杂：

• 1.选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列，根据需求设置历史数据保存的时长，比如Kafka，可以保存全部历史数据。
• 2.当某个或某些指标有重新处理的需求时，按照新逻辑写一个新作业，然后从上游消息队列的最开始重新消费，把结果写到一个新的下游表中。
• 3.当新作业赶上进度后，应用切换数据源，读取2中产生的新结果表。
• 4.停止老的作业，删除老的结果表。