当下，企业的实时计算需求越来越高频。比如很多企业在建的实时数据可视化大屏就是很典型的实时计算场景：大屏数据实时刷新，展示最近一分钟甚至半分钟内的交易额。类似的实时计算场景还有很多，比如智能算法推荐、系统风险预警、实时特征工程等。

而以往的离线数仓具有高延时性，数据时效性一般为T+1，调度频率也是以天为单位，无法满足这些场景的数据时效性要求。所以，实时数仓便成为很多企业的大数据架构选择。

1. 何为实时数仓？

关于实时数仓，目前行业内还没有一个标准的定义。我们可以从以下几个方面来理解“实时数仓”：①实时数仓主要支持实时数据处理，并能够根据业务需求提供实时数据。②实时数仓的整个数据链路均采用实时的方式，包括数据归集、加工处理、数据分发等各环节。③另外，实时数仓的数据生态也采用实时方式，比如数据建设、数据质量、数据血缘、数据治理等。

2. 数仓架构演进

从经典数仓架构到离线数仓架构，再到能支撑实时计算场景需求的Lambda和Kappa架构，数仓架构也经历了较长的演进过程。

数仓架构演进

这里着重介绍一下Lambda架构和Kappa架构。

Lambda架构其实是在离线数仓架构的基础上，新增了一条实时链路，用于支撑低延时业务场景的计算需求。与此同时，离线计算（批处理）链路仍然存在。也就是说，Lambda架构采用实时和离线两条链路。由于同一部分业务代码需要有两套逻辑支撑，所以Lambda架构的后期维护比较复杂，对资源的消耗也比较大。

基于此又迭代产生了Kappa架构。Kappa架构在Lambda架构的基础上进行了优化，删除了Batch Layer（批处理层）的部分，将数据通道以消息队列进行替代，使用同一套逻辑进行离线和实时任务的计算。不过，目前Kappa架构还不是非常成熟，仍存在一些无法解决的问题。

鉴于Lambda架构和Kappa架构都存在一些缺陷，目前很多企业将两者相结合，采用Lambda+Kappa的混合架构进行数仓建设。比如，针对大部分实时指标，企业仍然使用Kappa架构进行计算；针对少量关键指标（比如金额相关），则使用Lambda 架构的批处理模块重新计算，增加一次校对过程，以此确保数据的时效性和计算结果的准确性。

3. 实时数仓技术选型

目前主流的实时计算引擎有Storm、Spark和Flink。如下图，每个计算引擎都有其特性。

各实时计算引擎特性对比

我们建议综合考虑延时和实时场景需求等方面因素，来进行计算引擎的选型。

1. 延时

如果对延时要求较低，可以使用Spark Streaming。Spark Streaming的API非常丰富，并且吞吐量高。此外Spark已经发展较长时间，其生态体系也比较成熟。

如果对延时要求高，则推荐使用Flink。Flink的API也是相对比较丰富的，而且目前Flink社区非常活跃，尤其是在中国，其相关生态迭代迅速。

Structured Streaming也能够满足低延时需求，但是其目前的使用率还比较低，生态迭代发展较慢，相对来讲不是非常成熟。

2. 实时场景的要求

如果企业需要支撑一些比较特殊的实时场景需求，比如窗口、Watermark等，我们比较推荐Flink。Flink对实时场景的支持已经非常完善了。相对而言，Storm的优势不明显，且整体较为陈旧，不是特别建议使用。

4. 实时数仓的建设

和离线数仓一致，实时数仓的建设也采用分层思想：ODS原始层对接原始数据；在ODS原始层之上，对数据进行ETL处理，形成DWD明细层；维度数据比如区域信息，建设成DIM维度层；最终经过数据的分析加工，形成DM汇总层。

下图是实时数仓的分层设计案例，供参考。

对于实时数仓的不同数据层，直播课程里都介绍了相应的建设核心、建设方法。

1. 对于ODS层，需要使数据来源尽可能统一，并能够利用分区来确保数据局部有序。

2. 对于DWD层，重点是解决原始数据中存在的数据噪声、数据不完整和数据格式不统一等情况，形成规范、统一的数据源。在DWD层，除了数据本身，我们还需要为每条数据额外补充一些信息，以应对实时数据生产环节的一些常见问题。比如为了解决重复数据的问题，需要给每一个数据打一个标记，形成“唯一键”，来标记微调数据。

3. 对于DIM层，业内一般采用维表关联等建设方式。

需要注意的是，DIM层的建设要分两部分来看。一是针对变化频率较低的维度数据，比如说地域信息等，可以将离线中的维度数据同步到缓存，然后在缓存中进行访问，或者通过一些公共服务以及维度服务进行查询；二是针对变化频率较高的维度数据，比如说一些商品的价格信息，需要监测其变化情况，并创建一张价格变动的拉链表。

4. 最后是DM汇总层的建设。这一层主要是对共性指标进行统一加工，同时根据主题进行多维度的汇总等操作。

Q&A精选

直播过程中，大家就课程内容进行了交流，本文挑选了直播间的精彩提问做了Q&A梳理。

Q1：数据仓库和数据湖之间有哪些关系？

大数据架构从以数仓为主到演变为数仓+数据湖的形式，其实是业务系统越来越复杂、数据量级越来越大、数据种类越来越多的体现。

早期的数据分析需求大多面对的是业务系统的日志数据，为了适应大规模OLAP场景需求以及支持跨业务系统的复杂场景，基于数仓的大数据处理架构逐渐衍生出来。

随着业务系统的复杂性提升，数据量显著增加，数据结构也更加多元化，结构化数据、半结构化数据，甚至图像、语音、视频等非结构化数据越来越丰富。也许很多数据暂时未得到明确应用，但考虑到数据中可能蕴藏着的巨大潜在价值，企业需要先做好这些数据的存储，以便后续进行探索和挖掘。

这样就很自然的出现了一种妥协的解决方案，我们称之为“数据湖”，即从先进行数据处理后进行数据使用，转变为：先存储数据，待到后续想要使用数据时再考虑具体的数据加工处理方式。

“数据湖”架构既节约了前期的数据接入成本，又可以避免因为数据加工造成有价值信息丢失的情况。

综上，数仓和数据湖面对的是两种不同的大数据场景，个推目前也是通过将两者结合，以更好地进行数据价值挖掘。

Q2：实时任务与离线任务如何调度？

调度可以大致从任务调度、资源调度、调度框架几个方面展开说明。

任务调度：目前，无论是实时还是离线引擎，都会将任务划分为几个阶段（stage）执行。在任务调度机制上，实时任务和离线任务有一定差异。实时程序一般为常驻程序，会在调度阶段给每个stage提前分配资源，待所有资源申请好之后开始运行任务。离线程序一般则是按照顺序依次调度、依次申请资源。

资源调度：资源调度主要是对集群进行资源分配。离线和实时任务在这方面区别不大，目前主流的方式是采用yarn、k8s。

调度框架：调度框架主要负责任务的启动、调度、监控。离线和实时任务使用的框架基本一致，常见的有azkaban、dophinscheduler。

Q3：实时数仓的建设过程中有哪些容易让人陷入误区的点？建设过程中如何避免呢？

首先，没有一种技术能够适用于所有的场景，实时数仓的引入在增加数据时效性的同时也会使数据处理的架构复杂性增加。比如在Lamada架构下，企业还需要维护两套代码。所以，实时数仓在应用的时候，首先要从业务场景出发，期望通过引入实时数仓来解决哪些问题以及达成哪些目标，需要提前思考清楚。

其次，在很多场景下，实时数仓还会出现数据质量不高、离线实时数据不一致、故障容忍度低等缺点，所以数据开发人员还需要考虑这些新问题可能对业务造成的影响。

总体而言，实时数仓的建设还是要紧密结合公司的真实情况和业务需求，避免投入了很多的资源，无法带来业务收益，甚至对业务产生干扰。

Q4：Lambda架构和Kappa架构有区分吗？

在数据链路、开发成本、技术栈等方面都有较大区别： 

数据链路：Lambda架构存在离线、实时2条链路，而Kappa架构会统一数据链路。

开发成本：主流Lambda由于历史原因不同链路会使用不同的计算引擎，如离线采用Spark、实时采用Flink，开发成本较高。而Kappa架构一般会统一计算引擎，开发流程简化，维护成本较低。

技术栈：Lambda的2条数据链路会使用不同体系的组件，如离线采用Hive、Spark，实时采用Kafka、Flink，而kappa架构统一使用实时相关的组件，如Flink、Kafka。

Q5：实时数仓的实时能达到什么级别？

实时数仓通过中间件和更少的数据层级来减少数据的处理周期，实时性可以达到秒级、毫秒级。

 关于个推TechDay“治数训练营”

个推TechDay“治数训练营”系列直播课程由每日互动（个推）结合自身多年来的数据挖掘和治理经验特别打造。汇聚多位优秀大数据架构师的实操方法论，凝结众多数据开发和数据分析工程师的一线实践经验，个推TechDay“治数训练营”下期更精彩，请大家持续关注~