<>|0x00 数仓为什么要实时

去年开始,实时数仓的概念突然火了。也许是传统的离线数仓搞了很多年,技术相对成熟了,因此大家都把注意力放到了挑战性更高的实时上来;也许是随着存量市场竞争的到来,对于速度的要求越来越快,T+1已经不能满足数据的获取要求了,实时的构建需求也就应运而生了。
总之,时效性开始大于分析性。
文本简单介绍实时数仓的一些基础理论,更系统性的理论,仍然行业需要更大范围的应用和总结。总之,这是一块有前景的新领域,值得探索。

<>|0x01 实时数仓的技术要求

* 高并发性

未来的实时数据一定不是仅仅给几个运营或管理层人员使用,会更多的面向商户、用户,那么用户增加的情况下一定会带来并发量的提升,因此实时数仓一定要具备提供高并发数据服务的能力。
* 查询速度

目前很多实时指标的应用场景在移动端,移动端对于数据的响应要求远高于PC端,对于大多数数据使用场景希望能够毫秒级返回,未来实时标签如果应用到用户推荐上,对于响应的速度要求更高。
* 处理速度
要保证大促期间,在流量峰值的情况下有极强的处理能力,并且具备消费低延迟性甚至0延迟。
<>|0x02 实时数仓的技术基础:流式技术架构

目前流式计算框架相对成熟,以Storm、Spark
Streaming为代表的开源组件也被广泛应用。流式数据处理,简单来讲,就是系统每产生一条数据,都会被立刻采集并发送到流式任务中心进行处理,不需要额外的定时调度来执行任务。目前在业界比较广泛采用的框架有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 实时数仓的分层模型

实时数仓的分层思路沿用了离线的思想。

* CDM层(明细数据层): CDM层主要分交易、营销、流量、商户、商品、履约、客满7个域。
* DWS层(汇总数据层):DWS层对各个域进行了适度汇总。
* ADS层 (应用数据层):ADS层并不完全根据需求一对一建设,而是结合不同的需求对这一层进行统一设计,形成新零售的指标库,以快速支撑更多的需求场景。
<>|0x06 实时数仓中的幂等机制

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

* At most once:消息传输机制是每条消息传输零次或者一次,即消息可能会丢失;
* At least once:意味着每条消息会进行多次传输尝试,至少一次成功,即消息传输可能重复但不会丢失;
* Exactly once:的消息传输机制是每条消息有且只有一次,即消息传输既不会丢失也不会重复。
<>|0x07 实时数仓中的多表关联

在流式数据处理中,数据的计算是以计算增量为基础的,所以各个环节到达的时间和顺序,既是不确定的,也是无序的。在这种情况下,如果两表要关联,势必需要将数据在内存中进行存储,当一条数据到达后,需要去另一个表中查找数据,如果能够查到,则关联成功,写入下游;如果无法查到,可以被分到未分配的数据集合中进行等待。在实际处理中,考虑到数据查找的性能,会把数据按照关联主键进行分桶处理,以降低查找的数据量,提高性能。

<>|0x08 实时数仓中的洪峰挑战

主要解决思路有如下几种:

* 独占资源与共享资源合理分配:在一台机器中,共享资源池可以被多个实时任务抢占,如果一个任务80%的时间都需要抢资源,可以考虑分配更多的独占资源;
* 合理设置缓存机制:虽然内存的读写性能是最好的,但很多数据依然需要读库更新,可以考虑将热门数据尽量多的留在内存中,通过异步的方式来更新缓存;
* 计算合并单元:在流式计算框架中,拓扑结构的层级越深,性能越差,考虑合并计算单元,可以有效降低数据的传输、序列化等时间;
* 内存共享:在海量数据的处理中,大部分的对象都是以字符串形式存在的,在不同线程间合理共享对象,可以大幅度降低字符拷贝带来的性能消耗;
*
在高吞吐与低延迟间寻求平衡:高吞吐与低延迟天生就是一对矛盾体,将多个读写库的操作或者ACK操作合并时,可以有效降低数据吞吐,但也会增加延迟,可以进行业务上的取舍。
<>|0xFF 总结

在整个实时数仓的建设中,业界已经有了常用的方案选型。整体架构设计通过分层设计为OLAP查询分担压力,让出计算空间,复杂的计算统一在实时计算层处理掉,避免给OLAP查询带来过大的压力。汇总计算交给OLAP数据库进行。因此,在整个架构中实时计算一般是Spark+Flink配合,消息队列Kafka一家独大,在整个大数据领域消息队列的应用中仍然处于垄断地位,Hbase、Redis和MySQL都在特定场景下有一席之地。

目前还没有一个OLAP系统能够满足各种场景的查询需求。其本质原因是,没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美,每个系统在设计时都需要在这三者间做出取舍。
从长远看,Spark和Flink更有可能成为下一代的Hadoop,值得投入大量时间学习。

技术
下载桌面版
GitHub
百度网盘(提取码:draw)
Gitee
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:[email protected]
QQ群:766591547
关注微信