网站怎么制作免费的,提升审美网站,建模,自适应网站设计稿分析回答
Omega架构我们暂且称之为混合数仓。
什么是ECS设计模式
在谈我们的解法的时候#xff0c;必须要先提ECS的设计模式。
简单的说#xff0c;Entity、Component、System分别代表了三类模型。
实体(Entity)#xff1a;实体是一个普通的对象。通常#xff0c…分析回答
Omega架构我们暂且称之为混合数仓。
什么是ECS设计模式
在谈我们的解法的时候必须要先提ECS的设计模式。
简单的说Entity、Component、System分别代表了三类模型。
实体(Entity)实体是一个普通的对象。通常它只包含了一个独一无二的ID值用来标记它是一个独立的对象。
组件(Component)对象一个方面的数据以及对象如何和世界进行交互。用来标记实体是否需要进行这一方面的处理通常使用结构体类或关联数组实现。
系统(System)每个系统不间断地运行(就像每个系统运行在自己的私有线程上)处理标记使用了该系统处理的组件的每个实体。
Entity对应于数仓中的TableComponent对应SchemaSystem对应数仓中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层则是产出应用最终所需的数据。
所以我们一般的数仓数据处理流程是 基于ECS设计模式设计的混合数仓
在ECS的设计模式下核心考虑的是Component是产出。产出具有业务含义的component组装出具体的业务表Entity。
Schema的注册和Table注册
对应在数仓模型中可以这么理解数仓里的表任何一个schema都是独立的。它们不具有业务含义只是业务的一个属性。组合起来构成一个具有业务含义的表。
因此我们需要一个专门管理schema的系统。这里包含了schema注册和shcema使用。schema注册系统主要负责对schema唯一性作保证避免schema重复从而影响使用。同时规定好Schema从元数据中提取的规则正则表达式或者拆分字符串保证不论在什么系统中都可以得到唯一的提取结果。
schema的使用则依赖table注册系统。通过table注册系统将一些具有相关含义的schema串联起来形成table提供给业务使用。
如下图 Schema开发与混合数仓架构
有了schema注册就要提到schema产出的问题了。在上文提到过在Lambda架构下离线实时数仓需要同时维护两份代码其实就是需要维护两份schema的注册和产出过程。在Kappa架构中虽然只需要在实时数仓中做数据处理但面对大量历史数据处理时需要消耗非常多的资源而且中间结果复用能力有限不适合复杂的业务。
由于我们将schema 注册抽离出来在ECS的设计模式下数据加工过程只有schema之间的交互所以只需要关心数据加工部分代码。而对于FlinkBlink与MaxComputeODPS来说数据处理部分的sql代码都遵循相近的SQL规范这里没查到对应的SQL版本但使用过程中感受是几乎一致差别在于一些函数上。这一点可以通过UDF等方式解决。所以可以保证很好的复用性。如果实时数仓和离线数仓数据处理层面的代码差异较大的话可以引入编译器的形式解决。在任务提交的时候对代码进行差异化的编译适用于对应的数仓。
从而我们可以画出以下的架构图 Kafka传入的消息是这套架构的ODS层这一点上跟Lambda和Kappa架构是保持一致的。
数据进入数仓后数据会被Schema Register中注册的规则提取出来产出一个个对应的schema。即对应DWD层。
有了schema后数据进入处理加工逻辑。即System部分。这里需要针对实时和离线数仓分别产出对应的加工代码并执行具体的加工。此处对应的是DWS层。
最后将加工后产出的schema和table Register系统结合产出最终的ADS层的数据。
这套架构的好处是通过ECS设计模式的思想将数据处理过程拆分成数据声明Schema RegisterTable Register数据处理System和结果拼接Table Creater三个流程。在这三个过程中将Flink、Max Compute视为计算资源将整体数据加工处理的逻辑独立在底层中间件之上与开发环境解耦。从而实现工程化的管理数据仓库里的数据和加工过程。
但这套架构也存在一定的问题。例如实时数据和离线数据是不互通的。如果统计过去180天UV总数时需要离线和实时数据合并去重的处理就会遇到麻烦。
反思扩展
这个架构命名为Omega架构对应希腊字母中的Omega含义是“终结”。我希望这套架构能解决目前实时数仓和离线数仓比较混乱的局面可以让大数据开发、管理的能力更上一个台阶让更多小伙伴可以更加方便的取数加工从而更好的服务于业务。 喵呜面试助手一站式解决面试问题你可以搜索微信小程序 [喵呜面试助手] 或关注 [喵呜刷题] - 面试助手 免费刷题。如有好的面试知识或技巧期待您的共享
