乍眼一看，是不是觉得和离线数仓的架构图，相差无几？其实二者差别还是很多的：

与离线数仓相比，实时数仓的层次更少一些
从目前建设离线数仓的经验来看，数仓的数据明细层内容会非常丰富，处理明细数据外一般还会包含轻度汇总层的概念，另外离线数仓中应用层数据在数仓内部，但实时数仓中，app 应用层数据已经落入应用系统的存储介质中，可以把该层与数仓的表分离。
应用层少建设的好处：实时处理数据的时候，每建一个层次，数据必然会产生一定的延迟。
汇总层少建的好处：在汇总统计的时候，往往为了容忍一部分数据的延迟，可能会人为的制造一些延迟来保证数据的准确。举例，在统计跨天相关的订单事件中的数据时，可能会等到 00:00:05 或者 00:00:10 再统计，确保 00:00 前的数据已经全部接受到位了，再进行统计。所以，汇总层的层次太多的话，就会更大的加重人为造成的数据延迟。
与离线数仓相比，实时数仓的数据源存储不同。在建设离线数仓的时候，目前公司整个离线数仓都是建立在 Hive 表之上。但是，在建设实时数仓的时候，同一份表，会使用不同的方式进行存储。比如常见的情况下，明细数据或者汇总数据都会存在 Kafka 里面，但是像商家、直播等维度信息需要借助 Hbase，MySQL 或者其他 KV 存储等数据库来进行存储。
离线数仓建设的数据域也更丰富些，因为离线数仓的应用和分析场景比实时数仓丰富，所以对于基础数据建设的覆盖度要求比实时数仓要高。结合直直播电商的业务场景看，交易、营销、流量、内容这几个数据域的实时应用场景往往最多，因此建设优先级也往往是最高的。

技术架构图