看来大家还是对数据仓库和大数据平台比较感兴趣，今天就和大家再聊聊怎么做实时数仓吧。实时数仓可谓是决定性的东西，能决定什么？决定你的报表和BI到底能不能实时展现数据。

1、数据仓库的发展趋势

1.1 数据仓库的趋势

关于数据仓库的概念就不多介绍了。

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

数据仓库的趋势：

• 实时数据仓库以满足实时化&自动化决策需求
• 大数据&数据湖以支持大量&复杂数据类型

 

1.2 数据仓库的发展

数据仓库有两个环节：数据仓库的构建与数据仓库的应用。

早期数据仓库构建主要指的是把企业的业务数据库如 ERP、CRM、SCM 等数据按照决策分析的要求建模并汇总到数据仓库引擎中，其应用以报表为主，目的是支持管理层和业务人员决策（中长期策略型决策）。

随着业务和环境的发展，这两方面都在发生着剧烈变化。

随着IT技术走向互联网、移动化，数据源变得越来越丰富，在原来业务数据库的基础上出现了非结构化数据，比如网站 log，IoT 设备数据，APP 埋点数据等，这些数据量比以往结构化的数据大了几个量级，对 ETL 过程、存储都提出了更高的要求。

互联网的在线特性也将业务需求推向了实时化，随时根据当前客户行为而调整策略变得越来越常见，比如大促过程中库存管理，运营管理等（即既有中远期策略型，也有短期操作型）；同时公司业务互联网化之后导致同时服务的客户剧增，有些情况人工难以完全处理，这就需要机器自动决策，比如欺诈检测和用户审核。

 

总结来看，对数据仓库的需求可以抽象成两方面：实时产生结果、处理和保存大量异构数据。

2、数据仓库架构的演变

从1990年 Inmon 提出数据仓库概念到今天，数据架构经历了最初的传统数仓架构——离线数仓库——离线大数据架构、Lambda 架构、Kappa 架构以及 Flink 的火热带出的流批一体架构，数据架构技术不断演进，本质是在往流批一体的方向发展，让用户能以最自然、最小的成本完成实时计算。

2.1 传统数仓架构

 

这是比较传统的一种方式，结构或半结构化数据通过离线ETL定期加载到离线数据，之后通过计算引擎取得结果，供前端使用。这里的离线数仓+计算引擎，通常是使用大型商业数据库来承担，例如Oracle、DB2、Teradata等。

2.2 离线大数据架构

随着数据规模的不断增大，传统数仓方式难以承载海量数据。随着大数据技术的普及，采用大数据技术来承载存储与计算任务。当然，也可以使用传传统数据库集群或MPP架构数据库来完成。例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。

2.3 Lambda架构

 

随着业务的发展，随着业务的发展，人们对数据实时性提出了更高的要求。此时，出现了Lambda架构，其将对实时性要求高的部分拆分出来，增加条实时计算链路。从源头开始做流式改造，将数据发送到消息队列中，实时计算引擎消费队列数据，完成实时数据的增量计算。

与此同时，批量处理部分依然存在，实时与批量并行运行。最终由统一的数据服务层合并结果给于前端。一般是以批量处理结果为准，实时结果主要为快速响应。

2.4 Kappa架构

 

Lambda架构，一个比较严重的问题就是需要维护两套逻辑。一部分在批量引擎实现，一部分在流式引擎实现，维护成本很高。此外，对资源消耗也较大。而后面诞生的Kappa架构，正是为了解决上述问题。其在数据需要重新处理或数据变更时，可通过历史数据重新处理来完成。

方式是通过上游重放完成(从数据源拉取数据重新计算)。Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。

2.5混合架构

上述架构各有其适应场景，有时需要综合使用上述架构组合满足实际需求。当然这也必将带来架构的复杂度。用户应根据自身需求，有所取舍。在一般大多数场景下，是可以使用单一架构解决问题。现在很多产品在流批一体、海量、实时性方面也有非常好的表现，可以考虑这种“全能手”解决问题。

 

3、三种大数据数据仓库架构

3.1 离线大数据架构

数据源通过离线的方式导入到离线数据中。下游应用根据业务需求选择直接读取 DM 或加一层数据服务，比如 MySQL 或 Redis。数据仓库从模型层面分为三层：

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

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

 

3.2 Lambda 架构

Lambda 架构问题：

同样的需求需要开发两套一样的代码：这是 Lambda 架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。

资源占用增多：同样的逻辑计算两次，整体资源占用会增多，多出实时计算这部分

 

3.3 Kappa 架构

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

• Kappa 架构可以认为是 Lambda 架构的简化版（只要移除 lambda 架构中的批处理部分即可）。
• 在 Kappa 架构中，需求修改或历史数据重新处理都通过上游重放完成。
• Kappa 架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。

 

Kappa 架构的重新处理过程：

 

3.4 Lambda 架构与 Kappa 架构的对比

 

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

Kappa 架构并不是中间结果完全不落地，现在很多大数据系统都需要支持机器学习（离线训练），所以实时中间结果需要落地对应的存储引擎供机器学习使用，另外有时候还需要对明细数据查询，这种场景也需要把实时明细层写出到对应的引擎中。后面案例会涉及到。

 

4、实时数仓建设思路

计算框架选型：storm/flink等实时计算框架，强烈推荐flink，其『批量合一』的特性及活跃的开源社区，有逐渐替代spark的趋势。

数据存储选型：首要考虑查询效率，其次是插入、更新等问题，可选择apache druid，不过在数据更新上存在缺陷，选型时注意该问题频繁更新的数据建议不要采用该方案。当然存储这块需要具体问题具体分析，不同场景下hbase、redis等都是可选项。

实时数仓分层：为更好的统一管理数据，实时数仓可采用离线数仓的数据模型进行分层处理，可以分为实时明细层写入druid等查询效率高的存储方便下游使用；轻度汇总层对数据进行汇总分析后供下游使用。

数据流转方案：实时数仓的数据来源可以为kafka消息队列，这样可以做到队列中的数据即可以写入数据湖用于批量分析，也可以实时处理，下游可以写入数据集市供业务使。

5、菜鸟实时数仓案例

最后分享菜鸟仓配实时数据仓库的案例本，涉及全局设计、数据模型、数据保障等几个方面。

5.1 整体设计

整体设计如下图，基于业务系统的数据，数据模型采用中间层的设计理念，建设仓配实时数仓；计算引擎，选择更易用、性能表现更佳的实时计算作为主要的计算引擎；数据服务，选择天工数据服务中间件，避免直连数据库，且基于天工可以做到主备链路灵活配置秒级切换；数据应用，围绕大促全链路，从活动计划、活动备货、活动直播、活动售后、活动复盘五个维度，建设仓配大促数据体系。

 

5.2 数据模型

不管是从计算成本，还是从易用性，还是从复用性，还是从一致性等等，都必须避免烟囱式的开发模式，而是以中间层的方式建设仓配实时数仓。与离线中间层基本一致，将实时中间层分为两层。

 

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

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

6、美团点评基于Flink的实时数仓平台实践

下图所示的是美团点评实时计算平台的架构

 

最底层是收集层，这一层负责收集用户的实时数据，包括 Binlog、后端服务日志以及 IoT 数据，经过日志收集团队和 DB 收集团队的处理，数据将会被收集到 Kafka 中。这些数据不只是参与实时计算，也会参与离线计算。

收集层之上是存储层，这一层除了使用 Kafka 做消息通道之外，还会基于 HDFS 做状态数据存储以及基于 HBase 做维度数据的存储。

存储层之上是引擎层，包括 Storm 和 Flink。实时计算平台会在引擎层为用户提供一些框架的封装以及公共包和组件的支持。

在引擎层之上就是平台层了，平台层从数据、任务和资源三个视角去管理。

架构的最上层是应用层，包括了实时数仓、机器学习、数据同步以及事件驱动应用等。

从功能角度来看，美团点评的实时计算平台主要包括作业和资源管理两个方面的功能。其中，作业部分包括作业配置、作业发布以及作业状态三个方面的功能。

• 在作业配置方面，则包括作业设置、运行时设置以及拓扑结构设置；
• 在作业发布方面，则包括版本管理、编译/发布/回滚等；
• 作业状态则包括运行时状态、自定义指标和报警以及命令/运行时日志等。

在资源管理方面，则为用户提供了多租户资源隔离以及资源交付和部署的能力。

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

在看过前面的案例之后，我们看一下实时数仓与离线数仓在几方面的对比：

首先，从架构上，实时数仓与离线数仓有比较明显的区别，实时数仓以 Kappa 架构为主，而离线数仓以传统大数据架构为主。Lambda 架构可以认为是两者的中间态。

其次，从建设方法上，实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论，产出事实宽表。另外实时数仓中实时流数据的 join 有隐藏时间语义，在建设中需注意。

最后，从数据保障看，实时数仓因为要保证实时性，所以对数据量的变化较为敏感。在大促等场景下需要提前做好压测和主备保障工作，这是与离线数据的一个较为明显的区别。

综上，实时数仓主要解决数据时效性问题，结合机器学习框架可以处理实时推荐、实时获取广告投放效果等智能化业务场景。实时数仓的建设应早日提上日程，未来企业对数据时效性的要求会越来越高，实时数仓会很好的解决该问题。