数仓规范_数仓词根设计规范

研发流程：

开发设计流程

数据建模流程

数据标准和数据规范

命名规范化工具

词根设计

定义

• 把可能会多次用到的短语，集中命名，保证全局范围内的命名含义一致性。

内容

• 所属分类
• 名称
• 英文简称
• 数据类型
• 备注

分类

• 普通词根：描述事物的最小单元体，如：交易-trade。
• 专有词根：具备约定成俗或行业专属的描述体，如：美元-USD。

公共字段

• 公共字段=词根组合+其它关键词
• 公共字段放入词根库不太严谨，但字段命名时候可以直接取用，降低了命名不一致的风险，所以工具化不太完善的公司推荐这样使用。

常见词根表模板 举例： 以流程图的方式来展示，更加直观和易懂，本图侧重 dwm 层表的命名 规范，其余命名是类似的道理：

分层：表的使用范围
事业群和部门：生产该表或者该数据的团队
业务线：表明该数据是哪个产品或者业务线相关
主题域：分析问题的角度，对象实体
自定义：一般会尽可能多描述该表的信息，比如活跃表更新周期：比如说天级还是月级更新
1

数据字典

定义：

表示某一数据项的取值枚举集合，在规定的集合里取值，一般由代码值，代码描述组成一个字典项。如： 系统代码分类表，系统代码表，属性表，配置表...

数据字典的用途

- 数据字典是各类数据描述的集合 　　- 数据字典是进行详细的数据收集和数据分析所获得的主要结果 　　- 数据字典在数据库设计中占有很重要的地位

数据字典的内容

- 数据字典的内容：数据项；数据结构；数据流；数据存储；处理过程。数据项是数据的最小组成单位，若干个数据项可以组成一个数据结构。数据字典通过对数据项和数据结构的定义来描述数据流、数据存储的逻辑内容。

为什么要建设数据字典

1.设计业务数据字典，主要有如下几个目的：
规范和统一指标命名，使其通俗、易懂。
统一指标的维度、度量和统计方式，避免发生歧义和不一致。
更好的管理和使用数据，共享数据指标，达成对业务指标的共识。
为技术数据字典的建设，提供业务依据。

2.设计技术数据字典，主要有如下几个目的：
记录数据仓库中的逻辑模型的定义。
对数仓各层级间的映射关系、数据流向，做数据血缘分析。
监控数仓的任务执行情况和运行状态。
帮助开发人员快速查找到目标数据，提高工作效率。
利于开发新人快速的熟悉现有数仓架构，顺利开展工作。
1

字典数据表模板 字典类型表模板

命名规范

分层规范
库表命名规范
指标字段命名规范
指标口径规范
索引命名规范
ETL作业命名规范
代码设计规范
层次调用规范
1

分层规范：

• 一、数据运营层：ODS(Operational Data Store)

ODS层，是最接近数据源中数据的一层，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。

• 二、数据仓库层：DW (Data Warehouse)

数据仓库层是我们在做数据仓库时要核心设计的一层，在这里，从 ODS 层中 获得的数据按照主题建立各种数据模型 。DW 层又细分为DWD(Data Warehouse Detail )层、DWM(Data WareHouse Middle )层和DWS(Data WareHouse Servce )。

1. 数据明细层：DWD (Data Warehouse Detail)

该层一般保持和ODS层一样的数据粒度 ，并且提供一定的数据质量保证 。

DWD层要做的就是将数据清理、整合、规范化、脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据都会被处理。

同时 ，为了提高数据明细层的易用性 ，该层会采用一些维度退化手法 ，将维度退化至事实表中， 减少事实表和维表的关联。另外，在该层也会做一部分的数据聚合，将相同主题的数据汇集到一 张表中 ，提高数据的可用性 。

2. 数据中间层：DWM (Data WareHouse Middle)

该层会在 DWD 层的数据基础上，对数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性， 减少重复加工。直观来讲 ， 就是对通用的核心维度进行聚合操作， 算出相应的统计指标。

在实际计算中 ， 如果直接从 DWD 或者 ODS 计算出宽表的统计指标 ， 会存在 计算量太大并且维度太少的问题，因此一般的做法是，在 DWM 层先计算出多个小的 中间表 ，然后再拼接成一 张 DWS 的宽表 。 由于宽和窄的界限不易界定，也可以去掉 DWM 这一层， 只留 DWS 层，将所有的数据再放在DWS 亦可。

3. 数据服务层：DWS (Data WareHouse Servce)

DWS 层为公共汇总层， 会进行轻度汇总 ， 粒度比明细数据稍粗，基于DWD层上的基础数据， 整合汇总成分析某一个主题域的服务数据，一般是宽表。DWS层应覆盖 80%的应用场景 。又称数据集市或宽表。

按照业务划分，如主题域流量、订单、用户等 ，生成字段比较多的宽表 ， 用 于提供后续的业务查询，OLAP分析，数据分发等。一般来讲，该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。

• 三、数据应用层：APP (Application)

在这里，主要是提供给数据产品和数据分析使用的数据 ，一般会存放在ES 、 PostgreSql、Redis 等系统中供线上系统使用 ，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用 。比如我们经常说的报表数据，一般就放在这里。

• 四、维表层 (Dimension)

最后补充一个维表层，维表层主要包含两部分数据：高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。

低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。

库表命名规范

• 库命名规范：
• 表命名规范 （1）一些通用标准

表命名其实在很大程度上是对元数据描述的一种体现，表名应该能够让用户快速看出表的含义和作用，提升数据仓库的可维护性和易用性，以下是表命名规范的一些通用标准：

采用小写字母和下划线的命名方式（蛇形命名法），禁止使用特殊字符和空格。

表名应该简洁明了、有意义，并真实反映表所存储的内容和业务领域；表名应该为名词或名词短语，禁止使用动词，避免出现英文单词和汉语拼音混用的局面。

尽量缩短表名，但是不应该过于简略，最好不要超过32个字符。

对于包含多个单词的表名，可以使用下划线"_"进行分隔，例如：order_item。
在数仓中，通常会存在多种类型的表，如事实表、维度表、临时表、中间表等，建议在表名中包含类别前缀，如temp_order，dim_product等，以便对不同表进行分类管理。

避免使用缩写，因为缩写可能会产生歧义或混淆。

数据域、主题域命名统一管理缩略词请统一参考【字典库】。

优先使用词根中已有关键字（数仓标准配置中的词根管理），定期 Review 新增命名的不合理性。

禁止采用非标准的缩写。
1

虽然表命名规范上有了明确的规定，但在实际使用过程中，也需要特别关注业务需求的变化，及时进行调整和优化。

（2）ODS层表命名规范

表名规范：ods_来源类型[业务|系统]_业务表名_装载策略_装载周期
表名示例：ods.ods_db_logs_gold_logs_i_d
规范说明： - 存储库名：ods - 来源类型：区分不同来源及系统，含结构化、半结构及非结构化数据。 -- 类型分类：DataBase（db）、Http（api）、Rsync Log（rsync）、MQ（topicName）、hive（layerName）。 - 项目编码：参考业务对应的编码对照库，注：一般指业务系统简称编码 - 业务表名：与数据来源系统一致，以避免造成其二义性。有分表则去除分表规则，目标添加source_table字段区分来源表名。 - 装载策略：增量（i）、全量（f）、快照（s）、 拉链（h）、 - 装载周期：根据实际装载周期确定。实时（rt）、小时（h）、天（d）、周（w）、月（m）、季（q）、年（y）、一次性任务（o）、无周期（n）
1

（3）DWD层表命名规范

表名规范：dwd_一级数据域_二级数据域[_业务过程]_业务描述_装载策略_装载周期
表名示例：dwd.dwd_log_app_click_info_i_d
规范说明： - 存储库名：dwd - 一级数据域：用户域、内容域、日志域、财务域、互动域、服务域等等 - 二级数据域：移动端、Web端、会员、金币等等，统一定义 - 业务过程：曝光、浏览、点击、注册、登录、注销等等，统一定义 - 业务描述：描述业务内容 - 装载策略：增量（i）、全量（f）、快照（s）、 拉链（h） - 装载周期：根据实际装载周期确定。实时（rt）、小时（h）、天（d）、周（w）、月（m）、季（q）、年（y）、一次性任务（o）、无周期（n）
1

（4）DWS层表命名规范

表名规范：dws_一级数据域_二级数据域_数据粒度_业务描述_统计周期
表名示例：dws.dws_log_mbr_event_info_1d
规范说明：
存储库名：dws
一级数据域：用户域、内容域、日志域、财务域、互动域、服务域等等
二级数据域：流量、渠道、会员、留存、事件等等
数据粒度：描述业务数据粒度
业务描述：描述业务内容
统计周期：统计实际周期范围，缺省情况下，离线计算应该包括最近一天（_1[h|d|w|m|q|y]），最近N天（_n[h|d|w|m|q|y]）和历史截至当天（_t[h|d|w|m|q|y]）三个表。小时(h)、天（d）、周(w)、月（m）、季（q）、年（y）。
1

（5）APP层表命名规范

表名规范：app_应用类型_业务主题_业务描述_统计周期_装载周期
表名示例：app.app_rpt_channel_user_1d_d
规范说明：
存储库名：app
应用类型：固定报表、分析报表、标签系统、用户画像、数据接口
业务主题：看板、驾驶仓、ROI、渠道分析、漏斗分析、留存分析、活跃分析等等
业务描述：描述业务内容
统计周期：统计实际周期范围，缺省情况下，离线计算应该包括最近一天（_1[h|d|w|m|q|y]），最近N天（_n[h|d|w|m|q|y]）和历史截至当天（_t[h|d|w|m|q|y]）三个表。小时(h)、天（d）、周(w)、月（m）、季（q）、年（y）。
装载周期：根据实际装载周期确定。实时（rt）、小时（h）、天（d）、周（w）、月（m）、季（q）、年（y）、一次性任务（o）、无周期（n）
1

（6）DIM层表命名规范

表名规范：dim_应用类型_业务主题_业务描述_[层级_装载策略_装载周期]
表名示例：dim.dim_pub_city_lvl、dim_pub_chl_i_h
规范说明： - 存储库名：dim - 应用类型：公共、自定义 - 业务主题：渠道、版本、产品、城市等等 - 业务描述：描述业务内容 - 层级 ：层级（lvl） - 装载策略：增量（i）、全量（f）、快照（s）、 拉链（h） - 装载周期：根据实际装载周期确定。实时（rt）、小时（h）、天（d）、周（w）、月（m）、季（q）、年（y）、一次性任务（o）、无周期（n）
1

（7）TEMP层表命名规范

表名规范：temp_目标表名_((数据日期[_数据小时])|(开始日期_结束日期))
表名示例：temp.temp_dwd_log_app_click_info_i_d_20210311（会话表）、temp.temp_username_test_20210311_20210321 （临时表）
规范说明： - 存储库名：temp - 目标表名： 会话表：目标表名
临时表：业务描述 - 数据日期：ETL跑批日期 、ETL数据处理日期 - 数据小时：ETL跑批小时 、ETL数据处理小时
1

指标规范化建设

• 指标混乱现状

同名不同径、同径不同名、同部不同径、命名难理解、计算不易懂、来源不清晰等，这些都是当前指标混乱的状况。

第一，相同指标名称，口径定义不同。不同的部门对相同的指标，口径定义的不同，导致指标数值可能不一致，这种是指标管理中最容易出现的情况。口径不一致，数据也就没办法横向对比，失去了数据辅助商业决策的意义。

第二，相同口径，但指标名称不一样。这种情况与上面相反，想象发放优惠券场景，现在你有两个数据产品：一个是经营大脑，主要展示的是企业日常经营活动健康度的核心指标，它有一个指标叫“优惠券抵扣金额”；一个是市场360，主要是展示市场活动效果衡量的指标，它也有一个指标叫“优惠券消耗金额”。其实，两者的口径定义并没有区别，但是指标名称不同，这会让使用指标的人疑惑。

第三，指标口径描述不清晰。有些报表上的指标口径描述的比较笼统。比如“关单金额”，口径描述“关闭订单的金额”。不同人的理解可能不一样，有的人会认为是支付成功后关闭订单；也有可能是支付完成前，取消订单。描述不清晰，就会让人们对数据的理解产生歧义。

第四，指标口径描述错误。在流量分析数据产品中，有“7日UV”这个指标，口径的定义是7日内日均UV。根据口径描述的计算逻辑，应该是最近7日，每日UV相加除以7取平均值。显然，这个定义在业务场景中是有问题的，正确的7日 UV的口径定义应该是7日内有登录过且去重的用户数。

第五，指标命名难于理解。常见的一个指标ROI，在电商业务场景中，优惠劵、商品降价促销都可以计算ROI，此时，比较好的命名应该是（商品_类目_通用）优惠劵ROI。因此，指标命名不规范的话，从指标名称中很难看出指标描述的业务过程。

最后，指标数据来源和计算逻辑不清晰。如果指标数据来源不清楚，一旦这个指标数据异常，就很难去做溯源。有些指标的计算逻辑比较复杂，仅仅凭借业务口径一段描述，使用指标的人还是无法理解这个指标的计算逻辑，这个时候就需要有一些伪码或者SQL描述。
1

• 规范定义指标 首先， 按照业务线、主题域和业务过程三级目录方式管理指标（业务线是顶级目录）。电商、游戏、音乐、传媒、短视频都是不同的业务线。在业务线之下，是主题域， 指标中的主题域与数仓中的概念是一致的，划分标准最好与跟数仓保持一致。在主题域下面还有细分的业务过程，比如对于交易域，细分的业务过程有浏览、选购、下单、支付等。

其次，拆分派生指标。派生指标是由统计周期、聚合粒度（也称统计粒度）、限定维度（也称业务限定）、原子指标组成。。

1）原子指标：原子指标就是度量，对某一业务事件进行度量，有明确的业务含义，比如支付金额等。具有明确的业务含义且在逻辑层面不可再拆分。

原子指标隶属于业务过程，一般在事实表中包含，所以创建原子指标时必须选择所属的业务过程。原子命名规范可由业务修饰词 + 词根组成：
1

2）派生指标：对原子指标业务统计范围的确定。由一个原子指标＋修饰词（业务限定）＋时间周期+聚合粒度组成。

派生指标可以分为两类：事务型指标、存量型指标。按照其特性不同，有些必须新建原子指标，有些可以在其他类型原子指标的基础上增加修饰词形成衍生指标。

事务型指标：是指对业务过程进行衡量的指标，如近N天支付金额。这类指标需维护原子指标及修饰词，在此基础上创建衍生指标。
存量型指标：是指对实体对象某些状态的统计，对应的时间周期一般为”历史截止当前某个时间“。这类指标需维护原子指标及修饰词，在此基础上创建衍生指标。
1

3）复合指标：建立在原子指标、派生指标之上，通过一定运算规则形成的计算指标集合，常见有以下几种：

比率型：比如xxxCTR、xxx满意度。这种情况下需要创建原子指标，比如创建CTR、满意度等原子指标。
比例型：比如xxx百分比，xxx占比。这种情况下需要创建原子指标，比如创建播放歌曲人数占比。
变化量型：比如xxx指标相对上N天的变化量。这种情况下不不创建原子指标，增加统计方法相关的修饰词，然后在此基础上创建衍生指标，比如上N天变化量的修饰词。
变化率型：比如xxx指标相对上N天的变化率。这种情况需要创建xxx变化率原子指标。
统计型：比如人均、次均，xxx分位数等。这种情况下不创建原子指标，增加统计方法相关的修饰词，在此基础上创建衍生指标。
排名型：一般为TOP_xxx_xxx。这种情况下创建原子指标，比如top_n_支付金额，在此基础上创建衍生指标。 
1

接下来，需要规范指标命名。指标命名规范要遵循两个基本的原则：易懂，就是看到指标的名称，就可以基本判断这个指标归属于哪个业务过程；统一，就是要确保派生指标和它继承的原子指标命名是一致的。 以电商场景指标为例：

所有业务下单跟支付指标，默认以主单为统计口径，不用带“主单”相关字眼，如商城下单次数；当统计口径为“子单”时则需要在命名中标出，如：商城子单下单次数；

所有与人相关指标默认以“注册用户”为统计实体，不需要带“用户”相关字眼，如访问次数；当统计主体为“游客”时则需要在命名中标出，如：游客访问次数；

无指定业务范围的指标默认为平台指标，不需要带“平台”相关字眼，如近30天支付人数。如果有限定业务范围，则需要加上业务名称，如：商城-近30天支付人数；

无指定时间周期的指标默认为“近1天”（但需要保存小时粒度，便于后续下钻），不需要带“时间”相关字眼，如注册人数。如果有限定时间范围，则需要加上时间周期：如：近7天注册人数。
1

综上，完整的命名的规范为：商城（业务板块）+用户（实体）+近7天（统计周期）+新增（业务动作）+子单（类型）+单日（间隔周期）+平均（统计运算规则）+支付金额（原子指标），如：商城-用户近7天新增子单单日平均支付金额（没有的部位可留空，如：商城-汇总支付金额）。

• 指标字段命名规范

指标命名规范同样重要，它能够提高数据仓库的可读性和易维护性，方便用户进行数据查询和分析。以下是数仓中指标字段命名规范的一些通用做法：

命名全部采用小写、字母和数字构成，且只能以字母开头，并且尽量避免使用数字；不允许使用除数字、字母、下划线之外的特殊字符。
命名应采用能够准确反映其中文含义的英文单词或英文单词缩写构成，避免出现英文单词和汉语拼音混用的局面，尽量达到见字知意效果。
命名长度尽量控制在32个字符以内，特殊字段除外。
名称的各部分之间以下划线"_"连接。
实体名称作为前缀。
字段属性的名称尽量保留实体的名称作为前缀，比如"channel_id/渠道编号"。
对于数字类型的字段，应该使用合适的精度和小数位数进行定义，并在字段名中加上相应的单位名称，例如 amount_usd、quantity_kg。
对于表中常用字段，如创建时间、更新时间等，建议采用标准的字段名，例如 created_at、updated_at。
1

此外，需要规范统计口径。当指标主体为实体（名词）：游客、用户、商品等，则只需定义单位为“人/个” 即可。如：游客人数、用户人数、商品个数。当指标为业务动作（动词）：如点击、支付、下单等，单位除定义为“次数” 外，还需考虑跟这个动作关联的实体的单位，如“商品”时需要定义多一个单位“笔数”；为“用户”时则需要定义多一个“人数”等；所以一个下单动作的指标，会有多个不同的统计口径：下单次数、下单人数、下单笔数、下单金额等。总之，在定义指标名时需要详细列出，避免出现“下单数”这样模糊的指标。

• 指标口径规范

指标口径规范是定义和描述指标测量的方式和方法的文档或标准，是为了保证主题域内指标口径一致，无歧义。例如，存款利率的计算方式可能因银行不同而有差异，因此在明确口径规范后才能准确地计算和比较各个银行之间的存款利率。 以下是一些常见的指标口径规范：

定义度量标准：定义每个指标的计算方法和公式，以保证所有人对指标的解释和计算方式达成一致。例如，销售额=销售数量*销售单价。
确定数据源：明确每个指标的数据来源，并对数据的准确性进行验证和验证过程进行说明。例如，销售数量来自订单表，销售单价来自价格表。
设定计算周期：确定每个指标计算的时间点和时间范围，以保证指标的时效性和可比性。例如，月度销售额需要在每月末算出。
选择计算精度：根据业务需求和数据特点，确定指标计算的精度和取舍原则。例如，保留两位小数或者四舍五入取整。
标准化指标名称：使用简洁明了、具有意义的指标名称，并与业务术语相一致，以便于理解和识别。
编写指标说明：编写指标说明文档，详细阐述每个指标的含义、计算方法、数据来源、计算周期等信息，以方便用户查询和理解。
1

接下来，需要确定指标的关联应用和可分析维度。对于使用指标的人（运营、分析师）了解了这个指标的口径定义之后，下一步就是要看指标的数值。因此，在全局的指标字典中，需要标明指标被哪些应用使用，这样方便去对应的数据产品或者报表上查看指标的数值。此外，还应该有指标的可分析维度，方便分析师从不同的维度分析指标的变化趋势。

最后，执行指标的分等级管理。不同等级的指标意味着管理方式不同。业务中存在大量指标，在建立指标中心的过程中，需要将指标区分等级，可以按照以下原则区分等级，来管理指标。

一级指标：数据中台直接产出，核心指标（面向公司高层）、原子指标以及跨部门的派生指标，有明确的定义、流程和负责人。
二级指标：基于中台提供的派生指标，由各业务部门自定通过指标中心生成，没有严格的开发流程，各业务部门根据需要自行创建，但需要遵守命名规范。所有维护管理工作由部门内部负责。
1

不同等级的指标意味着管理方式不同：一级指标，要确保指标按时、保证质量产出，指标创建由中台负责；二级指标，允许业务方自己创建，中台不承诺指标的产出时间和质量。

明确规范定义指标的基本原则后，接下来，我们搭建指标字典。

索引命名规范

索引是关系型数据库中提高查询性能的重要手段，而索引命名规范则可以方便开发人员对索引进行管理和维护。以下是一些常见的索引命名规范：

使用简洁的名称：索引名称应该简单、易于理解、与索引所涉及的列相关，并且具有描述性，可以从名称中快速获得该索引执行的目的和过程。
加上前缀：在命名索引时，可以通过添加前缀对其进行分类或归类。例如，可以使用“idx_”前缀表示索引，“uniq_”前缀表示唯一索引，“fk_”前缀表示外键等，以便于快速区分和查找。
包含列名和表名：索引名称通常应包含所涉及的列名和表名，以便于开发人员快速识别该索引所属的表和所涉及的列。例如，idx_employee_id。
使用驼峰命名法：推荐使用驼峰命名法来命名索引。例如，idx_employee_id。
避免使用特殊字符和空格：建议尽量避免使用特殊字符和空格，因为这些可能会导致问题，例如对SQL语句的解析产生影响。
1

ETL作业命名规范

ETL（抽取、转换和加载）是将源系统数据转换成规范化的数据仓库数据的重要步骤，其命名应该体现其作用和功能，方便管理和维护。以下是一些常见的ETL作业命名规范：

使用简洁明了、具有意义的名称：ETL作业名称应该简短、具有描述性，可以从名称中快速获得该作业执行的目的和过程。
加上前缀：在命名ETL作业时，可以通过添加前缀对其进行分类或归类。例如，可以使用“load_”前缀表示加载作业，“extract_”前缀表示抽取作业，“transform_”前缀表示转换作业等，以便于快速区分和查找。
按层次结构命名：数据仓库通常采用星型或雪花型模式来组织数据。建议按照模式的层次结构来对ETL作业进行命名，以便于理解和识别。
加上时间戳：为了避免出现不同版本的作业混淆或者错误覆盖，可以在作业名称末尾加上时间戳。这样可以追踪每个作业的时间和版本，方便问题追溯和审计。
避免使用特殊字符和空格：命名ETL作业时应尽量避免使用特殊字符和空格，因为这些可能会导致一些问题，例如文件系统不支持特殊字符、SQL语句错误等。
1

代码设计规范

脚本是否有备注、复杂计算逻辑是否有注释释。
任务是否支持多次重跑而输出不变
分区表是否使用分区键过滤并且有有效裁剪。
外连接的过逑条件是否使用正确，例如在左连接的 where 语句存在右表的过滤条件。
关联小表，是否使用/*+ map join * /。
不允许引用别的计算任务临时表。
原则上不允许存在一个任务更新多个目标表。
是否存在笛卡尔积。
禁止在代码里面使用 drop、create、rename 等 DDL 语句。
使用动态分区时，有没有检查分区键值为 NULL 的情况。
对于重要的任务 DQC 质量监控规则是否配置，严禁裸奔。
代码中有没有进行适当的规避数据倾斜语句。
1

层次调用规范

设计模型层次和制定调用规范的目的是：避免烟囱式建设，数据更多的共享，减小重复计算、保持数据一致性等。

ODS->DWD->DWS>ADS禁止反向调用

ods层一般只被dwd层调用，不建议跨层调用；

ads层优先调用dwd和dws层数据，不建议直接抽ods层数据，优先调用dws层；

充分了解业务需求，尽量沉淀常用指标到dwd层、dws层、dim层；

dws层可先建轻度汇总层，避免指标直接从dwd明细层出；

dws层要尽量沉淀出常用指标，避免ads层过度调用dwd层数据；

dws层不宜过深，比如超过10层
1

指标字典

定义：

指标字典是业务数据标准化的基础，目的是对指标进行统一管理，方便共享达成对业务指标的共识，并统一修改和维护。指标字典可以更新在excel或者指标管理平台。如果有足够多的的资源，那么开发指标管理模块可以放在数据管理系统再配合血缘关系，就方便追踪数据流转了。 很多公司喜欢用Excel管理指标，觉得Excel上手容易，编辑比较方便。但是，Excel并不是一个适合指标管理的工具，有这样几个原因：难于共享、缺少权限控制；无法动态更新；指标无法跟数仓的模型动态关联。因此，我们需要搭建一个面向指标的管理平台。 指标字典是基于元数据中心构建的一个指标管理工具，它从元数据中心自动同步数仓的主题域和业务过程，按照规范化定义创建指标。新创建的指标同时会以特定类型的标签，下沉到元数据中心对应的表和字段上，这样在数据地图上就可以搜索到表关联的指标。

指标字典包含哪些内容项 指标字典模板 那么，该如何搭建全局的指标字典呢？

首先，要形成一个全局业务口径一致的指标字典，让使用指标的人，可以通过指标字典，快速了解指标的业务含义和计算过程，不会对指标口径产生歧义。数据中台团队必须要有一个专门负责指标管理的人或者小组（一般不超过3个人），最好是数据产品经理来负责。 构建全局的指标字典分为两个场景：一个是面对一个新的指标需求，如何基于指标系统完成指标开发流程；另外一个是面对已经存在的，混乱的指标现状，如何进行全局梳理。 针对创建新指标，建立评估、审核、上线标准化流程（如图）： 其中，在指标需求评审阶段，需要确定这是不是一个新的指标，并明确它是原子指标还是派生指标。在这个过程中，需要需求方、数据开发、应用开发都参加，目的是要大家达成一致。如果是一个已经存在的指标，直接可以通过设计逻辑模型、发布接口、获取数据；如果是新指标且有开发需求，进行后续业务操作和开发流程。前者交付时间短，后者需要排期，交付时间长。 此流程适用于一级指标，对于二级指标，可以不需要评审，当然开发也是由业务方开发和发布上线。

针对已有指标，需要开展重点梳理与统一工作： 首先，公司以数据产品经理牵头，成立以产品、开发、分析师为核心的一至三人的工作小组，专门负责指标的全局梳理，制定指标梳理计划和目标，与业务方共同制定时间计划； 其次，对于每一个业务线，需要对还在使用的数据报表、数据产品进行盘点，也可以把不常用的报表和指标下线。对于每一个报表和数据产品中涉及的指标，可以按照以下格式进行收集和整理：清晰指标名称、明确业务口径、确定数据来源等，对于口径相同的，应该去除重复，关联的应用应该合并。对于派生指标，要明确指标的统计粒度、修饰词、时间周期以及关联的原子指标。 最后，需要根据指标业务口径，明确指标所属的主题域和业务过程，把整理好的指标按业务线-主题域，录入指标字典（指标平台）。

• 指标体系建设：

指标管理

模型管理

需求变更流程

1：申请需求变更
数据产品经理完成业务方迭代需求对接后，将新的需求录入数据仓库需求模板的迭代需求申请单中。
说明 如果企业具备需求相关管理平台，建议通过平台+数据库形式规范化存储不断迭代的每个需求版本。

2：评审需求变更
原则上需求评审需由数据产品经理发起评审会议来完成，但如果需求迭代内容不多，评审方式可视情况而定选择邮件或现场会议方式，具体视变更内容由变更委员会决定。
评审内容仍为实现需求必须面对的技术可行性、数据可行性、安全与合规要求性展开讨论，如果多方有异议，则必须共同达成一致性解决方案。

3：确认并合并需求
数据产品经理将上一版本定稿的产品需求文档内容，与本次评审定稿的产品需求文档内容进行合并。
如果两个工作日内无异议，则视为需求确认。
1

流程规范

需求提交流程

提出需求
      需求提出人：以文档的形式提出需求（写清楚需求内容、交付物、期望交付日期），发给数仓 Leader。

沟通需求
      数仓 Leader 将需求分配给相关人承接，同时协商好实际交付日期。
      如果需求提出人的交付日期与数仓 Leader 的交付日期不一致，双方需要进一步协商一致。

开发交付
      需求承接人，需按照协商一致的交付日期，按期交付。
1

模型设计流程 ETL开发流程

需求理解
数据探查
程序开发
流程依赖
配置调度
1

上线流程