实时计算是常见的大数据计算场景。业务部门需要实时反馈产品的被点击、浏览、收藏、购买、评价等数据，对时延的要求一般是秒级，甚至毫秒级。而批处理计算引擎一般需要几分钟或者几小时才能返回结果，显然无法满足该场景的计算需求。基于实时计算的需求，流式计算引擎应运而生。目前，应用得较多的流式计算引擎主要有Spark、Storm和Flink。
典型的实时计算流程如下图所示，首先通过Flume实时采集数据，然后通过消息队列对采集的数据进行缓存，之后应用流式计算引擎实施计算，最后将计算的结果存储在高速的查询引擎中，以便后续高效地使用这些数据支持报表开发、多维分析或者数据挖掘等。
一、实时计算和离线计算如何高效共存
部分企业对实时计算和离线计算共存的需求十分迫切。大部分的报表和任务还是以离线计算为主，对实时要求较高的应用需要使用实时计算引擎。
最直观的想法是分别为离线计算和实时计算场景搭建计算平台，让两套平台共存。这就是常说的Lambda架构的处理方式，如下图（1）所示。
一个企业如果维护两套独立的计算平台，那么成本较高，运维难度大，且两个平台的数据准确性和一致性难以保障。如何高效地解决两套计算引擎共存的问题
Kappa 流批一体化架构和处理方式能有效地解决两者高效共存的问题，其架构示意图如上图（2）所示。Kappa架构的核心组件是消息队列、数据仓库、流批一体化计算引擎和高效的查询引擎。目前，最流行的流批一体化计算引擎是Flink。
二、实时数据仓库
实时数据仓库与离线数据仓库最大的区别是通过使用消息队列、流批一体化计算引擎、查询引擎等工具让整个平台的计算和查询效率更高，以满足业务的实时需求。因此，实时数据仓库对计算能力要求更高。如果数据量短期陡然增加，那么要考虑实时数据仓库的性能和稳定性问题。相比之下，离线数据仓库对数据量的增加不太敏感，性能更加稳定。另外，从分层建模的角度来看，实时数据仓库的层级不宜太多，否则会增加响应的延时。下图是基于流批一体化计算引擎
1.ODS层
从数据源中抽取贴源数据并将其存储在Kafka中，构成了实时数据仓库的ODS层。
2.DWD层
通过实时订阅Kafka中的流式业务数据，利用Flink计算引擎进行ETL、清洗、聚合、多表关联等操作，得到实时的明细数据，并将其存储在Kafka中。
3.DWS层
通过Flink计算引擎对DWD层的明细数据进行聚合和汇总操作，得到DWS层。基于业务差异化的需求，DWS层分为轻度汇总层和高度汇总层。轻度汇总层的主要用途是支持APP层的应用需求。高度汇总层的主要用途是满足业务对统计数据的高效查询需求，如实时大屏、数据产品等。
4.APP层
基于业务的差异化需求，轻度汇总层会采用不同的存储介质。比如，OLAP需求一般存储在ClickHouse或者Kylin中。查询需求一般存储在Elasticsearch、HBase或MongoDB中。高度汇总层的数据量一般较小，为了满足高效的查询需求，数据一般存储在高速查询的介质中，如MySQL 和HBase中。如果数据量更小，那么数据可以存储在内存数据库Redis 中，以便进一步提高查询效率。
APP 层是数据应用层，基于下面各层的数据开发各种应用，如BI、多维分析、及时查询、数据检索、定价、反欺诈等。
5.DIM 层
DIM 层的主要存储引擎是MySQL、Redis和HBase。在数据量比较小的情况下，可以使用内存数据库，效率更高。HBase能有效地支持添加（Append） 操作， 查询结果以秒级别返回。对于维度多变的场景， 可以有限地使用HBase存储。