说说Omega架构

分析&回答

Omega架构我们暂且称之为混合数仓。

什么是ECS设计模式

在谈我们的解法的时候,必须要先提ECS的设计模式。

简单的说,Entity、Component、System分别代表了三类模型。

实体(Entity):实体是一个普通的对象。通常,它只包含了一个独一无二的ID值,用来标记它是一个独立的对象。

组件(Component):对象一个方面的数据,以及对象如何和世界进行交互。用来标记实体是否需要进行这一方面的处理,通常使用结构体,类或关联数组实现。

系统(System):每个系统不间断地运行(就像每个系统运行在自己的私有线程上),处理标记使用了该系统处理的组件的每个实体。

Entity对应于数仓中的Table,Component对应Schema,System对应数仓中SQL逻辑。

对于数仓来说,每张表的意义是由一群schema决定的。而每一个schema只代表一个含义。SQL代码的作用是组装schema到对应的table中,实现它的业务意义。对于一个OLAP系统,我们喜欢大宽表的意义就是因为OLAP分析的是schema之间的关系,用大宽表可以很轻易的提取所需要的schema,组装一个业务所需的表。

ECS设计模式的核心思想就是,所有shcema都独立出来,整个数仓就是一个大宽表。当需要使用的时候,把对应的schema组装成具有业务含义的table。这就像一个个Component组装成一个Entity一样。而SQL在其中起到的作用是就是产出对应的schema和组装schema。

将ECS设计模式引入数仓设计,希望开发者可以更加关注于逻辑,关注数据如何处理,也就是S的部分。业务则由从列构建表的时候产生。将表结构和数据处理逻辑进行拆分,从而希望能提升SQL代码的可读性和结构性。

传统数仓的数据处理流程

数仓通常是分为三层:ODS(原始数据),DW(数据仓库层),ADS(应用数据层)。ODS是从消息中间件中拿到的最原始的数据。DW层则是对数据进行加工后的数据,通常还是分为:DWS和DWD。DWD层中是对ODS层的数据进行清洗后提取的出来的。而DWS层是经过了一些轻度汇总后的数据。用户可以基于此层直接加工出ADS层所需的数据。ADS层则是产出应用最终所需的数据。

所以我们一般的数仓数据处理流程是:

说说Omega架构_第1张图片

基于ECS设计模式设计的混合数仓

在ECS的设计模式下,核心考虑的是Component是产出。产出具有业务含义的component,组装出具体的业务表(Entity)。

Schema的注册和Table注册

对应在数仓模型中,可以这么理解:数仓里的表,任何一个schema都是独立的。它们不具有业务含义,只是业务的一个属性。组合起来构成一个具有业务含义的表。

因此,我们需要一个专门管理schema的系统。这里包含了schema注册和shcema使用。schema注册系统主要负责对schema唯一性作保证,避免schema重复从而影响使用。同时规定好Schema从元数据中提取的规则(正则表达式或者拆分字符串),保证不论在什么系统中都可以得到唯一的提取结果。

schema的使用则依赖table注册系统。通过table注册系统,将一些具有相关含义的schema串联起来,形成table提供给业务使用。

如下图:

说说Omega架构_第2张图片

Schema开发与混合数仓架构

有了schema注册,就要提到schema产出的问题了。在上文提到过,在Lambda架构下,离线实时数仓需要同时维护两份代码,其实就是需要维护两份schema的注册和产出过程。在Kappa架构中,虽然只需要在实时数仓中做数据处理,但面对大量历史数据处理时需要消耗非常多的资源,而且中间结果复用能力有限,不适合复杂的业务。

由于我们将schema 注册抽离出来,在ECS的设计模式下,数据加工过程只有schema之间的交互,所以只需要关心数据加工部分代码。而对于Flink(Blink)与MaxCompute(ODPS)来说,数据处理部分的sql代码都遵循相近的SQL规范(这里没查到对应的SQL版本,但使用过程中感受是几乎一致,差别在于一些函数上。这一点可以通过UDF等方式解决。),所以可以保证很好的复用性。如果实时数仓和离线数仓数据处理层面的代码差异较大的话,可以引入编译器的形式解决。在任务提交的时候对代码进行差异化的编译,适用于对应的数仓。

从而我们可以画出以下的架构图:

说说Omega架构_第3张图片

Kafka传入的消息是这套架构的ODS层,这一点上跟Lambda和Kappa架构是保持一致的。

数据进入数仓后,数据会被Schema Register中注册的规则提取出来,产出一个个对应的schema。即对应DWD层。

有了schema后,数据进入处理加工逻辑。即System部分。这里需要针对实时和离线数仓分别产出对应的加工代码,并执行具体的加工。此处对应的是DWS层。

最后,将加工后产出的schema和table Register系统结合,产出最终的ADS层的数据。

这套架构的好处是通过ECS设计模式的思想,将数据处理过程拆分成:数据声明(Schema Register,Table Register),数据处理(System)和结果拼接(Table Creater)三个流程。在这三个过程中,将Flink、Max Compute视为计算资源,将整体数据加工处理的逻辑独立在底层中间件之上,与开发环境解耦。从而实现工程化的管理数据仓库里的数据和加工过程。

但这套架构也存在一定的问题。例如,实时数据和离线数据是不互通的。如果统计过去180天UV总数时,需要离线和实时数据合并去重的处理就会遇到麻烦。

反思&扩展

这个架构命名为Omega架构,对应希腊字母中的Omega,含义是“终结”。我希望这套架构能解决目前实时数仓和离线数仓比较混乱的局面,可以让大数据开发、管理的能力更上一个台阶,让更多小伙伴可以更加方便的取数,加工,从而更好的服务于业务。

喵呜面试助手:一站式解决面试问题,你可以搜索微信小程序 [喵呜面试助手] 或关注 [喵呜刷题] -> 面试助手 免费刷题。如有好的面试知识或技巧期待您的共享!

你可能感兴趣的:(大数据,架构,数据仓库,数据库)