去年，实时数据仓库的概念突然变得非常流行。可能是因为传统的离线数据仓库已经发展了多年，技术相对成熟，所以大家开始将注意力放在更具挑战性的实时数据仓库上；也可能是随着存量市场竞争的到来，对于数据获取速度的要求越来越高，T+1的数据获取无法满足需求，因此实时构建数据的需求也应运而生。

实时数据仓库的技术要求：

1. 高并发性：未来实时数据不仅仅是为几个运营或管理层人员使用，更会面向商户和用户。随着用户数量的增加，会带来并发量的增加。因此，实时数据仓库必须具备提供高并发数据服务的能力。

   
   

2. 查询速度：目前许多实时指标的应用场景是移动端，移动端对数据响应速度的要求远高于PC端。大多数数据使用场景希望能够在毫秒级返回数据。未来，如果将实时标签应用于用户推荐中，对响应速度的要求将更高。

   
   

3. 处理速度：在大促销期间，需要具备极强的处理能力，能够应对流量峰值的情况。还需要具备低延迟甚至零延迟的消费能力。

   
   

实时数据仓库的技术基础：流式技术架构 目前，流式计算框架相对成熟，开源组件如Storm、Spark Streaming和Flink得到广泛应用。简单来说，流式数据处理是指系统每产生一条数据，都会立即采集并发送到流式任务中心进行处理，无需额外的定时调度。

业界广泛采用的框架有Twitter的Storm、Apache的Spark Streaming以及近年来流行的Flink。这些框架整体架构相似，但在实现细节上有许多不同，需要根据业务场景的特征灵活选择。

流式框架具有以下优点：

1. 高时效性：通常延迟在秒级别。
   
   

2. 任务常驻：流式任务一旦启动，会持续运行，直到人为终止，且数据源是无限的。
   
   

3. 高处理性能：流式计算通常会使用高性能服务器来运行任务，因为一旦处理吞吐量无法跟上采集吞吐量，就会导致数据计算延迟。
   
   

4. 逻辑简单：由于流式计算通常是对单条数据进行处理，缺乏数据间关联运算能力，因此在支持的业务逻辑上相对简单，处理结果与离线存在一定差异。
   
   

实时数据仓库的两个常见架构： Lambda架构：Lambda架构的核心理念是"流批一体化"。随着机器性能和数据框架的不断完善，用户实际上并不关心底层如何运行，只要能够按照统一模型返回结果即可。现在许多应用（例如Spark和Flink）都支持这种结构，即数据进入平台后可以选择批处理运行或者流式处理运行，但无论如何，一致性始终保持不变。

Kappa架构：虽然Lambda架构理念很好，但长期使用会导致数据复杂性增加。为解决复杂性问题，有人提出了用一套架构解决所有问题的设想，而流行的做法就是基于流计算。通过增加流计算的时间窗口来实现逻辑上的批处理操作。

实时数据仓库的查询引擎： 实时数据仓库的查询依赖于交互式查询引擎，常见于OLAP场景。根据存储数据方式的不同，可以分为ROLAP、MOLAP和HOLAP：

ROLAP：在大数据生态圈中，常用于ROLAP场景的交互式计算引擎包括Impala和Presto。它们以关系数据库为核心，使用关系型结构进行多维数据表示和存储。

ROLAP将多维结构划分为事实表和维度表。事实表存储数据和维度关键字，维度表存放维度层次、成员类别等维度描述信息。ROLAP的优势是可以实时从源数据中获取最新数据更新，以保持数据实时性，但运算效率较低，用户等待时间较长。

MOLAP：MOLAP是一种通过预计算Cube方式加速查询的OLAP引擎，其核心思想是"空间换时间"。常见代表包括Druid和Kylin。MOLAP以多维数据组织方式为核心，使用多维数组存储数据。

多维数据形成"数据立方体（Cube）"结构，该结构经过高度优化，可以最大程度提高查询性能。MOLAP的优势在于可通过预处理多维数据显著提高运算效率，但占用存储空间大且数据更新有一定延迟。

HOLAP：HOLAP是基于混合数据组织的OLAP实现。根据业务需求，用户可以选择使用ROLAP和MOLAP。通常，不常用或需要灵活定义分析的部分使用ROLAP，而常用、常规模型采用MOLAP。

实时数据仓库的分层模型： 实时数据仓库的分层思路沿用了离线数据仓库的思想。

CDM层（明细数据层）：根据业务场景的不同，CDM层会被划分为各个主题域。

DWS层（汇总数据层）：DWS层对各个域进行适度汇总。

ADS层（应用数据层）：ADS层的设计并不完全根据需求一对一建设，而是结合不同需求对该层进行统一设计，以快速支持更多需求场景。

实时技术中的幂等机制： 幂等是一个数学概念，其特点是任意多次执行产生的影响与一次执行的影响相同，例如setTrue()函数就是一个幂等函数，无论执行多少次，结果都一样。在复杂情况下（如网络波动、Storm重启等），可能出现重复数据，因此并非所有操作都是幂等的。在幂等的概念下，我们需要了解消息传输保障的三种机制：At most once、At least once和Exactly once。

At most once：消息传输机制上每条消息传输零次或一次，即消息可能丢失。

At least once：意味着每条消息会进行多次传输尝试，至少一次成功，即消息传输可能重复但不会丢失。

Exactly once：消息传输机制上每条消息有且只有一次，即消息传输既不会丢失也不会重复。

实时数据仓库中的多表关联： 在流式数据处理中，数据计算基于计算增量进行，因此各个环节到达的时间和顺序都是不确定且无序的。在这种情况下，进行两个表的关联必须将数据存储在内存中。当一条数据到达时，需要在另一个表中查找数据。如果能够找到则关联成功，写入下游；如果找不到，则可以将其分到未分配数据集合中等待。为了提高数据查找性能，在实际处理中，通常会根据关联主键对数据进行分桶处理，减少查找数据量，提高性能。

实时技术中的洪峰挑战： 解决洪峰挑战的主要思路如下：

1. 合理分配独占资源和共享资源：在一台机器中，共享资源池可以被多个实时任务抢占。如果一个任务80%的时间都需要争夺资源，可以考虑分配更多的独占资源。
   
   

2. 合理设置缓存机制：尽管内存的读写性能最好，但仍然有许多数据需要从读库更新。可以将热门数据尽量保留在内存中，并通过异步方式更新缓存。
   
   

3. 计算合并单元：在流式计算框架中，拓扑结构层级越深，性能越差。考虑合并计算单元，可以有效降低数据传输、序列化等时间。
   
   

4. 内存共享：在海量数据处理中，大部分对象以字符串形式存在。合理共享对象在不同线程间，可以大幅降低字符拷贝带来的性能消耗。
   
   

5. 平衡高吞吐与低延迟：高吞吐与低延迟本身就是矛盾体。将多个读写库操作或ACK操作合并可以有效降低数据吞吐量，但也会增加延迟。可以在业务上取舍。
   
   

总结： 在实时数据仓库的建设中，已经有了常用的方案选择。整体架构设计通过分层设计为OLAP查询分担压力，让出计算空间，复杂的计算统一在实时计算层处理，避免给OLAP查询带来过大压力。汇总计算交给OLAP数据库进行。

因此，在整个架构中，实时计算通常使用Spark+Flink，消息队列Kafka处于垄断地位。在大数据领域，Kafka仍然是消息队列应用中的首选。Hbase、Redis和MySQL在特定场景下也有一席之地。