1.1 主题定义：主题是在较高层次上将企业信息系统中的数据进行综合、归类和分析，利用的抽象概念。每一个主题基本对应一个抽象的概念。每一个主题基本对应一个宏观的分析领域。主题域是对某个主题进行分析后确定的主题边界。为保障这个体系的生命力，主题是需要抽象提炼，并长期维护和更新，但不轻易的变动。在划分主题是，能够覆盖当前的当前所有的业务需求，又能在新业务进入时无影响地被包含当前已有的主题域中和扩展新的数据。

1.2 分析主题（dwm，dm层）是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一种抽象概念，每一个主题基本对应一个宏观的分析领域。在逻辑意义上，，它是对应企业中某一宏观分析领域锁涉及的分析对象。
1.3 业务主题层（dwd层）是面向实际业务进行划分主题的一种方式，比如物流、售后、交易（订单）等业务发生场景，主要在DWD明细层进行划分的一种方式
1.4 应用主题（APP层）面向应用系统、分析系统

表名：【模型层】【主题】【实体名称】【时间、全量周期】

分层：
分层的意义

  1. 清晰数据结构：每一层都有它的作用域和职责，在使用表的时候能更方便地定位和理解。
  2. 减少重复开发：规范数据分层，开发一些通用的中间层数据，能减少极大的重复计算。
  3. 统一数据口径：通过数据分层提供统一的数据出口，统一对外输出的数据口径。
  4. 复杂问题简单化：将一个复杂的任务解成多个步骤来完成，每一层解决特定的问题
  5. image.png

分层的依赖关系图
image.png
原则上只有dwd、app层，可以依赖本层，其它层不可以本层、反向依赖

模型层次 英文名 中文名 层次定义
APP(也有叫DWA) Application 应用数据层 该层级的主要功能是提供差异化的数据服务、满足业务方的需求，支持数据集、风神看板、数据产品、数据服务。
DM Data Market 数据集市层 数据价值化沉淀，面向分析场景和数据产品需求，连接事实表和维度表形成冗余的多维的宽表。可以加工高度汇总层数据。该层次主要功能是加工多维度冗余的宽表（解决复杂的查询）、多角度分析的深度汇总表。针对具体分析项目、临时业务分析需求等，完成多样化数据模型设计，快速应对业务的变化。考虑快速响应和迭代，直接面向业务产品运营同学的需求，对于不确定的业务模型在该层次开发，比如：dau异动分析。
DWM(也有叫DWI、DWA) Data Warehouse Model 汇总数据层(或轻度汇总层) 面向分析主题和业务过程的、统一的数据访问层，所有的基础数据、业务规则和业务实体的基础指标库以及多维模型都在这里统一计算口径、统一建模，大量基础指标库以及多维模型在该层实现。该层级以分析需求为驱动进行模型设计，实现跨业务主题域数据的关联计算或者轻度汇总计算，因此会有大数据量的多表关联汇总计算。封装业务规则（衍生计算），或者轻度汇总，加工原子指标和公共衍生指标，通用的汇总表，较强的共用性。所以很多字段不是来自业务系统，而是根据分析需求和业务场景计算出来得。抽象维度和指标，整合信息，口径收敛。
DWD Data Warehouse Detail 明细数据层 该层的主要功能是基于主题域的划分，面向业务主题、以数据为驱动设计模型，完成数据整合，提供统一的基础数据来源。在该层级保持原有粒度，维度退化，逻辑下沉并封装业务规则，或者轻度汇总，相同实体纵向整合。标准的明细层，屏蔽业务变化，完成数据的清洗、重定义、整合分类功能。
DIM Dimension 通用维度层 该层主要存储简单、静态、代码类的维表，包括从OLTP层抽取转换维表、根据业务或分析需求沉淀一致性维度，归一化维度属性口径。可贯穿被使用于数仓任一层。
ODS Operational Data Store 操作数据层 该层级主要功能是存储从源系统直接获得的数据（数据从数据结构、数据之间的逻辑关系上都与源系统基本保持一致）。实现某些业务系统字段的数据仓库技术处理、少量的基础的数据清洗（比如脏数据过滤、字符集转换、维值处理）、生成增量数据表。依据策略保留历史数据，不直接暴露给应用；外部数仓表同ODS。在这个层次中要描述清楚数据生成的流程图，便于用户了解数据生产的业务背景。需要构建角色、流程、数据的对应关系。该层原则为不做任何处理或尽可能少做处理，保留数据原貌，便于还原、追溯原始数据。

基础数据层（ODS）

  1. 层次名称：基础数据层、贴源数据层
  2. 层次前缀：ODS
  3. 主要作用：贴源数据层，与业务系统同构，依据策略保留历史数据，不直接暴露给应用；外部数仓表同ODS。
  4. 层次边界：不做任何口径的加工，只接入一份数据，上游仅支撑给DWD/DIM。
  5. 设计驱动模式：技术驱动为主
  6. 设计要点：
  • 与业务系统同构
  • 尽可能保留最长时间历史
  • 确定抽取方式，事实表原则上增量抽取。
  • 关注SLA，尽量避免超过半小时作业。
  1. 上游数据：业务系统mysql、kafka、redis
  2. 下游数据：流向DWD层、DIM层，不对外开放。
  3. SLA要求：根据业务和技术需求，在下游依赖SLA之前若干小时。
  4. 示例：

层级：ods
主题：设备主题
表中文名：新增日活表
表英文名：m_device_distinct
库名：growth
分区字段：p_date
抽取周期：日级全量r
外键：无
表说明：一台设备和一个apps确定一条记录。
表负责人：杨国文

4.2 通用维度层（DIM）

  1. 层次名称：通用维度层、维度层、一致性维度层
  2. 层次前缀：DIM
  3. 主要作用：沉淀一致性维度，归一化维度属性口径。
  4. 粒度：面向业务过程和业务实体，粒度相对较灵活。
  5. 设计驱动模式：业务驱动。
  6. 设计要点：
  • 根据ETL加工/分析需求，把通用的一致性维度放入该层。
  • 可以适当考虑分级建设，除去标签类维度，原则上避免大的维度宽表。
  • 可以适当考虑横向拆分，比如冷热拆分，将核心维度放一张表，较少应用的放在扩展表。
  • 这里的维度字段原则上不涉及从事实表中计算出来的衍生字段。
  • 设计思想体现为Kimball维度建模思想。
  1. 上游数据：一般为ODS，例如当标签属性时，也会用到其他层的数据。
  2. 下游数据：除上游依赖层次，可以流向任意层，对外部数仓开放。

  3. SLA要求：根据业务和技术需求，在下游依赖SLA之前若干小时。

    4.3 明细数据层（DWD）

  4. 层次名称：明细数据层、多维明细层

  5. 层次前缀：DWD
  6. 主要作用：面向业务实体，保持原有粒度，维度退化，逻辑下沉并封装业务规则，或者轻度汇总，相同实体纵向整合。标准的明细层，屏蔽业务变化。
  7. 粒度：原则上基础明细层粒度相同，特殊情况下可以轻度粒度汇总。
  8. 设计驱动模式：业务驱动
  9. 设计要点：
  • 保持原有粒度，依据下游共性需求，形成业务规则封装的衍生字段。
  • 纵向整合，将同样业务逻辑的表union到一起。
  • 从json中解析通用字段。
  • 尽可能的屏蔽底层业务变化。
  • 根据情况拆分&合并进行重组，避免大宽表。
  • 设计思想体现为日志类数据为Kimball维度建模思想，业务类体现为inmon降范式建模思想。
  1. 上游数据：ODS、DWD、DIM、可以层次自依赖
  2. 下游数据：流向DWM、DM，对外部数仓开放。

  3. SLA要求：根据业务和技术需求，在下游依赖SLA之前若干小时。

    4.4 汇总数据层（DWM）

  4. 层次名称：汇总数据层、数据汇总层、轻度汇总层

  5. 层次前缀：DWM
  6. 主要作用：面向业务过程，封装业务规则（衍生计算），或者轻度汇总，加工原子指标和公共衍生指标，通用的汇总表，较强的共用性。所以很多字段不是来自业务系统，而是根据分析需求和业务场景计算出来得。抽象维度和指标，整合信息，口径收敛。
  7. 粒度：面向业务过程的通用粒度。
  8. 设计驱动模式：业务驱动+需求驱动。
  9. 设计要点：
  • 根据业务规则，生成衍生字段；
  • 根据分析需求，形成轻度汇总数据
  • 不跨域
  • 不直接被风神等dashboard引用
  • 设计思想体现为Kimball&inmon融合思想
  1. 上游数据：DWD、DIM
  2. 下游数据：流向DWM、DM，对外部数仓开放。

  3. SLA要求：根据业务和技术需求，在下游依赖SLA之前若干小时。

    4.5 数据集市层（DM）

  4. 层次名称：数据集市层、多维分析层

  5. 层次前缀：DM
  6. 主要作用：数据价值化沉淀，面向分析场景和数据产品需求，连接事实表和维度表形成冗余的多维的宽表。
  7. 粒度：面向分析实体，相对粒度较粗，但也有事实明细表通过属性衍生形成的大宽表。
  8. 设计驱动模式：需求驱动。
  9. 设计要点：
  • 根据分析需求/数据产品来驱动建设；
  • 数据可以是跨数据域，也可以单数据域。
  • 维度可以适当冗余。
  • 不应有大量逻辑计算，以简单left join逻辑为主。
  • 设计思想体现为宽表建模思想。
  1. 上游数据：DWM、DWD、DIM，避免层次自依赖。
  2. 下游数据：不流向对SLA要求高的APP层（面向interface接口层），可以流向风神数据集的app层，应用于分析和数据产品，不对外部数仓开放。

  3. SLA要求：根据业务和技术需求，在下游依赖SLA之前若干小时。

    4.6 应用数据层（APP）

  4. 层次名称：应用数据层、分析数据层、产品应用层

  5. 层次前缀：APP
  6. 主要作用：该层级的主要功能是提供差异化的数据服务、满足业务方的需求，支持数据集、风神看板、数据产品、数据服务。
  7. 粒度：依据分析需求或产品需求来确定。
  8. 设计驱动模式：需求驱动。
  9. 设计要点：
  • 依据分析数据、数据产品或数据服务的需求驱动建设。
  • 尽可能的做薄，通用逻辑下沉到其它底层。
  • 个性化应用，数据表裁剪。
  1. 上游数据：
  • 接口类型数据：依赖DWD、DWM、DIM，考虑SLA，重新拼接数据。
  • 分析型BI数据：依赖DM、（DIM），考虑分析维度和范围，尽可能的提高数据集中度。
  1. 下游数据：流向数据服务接口、风神数据集，对外部数仓开放。
  2. SLA要求：根据业务需求，一般在用户上班查询报表之前，或者早上查询昨天指标之前。

库表规范

5.1 库规范

  1. 在保持合理规模和灵活性的情况下，尽量减少库的数量，保持合理的粒度能减少库的管理成本和资源的浪费。
  2. 一个库只能属于一个产品线或者一个业务域，其它具体情况各产品线可根据情况酌情处理。
  3. 库命名：【部门】+【产品线/业务域】+【业务名称】，其中部门是产品线或者业务域所在的部门，业务名称是为了区分同一个产品线下可能会有不同的业务，用产品线下的细分。
  4. 示例：电商库命名：

ecom：电商标准化数仓库
dm_temai：公共调试库（建议）
待迁移的库：dm_temai 、 ecom_ods、ecom_dwd、ecom_bi、ecom_dwa、ecom_app、ecom_bi、ecom_dim
懂车帝库名：懂车帝数据仓库开发规范V1.0 见6.0

  1. 创建库建议在coral数据地图https://data.bytedance.net/coral的库表管理——DB管理中操作。

    5.2 Hive表规范

    当前已支持建表规范自动化检查，详情参考 你与数仓建设规范之间，还差一个“它”

  2. 基本要求

在命名过程中首先建立统一的中英文词库，在翻译过程中，先到词库中查找相应的单词缩写或者词根，然后根据表名和字段名的命名规则进行命名。表名和字段名在用词、词缩写方式上都应保持一致，避免出现同一词有多种缩写的情况。同时表的命名要尽可能从名称上体现这个表的核心属性。

  1. 长度规范：整个表名/字段名的字符长度建议不超过64；每个单词长度建议不超过10个字符，超过需要对长单词缩写。
  2. 拼写规范：只能使用小写英文单词及其缩写，下划线（“_”)，和阿拉伯数字，尽量不要使用阿拉伯数字，建议不使用拼音或者拼音的简写，业务约定俗成的除外，禁止使用大写字母。优先使用词根。
  3. 分隔规范：采用下划线命名法，所有独立的单词都必须使用下划线（“_”)分隔。
  4. 表意要求：表名应尽量能望文生义，反映表本身的含义，建议不使用类似，a，b，c，1，2，3等无意义的标名称。
  5. 区分要求：同一个表内有性质比较相近的字段时，需要明确区别，比如发货时间和收货时间，不能使用time1和time2。谨慎在字段里使用new表达某个新的含义，新旧对比不具备可扩展性，尽量取个更清晰的名字，但类似新老客逻辑可以使用new来表达，也可以考虑first/last这种表达方法，last表达最新的表示含义。
  6. 单词缩写

采用业内通用/前缀缩写法为主，去除元音法为辅的规则。对于两个或多个单词构成的组合单词，可以直接组合各单词首字母。

  1. 通用缩写法：一般常用的缩写，例如organization->org。
  2. 前缀缩写法：视情况保留前3～6个字母，一般标准是保证结尾为第二个接元音的辅音，例如service->serv，transaction->trans。
  3. 去除元音法：只保留若干个重要辅音，例如count->cnt，control->ctrl。
  4. 首字母缩写法：直接使用各单词首字母缩写，例如daily active user->dau；也可以多字母拼接，例如user cnt->ucnt。
  5. 词根字典

分层命名规范
一般以层级名称为前缀。中间加若干必须的关键词，若干可选关键词，例如主题、业务域、粒度、刷新周期、存储形态等。

电商分层命名规范示例：

粒度：粒度不建议超过3个，超过3个可以截取重要的。
规范：[]为强制字段，（）为可选自选。
APP层命名规范:app分析域|业务域[实体说明][刷新周期][存储形态]
示例：app_thunder_live_author_info_df（直播间达人_粒度的全量信息表）

DM层命名规范:[dm]分析域(粒度)[实体说明]_[刷新周期][存储形态]
示例：dm_author_order_stats_df（电商作者订单统计表）

DWM层命名规范:[dwm]分析域(粒度)[实体说明]_[刷新周期][存储形态]
示例：dwm_payment_bill_di（结算账单表）

DWD层命名规范:[dwd]业务域(粒度)[实体说明]_[刷新周期][存储形态]
示例：dwd_flow_event_di（流量事件明细表）

DIM层命名规范:[dim]分析域|业务域(粒度)[实体说明]_[刷新周期][存储形态]
示例：dim_author_hotsoon_info_df（火山作者信息表）

ODS层命名规范:
【国内】[ods][数据库名][表名]_(upload)

【国际化】[ods][数据库名][表名]机房

示例：ods_smart_orderdb_t_order_refund（订单退款表）ods_smart_orderdb_t_order_refund_us（订单退款表北美机房）

表名（redis）：用psm命名，”.”变成””【国内】[ods][psm修正]

【国际化】[ods][psm修正][机房]

示例：toutiao.redis.alliance_item->ods_toutiao_redis_alliance_item

套件(lark)分层命名规范示例：

ODS层： {层级}{数据来源}{数据库db}{源表名}{分区+抽取方式}；数据来源：log(日志)、 kafka 、 binlog、mdb(mysql)等消息来源；ODS表结构与源业务数据结构同构
DWD层：事实表：{层级} fact{业务缩写}{表内容} {分区+抽取方式}
DIM层：维表：dim{业务缩写}{表内容}{分区+抽取方式}
DWI层/DWM层：{层级}{主题}{表内容}{分区} {分区+抽取方式}
DWA层：{层级}{数据产品/应用}{表内容}{分区+抽取方式}
视图命名规范:

电商命名规范：[主表名]view
数据BP视图命名规范：[模型层级][主题][实体名称][刷新周期+增量(i)/全量(f)][统计周期]_view
懂车帝视图命名规范：[模型层级][主题][实体名称][刷新周期+增量(i)/全量(f)][统计周期]_view
注意：不建议大规模使用视图
临时表命名规范:[tmp][表名]。

with表：with[主表名][两位数字] with_dvc_device_location_01

upload表一般不建议入仓

表名后缀

info一般描述基础维度表。

dict一般描述字典表。

detail一般描述明细表。

extend一般描述明细扩展表，配对使用，detail为核心明细表，extend为同粒度扩展的事实/维度。

profile一般描述画像表。

upload一般描述手工维护表。

抽取方式：f（全量）, i（增量）。

刷新周期：d（天）, w（周）, m（月）, q（季度）, y（年）。

不建议作为标准使用：

stats：本身含义为统计，数据仓大部分都是统计，所以不具备描述特性，有的规范建议为宽表，可以谨慎使用宽表场景。
all：谨慎添加，因为all是比较而言，很可能你写了一个all，后面又加工一个更全的表，之前表的意义就不准确。
dict：之前描述从业务数据库同步的全量快照表，仅限于从mysql数据库对抽到ods层的表。不建议表达抽取模式含义。
建表检查

数据表命名是否满足规范要求。
数据表的中文名称是否完善。
建表语句须显示定义partition，文件格式，表的comment，字段的comment等信息，保证表含义及字段含义描述信息完整。其中comment信息不允许为空
数据表的分区是否符合规范。
数据表需确认是否是在线表，如是临时表和测试表，不要选择在线表。
建议临时表/测试表不要在数仓主库创建，在其它库创建。
数据表的描述信息是否完善，有必要的使用背景和使用注意事项的描述。
数据表的层级、业务域、产品线、主题是否完善。
数据表的字段类型是否合适。
数据表的字段描述是否完善。
安全与权限：每个字段的数据安全平台推荐标签是否合适，目前选择性填写，后续根据数据平台对安全性的要求标准计划性填写。