CN114490571A - 一种建模方法、服务器及存储介质 - Google Patents
一种建模方法、服务器及存储介质 Download PDFInfo
- Publication number
- CN114490571A CN114490571A CN202111633342.3A CN202111633342A CN114490571A CN 114490571 A CN114490571 A CN 114490571A CN 202111633342 A CN202111633342 A CN 202111633342A CN 114490571 A CN114490571 A CN 114490571A
- Authority
- CN
- China
- Prior art keywords
- index
- dimension
- model
- words
- standard
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/21—Design, administration or maintenance of databases
- G06F16/211—Schema design and management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/28—Databases characterised by their database models, e.g. relational or object models
- G06F16/283—Multi-dimensional databases or data warehouses, e.g. MOLAP or ROLAP
Landscapes
- Engineering & Computer Science (AREA)
- Databases & Information Systems (AREA)
- Theoretical Computer Science (AREA)
- Data Mining & Analysis (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Machine Translation (AREA)
Abstract
本申请实施例提供一种建模方法、服务器及存储介质,其中方法包括:获取需求描述语言;对需求描述语言进行分词处理,以确定匹配指标元素的指标词;所述指标元素包括时间周期、修饰词和原子指标;将匹配指标元素的指标词翻译为匹配指标元素的标准词;若匹配指标元素的标准词不存在已录入的派生指标,为匹配指标元素的标准词定义派生指标,并自动录入派生指标;输出派生指标,作为构建的指标模型;所述派生指标包括描述时间周期、修饰词和原子指标的标准词。进一步的,本申请实施例还提供快速构建维度模型的方案,以及逆向生成维度模型的方案。本申请实施例可提升模型构建效率,所构建的模型包括指标模型;进一步的,所构建的模型还包括维度模型。
Description
技术领域
本申请实施例涉及数据仓库技术领域,具体涉及一种建模方法、服务器及存储介质。
背景技术
数据仓库简称数仓,是为企业所有级别的决策制定过程,提供所有类型数据支持的战略集合。数仓中具有指标模型和数仓模型,针对数仓的建模涉及到构建指标模型和数仓模型。指标模型作为数仓中的重要模型,如何提升模型构建效率,一直是本领域技术人员亟需解决的技术问题。
发明内容
有鉴于此,本申请实施例提供一种建模方法、服务器及存储介质,以提升模型构建效率。
为实现上述目的,本申请实施例提供如下技术方案。
第一方面,本申请实施例提供一种建模方法,包括:
获取构建指标模型的需求描述语言;
对所述需求描述语言进行分词处理,以从所述需求描述语言中确定匹配指标元素的指标词;所述指标元素包括时间周期、修饰词和原子指标;
将所述匹配指标元素的指标词翻译为匹配指标元素的标准词;
若所述匹配指标元素的标准词不存在已录入的派生指标,为所述匹配指标元素的标准词定义派生指标,并自动录入所述派生指标;输出所述派生指标,作为构建的指标模型;所述派生指标包括描述时间周期、修饰词和原子指标的标准词。
进一步的,所述第一方面的建模方法还包括:
根据目标维度,选择元仓的业务系统的主表;
从所述主表中,筛选与所述目标维度对应的维度模型的核心属性;
根据所述主表的元信息以及所述核心属性,生成维度模型的基础模型;
选择关联维度,在所述基础模型的基础上冗余所述关联维度的核心属性,并建立基础模型与关联维度的关联关系;
基于所述关联关系以及数据来源,对维度模型自动进行数据开发和代码生成。
进一步的,所述第一方面的建模方法还包括:
加载数仓表;
根据配置的至少一个分层划域规则,对所述数仓表的表命名进行解析,从所述表命名中解析出与各分层划域规则对应的命名表达式,以得到至少一个命名表达式;其中,一个分层划域规则定义分层划域信息的一种设计对应的表命名方式;
从所述至少一个命名表达式中确定目标命名表达式,将所述目标命名表达式对应的分层划域信息,作为目标分层划域信息;
根据推导特征,推导数仓表对应的维度模型的类型;将所述数仓表逆向为所述类型的维度模型对应的模型表,将所述模型表关联上目标分层划域信息。
第二方面,本申请实施例提供一种服务器,包括至少一个存储器和至少一个处理器,所述存储器存储一条或多条计算机可执行指令,所述处理器调用所述一条或多条计算机可执行指令,以执行如上述所述的建模方法。
第三方面,本申请实施例提供一种存储介质,所述存储介质存储一条或多条计算机可执行指令,所述一条或多条计算机可执行指令被执行时实现如上述所述的建模方法。
本申请实施例提供的建模方法,可获取构建指标模型的需求描述语言,对所述需求描述语言进行分词处理,以从所述需求描述语言中确定匹配指标元素的指标词,所述指标元素包括时间周期、修饰词和原子指标;将所述匹配指标元素的指标词翻译为匹配指标元素的标准词;若所述匹配指标元素的标准词不存在已录入的派生指标,则可为所述匹配指标元素的标准词定义派生指标,并自动录入所述派生指标,同时输出所述派生指标,作为构建的指标模型;其中,所述派生指标包括描述时间周期、修饰词和原子指标的标准词。可见,本申请实施例可将需求人员提供的非结构化的需求描述语言,通过自动的智能分词、翻译的解析处理,产出符合OneData理论的匹配指标元素的标准词,并为匹配指标元素的标准词自动定义派生指标,自动录入到指标管理平台,降低了OneData理论应用的门槛,同时建模人员无需手动录入管理。本申请实施例通过对需求描述语言的自动分词、翻译处理,实现了需求描述语言的自动拆解,并且实现了派生指标的自动定义和自动录入,降低了OneData理论应用的门槛,提升了指标模型的构建效率。
进一步的,本申请实施例通过和元仓进行数据打通,直接引用元仓的业务系统的主表以及核心属性,同时将关联维度的冗余属性进行关联,解决了需要手功设计维度模型的模型表(事实表和维度表)、模型属性以及关联关系所带来的建模效率降低的问题;同时,避免了维度模型没有冗余的维度属性进行参考而导致后续模型改动较大的问题;进一步的,基于字段等数据来源以及关联维度与冗余的维度属性的关系,可以自动生成简代码,简化代码开发,提升研发效率。
进一步的,本申请实施例可基于配置的分层划域规则,对数仓表进行表命名解析,从而确定出数仓表的目标分层划域信息,进而在数仓表逆向为维度模型的模型表之后,将模型表与目标分层划域信息进行关联,实现自动关联维度模型和数仓规划;进一步的,基于推导特征,推导数仓表对应的维度模型的类型,从而直接逆向出可以使用的相应类型的维度模型的模型表,而不需要人工逆向之后二次处理确定模型类型,提升了模型构建效率。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据提供的附图获得其他的附图。
图1为指标模型和数仓模型的关系示例图。
图2为指标模型的构建过程示例图。
图3为本申请实施例提供的建模方法的流程图。
图4为本申请实施例构建指标模型的实现示例图。
图5为维度模型的示例图。
图6为构建维度模型的示例图。
图7为本申请实施例提供的建模方法的另一流程图。
图8A为本申请实施例提供的构建维度模型的过程示例图。
图8B为本申请实施例提供的构建维度模型的示例图。
图9为本申请实施例提供的建模方法的再一流程图。
图10为本申请实施例提供的建模装置的框图。
图11为服务器的框图。
具体实施方式
下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
指标模型可以认为是用于在数仓模型中进行数据查询的指标,图1示例性的示出了数仓的指标模型和数仓模型的关系示例图。如图1所示,数仓中可以包括指标模型110和数仓模型120。其中,指标模型110可以由用于数据查询的指标构成。数仓模型120可以具体用于存储数据;在一些实施例中,数仓模型120可以为维度模型,维度模型可以通过维度建模方式构建,主要由事实表和维度表等基本要素构成。指标模型110中的指标可以与数仓模型120中的字段相关联,从而在利用指标从数仓模型中查询数据时,可从指标关联的字段中查找到相应的数据。
建模人员一般是基于需求人员的需求描述语言,构建指标模型。例如,在指标的开发过程中,需求人员希望建模人员开发满足某一需求的指标时,需求人员可以提供一段需求描述语言,建模人员需要将该需求描述语言转换为能够用于数据查询的指标,并录入到指标管理平台中。在一个示例中,需求人员提供了“查询A城市每天的线上销售额”的需求描述语言时,建模人员需要将该需求描述语言拆解为能够用于数据查询的指标,例如,A城市、每天、线上、销售额这些可用于数据查询的指标,以实现与数仓模型中的字段进行关联。然而在指标模型的构建过程中,并不是通过随意的文本描述即可实现指标定义的标准化,因此如何指导建模人员将需求描述语言拆解为指标,并实现指标规范、标准化定义显得尤为必要。
OneData理论可以满足指标规范、标准化定义的需求,并且指导建模人员对需求描述语言进行拆解。OneData理论将指标细化为原子指标、时间周期、修饰词等指标元素,并通过这些指标元素定义派生指标。也就是说,在OneData理论中,派生指标=原子指标+时间周期+修饰词。
需要说明的是,原子指标用于明确业务的统计口径和计算逻辑,是基于用户的业务活动创建,可用于统计业务活动中某一业务状况的数值,其为不可再拆解的业务过程和度量;例如,用户的业务过程为“下单”,度量为“支付金额”,则原子指标就可以定义为“下单支付金额”;
业务过程是指企业在指定的业务场景中所执行的业务活动,是数据建模所需要分析的逻辑主体,一个业务过程在大数据体系中会沉淀出一张业务明细表;例如,交易场景中可以有加入购物车、下单、支付等业务过程,分别是产出加入购物车、下单、支付的业务流水明细表和数据;
度量是指业务过程产出的业务明细表里面的具体的数值字段,比如“下单”业务过程产出了“订单流水表”,而其中的“支付金额”字段就是度量。
时间周期是用来明确数据统计的时间范围或者时间窗口,例如1天,1周等。时钟周期用于在统计派生指标时,限定派生指标的时间范围。
修饰词是用来限定派生指标的业务范围,例如,统计“1天A城市生鲜门店的销售额”,则A城市和生鲜门店就是对业务范围的限定修饰。
派生指标是由原子指标、时间周期、修饰词构成,用于反映企业某一业务活动在指定时间周期及业务范围中的业务状况。例如派生指标为:1天_A城市_销售额,则1天对应时间周期,A城市对应修饰词,销售额对应原子指标。
需要进一步说明的是,原子指标定义了基本的计算口径,不同业务分析的时间维度和业务范围是不一样的,因此时间维度和业务范围这两个要素结构化成时间周期和修饰词,用来对原子指标计算的结果进行范围限制,则可在底层一致的计算口径下,通过不同的业务和时间范围的要求,组合出不同的派生指标,来满足业务多变的需求。
在一个示例中,需求人员构建指标的需求描述语言为“查询A城市每天或者每月的线上销售额”,则可从该需求描述语言中提炼出以下指标元素对应的指标词:时间周期-每天、每月,修饰词-A城市、线上,原子指标-销售额。基于这些指标元素对应的指标词,可以定义多个派生指标,例如:每天_线上_销售额、每月_线上_销售额、每天_线上且A城市_销售额、每月_线上且A城市_销售额,从而实现基于需求人员的需求描述语言开发、构建出多个派生指标,以实现构建指标模型。
可见,在构建派生指标形式的指标模型时,涉及到将需求描述语言拆解为结构化的指标元素对应的指标词(例如原子指标、时间周期、修饰词等指标元素对应的指标词),并由指标元素对应的指标词定义派生指标,这对于建模人员而言是一个较大的挑战。也就是说,在OneData理论的规范化设计和架构下,将需求人员提供的需求描述语言进行结构化的拆解,再进行手动录入管理,对于业务、研发等建模人员而言,存在较为严重的规范约束。作为一个示例,图2示例性的示出了指标模型的构建过程示例图。如图2所示,需求人员提供了指标模型的需求描述语言后,建模人员面临基于OneData理论,如何将需求描述语言进行拆解,以得到时间周期、修饰词、原子指标这些指标元素对应的指标词的问题,而这要求建模人员能够熟练运用OneData理论,导致OneData理论存在一定的应用门槛。基于得到的指标元素对应的指标词,如果指标元素对应的指标词已存在事先录入的派生指标,则可将事先录入的派生指标作为指标模型进行需求交付;而如果指标元素对应的指标词未存在事先录入的派生指标,则需要建模人员定义由指标元素对应的指标词所构成的派生指标并手动录入,以开发出派生指标,这涉及到建模人员的手动操作,存在效率较低的问题。需要说明的是,在得到指标元素对应的指标词后,基于OneData理论对指标元素的结构化管理,可以方便各个指标元素的管理和后续数据查找。
可见,在OneData理论的规范下,如何将需求描述语言自动、高效的拆解为指标元素对应的指标词,以及实现派生指标的自动录入,是降低OneData理论应用门槛、提升指标模型构建效率需要解决的问题。基于此,本申请实施例在既满足OneData理论规范,又不影响研发效率的前提下,对需求描述语言进行智能和自动化的解析,从而将需求描述语言自动拆解成为指标元素对应的标准词,并实现指标元素对应的标准词、以及对应的派生指标自动录入到指标管理平台,提升指标模型的构建效率。
图3示例性的示出了本申请实施例提供的建模方法的可选流程图。利用图3所示方法流程,本申请实施例可实现自动、高效的构建基于派生指标的指标模型。图3所示方法流程可由服务器执行实现,可选的,该服务器可以是基于云计算的大数据计算引擎服务器;例如,由大数据计算引擎中的数据中台服务器执行实现该方法流程,数据中台可提取各个业务的数据,统一标准和口径,并通过数据计算和加工提供数据服务。参照图3,该方法流程可以包括如下步骤。
在步骤S310中,获取构建指标模型的需求描述语言。
需求人员在希望开发满足某一需求的指标模型时,可以提供构建指标模型的需求描述语言。该需求描述语言可以输入到服务器,例如,需求人员可利用其终端设备,向服务器提交构建指标模型的需求描述语言,该需求描述语言可以是基于业务开发的需求而定。需求描述语言可以是文本语言,描述构建指标模型的需求内容。例如,需求人员具有开发“查询门店1天生鲜类商品的销售额”的指标需求时,则可以通过终端设备向服务器提交“查询门店1天生鲜类商品的销售额”的需求描述语言。需求描述语言的内容可以由需求人员自行组织,本申请实施例并不设限。
在步骤S311中,对所述需求描述语言进行分词处理,以从所述需求描述语言中确定匹配指标元素的指标词。
服务器在获取到需求描述语言后,可以对需求描述语言进行分词处理,从而从需求描述语言中确定出匹配指标元素的指标词。在一些实施例中,指标元素包括时间周期、修饰词和原子指标,服务器可对需求描述语言进行分词处理,从需求描述语言中确定匹配时间周期的指标词、匹配修饰词的指标词、和匹配原子指标的指标词。
在一些实施例中,服务器可利用NLP(Natural Language Processing,自然语言处理)等自然语言识别平台,对需求描述语言进行智能分词。作为可选实现,本申请实施例可基于预设的指标元素对应的候选词,利用NLP平台对需求描述语言进行分词处理,以从需求描述语言中确定与指标元素对应的候选词相匹配的指标词。例如,基于预设的时间周期对应的候选词、修饰词对应的候选词、原子指标对应的候选词,利用NLP平台对需求描述语言进行原子性的分词处理,从而从需求描述语言中确定与时间周期的候选词相匹配的指标词、与修饰词的候选词相匹配的指标词、与原子指标的候选词相匹配的指标词。可选的,本申请实施例可在服务器的建模平台预先录入指标元素对应的候选词(例如预先录入时间周期对应的候选词、修饰词对应的候选词、原子指标对应的候选词),进而在利用NLP平台对需求描述语言进行分词处理时,NLP平台可基于预先录入的指标元素对应的候选词,对需求描述语言进行原子性的分词处理,从需求描述语言中确定匹配指标元素的指标词。
在一些实施例中,指标元素对应的候选词可以表示指标元素可能使用的词语,例如,时间周期可能使用的词语、修饰词可能使用的词语、原子指标可能使用的词语等。基于预设的各个指标元素可能使用的词语(即各个指标元素对应的候选词),本申请实施例可通过智能分词技术,将需求描述语言中与指标元素无关的词语进行过滤,并将需求描述语言中与指标元素的候选词相匹配的指标词分隔出来,从而从所述需求描述语言中确定匹配指标元素的指标词。比如,需求人员输入的需求描述语言为“我想看一天的生鲜类销售额”,则基于预设的时间周期的候选词、修饰词的候选词、原子指标的候选词,可从该需求描述语言中过滤掉与时间周期、修饰词、原子指标等指标元素无关的词语(比如过滤“我想看”的词语),并分词出匹配时间周期的指标词“1天”,匹配修饰词的指标词“生鲜类”,匹配原子指标的指标词“销售额”。
需要说明的是,分词是数据搜索和语言解析中的一个功能,分词可以是基于自然语言词库和行业内的定制化词库,对一段语言进行原子性的切割分段,并输出各词性对应的词语。比如对于“1天A城市销售额”这段语言,合理的分词结果为:“1天”为时间周期,“A城市”是修饰词,“销售额”是原子指标;原子性的切割主要是将语言中的连贯词汇与词库中的时间周期、修饰词、原子指标对应的候选词进行匹配,然后切割出来。在进一步的一些实施例中,预设的指标元素对应的候选词可以记录在指标词库中(例如,指标词库可以记录时间周期对应的候选词、修饰词对应的候选词、原子指标对应的候选词等),指标词库可以位于智能词库中。作为可选实现,本申请实施例可基于指标词库记录的指标元素对应的候选词,利用NLP平台对需求描述语言进行分词处理,以从需求描述语音中得到匹配指标元素的指标词。
作为可选实现,指标词库记录的指标元素对应的候选词,可以基于多个行业的行业词库确定。在一个示例中,指标元素对应的候选词可以是建模人员预先录入到指标词库,和/或,从不同行业的行业词库中提炼得到。比如,建模人员在指标词库中录入各指标元素对应的候选词时,可以借鉴电商、物流、新零售等行业的行业词库,从而确定属于原子指标的候选词,属于时间周期的候选词、属于修饰词的候选词等。又比如,本申请实施例可支持从电商、物流、新零售等行业的行业词库中自动提炼出时间周期、修饰词、原子指标等各指标元素对应的候选词。
在步骤S312中,将所述匹配指标元素的指标词翻译为匹配指标元素的标准词。
在对需求描述语言进行分词处理,从需求描述语言中确定匹配指标元素的指标词后,由于指标元素对数据研发具有建表字段的规范约束,因此指标元素的最终用词应标准化,也就是说,定义派生指标所使用的指标元素的用词应是标准词。从而本申请实施例可将匹配指标元素的指标词中,不符合标准词的指标词翻译为标准词,以使得匹配指标元素的用词均是标准词,从而得到匹配指标元素的标准词。在一个示例中,假设数据研发希望商品应该统一翻译成sku,而不包含item、shangpin等词汇,则如果某一指标元素表达商品的指标词为shangpin,则需要翻译为商品的标准词sku。本申请实施例所指的翻译可以理解为是把时间周期、修饰词、原子指标这些指标元素的词语进行统一的自动翻译,并生成一个英文编码,辅助数据研发基于指标元素进行表字段的命名。
在一些实施例中,本申请实施例可利用翻译平台,将所述匹配指标元素的指标词翻译为匹配指标元素的标准词。可选的,本申请实施例可利用翻译平台,基于指标元素的标准词的属性,从匹配指标元素的指标词中确定与标准词的属性相同但不为标准词的指标词,由标准词替换所确定的指标词,以得到匹配指标元素的标准词。
需要说明的,翻译是将输入的源语言翻译成目标语言,其中包含了自然语言翻译,以及行业内特定的词库翻译,包括缩写等。基于此,作为可选实现,本申请实施例可在智能词库中定义各指标元素的标准词(例如在智能词库中定义时间周期的标准词、修饰词的标准词、原子指标的标准词等),以及各标准词的属性(例如各标准词的词性、词义等),从而利用翻译平台,基于智能词库中定义的指标元素的标准词的属性,从匹配指标元素的指标词中,确定与标准词的属性相同但不为标准词的指标词,并由标准词替换所确定的指标词,以实现将不符合标准词的指标词翻译为标准词,从而避免指标元素的最终用词的重复定义(比如指标元素的最终用词中存在重复的近义词、同义词等),使得指标元素的最终用词能够规范化。
基于步骤S311和步骤S312,本申请实施例可通过对需求描述语言进行智能分词和智能翻译处理,从需求描述语言中确定出匹配指标元素的标准词,从而实现从需求描述语言中提炼出用词标准的指标元素。在一个示例中,以需求描述语言为“我想看生鲜1天的销售额”为例,在对需求描述语言进行智能分词后,可得到时间周期-1天、修饰词-生鲜、原子指标-销售额的匹配指标元素的指标词,这些指标词在智能词库中进行标准词的匹配(例如,将指标词替换为智能词库中词义、词性等属性相同的标准词),从而对分词结果(即匹配指标元素的指标词)进行标准化重组,形成标准的指标描述(即匹配指标元素的标准词)。
在步骤S313中,判断所述匹配指标元素的标准词是否存在已录入的派生指标,若否,执行步骤S314,若是,执行步骤S315。
在步骤S314,为所述匹配指标元素的标准词定义派生指标,以创建出派生指标;以及自动录入所述派生指标。
在步骤S315中,输出所述派生指标,作为构建的指标模型。
在一些实施例中,指标管理平台可以事先录入派生指标,事先录入的派生指标可由不同指标元素的不同标准词构成,服务器在获取到匹配指标元素的标准词后,可判断该匹配指标元素的标准词是否在指标管理平台中存在已录入的派生指标;若是,则可输出指标管理平台已录入的派生指标,作为构建的指标模型,以交付需求;若否,则服务器可自动定义由所述匹配指标元素的标准词所构成的派生指标,以创建出派生指标,从而将派生指标自动录入到指标管理平台,进而输出派生指标,作为构建的指标模型,以交付需求。
在一些实施例中,所述派生指标包括描述时间周期、修饰词和原子指标的标准词。本申请实施例可判断匹配时间周期的标准词、匹配修饰词的标准词以及匹配原子指标的标准词,是否存在已录入的派生指标;若是,则可输出指标管理平台已录入的派生指标,作为构建的指标模型,以交付需求;若否,则服务器可为匹配时间周期的标准词、匹配修饰词的标准词以及匹配原子指标的标准词自动定义派生指标,从而将定义的派生指标自动录入到指标管理平台,同时输出派生指标,作为构建的指标模型,以交付需求。
在一个示例中,假设需求描述语言为“我想看一天的生鲜类销售额”,从需求描述语言提炼的匹配指标元素的标准词为:时间周期-1天、修饰词-生鲜、原子指标-销售额,则该匹配指标元素的标准词所构成的派生指标为:1天-生鲜-销售额;服务器可判断指标管理平台是否存在已录入的“1天-生鲜-销售额”的派生指标;若是,则输出该派生指标,交付需求;若否,则为时间周期-1天、修饰词-生鲜、原子指标-销售额的指标元素,定义“1天-生鲜-销售额”的派生指标,并自动录入到指标管理平台,同时,输出该派生指标,交付需求。
本申请实施例提供的模型构建方法,可获取构建指标模型的需求描述语言,对所述需求描述语言进行分词处理,以从所述需求描述语言中确定匹配指标元素的指标词,所述指标元素包括时间周期、修饰词和原子指标;将所述匹配指标元素的指标词翻译为匹配指标元素的标准词;若所述匹配指标元素的标准词不存在已录入的派生指标,则可为所述匹配指标元素的标准词定义派生指标,并自动录入所述派生指标,同时输出所述派生指标,作为构建的指标模型;其中,所述派生指标包括描述时间周期、修饰词和原子指标的标准词。可见,本申请实施例可将需求人员提供的非结构化的需求描述语言,通过自动的智能分词、翻译的解析处理,产出符合OneData理论的匹配指标元素的标准词,并为匹配指标元素的标准词自动定义派生指标,自动录入到指标管理平台,降低了OneData理论应用的门槛,同时建模人员无需手动录入管理。本申请实施例通过对需求描述语言的自动分词、翻译处理,实现了需求描述语言的自动拆解,并且实现了派生指标的自动定义和自动录入,降低了OneData理论应用的门槛,提升了指标模型的构建效率。
在一些实施例中,图4示例性的示出了本申请实施例构建指标模型的实现示例图。如图4所示,针对需求人员提供的非结构化的需求描述语言,服务器可利用基于OneData理论的指标智能解析引擎,使用智能词库对需求描述语言进行智能分词以及智能翻译处理,以从需求描述语言中得到匹配指标元素的标准词;可以理解的是,所得到的匹配指标元素的标准词是符合OneData理论,且基于标准词进行了同义词和相似词去重之后的各指标元素的标准描述。其中,智能分词利用到NLP平台、智能翻译利用到翻译平台;具体的,智能词库中的指标词库可用于智能分词过程,并且指标词库中记录的各指标元素对应的候选词可基于各行业的行业词库得到;智能词库中进一步记录了各指标元素的标准词(例如标准中文名词、英文名词、英文缩写等)、各标准词的词性(词性可以表达标准词的词类型,例如表达时间周期、修饰词、原子指标类型的指标元素、同时还可表达标准词为行业术语、生活用词、自然语言等类型的词语)、和各标准词的词义(例如同义词、相似词、关联词等),智能词库中记录的标准词、标准词的词性和词义可用于智能翻译过程。结合图4所示,例如需求人员提供“1天的生鲜门店的DAU(Daily Active User,日活跃用户数量)”、“生鲜门店的1天GMV(Gross Merchandise Volume,商品交易总额)”等需求描述语言,则在经过智能分词、智能翻译处理之后,可以得到匹配时间周期的标准词“1天”,匹配修饰词的标准词“生鲜门店”,匹配原子指标的标准词“DAU”、“GMV”等匹配指标元素的标准词,从而服务器可以自动定义出“1天_生鲜门店_DAU”、“1天_生鲜门店_GMV”等派生指标并自动录入到服务器的指标管理平台,从而在指标管理平台沉淀出由多个派生指标形成的指标森林,以实现结构化、标准化、可复用、可扩展的构建指标模型。
在进一步的一些实施例中,结合图4所示,本申请实施例还可对NLP平台实时同步指标元素的候选词,以及对翻译平台进行针对指标元素的标准词的语义离线训练,以提升智能分词和智能翻译的解析过程的准确度。作为可选实现,针对建模人员而言,建模人员可以在建模平台录入时间周期、修饰词、原子指标等指标元素的候选词(录入的指标元素的候选词可来源于维度模型的建模过程、指标的词根管理等过程),建模平台可以调用NLP平台的接口,将录入的指标元素的候选词同步到NLP平台,从而NLP平台可以实时同步建模人员所录入的指标元素的候选词,以对需求描述语言进行原子性的分词操作,提升智能分词的准确度。对翻译平台进行指标元素的标准词的语义离线训练时,本申请实施例可利用数据中台的开发平台,在开发平台中集成PI算法平台(一种大型实时数据库平台),从而利用PI算法平台对指标元素的标准词进行离线的语义优化计算(比如去掉同义词、纠正错词等),然后将语义离线训练结果同步到翻译平台。
下面结合手动录入指标的方案,以及半自动化的识别指标的方案,对本申请实施例提供的指标模型构建方案的优点进行说明。
手动录入指标的方案需要建模人员基于对业务的理解和OneData理论的理解,手动的对需求描述语言进行分析拆解,然后手动录入到指标管理平台,缺点是效率慢,指标可能会重复定义(比如重复定义近义词、同义词等);虽然指标是希望规范化定义,但是随着业务膨胀,手动梳理的错误率以及重复定义率将会提升,这需要投入非常大的人力和管理成本,影响研发效率,延长需求交付时长;
半自动化的识别指标的方案采用非自然语言分词和识别的方案,比如按照特定的分隔符对指标元素的词语位置进行前置的录入约束,例如“时间周期_修饰词_原子指标”这种格式,这对录入人员的要求比较高,必须对业务、OneData理论较为理解才可以提前进行需求描述语言的拆解和重组,而且也无法解决近义词和同义词的重复定义问题;
本申请实施例提供的方案,将需求人员提供的需求描述语音,自动化的基于OneData理论进行智能分词和智能翻译处理,解决了建模人员需要深入理解业务和OneData理论的要求,降低了OneData理论应用的门槛。同时提供统一的指标管理平台,对指标元素进行自动化的录入和管理,解决手动录入导致研发效率降低的问题,同时也降低了人力维护的成本。进一步,本申请实施例可对NLP平台和翻译平台进行实时同步和离线语义训练,提高了智能分词和智能翻译的解析准确性,进一步实现了指标的结构化和规范化管理。
本申请实施例基于OneData理论进行指标的智能解析,可以依赖智能实时分词、智能实时翻译、自然语言训练、指标管理平台等技术,通过将OneData理论与分词、翻译和自然语言训练相结合,以实现将需求描述语言自动拆解为指标元素对应的标准词,并实现指标元素对应的标准词、以及对应的派生指标自动录入到指标管理平台,提升指标模型的构建效率。
在进一步的一些实施例中,本申请实施例可基于派生指标,在数仓的数仓模型中查询数据。作为可选实现,本申请实施例可应用于大数据、海量数据的数据查询背景,在大数据、海量数据的情况下,基于本申请实施例构建的派生指标,实现大数据、海量数据下的精准数据查询匹配。
在一些实施例中,数仓中用于查询数据的数仓模型可以是维度模型,维度模型可利用维度建模方式构建。维度建模(dimensional modeling)是数据仓库建设中的一种数据建模方法,是将数据结构化为维度模型的逻辑设计方法。维度模型主要由事实表和维度表等基本要素构成,其中度量称为“事实”,环境描述称为“维度”。
维度表是维度的详细描述,用来反映业务的一类属性,可选的,一个维度表可对应一个维度的详细描述。维度作为度量的环境(例如分析事实的多样环境),维度可以表示统计、分析数据的角度。可选的,一个维度可以属于一个数据域,例如地理维度(其中包括国家、地区、省以及城市等级别的内容)、时间维度(其中包括年、季、月、周、日等级别的内容)等。在一个示例中,在分析交易数据时,可以通过地理、商品和时间等多个维度进行分析,每个维度的详细描述可通过维度表承载。
事实表是维度模型的基本表,数据仓库可以包含一个或者多个事实表,用于记录数据的全量信息;在一个示例中,事实表可能包含业务销售数据,比如商品的销售额等数据。
维度表与事实表相结合,可以实现从多个维度分析查询数据内容。比如,事实表中可以存储多个维度标签以及数据的全量信息(例如业务销售数据),多个维度表可以承载度量数据的多个维度,通过事实表中的多个维度标签分别关联多个维度表,可结合多个维度表对事实表进行数据查询,实现从多个维度进行数据的查询分析。作为可选实现,图5示例性的示出了维度模型的示例图。如图5所示,维度模型可以包括事实表510,以及多个维度表521至52n,n表示维度的具体数量,可根据实际情况而定;事实表510可以包括多个维度标签511至51n,以及数据的全量信息;一个维度标签对应一个维度表,例如维度标签511对应维度表521,以此类推,直至维度标签51n对应维度表52n。从而通过多个维度表521至52n在多个维度的详细描述,以及事实表510中记录的数据的全量信息,可以实现在维度模型中进行多个维度的数据查询。
在一个示例中,多个维度表可以例如地理维度表和时间维度表,地理维度表可以对地理(国家、地区、省以及城市等)进行详细描述;时间维度表可以对时间范围进行详细描述;事实表可以存储地理标签、时间标签和业务销售数据;从而事实表的地理标签关联对应地理维度表、时间标签关联对应时间维度表后,可以在维度模型中进行地理维度和时间维度的数据查询。
可以看出,构建维度模型的关键是构建出组成维度模型的表(例如维度表与事实表)以及它们之间的关系。图6示例性的示出了构建维度模型的示例图,如图6所示,构建维度模型包括如下阶段:维度表设计阶段610、事实表设计阶段620、关系设计阶段630、开发数据及生成代码阶段640。其中,维度表设计阶段610主要用于设计维度模型的维度表,该阶段由开发人员手功完成;事实表设计阶段620主要用于设计维度模型的事实表,该阶段由开发人员手功完成;关系设计阶段630主要用于设计事实表和维度表的关系以及维度表和维度表的关系,例如在设计一张交易表和一张会员表之后,再设计交易表和会员表的关联关系,比如通过会员ID关联交易表和会员表,该阶段由开发人员手功完成;开发数据及生成代码阶段640主要用于将模型表(维度表和事实表)生效到大数据引擎中,同时开发数据并生成代码,该阶段由开发人员手功完成。上述维度模型的构建过程依赖于开发人员手功完成,建模过程较为繁琐,模型构建效率相对较低,因此本申请实施例提供新型的维度模型构建方案,基于元仓(统一的元数据仓库,记录了表、字段、血缘以及依赖关系等核心信息),抽象形成一套高效的维度模型的建模流程,同时支持数据开发及生成简代码。
作为可选实现,图7示例性的示出了本申请实施例提供的建模方法的另一可选流程图。该方法流程可由服务器执行实现,如图7所示,该方法流程可以包括如下步骤。
在步骤S710中,根据目标维度,选择元仓的业务系统的主表。
目标维度是本申请实施例需要构建的维度模型的维度,目标维度可以根据业务需求选择,本申请实施例并不设限。基于需要构建的维度模型的目标维度,本申请实施例可从元仓的业务系统中选择相应的主表。例如,本申请实施例需要构建门店商品维度模型,则对应到元仓的业务系统中存在一张门店商品表的主表,门店商品维度模型中门店商品维度表的雏形可以来自于元仓的业务系统的这张门店商品表的主表。在一个示例中,假设需要构建门店商品的维度模型dim_shop_sku,则本申请实施例可从元仓的业务系统中选择主表ods_shop_sku。
在步骤S711中,从所述主表中,筛选与所述目标维度对应的维度模型的核心属性。
在一些实施例中,本申请实施例主要基于需要构建的维度模型的目标维度,从所述主表中筛选维度模型的核心属性,即针对维度模型的目标维度,本申请实施例可从所述主表中筛选出与目标维度对应的维度模型的核心属性。例如需要构建门店商品的维度模型,则可从主表中筛选出门店商品核心属性。在一些实施例中,基于维度模型包括维度表和事实表,本申请实施例可筛选所述主表中与所述目标维度对应的维度表的核心属性,或事实表的核心属性。作为可选实现,维度表的核心属性可以包括维度表的维度主键和维度属性,事实表的核心属性可以包括粒度、冗余属性以及度量。
在步骤S712中,根据所述主表的元信息以及所述核心属性,生成维度模型的基础模型。
在一些实施例中,基于选择的主表,本申请实施例可使用主表的元(meta)信息以及核心属性,生成维度模型的基础模型。可选的,维度模型的基础模型可以包括基础字段属性、字段类型和描述信息;其中,基础字段属性、类型和描述信息可以从所述核心属性以及元信息中确定,在可能的其他实现中,描述信息可以直接继承自元仓的业务系统的主表。
在步骤S713中,选择关联维度,在所述基础模型的基础上冗余所述关联维度的核心属性,并建立基础模型与关联维度的关联关系。
在生成维度模型的基础模型之后,本申请实施例可在基础模型的基础上,冗余其他需要关联的关联维度的核心属性,并建立基础模型与关联维度的关联关系;例如在基础模型的基础上,冗余需要关联的其他维度表的核心属性,并与基础模型建立关联关系。可选的,本申请实施例可基于关联维度的ID选择关联维度的维度表,在基础模型的基础上冗余关联维度的维度表的核心属性,并建立基础模型与关联维度的关联关系,所述关联维度可以为至少一个与目标维度相关的维度。
作为可选实现,在构建门店商品维度模型时,与门店商品维度相关的维度可以是类目和品牌,从而本申请实施例可选择类目和品牌作为关联维度,在生成门店商品维度模型的基础模型之后,本申请实施例可在基础模型的基础上,冗余类目和品牌的关联维度的核心属性,并与基础模型构建关联关系。在一个示例中,本申请实施例可选择关联维度为类目维度和品牌维度,从而基于类目ID选择类目维度表,在基础模型的基础上冗余类目维度表的核心类目属性(比如类目名称、类目层级等),基于品牌ID选择品牌维度表,在基础模型的基础上冗余品牌维度表的核心品牌属性,并建立基础模型与类目和品牌的关联关系。可选的,在基础模型的基础上,冗余关联维度的核心属性的一种实现方式可以是,在基础模型直接加载关联维度的核心属性,例如,将核心类目属性直接加载到维度模型的门店商品维度表的冗余属性中。
在步骤S714中,基于所述关联关系以及数据来源,对维度模型自动进行数据开发和代码生成。
本申请实施例在构建维度模型的基础模型,并冗余关联维度的核心属性,建立出基础模型与关联维度的关联关系之后,可以基于关联关系和维度模型的数据来源,自动进行维度模型的数据开发和代码生成,以实现自动构建维度模型。需要说明的是,区别于维度模型的代码由人工开发完成,本申请实施可以基于基础模型与关联维度的关联关系,实现自动生成维度模型的简代码,从而节省人工开发工作,开发人员可以直接在简代码上进行修改,以得到最终的维度模型的代码。
本申请实施例通过和元仓进行数据打通,直接引用元仓的业务系统的主表以及核心属性,同时将关联维度的冗余属性进行关联,解决了需要手功设计维度模型的模型表(事实表和维度表)、模型属性以及关联关系所带来的建模效率降低的问题;同时,避免了维度模型没有冗余的维度属性进行参考而导致后续模型改动较大的问题。进一步的,基于字段等数据来源以及关联维度与冗余的维度属性的关系,可以自动生成简代码,简化代码开发,提升研发效率。
图8A示例性的示出了本申请实施例提供的构建维度模型的过程示例图,图8B示例性的示出了本申请实施例提供的构建维度模型的示例图。如图8A所示,本申请实施例构建维度模型过程可以包括如下阶段:选择业务系统的主表阶段810、筛选主表属性阶段820、生成基础模型阶段830、选择关联维度阶段840、生成关联关系以及冗余属性阶段850、自动数据开发和生成代码阶段860。
以生成门店商品维度模型为例,门店商品维度模型主要包括门店商品核心属性、商品类目属性、商品品牌属性。结合图8A和图8B所示,在选择业务系统的主表阶段810、筛选主表属性阶段820、和生成基础模型阶段830,本申请实施例可选择元仓业务系统的门店商品表(例如图8B所示ods_shop_sku)作为主表,并筛选出门店商品表的门店商品核心属性,基于门店商品核心属性构建出门店商品维度模型的基础模型(例如图8B所示dim_shop_sku的基础模型)。
在选择关联维度阶段840、生成关联关系以及冗余属性阶段850,本申请实施例可基于类目ID选择类目维度表(例如图8B所示dim_category),在基础模型冗余核心类目属性,基于品牌ID选择品牌维度表(例如图8B所示dim_brand),在基础模型冗余核心品牌属性,同时建立基础模型和类目以及品牌的关联关系。
在自动数据开发和生成代码阶段860,本申请实施例可自动进行门店商品维度模型的数据开发和简代码生成。
本申请实施例通过打通业务系统的元仓,大幅简化了维度模型的构建过程,同时,通过在模型构建中沉淀的冗余属性的来源以及关联关系生成简代码,大幅提高了代码的开发编写效率。
生成维度模型的另一种方式是:将已有的数仓模型通过逆向工程,逆向为维度模型。例如,公有云存在有较多数量的基于kimball理论构建的数仓模型,可以通过将这些已有的数仓模型通过逆向工程,逆向为维度模型。
目前主流的逆向工程主要是从数仓模型的数据源中解析出表、字段、约束等信息,从而基于解析的表、字段、约束等信息来生成维度模型对应的表(事实表、维度表等)。然而,基于从数据源解析的表、字段、约束等信息来构建维度模型对应的表,并无法解析表的分层划域信息,这导致最终构建的维度模型无法与数仓规划关联上,致使构建的维度模型的性能存在缺失。
需要说明的是,分层划域信息是数仓规划的顶层设计,用于模型的分类以及管理,包括但不限于数仓分层、业务分类、数据域等分层划域信息。可见,分层划域是数仓设计最关键的部分之一,是模型分类管理的核心,也是数仓业务体系化的重点,是架构师自顶向下规划数仓的核心;如果构建的维度模型不具有分层划域信息,将导致构建的维度模型无法与数仓规划关联上,将对维度模型的分类以及管理存在影响。
进一步的,基于从数据源解析的表、字段、约束等信息来构建维度模型对应的表,并无法直接推导表的类型(例如无法推导表是维度表还是事实表)。这是因为维度建模最核心的就是维度表和事实表,而数仓模型的数据源一般使用的是ER(EntityRelationship,实体联系)模型,并不区分表类型。因此基于从数仓模型的数据源所解析的表、字段、约束等信息来构建维度模型对应的表,并无法推导表的类型,而是需要人工确认表的类型是维度表还是事实表,这无疑效率较低。
为解决上述问题,本申请实施例提供新型的逆向生成维度模型的方案。作为可选实现,图9示例性的示出了本申请实施例提供的建模方法的再一可选流程图。该方法流程可由云服务器执行实现。作为可选实现,该方法流程可由基于云计算的大数据计算引擎执行实现。例如,由大数据计算引擎中的数据中台服务器执行实现该方法流程。参照图9,该方法流程可以包括如下步骤。
在步骤S910中,加载数仓表。
在一些实施例中,数仓表可以是已有数仓模型中的表,数仓模型中具有多个数仓表,本申请实施例可将数仓表通过逆向工程,逆向为维度模型的表,以实现构建维度模型。在将数仓表逆向为维度模型的表的过程中,本申请实施例旨在将表关联上分层划域信息,并能够实现自动推导表的类型。
在步骤S911中,根据配置的至少一个分层划域规则,对所述数仓表的表命名进行解析,从所述表命名中解析出与各分层划域规则对应的命名表达式,以得到至少一个命名表达式;其中,一个分层划域规则定义分层划域信息的一种设计对应的表命名方式。
分层划域信息可以具有多种设计,例如数仓分层、业务分类、数据域等分层划域信息在表命名中可以具有不同的排列顺序,比如数仓分层_业务分类_数据域为一种设计的分层划域信息,数仓分层_数据域_业务分类为另一种设计的分层划域信息,不同顺序的分层划域信息可对应分层划域信息的不同设计。本申请实施例可为不同设计的分层划域信息配置不同的分层划域规则,并且与数仓表的表命名进行匹配,一个分层划域规则可以定义分层划域信息的一种设计对应的表命名方式;从而基于配置的至少一个分层划域规则,本申请实施例可对所述数仓表的表命名进行解析,以从所述表命名中解析出与各分层划域规则对应的命名表达式,其中,一个分层划域规则可对应从表命名中解析出一个命名表达式,从而基于至少一个分层划域规则,本申请实施例可得到至少一个命名表达式。
在一个示例中,假设配置的一个分层划域规则为{数仓分层}_{业务分类}_{数据域}_{业务过程}_{自定义}_{存储策略},则该分层划域规则表达的是{数仓分层}_{业务分类}_{数据域}_{业务过程}_{自定义}_{存储策略}这样顺序设计的分层划域信息在表命名中的命名方式。
进一步的,假设数仓表的表命名为dwd_csn_crm_hotline_outbound_touch_df,则基于上述分层划域规则,本申请实施例可从表命名中解析出以下表1所示的命名表达式。可见,基于不同的分层划域规则,则本申请实施例可从表命名中解析出不同的命名表达式。
表1
在步骤S912中,从所述至少一个命名表达式中确定目标命名表达式,将所述目标命名表达式对应的分层划域信息,作为目标分层划域信息。
在从数仓表的表命名中解析出至少一个命名表达式后,本申请实施例可基于选举策略,例如命中最多分层划域信息优先,命中最多关键分层划域信息优先等选举策略,从至少一个命名表达式中确定目标命名表达式;作为可选实现,本申请实施例可将至少一个命名表达式中命中最多分层划域信息或者,命中最多关键分层划域信息的命名表达式,作为目标命名表达式。从而将所述目标命名表达式对应的分层划域信息,作为目标分层划域信息,后续在数仓表逆向为维度模型的模型表后,为模型表关联所述目标分层划域信息,则可使得构建的维度模型能够与数仓规划关联上。
在步骤S913中,根据推导特征,推导数仓表对应的维度模型的类型;将所述数仓表逆向为所述类型的维度模型对应的模型表,将所述模型表关联上目标分层划域信息。
在进一步的一些实施例中,在确定目标分层划域信息之后,本申请实施例可确定数仓表的推导特征,从而根据推导特征推导数仓表对应的维度模型的类型是事实表还是维度表。推导特征可以包括目标分层划域信息、表中字段聚合计算的个数、表中字段类型是数值型的个数、字段出现在GROUP BY(聚合)中的次数、JOIN(连接)出现在主次位的次数等;其中,目标分层划域信息可由解析表命名并通过选举策略确定(例如,基于至少一个分层划域规则,通过表命名的分割线首位推导,得出至少一个命名表达式,并通过选举策略确定出目标命名表达式,进而确定出目标命名表达式对应的目标分层划域信息),其余特征可基于数仓的ETL(数据抽取、清洗转换、加载)代码提取得到。作为可选实现,本申请实施例可基于目标分层划域信息,以及从数仓的代码提取得到的特征,确定推导特征,从而根据推导特征推导数仓表对应的维度模型的类型,数仓表对应的维度模型的类型包括事实表和维度表。作为可选实现,基于推导特征推导模型类型可以视为是二分类问题,可以使用GBDT(GradientBoosting Decision Tree,梯度提升决策树)等算法实现。
基于推导的数仓表对应的维度模型的类型,本申请实施例可将数仓表逆向为所述类型的维度模型对应的模型表,例如数仓表对应的维度模型的类型为事实表,则将数仓表逆向为维度模型的事实表,数仓表对应的维度模型的类型为维度表,则将数仓表逆向为维度模型的维度表。逆向得到的模型表可与目标分层划域信息进行关联,以使得构建的维度模型和数仓规划关联上,
本申请实施例可基于配置的分层划域规则,对数仓表进行表命名解析,从而确定出数仓表的目标分层划域信息,进而在数仓表逆向为维度模型的模型表之后,将模型表与目标分层划域信息进行关联,实现自动关联维度模型和数仓规划;进一步的,基于推导特征,推导数仓表对应的维度模型的类型,从而直接逆向出可以使用的相应类型的维度模型的模型表,而不需要人工逆向之后二次处理确定模型类型,提升了模型构建效率。
上文描述了本申请实施例提供的多个实施例方案,各实施例方案介绍的各可选方式可在不冲突的情况下相互结合、交叉引用,从而延伸出多种可能的实施例方案,这些均可认为是本申请实施例披露、公开的实施例方案。
下面对本申请实施例提供的建模装置进行介绍,下文描述的建模装置可以认为是服务器为实现本申请实施例提供的建模方法所需设置的功能模块。下文描述的建模装置的内容可与上文描述的建模方法的内容相互对应参照。
作为可选实现,图10示出了本申请实施例提供的建模装置的可选框图。该建模装置可以应用于服务器。参照图10,该建模装置可以包括:
需求获取模块01,用于获取构建指标模型的需求描述语言;
分词模块02,用于对所述需求描述语言进行分词处理,以从所述需求描述语言中确定匹配指标元素的指标词;所述指标元素包括时间周期、修饰词和原子指标;
翻译模块03,用于将所述匹配指标元素的指标词翻译为匹配指标元素的标准词;
定义及录入模块04,用于若所述匹配指标元素的标准词不存在已录入的派生指标,为所述匹配指标元素的标准词定义派生指标,并自动录入所述派生指标;输出所述派生指标,作为构建的指标模型;所述派生指标包括描述时间周期、修饰词和原子指标的标准词。
在一些实施例中,分词模块02,用于对所述需求描述语言进行分词处理,以从所述需求描述语言中确定匹配指标元素的指标词包括:
基于预设的指标元素对应的候选词,利用NLP平台对需求描述语言进行分词处理,以从需求描述语言中确定与指标元素对应的候选词相匹配的指标词。
在一些实施例中,翻译模块03,用于将所述匹配指标元素的指标词翻译为匹配指标元素的标准词包括:
利用翻译平台,基于指标元素的标准词的属性,从所述匹配指标元素的指标词中确定与标准词的属性相同但不为标准词的指标词,由标准词替换所确定的指标词,以得到匹配指标元素的标准词。
在一些实施例中,所述指标元素对应的候选词记录在智能词库的指标词库中,所述指标词库记录的指标元素对应的候选词,基于多个行业的行业词库确定,和/或,所述指标词库记录的指标元素对应的候选词为预先录入的;所述智能词库还记录指标元素的标准词的属性,标准词的属性包括标准词的词义和词性。
在一些实施例中,所述装置还可用于:
调用所述NLP平台的接口,将录入的指标元素对应的候选词,实时同步到所述NLP平台;
对指标元素的标准词进行语义离线训练,将语义离线训练结果同步到翻译平台。
在一些实施例中,所述装置还可用于:
判断匹配时间周期的标准词、匹配修饰词的标准词以及匹配原子指标的标准词,是否存在已录入的派生指标;
在一些实施例中,定义及录入模块04,用于若所述匹配指标元素的标准词不存在已录入的派生指标,为所述匹配指标元素的标准词定义派生指标,并自动录入所述派生指标包括:
若匹配时间周期的标准词、匹配修饰词的标准词以及匹配原子指标的标准词不存在已录入的派生指标,为匹配时间周期的标准词、匹配修饰词的标准词以及匹配原子指标的标准词自动定义派生指标,并自动录入所述派生指标;
在一些实施例中,所述装置还可用于:
若匹配时间周期的标准词、匹配修饰词的标准词以及匹配原子指标的标准词存在已录入的派生指标,输出已录入的派生指标,作为构建的指标模型。
在一些实施例中,所述装置还可用于:
基于所述派生指标在数仓模型中查询数据。
在一些实施例中,所述数仓模型包括维度模型;所述装置还可用于:
根据目标维度,选择元仓的业务系统的主表;
从所述主表中,筛选与所述目标维度对应的维度模型的核心属性;
根据所述主表的元信息以及所述核心属性,生成维度模型的基础模型;
选择关联维度,在所述基础模型的基础上冗余所述关联维度的核心属性,并建立基础模型与关联维度的关联关系;
基于所述关联关系以及数据来源,对维度模型自动进行数据开发和代码生成。
在一些实施例中,所述维度模型包括维度表和事实表;所述装置用于从所述主表中,筛选与所述目标维度对应的维度模型的核心属性包括:
筛选所述主表中与所述目标维度对应的维度表的核心属性,或事实表的核心属性;所述维度表的核心属性包括维度表的维度主键和维度属性,事实表的核心属性包括粒度、冗余属性以及度量。
所述装置用于选择关联维度,在所述基础模型的基础上冗余所述关联维度的核心属性,并建立基础模型与关联维度的关联关系包括:
基于关联维度的ID选择关联维度的维度表,在基础模型的基础上冗余关联维度的维度表的核心属性,并建立基础模型与关联维度的关联关系,所述关联维度为至少一个与目标维度相关的维度。
在一些实施例中,所述数仓模型包括维度模型;所述装置还可用于:
加载数仓表;
根据配置的至少一个分层划域规则,对所述数仓表的表命名进行解析,从所述表命名中解析出与各分层划域规则对应的命名表达式,以得到至少一个命名表达式;其中,一个分层划域规则定义分层划域信息的一种设计对应的表命名方式;
从所述至少一个命名表达式中确定目标命名表达式,将所述目标命名表达式对应的分层划域信息,作为目标分层划域信息;
根据推导特征,推导数仓表对应的维度模型的类型;将所述数仓表逆向为所述类型的维度模型对应的模型表,将所述模型表关联上目标分层划域信息。
在一些实施例中,所述装置用于从所述至少一个命名表达式中确定目标命名表达式包括:
将所述至少一个命名表达式中命中最多分层划域信息或者,命中最多关键分层划域信息的命名表达式,作为目标命名表达式。
在一些实施例中,所述装置用于根据推导特征,推导数仓表对应的维度模型的类型包括:
基于目标分层划域信息,以及从数仓的代码提取得到的特征,确定推导特征,根据所述推导特征推导数仓表对应的维度模型的类型,数仓表对应的维度模型的类型包括事实表和维度表。
本申请实施例还提供一种服务器,该服务器可以是大数据计算引擎服务器,该服务器可以通过设置本申请实施例提供的建模装置,以实现本申请实施例提供的建模方法。可选的,图11示出了服务器的可选框图。如图11所示,该服务器可以包括:至少一个处理器1,至少一个通信接口2,至少一个存储器3和至少一个通信总线4。
在本申请实施例中,处理器1、通信接口2、存储器3、通信总线4的数量为至少一个,且处理器1、通信接口2、存储器3通过通信总线4完成相互间的通信。
可选的,通信接口2可以为用于进行网络通信的通信模块的接口。
可选的,处理器1可能是CPU,GPU(Graphics Processing Unit,图形处理器),NPU(嵌入式神经网络处理器),FPGA(Field Programmable Gate Array,现场可编程逻辑门阵列),TPU(张量处理单元),AI芯片,特定集成电路ASIC(Application Specific IntegratedCircuit),或者是被配置成实施本申请实施例的一个或多个集成电路等。
存储器3可能包含高速RAM存储器,也可能还包括非易失性存储器(non-volatilememory),例如至少一个磁盘存储器。
其中,存储器3存储一条或多条计算机可执行指令,处理器1调用所述一条或多条计算机可执行指令,以执行本申请实施例提供的建模方法。
本申请实施例还提供一种存储介质,该存储介质存储一条或多条计算机可执行指令,该一条或多条计算机可执行指令被执行时实现如本申请实施例提供的建模方法。
本申请实施例还提供一种计算机程序,该计算机程序被执行时实现如本申请实施例提供的建模方法。
虽然本申请实施例披露如上,但本申请并非限定于此。任何本领域技术人员,在不脱离本申请的精神和范围内,均可作各种更动与修改,因此本申请的保护范围应当以权利要求所限定的范围为准。
Claims (13)
1.一种建模方法,其中,包括:
获取构建指标模型的需求描述语言;
对所述需求描述语言进行分词处理,以从所述需求描述语言中确定匹配指标元素的指标词;所述指标元素包括时间周期、修饰词和原子指标;
将所述匹配指标元素的指标词翻译为匹配指标元素的标准词;
若所述匹配指标元素的标准词不存在已录入的派生指标,为所述匹配指标元素的标准词定义派生指标,并自动录入所述派生指标;输出所述派生指标,作为构建的指标模型;所述派生指标包括描述时间周期、修饰词和原子指标的标准词。
2.根据权利要求1所述的建模方法,其中,所述对所述需求描述语言进行分词处理,以从所述需求描述语言中确定匹配指标元素的指标词包括:
基于预设的指标元素对应的候选词,利用自然语言处理NLP平台对需求描述语言进行分词处理,以从需求描述语言中确定与指标元素对应的候选词相匹配的指标词;
所述将所述匹配指标元素的指标词翻译为匹配指标元素的标准词包括:
利用翻译平台,基于指标元素的标准词的属性,从所述匹配指标元素的指标词中确定与标准词的属性相同但不为标准词的指标词,由标准词替换所确定的指标词,以得到匹配指标元素的标准词。
3.根据权利要求2所述的建模方法,其中,所述指标元素对应的候选词记录在智能词库的指标词库中,所述指标词库记录的指标元素对应的候选词,基于多个行业的行业词库确定,和/或,所述指标词库记录的指标元素对应的候选词为预先录入的;所述智能词库还记录指标元素的标准词的属性,标准词的属性包括标准词的词义和词性。
4.根据权利要求3所述的建模方法,其中,还包括:
调用所述NLP平台的接口,将录入的指标元素对应的候选词,实时同步到所述NLP平台;
对指标元素的标准词进行语义离线训练,将语义离线训练结果同步到翻译平台。
5.根据要求1所述的建模方法,其中,还包括:判断匹配时间周期的标准词、匹配修饰词的标准词以及匹配原子指标的标准词,是否存在已录入的派生指标;
所述若所述匹配指标元素的标准词不存在已录入的派生指标,为所述匹配指标元素的标准词定义派生指标,并自动录入所述派生指标包括:若匹配时间周期的标准词、匹配修饰词的标准词以及匹配原子指标的标准词不存在已录入的派生指标,为匹配时间周期的标准词、匹配修饰词的标准词以及匹配原子指标的标准词自动定义派生指标,并自动录入所述派生指标;
所述方法还包括:若匹配时间周期的标准词、匹配修饰词的标准词以及匹配原子指标的标准词存在已录入的派生指标,输出已录入的派生指标,作为构建的指标模型。
6.根据权利要求1所述的建模方法,其中,还包括:
基于所述派生指标在数仓模型中查询数据。
7.根据权利要求6所述的建模方法,其中,所述数仓模型包括维度模型;所述方法还包括:
根据目标维度,选择元仓的业务系统的主表;
从所述主表中,筛选与所述目标维度对应的维度模型的核心属性;
根据所述主表的元信息以及所述核心属性,生成维度模型的基础模型;
选择关联维度,在所述基础模型的基础上冗余所述关联维度的核心属性,并建立基础模型与关联维度的关联关系;
基于所述关联关系以及数据来源,对维度模型自动进行数据开发和代码生成。
8.根据权利要求7所述的建模方法,其中,所述维度模型包括维度表和事实表;所述从所述主表中,筛选与所述目标维度对应的维度模型的核心属性包括:
筛选所述主表中与所述目标维度对应的维度表的核心属性,或事实表的核心属性;所述维度表的核心属性包括维度表的维度主键和维度属性,事实表的核心属性包括粒度、冗余属性以及度量;
所述选择关联维度,在所述基础模型的基础上冗余所述关联维度的核心属性,并建立基础模型与关联维度的关联关系包括:
基于关联维度的ID选择关联维度的维度表,在基础模型的基础上冗余关联维度的维度表的核心属性,并建立基础模型与关联维度的关联关系,所述关联维度为至少一个与目标维度相关的维度。
9.根据权利要求6所述的建模方法,其中,所述数仓模型包括维度模型;所述方法还包括:
加载数仓表;
根据配置的至少一个分层划域规则,对所述数仓表的表命名进行解析,从所述表命名中解析出与各分层划域规则对应的命名表达式,以得到至少一个命名表达式;其中,一个分层划域规则定义分层划域信息的一种设计对应的表命名方式;
从所述至少一个命名表达式中确定目标命名表达式,将所述目标命名表达式对应的分层划域信息,作为目标分层划域信息;
根据推导特征,推导数仓表对应的维度模型的类型;将所述数仓表逆向为所述类型的维度模型对应的模型表,将所述模型表关联上目标分层划域信息。
10.根据权利要求9所述的建模方法,其中,所述从所述至少一个命名表达式中确定目标命名表达式包括:
将所述至少一个命名表达式中命中最多分层划域信息或者,命中最多关键分层划域信息的命名表达式,作为目标命名表达式。
11.根据权利要求9所述的建模方法,其中,所述根据推导特征,推导数仓表对应的维度模型的类型包括:
基于目标分层划域信息,以及从数仓的代码提取得到的特征,确定推导特征,根据所述推导特征推导数仓表对应的维度模型的类型,数仓表对应的维度模型的类型包括事实表和维度表。
12.一种服务器,其中,包括至少一个存储器和至少一个处理器,所述存储器存储一条或多条计算机可执行指令,所述处理器调用所述一条或多条计算机可执行指令,以执行如权利要求1-11任一项所述的建模方法。
13.一种存储介质,其中,所述存储介质存储一条或多条计算机可执行指令,所述一条或多条计算机可执行指令被执行时实现如权利要求1-11任一项所述的建模方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111633342.3A CN114490571A (zh) | 2021-12-28 | 2021-12-28 | 一种建模方法、服务器及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111633342.3A CN114490571A (zh) | 2021-12-28 | 2021-12-28 | 一种建模方法、服务器及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114490571A true CN114490571A (zh) | 2022-05-13 |
Family
ID=81495929
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111633342.3A Pending CN114490571A (zh) | 2021-12-28 | 2021-12-28 | 一种建模方法、服务器及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114490571A (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116431736A (zh) * | 2023-02-06 | 2023-07-14 | 北京三维天地科技股份有限公司 | 一种在线数据仓库模型的构建方法及系统 |
-
2021
- 2021-12-28 CN CN202111633342.3A patent/CN114490571A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116431736A (zh) * | 2023-02-06 | 2023-07-14 | 北京三维天地科技股份有限公司 | 一种在线数据仓库模型的构建方法及系统 |
CN116431736B (zh) * | 2023-02-06 | 2023-10-20 | 北京三维天地科技股份有限公司 | 一种在线数据仓库模型的构建方法及系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103177068B (zh) | 按照生存规则合并源记录的系统和方法 | |
Rattenbury et al. | Principles of data wrangling: Practical techniques for data preparation | |
US8185509B2 (en) | Association of semantic objects with linguistic entity categories | |
US20180096000A1 (en) | System for analysing data relationships to support data query execution | |
CN101506804B (zh) | 用于在大数据集分析期间维持一致性的方法和装置 | |
US11372896B2 (en) | Method and apparatus for grouping data records | |
Corr et al. | Agile data warehouse design: Collaborative dimensional modeling, from whiteboard to star schema | |
WO2018051098A1 (en) | System for data management in a large scale data repository | |
US10095766B2 (en) | Automated refinement and validation of data warehouse star schemas | |
CN111078780A (zh) | 一种ai优化数据治理的方法 | |
CN110647549A (zh) | 基于业务动态建模的数据指标解析与执行方法和装置 | |
US20070005658A1 (en) | System, service, and method for automatically discovering universal data objects | |
KR20110090939A (ko) | 퍼지 데이터 조작 | |
CN103309886A (zh) | 一种基于交易平台的结构化信息搜索方法和装置 | |
CN112613789A (zh) | 风险管控数据处理方法、风险预警规则前置数据监控方法 | |
CN102073701A (zh) | 一种基于语义定义的多数据源的数据查询方法 | |
CN110275874B (zh) | 一种大数据资源治理的智能化资源编目方法 | |
CN112131203A (zh) | 一种数据仓库搭建的方法和系统 | |
CN110728422A (zh) | 用于施工项目的建筑信息模型、方法、装置和结算系统 | |
CN111078766A (zh) | 一种基于多维理论的数据仓库模型建设系统及方法 | |
CN114625748A (zh) | Sql查询语句的生成方法、装置、电子设备及可读存储介质 | |
CN114490571A (zh) | 一种建模方法、服务器及存储介质 | |
CN117573646A (zh) | 一种基于维度建模的数据管理方法及系统 | |
CN115982429B (zh) | 一种基于流程控制的知识管理方法及系统 | |
US10360239B2 (en) | Automated definition of data warehouse star schemas |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |