一.实时数仓的产生

传统意义上的数据仓库主要处理T+1（有的也称为D+1）数据（即：今天产生的数据分析结果明天才能看到），T+1的概念来源于股票交易，是一种股票交易制度，即当日买进的股票，要到下一个交易日才能卖出。

随着数据时效性在企业运营中的重要性日益凸现，例如，实时推荐、精准营销、广告投放效果、实时物流等。数据的实时处理能力成为企业提升竞争力的一大因素，最初阶段企业主要采用来一个需求，编写一个实时计算任务的方式来处理实时数据，随着需求的增多，计算任务也相应增多，并且不同任务的开发人员不同，导致开发风格差异化，该阶段的实时数据处理缺乏统一的规划，代码风格差异化严重，在维护成本和开发效率上有很大障碍。

为避免上述问题，人们参照数据仓库的概念和模型来重新规划和设计实时数据处理，在此基础上产生了实时数据仓库（实时数仓）。

二.离线数仓与实时数仓对比

离线实时数仓对比图

在这里简单说一下大数据数据仓库的架构：

离线大数据架构：HDFS存储，hive、mr、spark进行离线计算；
Lambda架构：在离线大数据架构的基础上增加新链路用于实时数据处理，需要维护离线处理和实时处理两套代码；
Kappa架构：批流合一，离线处理和实时处理整合成一套代码，运维成本小，这就是现今flink之所以火的原因。Kappa架构已成为数据仓库架构的新趋势。

三.实时数仓建设思路

计算框架选型：storm/flink等实时计算框架，强烈推荐flink，其『批量合一』的特性及活跃的开源社区，有逐渐替代spark的趋势。
数据存储选型：首要考虑查询效率，其次是插入、更新等问题，可选择apache druid，不过在数据更新上存在缺陷，选型时注意该问题频繁更新的数据建议不要采用该方案。当然存储这块需要具体问题具体分析，不同场景下hbase、redis等都是可选项。
实时数仓分层：为更好的统一管理数据，实时数仓可采用离线数仓的数据模型进行分层处理，可以分为实时明细层写入druid等查询效率高的存储方便下游使用；轻度汇总层对数据进行汇总分析后供下游使用。
数据流转方案：实时数仓的数据来源可以为kafka消息队列，这样可以做到队列中的数据即可以写入数据湖用于批量分析，也可以实时处理，下游可以写入数据集市供业务使用。