几种实时数仓架构设计思路

共 3289字,需浏览 7分钟

 ·

2021-08-13 22:38

01 什么是实时数仓


首先需要明确什么是实时数仓,百度百科与维基百科都没有给出具体说明,哪究竟什么才是实时数仓呢?是不是可以通过实时流实时获取数据就是实时数仓?或者说流批一体就是实时数仓?在或者全面采用实时方式,采集和实时计算才是实时数仓?


这个问题在不同企业可能会有不同答案,有些会认为提供实时看板或实时报表就算是实时数仓;另外一些可能觉得数仓提供出去数据必须都是实时才算实时数仓。其实这个问题没有一个标准答案,不同人、场景、企业对它理解是不一样的。记得之前有位上司讲管理岗与技术岗区别,其中一点是:


对待一件事情或需求,T 岗答案都是明确:要么可以做,要么不可以做;M 岗的回答看似明确,其实会有多种解读角度。【这不就是老油条么,哈哈】


所以从不同角度去解读实时数仓,对什么是实时数仓定义是不一样;一般会有一些几种定义:

  • 具备实时数据处理能力,并能够根据业务需求提供实时数据的数仓能力,如可以为运营侧提供实时业务变化、实时营销效果数据。

  • 数仓中所有数据,从数据采集、加工处理、数据分发都采用实时方式。

  • 从数据建设、数据质量、数据血缘、数据治理等都是采用实时方式。


从中可以看出不同理解,建设实时数仓复杂程度是不一样。但最终建设一套什么样实时数仓还是由业务驱动,需要综合考虑投入产出。



02 实时数仓架构设计思路


数据流转与处理,在实时或者离线数仓基本上都是类似下图的,因为分层是一种非常有效的数据治理方式,所以在实时数仓如何进行管理的问题上,首先考虑的也是分层的处理逻辑。



从上图可以看出,在设计实时数仓方案时,需要对以下几点进行思考(不是为了设计出最牛逼技术方案,而是所设计方案是最切合业务场景与资源情况的;有时候牛逼技术方案会加大技术复杂程度与运维难度,会很考验我们驾驭能力;因此我们选择的不是技术最牛逼方案,而且最切合我们实际情况方案):
  • 是否数据集成流批一体:离线与实时是否使用统一数据采集方式;如统一通过 CDC 或者 OGG 将数据实时捕获推送到 kafka,批与流在从 kafka 中消费数据,载入明细层。

  • 是否存储层流批一体:离线与实时数据是否统一分层、统一存储;如离线与实时数据经过 ETL 处理之后根据统一分层(ODS、DMD、DMS)持久化到同一个数据存储中。

  • 是否 ETL 逻辑流批一体:流与批处理是否使用统一 SQL 语法或者 ETL 组件,再通过底层分别适配流与批计算引擎。

  • 是否 ETL 计算引擎流批一体:流与批使用同一套计算引擎,从根本上避免同一个处理逻辑流批两套代码问题。


数据集成与存储层流批一体主要产生以下问题:

  • 流处理更容易出现数据丢失,丢失的查询操作。

  • 一般使用消息中间件对流数据进行存储,消息中间件的存储特点也决定了,丢失的查询操作,非常苦难,难以对数。

  • Schema 的同步与转换问题,基于流处理来确保 Schema 保持一致,并且数据不受影响其实并不容易。面对频繁变动的业务系统,往往维护量会变高。



03 几种实时数仓架构分析


根据这几个是否一体:“是否数据集成流批一体、“是否存储层流批一体”、“是否 ETL 逻辑流批一体”、“是否 ETL 计算引擎流批一体”,不同流批一体组合会设计出不一样的实时数仓架构。比较经典的架构有 LambdaKappa;还有美团实时数仓架构(实时数据生产 + 实时分析引擎)与阿里的流批一体架构(Lambda+Kappa)。下面分别对这几个实时数仓架构概括说明。

Lambda 数仓架构



Lambda 有 Batch Layer(批处理)和 Speed Layer(流式处理)。然后通过将批、和流的结果拼接在一起。Lambda 架构具备有数据不可变性质避免人为引入错误问题、支持数据重跑、将复杂的流处理分离出来。而 Batch Layer 和 Speed Layer 由于需要满足不同的场景,往往会选择不同的组件。


而且,大家写过 Storm 就会知道,Storm 的代码写起来的是挺痛苦的(Trident 会有所改善)。所以,我们需要准备两套代码。同样的逻辑,针对批处理、和流处理要实现两次。


Lambda 架构问题:

  • 两套架构、各自独立

  • 一种逻辑两套代码

  • 组件太多

  • 数据散布在多个系统中,互相访问困难

Kappa 架构


Kreps 提出了另一个维度的思考,我们是否能够改进,采用流处理系统来建设大数据系统呢?提出完全可以通过建设以流为核心来建设数据系统。并且,通过重放历史数据来实现数据重跑。


这种以流处理为核心来建设数据系统,Kreps 称之为「Kappa 架构」。Kappa 和 Lambda 都是希腊字母符号。这套架构远比 Lambda 架构简单。就是把原先批处理,改成流处理。它没有了 Lambda 架构中的 Batch Layer、Speed Layer、以及 Serve Layer。



Lambda 架构问题:

  • 大数据量回溯成本高,生产压力大

  • 遗留离线数据数仓的迁移问题,要将成千上万的 ETL 作业迁往流处理系统,其工作量之大、成本之大、风险之大

  • 数据丢失的问题,流处理平台,数据丢失问题相对于批处理,更容易出现。而且,要进行对数非常困难

实时数据生产 + 实时分析引擎



上图是美团实时数仓架构设计,数据从日志统一采集到消息队列,再到数据流的 ETL 过程,作为基础数据流的建设是统一的。之后对于日志类实时特征,实时大屏类应用走实时流计算。


对于 Binlog 类业务分析走实时 OLAP 批处理。美团实时数仓架构主要是将一些在实时处理面临的难点,由实时 OLAP 处理。

实时处理面临的几个难点:

  • 业务的多状态性:业务过程从开始到结束是不断变化的,比如从下单->支付->配送,业务库是在原始基础上进行变更的,Binlog 会产生很多变化的日志。而业务分析更加关注最终状态,由此产生数据回撤计算的问题,例如 10 点下单,13 点取消,但希望在 10 点减掉取消单。

  • 业务集成:业务分析数据一般无法通过单一主体表达,往往是很多表进行关联,才能得到想要的信息,在实时流中进行数据的合流对齐,往往需要较大的缓存处理且复杂。

  • 分析是批量的,处理过程是流式的:对单一数据,无法形成分析,因此分析对象一定是批量的,而数据加工是逐条的。

Lambda+Kappa



从上图可以看出,阿里的实时数仓架构是同时 Lambda 与 Kappa 结合;数据集成没有使用流批一体,分别通过实时采集、数据同步方式实现流与批数据采集。ETL 逻辑流批一体,实现用户只写一套代码,平台自动翻译成 Flink Batch 任务和 Flink Stream 任务,同时写到一张 Holo 表,完成计算层表达的统一。存储层流与批是分开存储,但可以实现流批存储透明化,查询逻辑完全一致。



04 总结


架构设计不是为了设计出最牛逼技术方案,而是所设计方案是最切合业务场景与资源情况的。有时候牛逼技术方案会加大技术复杂程度与运维难度,需要投入更高成本驾驭它。因此我们选择的不是技术最牛逼方案,而且最切合我们实际情况技术架构。


在实时数仓架构设计时,主要是思考“是否数据集成流批一体、“是否存储层流批一体”、“是否 ETL 逻辑流批一体”、“是否 ETL 计算引擎流批一体”;权衡这几个一体带来问题,而设计出符合业务场景的实时数仓架构。

推荐阅读:

世界的真实格局分析,地球人类社会底层运行原理

不是你需要中台,而是一名合格的架构师(附各大厂中台建设PPT)

企业IT技术架构规划方案

论数字化转型——转什么,如何转?

华为干部与人才发展手册(附PPT)

企业10大管理流程图,数字化转型从业者必备!

【中台实践】华为大数据中台架构分享.pdf

华为的数字化转型方法论

华为如何实施数字化转型(附PPT)

超详细280页Docker实战文档!开放下载

华为大数据解决方案(PPT)

浏览 112
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报