去年开始,实时数仓的概念突然火了。也许是传统的离线数仓搞了很多年,技术相对成熟了,因此大家都把注意力放到了挑战性更高的实时上来;也许是随着存量市场竞争的到来,对于速度的要求越来越快,T+1已经不能满足数据的获取要求了,实时的构建需求也就应运而生了。 总之,时效性开始大于分析性。 文本简单介绍实时数仓的一些基础理论,更系统性的理论,仍然行业需要更大范围的应用和总结。总之,这是一块有前景的新领域,值得探索。 |0x01 实时数仓的技术要求
|0x02 实时数仓的技术基础:流式技术架构目前流式计算框架相对成熟,以Storm、Spark Streaming、Flink为代表的开源组件也被广泛应用。流式数据处理,简单来讲,就是系统每产生一条数据,都会被立刻采集并发送到流式任务中心进行处理,不需要额外的定时调度来执行任务。 目前在业界比较广泛采用的框架有Twitter的Storm、Apache的Spark Streaming,以及最近几年流行的Flink。它们整体架构大同小异,但在实现细节上有诸多的不同,需要根据业务场景的特征来灵活选择框架。 流式框架具备以下优点:
|0x03 实时数仓的两个常见架构Lambda架构:Lambda架构的核心理念是“流批一体化”,因为随着机器性能和数据框架的不断完善,用户其实不关心底层是如何运行的,批处理也好,流式处理也罢,能按照统一的模型返回结果就可以了,这就是Lambda架构诞生的原因。现在很多应用,例如Spark和Flink,都支持这种结构,也就是数据进入平台后,可以选择批处理运行,也可以选择流式处理运行,但不管怎样,一致性都是相同的。 Kappa架构:Lambda架构虽然理念很好,但用多了会有一个问题:数据复杂性大大增加。为了解决复杂性的问题,有人提出了用一套架构解决所有问题的设想,而流行的做法就是基于流计算来做。通过加大流计算的“时间窗口”,来实现逻辑意义上的批处理操作。 |0x04 实时数仓的查询引擎实时数仓的查询依赖于交互式查询引擎,常见于OLAP场景,根据存储数据方式的不同可以分为ROLAP、MOLAP和HOLAP: ROLAP:在大数据生态圈中,主流的应用于ROLAP场景的交互式计算引擎包括Impala和Presto。基于关系数据库OLAP实现(Relational OLAP),它以关系数据库为核心,以关系型结构进行多维数据的表示和存储。 它将多维结构划分成两类表:一类是事实表,迎来存储数据和维度关键字;另一类是维度表,即对每个维度至少使用一个表来存放维度层次、成员类别等维度描述信息。ROLAP的最大好处是可以实时地从源数据中获得最新数据更新,以保持数据实时性,缺点在于运算效率比较低,用户等待时间比较长。 MOLAP:MOLAP是一种通过预计算Cube方式加速查询的OLAP引擎,它的核心思想是“空间换时间”,典型的代表包括Druid和Kylin。基于多维数据组织的OLAP实现(Multidimensional OLAP),它以多维数据组织方式为核心,使用多维数组存储数据。 多维数据在存储系统中形成“数据立方体(Cube)”结构,此结构是高度优化的,可以最大程度提高查询性能。MOLAP的优势在于借助数据多位预处理显著提高运算效率,主要缺陷在于占用存储空间大和数据更新有一定延迟。 HOLAP:基于混合数据组织的OLAP实现(Hybrid OLAP),用户可以根据自己的业务需求,选择哪些模型采用ROLAP、哪些采用MOLAP。一般来说,将不常用或需要灵活定义的分析使用ROLAP,而常用、常规模型采用MOLAP实现。 |0x05 实时数仓的分层模型实时数仓的分层思路沿用了离线的思想。
|0x06 实时技术中的幂等机制幂等是一个数学概念,特点是任意多次执行所产生的影响均与一次执行的影响相同,例如setTrue()函数就是一个幂等函数,无论多次执行,其结果都是一样的。在很多复杂情况下,例如网络波动、Storm重启等,会出现重复数据,因此并不是所有操作都是幂等的。在幂等的概念下,我们需要了解消息传输保障的三种机制:At most once、At least once和Exactly once。
|0x07 实时数仓中的多表关联在流式数据处理中,数据的计算是以计算增量为基础的,所以各个环节到达的时间和顺序,既是不确定的,也是无序的。在这种情况下,如果两表要关联,势必需要将数据在内存中进行存储,当一条数据到达后,需要去另一个表中查找数据,如果能够查到,则关联成功,写入下游; 如果无法查到,可以被分到未分配的数据集合中进行等待。在实际处理中,考虑到数据查找的性能,会把数据按照关联主键进行分桶处理,以降低查找的数据量,提高性能。 |0x08 实时技术中的洪峰挑战主要解决思路有如下几种:
|0xFF 总结在整个实时数仓的建设中,业界已经有了常用的方案选型。整体架构设计通过分层设计为OLAP查询分担压力,让出计算空间,复杂的计算统一在实时计算层处理掉,避免给OLAP查询带来过大的压力。汇总计算交给OLAP数据库进行。 因此,在整个架构中实时计算一般是Spark+Flink配合,消息队列Kafka一家独大,在整个大数据领域消息队列的应用中仍然处于垄断地位,Hbase、Redis和MySQL都在特定场景下有一席之地。 目前还没有一个OLAP系统能够满足各种场景的查询需求。其本质原因是,没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美,每个系统在设计时都需要在这三者间做出取舍。 从长远看,Spark和Flink更有可能成为下一代的Hadoop,值得投入大量时间学习。 |
|