建设方法及其规范数据中台

首页 > 快讯 > > 正文

日期:2021-04-13 21:54:00    来源:财讯网    

建设是指将企业内部的数据资源进行整合,构建出一个高效、可靠、安全、可扩展的数据共享平台,实现数据在企业内部的共享、交换、加工、挖掘和应用。而大数据服务化是数据中台建设的一个重要组成部分,是指将企业内部的大数据技术能力进行服务化,提供可复用、可扩展、高效、安全的大数据服务,以满足企业内部各个业务部门和业务场景的需求。

企业应该明确大数据中台的建设目标,以解决企业实际问题为出发点,确定中台应用场景和业务需求。建议从商业角度出发,明确业务目标,寻找数据与业务的关联,同时考虑数据的开放和共享。

企业建设数据中台不能一蹴而就,要基于业务,遵循规范来落地。数据中台数据来源多,数据结构复杂,业务逻辑复杂,存在数据的不一致性,指标的二义性,数据的重复等问题,因此数据中台的建设必须基于一套标准的规范来落地执行,以下将逐一展开阐述。

数据模型建设规范

数据模型是对现实事物的反映和抽象,能帮助我们更好地了解客观世界。数据模型定义了数据之间关系和结构,使得我们可以有规律地获取想要的数据。数据模型用于有效组织企业的数据资产,其设计工作应当在一定的规范约束下进行,这是建设高质量数据模型的前提条件。

公共规范

设计理念

企业数据的管理和组织,技术上需要满足业务对数据访问、计算、存储、质量上的要求,在业务上需要满足企业便捷使用数据的诉求。针对这样的诉求,阿里巴巴沉淀了OneData体系。数据中台数据模型设计方法是OneData体系的核心组成部分。它在维度建模思想基础上,针对大数据存储计算平台的特点,充分考虑新时代大数据应用特点,以数据中台体系建设的实践经验为依托,建立一套模型设计规范与准则。

在维度建模理论基础下,如何建设标准统一、质量可靠、性能优异、成本可控的数据体系是OneData体系追求的目标。

数据模型的维度设计主要以维度建模理论为基础,基于维度数据模型总线架构,构建一致性的维度和事实。

数据模型的事实表设计在维度模型事实表的基础上,结合数据使用场景的具体实践,进行一定扩展,采用宽表设计方法。所谓宽表,是指为了提升访问便利性和访问性能,在维度模型的事实表基础上,将部分常用维度退化(冗余)到事实表,或者将一些可枚举型的维度和度量,采用多指标、多字段方式实现在事实表中。

在指标定义中,采取组件化的形式,进行指标标准化定义,先规范定义,后生产,全生命周期控制,保障数据口径统一,减少重复建设,强调数据复用和共享。

基本原则

高内聚和低耦合:

一个逻辑和物理模型由哪些记录和字段组成,应该遵循最基本的软件设计方法论的高内聚和低耦合原则。主要从数据业务特性、访问特性、计算特性等方面来考虑:将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型;将高概率同时访问的数据放一起,将低概率同时访问的数据分开存储,针对计算依赖的数据产出时间是否相近,计算是否能同时产出等原则确定组合在一起还是拆分。

核心模型与扩展模型分离:

建立核心模型与扩展模型体系,核心模型包括的字段支持常用核心的业务,扩展模型包括的字段支持个性化或是少量应用的需要,必要时让核心模型与扩展模型做关联,不能让扩展字段过度侵入核心模型,破坏了核心模型的架构简洁性与可维护性。

公共处理逻辑下沉及单一:

越是底层公用的处理逻辑更应该在数据调度依赖的底层进行封装与实现,不要让公共的处理逻辑暴露给应用层实现,不要让公共逻辑在多处同时存在。公共处理逻辑下沉及单一,既有利于数据复用,也有利于变更修改。

成本与性能平衡:

适当的数据冗余换取查询和刷新性能,但是不宜过度冗余与数据复制。

数据可回滚:

数据计算处理逻辑不变,在不同时间多次运行数据结果确定不变。

一致性:

相同的字段在不同表字段命名和定义相同。

命名清晰可理解:

表命名规范需清晰、一致,易于下游理解和使用。

分层架构

OneData体系中,数据划分为三层:

ODS(Operational Data Store):

操作数据层。它相当于数据中台通用数据模型层的一个数据准备区,同时又承担着基础数据的记录以及历史变化,主要完成业务系统、日志等结构化和半结构化数据引入到数据中台。保留业务系统原始数据,包括增量明细和全量明细。在结构上其与源系统的增量或者全量数据基本保持一致。

CDM(Common Data Model):

通用数据模型,又细分为DWD和DWS。主要完成公共数据加工与整合,基于维度建模理念思想,建立一致性的维度,构建可复用面向分析和统计的明细事实表以及汇总公共粒度的指标。

ADS(Application Data Service):

应用层数据,提供直接面向业务应用的数据。为方便实现数据应用、数据消费的诉求,进行数据形式的组装,进行面向应用逻辑的数据加工处理。

在CDM层,由以下几部分组成:

DIM(Dimension),公共维度层,基于维度建模理念思想,建立企业的一致性维度。

DWD(Data Warehouse Detail),明细粒度事实层,以业务过程作为建模驱动,基于每个具体的业务过程特点,构建最细粒度的明细层事实表,结合企业的数据使用特点,将明细事实表的某些重要维度属性字段做适当冗余,也就是宽表化处理。

DWS(Data Warehouse Summary),汇总粒度事实层:以分析的主题对象作为建模驱动,基于上层的应用和产品的指标需求,构建公共粒度的汇总指标事实表,以宽表化手段物理化模型。

层次调用

应用层优先调用公共层数据,已经存在中间层数据,不允许应用层跨过中间层从ODS层重复加工数据。一方面,CDM研发人员应该积极了解应用层数据的建设需求,将公用的数据沉淀到公共层,为其他团队提供数据服务;另一方面,应用层团队也需积极配合CDM层团队进行持续的数据公共建设的改造和迁移。必须避免出现过度的ODS层引用和不合理的数据复制和子集合冗余。

ODS层数据不能被应用层任务引用,中间层不能有沉淀的ODS层数据,必须通过CDM层的视图访问。CDM层视图必须使用调度程序进行封装,保持视图的可维护性与可管理性。

CDM层任务的深度不宜过大(建议不超过10层)。

原则上一个计算刷新任务只允许一个输出表。

如果多个任务刷新输出一个表(不同任务插入不同的分区),需要建立一个虚拟任务,依赖多个刷新任务,通常情况下游应该依赖此虚拟任务。

CDM汇总层优先调用CDM明细层。可累加类指标计算,CDM汇总层尽量优先调用已经产出的粗粒度汇总层,避免大量汇总都直接从海量的明细数据层计算。

CDM明细层累计快照事实表优先调用CDM事务型事实表,保持数据一致性产出。

避免应用层过度引用和依赖CDM层明细数据,有针对性建设好CDM公共汇总层。

数据类型

为保证ODS层数据和源业务系统的兼容性,ODS层统一采用String类型,ODS层之上的CDM和ADS数据类型基于源系统数据类型转换,转换规则如下:

表(二)-1数据类型要求

CDM数据公共层如果是引用ODS层数据,默认使用ODS层字段数据类型;衍生加工数据字段按以下标准执行:

金额类及其它小数点数据:decimal

字符类数据:varchar或string

ID类和整型数值:bigint

时间类型数据:Datetime或Timestamp(如果有特殊的要求,可以使用String)

状态:string

分区字段

数据统计日期分区字段

按天分区:ds(YYYYMMDD)

按小时分区:hh(00-23)

按分钟:mi (00-59)

is_{业务}:表示布尔型数据字段。使用字符或表示,不允许出现空值域。

数据冗余

一个表做宽表冗余维度属性时,应该遵循以下几个建议准则:

冗余字段与表中其它字段高频率同时访问。

冗余字段的引入不应造成其本身的刷新完成时间过多后延。

公共层数据不允许字段重复率大于60%的相同粒度数据表冗余,可以选择原表基础上拓宽或者下游应用通过JOIN方式实现。

从一个集合中冗余一部分记录作为另外一张表存在时,可以优先考虑子分区方式,但是多级子分区不超过(5级),只有以下情况才考虑冗余:

子类型表有较多(大于10)个字段父类型表并不存在。

子集合的过滤条件被多次(大于5次)应用。

数据拆分

数据的水平和垂直拆分,基本上按访问热度分布和数据表的非“空“值或者非”零”值的数据值在行列二维空间上分布情况进行划分。

在物理上划分核心模型和扩展模型,将其字段进行垂直划分;比如会员表,建议拆分为核心表和扩展表。核心表相对字段较少,刷新产出时间较早,优先使用。扩展表字段较多,且可以冗余核心表部分字段,刷新产出时间较晚,适合数据分析人员使用。

将访问相关度较高的列在一个表存储,将访问相关度较低相关的字段分开存储;

数据记录数较大的维度表,可以适当冗余一些子集合。将经常用到的where条件按记录行进行水平切分或者冗余;水平切分可以考虑二级分区手段,以减少下游扫描数据量,避免多余的数据复制与冗余。比如商品表,可以根据当天是否有行为,产出一个有活跃行为的相关维表,以减少应用的数据扫描量。或可根据所属业务扫描数据范围大小的不同,进行适当子集合冗余。

将表中出现大量空值和零值的统计汇总表,依据其空值和零值分布状况可以做适当的水平和垂直切分,可以有效减少存储和减少下游的扫描数据量。

空值处理

汇总类指标的空值:空值处理,填充为零,基于列存储的压缩技术不会由于填充大量空值导致存储成本上升。

维度属性值为空:在汇总到对应维度上时,参照不上的统计事实记录行,填充-99(未知),在对应维表有一条-99(未知)的记录。

规范定义

指以维度建模作为理论基础,构建总线矩阵,划分和定义数据域、业务过程、维度、度量/原子指标、业务限定、时间周期、统计粒度、派生指标。

规范定义实例如下:

图(三)-1 数据建模规范定义实例图

指标体系

(1)基本原则

组成体系之间的关系

派生指标由原子指标、业务限定、时间周期、统计粒度组合得到。

图(三)-2 指标体系组成关系示意图

原子指标、业务限定,直接归属在业务过程下。

派生指标唯一归属一个原子指标,继承原子指标的数据域。

原子指标有确定的英文字段名、数据类型和算法说明;派生指标要继承原子指标的英文名、数据类型和算法要求。

命名约定

命名所用术语

指标命名,尽量使用英文简写,其次是英文,当指标英文名太长时,可考虑用汉语拼音首字母命名。如中国质造,用zgzz。

业务过程

英文名:用英文的缩写或者英文或者中文拼音简写

中文名:具体的业务过程中文即可

关于存量指标(见下文定义)对应的业务过程的约定:实体对象英文名+’_stock’。如在线会员数,一星会员数等,其对应的业务过程为mbr_stock;在线商品数,其对应的业务过程为itm_stock。

原子指标

英文名:动作+度量

中文名:动作+度量

原子指标必须挂靠在某个业务过程下。

时间周期

时间周期英文名长度为2位,加上“_”为三位,例如_1d。

常用的时间周期修饰词列表如下:

表(三)-1常用时间周期修饰词列表

业务限定:

英文名:尽量使用英文缩写,尽量是没有下划线的字母组合,最多有一个下划线。长度尽量控制在5个字符以内。

中文名:可以描述较为完整业务的中文名称。

派生指标

英文名:原子指标英文名+时间周期(=3位,例如,_1d)+业务限定英文名(以_开头带上业务限定英文名,例如,_pcvst)。

中文名:统计粒度+时间周期+业务限定+原子指标。

为控制派生指标英文名称过长,因此在定义业务限定英文名时,尽量精简明了。

(2)操作细则

派生指标的种类

派生指标可以分为三类:事务型指标、存量型指标和复合型指标。按照其特性不同,有些必须新建原子指标,有些可以在其他类型原子指标基础上增加业务限定形成派生指标。

事务型指标

是指对业务活动进行衡量的指标。例如,新发商品数,重发商品数,新增注册会员数,订单支付金额,这类指标需维护原子指标及业务限定,在此基础上根据指定的统计粒度创建派生指标。

存量型指标

是指对实体对象(如商品、会员)某些状态的统计,它最典型的特点是它的总量不是一个统计时间范围内的增量,而是历史累计到统计时间点的全量。例如,当前商品总数,当前会员总数,这类指标维护原子指标及修饰词,在此基础上创建派生指标,对应的时间周期为“历史截止到当前”。

比较衍生型指标

是在事务性指标和存量型指标基础上进一步衍生而成的,例如,店铺最近1天无线端支付金额按行业降序排名、本月成交额与去年同期同比变化率等。

比较衍生型指标的规则

排名型

在已有的派生指标上衍生创建。

其定义方式为:派生指标+排名范围(例如:行业、省份、一级类目等)+排名方式(例如:升序排名ark,降序排名drk)。举例:“店铺最近1天无线端支付金额按行业降序排名”,派生指标为店铺最近1天无线端支付金额,排名范围为行业,排名方式为降序排名。

排名对象集合型

对象集合型主要是数据产品和应用需要展现数据时,将一些对象以KV对的方式存储在一个字段中,方便前端展现。

其定义方式为:派生指标+排名范围(例如:行业、省份、一级类目等)+排名方式(例如:升序排名ark,降序排名drk)+topN+对象名+s(s代表指标为字符串)。

变化量型

变化量型指标分为同比变化量、环比变化量和滑动窗口变化量三种类型。

指标定义方式为:派生指标+变化量类型(=3位,第1位为比较周期窗口{y年/m月/d日},滑动窗口比没有这部分;第2位为比较方法{s同比/r环比/w滑动窗口比};第3位“a”表示比较内容为变化量)

常用的变化量类型列表如下:

表(三)-2变化量类型列表

变化率型

变化率型指标分为同比变化率、环比变化率和滑动窗口变化率三种类型。

指标定义方式为:派生指标+变化率类型(=3位,第1位为比较周期窗口{y年/m月/d日},滑动窗口比没有这部分;第2位为比较方法{s同比/r环比/w滑动窗口比};第3位“r”表示比较内容为变化率)

常用的变化率类型列表如下:

表(三)-3变化率类型列表

比例型

比例型指标定义方式为:派生指标+rb(ration by)+占比组,用于例如:“卖家最近1天销售金额行业占比”,派生指标为卖家最近1天销售金额,占比组为行业,可定义为pay_amt_1d_rb_industry。

ODS模型设计规范

在数据抽取前,需要先对具体数据资产进行盘点,后续根据盘点结果进行数据同步,具体数据资产盘点可根据数据资产目录模板进行。

同步策略

(1)小数据量表

抽取处理策略

数据库直连方式全量抽取。

存储策略

全量表:按天全量存储,生命周期一般设置为367天,如有特殊业务需要可调整生命周期。

(2)大数据量表

维表

抽取处理策略

数据库直连方式通过业务时间戳抽取增量数据到增量表,再从增量表merge入全量表。

有些表的数据量随业务的发展越来越大,如果按周期全量同步的方式会影响处理效率。在这种情况下,选择改为每次只同步新变更的增量数据,然后与上一同步周期获得的全量数据进行合并,从而获得最新版本的全量数据。

具体使用的方式可用主键去重(row_number) + 数据全量覆盖重新加载(insert overwrite)的方式,即如日调度,则将当天增量数据和前一天全量数据合并后根据主键去重,重新加载为最新的全量数据。

存储策略

增量表:可设置长周期(如367天或永久保存);

全量表:根据业务需求及存储资源考虑设置较长周期(如367天,若需要永久保存则要使用历史拉链处理)。

日志型事务表

抽取处理策略

原始日志增量抽取到增量表。按天增量存储。因为日志数据表现为只会有新增不会有修改的情况,因此不需要保存全量表。

存储策略

增量表:可设置长周期(建议永久保存);

非流水型事务表

抽取处理策略

从源数据库通过时间戳抽取增量数据到增量表,再从增量表merge入最近N天(例如最近200天)全量表。

具体使用的方式可用全外连接(full outer join) + 数据全量覆盖重新加载(insert overwrite)的方式,即如日调度,则将当天增量数据和前一天全量数据做全外连接,重新加载为最新的全量数据。

需要注意选择当天增量数据和前一天全量数据都需要限制最近N天创建的限制条件。

以下以淘宝订单为例,描述抽取与处理策略:

图(四)-1 非流水型事物表数据抽取与处理策略示意图

存储策略

增量表:可设置长周期(如永久保存);

最近N天全量表:根据业务需求及存储资源保留合适周期(如生命周期设置为7天或33天,若要对全量表快照保留长周期并做极限存储需要仔细评估计算与存储代价)。

历史数据处理

若需要进一步对所有的历史数据做存储,而不仅仅是最N天的全量。可在上述方案基础上,平衡历史可回滚、存储数据量、更新性能等方面,参考下面这样一套三级存储/更新方案:

图(四)-2 历史数据处理示意图

其中:OLD表存储最近N天之前的数据,这部分数据不再使用delta增量数据更新。使用创建日期作为分区,生命周期保存永久。

OLD_UPDATE表用于更新N天之前的记录merge至该表。表使用最新分区,只需保存一个很短的生命周期(例如3天)。

模型建设规范

业务过程

业务过程是指企业发生的主要业务事件或者流程,比如会员注册、网站点击、下单、支付等等。业务过程的梳理主要是业务调研,特别是在业务流程梳理阶段可以发现企业重要业务过程,完成第一轮的业务过程初稿整理,同时在数据应用调研时候再次对业务过程进行第二轮确认,将需要分析的业务过程重点分析,将当前不在需求范围内的业务过程暂时hold进入详细设计。

业务过程按其业务类型可以划分为以下几种类型,其他们定义时的规范体系可以遵循如下建议:

表(五)-1模型建设规范

在定义过程中,需要注意一下三个原则:

(1)原子化:注意业务流程与业务过程的区别,通常一个业务流程有多个原子化的业务过程组成,业务过程尽量进行业务级别原子化抽象,比如一个交易是由下单、支付、退款、确认收货等多个组成,因此不建议将交易构建为一个业务过程。一个技巧,当我们抽象了一个业务过程后,我们需要review以下是否有更细一层的业务组成,如果有继续细化,同时判断细化的业务过程是否是业务分析需要的。

(2)互斥性:不要让两个不同的业务过程描述同一个业务,能尽可能有效避免指标定义重复。

(3)用原子化组合能力:混合事务型和业务流程型应对引用原子化的事务型组合而成。

维度

维度表达的是用于描述和分析业务过程的具体方面,企业的数据总线是由业务过程+维度组成,在上一章节定义了业务过程后,业务过程被一系列的维度描述,未来数据的指标将会被统计到各个维度,维度定义和管理的的好坏,对后续数据质量、数据重复建设的管理至关重要。如图所示进行维度定义,关键信息填写建议:

维度英文名:维度英文名直接使用维度的下划线+英文缩写组合;

维度名称:使用维度的名称,切忌在后面添加“表”字,这是一个抽象的业务对象定义,不是表,比如商品、用户、类目;

同时我们提供了几种类型的维度定义:普通维度、普通维度(层级),枚举维度、虚拟维度。

(1)普通维度

普通维度是我们常见的一般维度,需要填写主键及其它一下信息,填写规范建议:

主键英文名:xx_id,xx是维度的英文名称部分;

主键名称:xxID,xx是维度的中文名称部分;

主键计算逻辑:尽可能的简化SQL表达主键,比较简单情况是来源于某张源表,复杂一些情况可能需要两个表join,可能需要去重操作。特别注意如果是从遗留系统里面迁移过来,如果存在一些排序逻辑,是不需要表达,因为我们这里只是利用主键对维度的数据范围进行定义,多个表且可能有重复情况可以使用UNION ALL+DISTINCT方式表达。同时注意SQL表达主键的需要使用SELECT xx as k语法,k表达的是key(主键)。

(2)普通维度(层级)

在一些父子结构的数据,如部门的组织关系、多级树形结构归类,在数据仓库中需要将其加工为扁平结构的维度模型,方便用户在数据计算和分析时进行任意层级的汇总和查询。

(3)枚举维度

枚举维度主要是用于一些用户定义的归类数据进行定义,一方面它可以进行数据内容格式的标准化,一方面可以方便用户快速录入。

Code:部分建议使用英文的代码标识,最好使用大众普遍认同且有业务含义的代码,value值表达的是实际的中文业务含义。

(4)虚拟维度

虚拟维度是用于表达退化到事实表中的维度信息,如果此维度的值域范围是不可枚举,类如cookieid,且需要作为统计指标的粒度,因此我们有必要对维度进行定义,但是实际底层物理实现并不会物理化一张维度表。如果在事实逻辑表中的维度值域范围是可枚举的,建议优先选择为枚举维度定义,这样更有利于建维度的值域范围标准化。

原子指标

原子指标是对有一个业务过程进行统计的度量,用户需要输入以下核心信息:

主要来源字段:对于计算逻辑没有影响,主要用来引导计算逻辑是什么字段衍生

英文名:建议:{业务过程英文名}_{其它说明英文缩写}_{度量词英文缩写}方式进行命名,比如crt_ord_qty,

名称:建议:中文名称,{业务过程中文名称}{度量中文名}

统计周期,主要是用于全量型事实表,在统计指标时进行时间周期范围的限定,比如我们要统计最近7天新发商品数,在没有构建新发商品的增量型事实逻辑表情况下,我们从商品维度逻辑表(全量)进行统计,因此我们指标的逻辑必须限定商品维度逻辑表的“创建时间”字段在最近7天内。

计算逻辑是一个SQL表达式,可以引用逻辑表的字段,在此切忌添加指标的特定条件限制,因为设计要求,特定条件是由业务限定承载,与原子指标进行组合为派生指标。

除了普通的简单统计类指标,还有一类较为复杂的,一个指标是由多个原子指标经过表达式计算产生,典型的比率型指标,是有两个指标进行运算获取,比如支付客单价,是支付金额除以支付客户数。

业务限定

业务限定是在构建派生指标具体化过程中对原子指标特定的说明修饰,这些限定通常是一个逻辑表达式去限定指标的统计数据范围。业务限定也需要进行一定的公用性抽象,让业务限定能尽可能的复用能极大的改善数据标准一致性问题,也能大大提升研发效率。

主要输入信息:

英文名:尽量使用英文缩写,尽量是没有下划线的字母组合,最多有一个下划线。长度尽量控制在5个字符以内。名称:可以较为完整的业务的中文名称描述: 对业务描述算法文字描述计算逻辑:类SQL的计算逻辑表达式

派生指标

派生指标是用户在业务需求中真正需要的指标,一个派生指标由:一个原子指标、一个时间周期、一个业务限定、一个粒度组合而成,在用户操作层面只要按产品界面提示构建即可。派生指标的配置相对比较简单,提供了批量化生产,切忌批量大量生成无业务需求的指标,每个指标都需要耗费资源。

维度逻辑表

下文仅会对维度表设计规范要求进行阐述,对维度表的属性和常见问题进行介绍,具体设计结果可参照维度表设计模板进行。

维度属性

维度属性可以通过两种方式引入:自定义SQL和从其它表的字段引入,有逻辑表达转换或者希望批量方式导入其他表的字段建议使用SQL方式。相关属性规范要求建议:

字段英文名:采用下划线连接方式的英文字段名,是否类型的字段,建议使用is_xxx的字段名表达,字段值存储”Y/N”。

数据类型:默认继承源系统数据类型,特殊情况基于客户的要求自己约束定义。

关联维度

在选择关联维度添加属性时,可以新增一个维度属性引用其它逻辑表,其中关键填写信息规范建议如下:

角色英文名:建议选取{维度本身的英文名}__{角色英文缩写}组成。(注意双下划线用于区分后半部分的角色英文缩写)

角色名称:以能准确表达关联维度在场景中的角色短语。

拉链表设计

在数据仓库的数据模型设计过程中,经常会遇到如下需求:

数据量较大。表中的部分字段被更新,例如用户的地址、产品的描述信息、订单的状态、手机号码等。需要查看某一个时间点或时间段的历史快照信息。例如,查看某一个订单在某一个历史时间点的状态,或查看某一个用户在过去某段时间内更新过几次等。变化的比例不大、频率不高。假设总共有1000万个会员,且每天新增和发生变化的会员只有10万左右,如果每天都在表中保留一份全量,那么每次全量中会保存很多不变的信息,极大地浪费了存储资源。

针对以上需求,MaxCompute提供了将不同表转化为极限存储表的方法。极限存储操作示例如下:

创建源表。

导入数据。

将src_tbl转变为极限存储的表。

事实逻辑表

事实逻辑表是描述某个事实(即业务过程)属性的数据仓库模型。它表达了业务过程的详细数据信息结构,因此我们在事实逻辑表上需要添加维度属性、度量及关联维度。下文仅会对事实逻辑表的设计规范要求进行阐述,具体事实逻辑表设计结果可参照事实表设计模板进行。

事实逻辑表定义

基于某个业务过程,需要创建事实逻辑表,需要填写的信息遵循如下规范建议:

英文名:我们预设定了业务过程名作为命名的一部分,因此候选部分用户以下划线连接的英文缩写进一步表达逻辑模型的业务含义。

名称:建议以相对完整的中文短语描述名称,主要包括业务主体、业务过程,比如淘宝交易下单业务事实表。

描述:详细描述数据范围,以及表达的业务含义,一条记录代表的数据业务描述。

事实属性与度量

用户可以通过点击新建字段功能,分别添加度量、事实属性和关联维度,在此需要遵循的规范是:

字段英文名称:符合基本规范定义企业通用词汇表要求,使用带下划线组合的英文字段组合。尽量采用主体_字段含义形式,比如客户状态(cust_status),不推荐直接使用status的形式;如果是是否类型的字段,采用命名。

字段中文名称: 简单的中文含义表达字段业务含义。

数据类型:默认继承源系统数据类型,特殊情况基于客户的要求自己约束定义。

关联维度

在选择关联维度添加属性时,可以新增一个维度属性引用其它逻辑表,其中关键填写信息规范建议如下:

角色英文名:建议选取{维度本身的英文名}__{角色英文缩写}组成。(注意双下划线用于区分后半部分的角色英文缩写)

角色名称:以能准确表达关联维度在场景中的角色短语。

汇总逻辑表

汇总逻辑表是有派生指标按统计粒度组织的一系列模型,相同粒度的派生指标组织在一个汇总逻辑表里,基于此逻辑表,用户可以访问所需要的指标。具体设计可参照模板18汇总表设计模板进行。

免责声明:市场有风险,选择需谨慎!此文仅供参考,不作买卖依据。

关键词:

下一篇:数据中台之数据研发规范
上一篇:最后一页