下载掌阅APP，畅读海量书库
立即打开
小白： 老姜，在搭建数据仓库的过程中，除了需要指定层次结构外，是否还需要遵循一些规范呢？
老姜： 当然，正所谓“没有规矩不成方圆”。图书馆内的图书，只有分门别类存放于指定区域，才能方便读者查找；家中的家具、用品，只有摆放到合理的位置，才能显得整齐有序；日常SQL代码，只有按照一定规范书写，才能提高整体的可读性。同理，数据仓库也有很多规范需要遵循，以便于仓库的标准化、统一化，方便管理及维护。
小白： 明白，那都有哪些需要注意的实战规范呢？
老姜： 数据仓库的规范通常体现在四个方面，分别为设计规范、开发规范、命名规范、流程规范。下面我们逐一介绍。
设计规范指数据仓库的整体的架构设计，其内容主要体现在三个方面，即技术架构规范、分层设计规范、主题设计规范，这三者具有一定的递进关系。
3.1节介绍过数据仓库技术架构的演进之路。那么对于企业而言，在数据仓库建设之初，需要对整体架构进行选型，并在搭建过程中严格执行，作为整体技术架构规范，如图3-7所示。
图3-7 技术架构规范
在技术架构选型确定后，就需要对数据仓库主体分层进行划分，如3.2节所讲。将原始明细数据存储于数据接入层，通过各分层的加工处理，最终输出到贴近业务的数据应用层，如图3-8所示。
图3-8 分层设计规范
如果说分层设计规范是对数据纵向的划分，那么主题设计则是对数据横向的划分。根据业务主题进行切割，不同类型主题数据分门别类进行管理。例如，对于短视频类产品，数据可划分为用户域、消费域、平台域、推荐域、发布器域、直播域、商业化域、竞品域等。
在明确了整体框架设计规范之后，便进入了开发实施阶段。在该阶段，往往会涉及多部门、多成员之间的合作，如果没有一套明确的开发标准，那么代码样式及输出会千差万别，相信这一点是任何一个数据仓库研发人员都不想看到的。
在此背景下，制订一套开发规范是至关重要的。根据侧重点，可将开发规范划分为编码规范、字段类型规范、生命周期规范。
在数据仓库开发的过程中，常会用到多种编辑语言，包括但不限于SQL、Python、Java等，鉴于其中会有很多共性的规范，这里选取数据分析师常用的SQL进行说明，谈谈其中需要注意的规范内容。
代码文件是数据处理的载体，涵盖了数据操作的核心代码。对于代码文件而言，需要遵守一定的约定，保障代码规范且顺利地运行。
· 一个SQL文件尽量仅生成一个目标表，保障一一对应，内容解耦。
· 代码文件名尽量与生成表名一致，便于查找及维护。
· 代码编码格式与执行环境保持一致，以防出现报错。
代码文件头部常用作代码说明，方便不了解内容的研发人员查看，其中涵盖代码的基础信息及日常修改记录。下面分享一种相对通用的代码头部样式以供参考，如图3-9所示。
图3-9 通用的代码头部样式
· 基础信息： 主要包括代码文件的创建人、创建日期、内容描述、表的生命周期、生成目标表名以及依赖的上游表。其中，内容描述需要说明该表的核心作用，所属层级及颗粒度。
· 修改记录： 主要包括该表日常修改的内容，包括增、删、改等操作。其中，需要注意的是，每次更改回溯的周期需要写明。因为在应用的过程中，有时你会发现，虽然表的生命周期很长，但某些字段从某天往前就没有数据了，附上记录有助于日常应用及工作交接。
表在不更改的情况下，一般仅创建一次，虽然低频，但仍需遵循一定的代码撰写规则，如图3-10所示。
图3-10 代码撰写规则
其中有几点规范需要注意。
· Create子句、表注释、表分区语句顶头，表内字段及说明语句缩进4个字符。
· 表内字段名、字段类型、字段说明，需分别对齐。
· 表内每个字段间隔逗号，建议放在字段前方，方便问题排查。
· 列注释、表注释、分区注释需要填写，并且内容需与真实内容一致。
表创建完成后，需要对核心代码进行撰写，鉴于核心代码是表的灵魂，且运行频次较高，因此对代码规范性的要求更为严格。
在撰写核心代码时，建议遵循以下几点原则，如图3-11所示。
图3-11 撰写核心代码的原则
· 功能完整： 保障代码的完整、健壮，这是代码生成的最基本要求。
· 结构清晰： 代码层次清晰，功能解耦，能够快速支持后续内容的增删。
· 效率保障： 充分考虑代码的执行效率，针对大数据量任务，要不断调优。
· 添加注释： 可在代码中增加必要的注释，以增强代码可读性。
· 缩进有序： 按照四个半角字符空格为一个缩进单位，所有缩进都是缩进单位的整数倍。
下面提供一个核心代码规范实例以供参考，如图3-12所示。
图3-12 核心代码规范实例
其中以下几点规范需要注意：
· SQL代码中涉及的关键字、保留字一律大写，其余内容一律小写。
· SELECT中的每个字段正常对应一行，遇到CASE WHEN函数时对应多行。
· 字段分隔逗号放在字段前方。
· 遇到FROM、WHERE、GROUP BY、ORDER BY、HAVING等关键字时，重起一行。
· 嵌套子语句，相对父语句缩进四个空格位。
在开发的过程中，需要对每个字段附上类型，一旦附上了，一般是不准许更改的，因此需要充分考虑可行性和兼容性。
字段类型主要涵盖字符串型、数字型、日期时间型等。
· 字符串型： 字符串类型格式是比较通用的，当字段既有数字也有字符时，需要选择字符串型。同时，固定长度字符串类型选择Char，非固定长度字符串类型选择Varchar，以防出现内容长度溢出的情况。
· 数字型： 整数一般选择Int类型，小数点数字一般选择Float类型，需要注意其精度情况。例如，针对大盘流量PV、UV指标，用户不会出现小数，因此可以设置成Int类型；而人均PV、人均时长等均值类指标，设置成Float格式更为合理。
· 日期时间型： 一般从外部导入的日期，通常是Varchar类型；而数据库自行生成的日期，通常采用Date类型进行存储。
这里有一点需要注意， 同样的字段在不同表中的字段类型需要一致，若出现不同情况，可能会影响下游的关联应用。
案例讲解
A表中的main_pv为Int类型，B表中的main_pv为String类型，在某些环境下，当两张表的main_pv字段发生Join、Union等操作时，会出现类型不一致报错的情况。虽然可以通过CAST等函数进行转化，但这在应用侧是一个成本，建议在设计表的过程中加以解决。
数据表的生命周期，指截至当前表内分区所存储的天数，例如 T +1产出的天级分区表，生命周期为7天，当日仅能看到从昨日往前7日的数据（含昨日）。对于应用者而言，表的生命周期越长越好，然而对于数据仓库设计者，过长的无用周期会导致存储资源的浪费。
一般来说，不同层级的数据表，均有一个参考周期。
· ODS层：6个月以内。
· DWD层：1～3年。
· DWS层：1～3年。
· ADS层：3个月以内。
当然，不同业务场景之间会存在一定差异。
针对ADS层数据的存储周期，可以通过近期访问次数及访问时间跨度的方式进行判断，如果近期访问频次很高且跨度很大，则可以考虑适当延长存储周期。
案例讲解
近3个月该表最早访问时间为3个月前，且访问频次天均10次以上，则可以考虑将生命周期设置在3～6个月，满足用户日常应用。
数据仓库建设的目的仍是为了下游应用，因此，降低下游用户的应用成本是至关重要的。下面这些问题，你可以看看是否遇到过。
· 很多表名非常类似，涉及各个层级的数据，也不知道粒度如何，用起来非常混乱！
· 表内的字段名特别乱，甚至不同表中相同含义字段的命名不一致！
· 任务名与表名差异很大，很难找到表对应的调度任务是哪一个！
以上这些问题，都是由于命名不规范所导致的。那规范的命名又包括哪些方面呢？下面，我们一起来看一下。
表命名，核心原则是“见名知意”，通过规范的标准，降低用户的识别成本。
表命名的通用方式为 [数据分层]_[业务域]_[内容描述]_[刷新周期][存储策略] ，以“搜索业务用户活动行为主题表”为例，如图3-13所示。
图3-13 表命名的通用方式示例
其中，各个部分的命名规范如下。
数据分层在3.2节中有所讲解，对应的命名如图3-14所示。
图3-14 数据分层命名规范
根据业务类型命名，列举几个供参考，如图3-15所示。
图3-15 业务域命名规范
对表的核心内容进行描述，帮助应用者快速识别出表的作用，同样列举几个供参考，如图3-16所示。
图3-16 内容描述命名规范
刷新周期指表的例行更新周期，即刷新频率，如图3-17所示。
图3-17 刷新周期命名规范
存储策略指的是表内每个分区记录的数据范围，例如每个分区记录用户当日的行为数据为增量表，每个分区记录全部用户的画像数据为全量表，如图3-18所示。
图3-18 存储策略命名规范
字段命名作用同表命名作用一致，同样是为了减少应用上的歧义。字段命名需要遵循以下几项原则。
· 字段名需含义清晰，唯一解释，不可出现同名不同义的情况。
· 字段名建议用英文简写，不建议用拼音，更不建议用拼音简写。
· 字段名一律小写，避免出现混乱的情况。
· 字段名各单词间用下画线进行分割。
· 字段名长度不宜过长，建议控制在20个字符以内。
字段命名的通用方式为 [修饰词]_原子指标_[时间修饰] ，以“过去30日内搜索点击次数指标”为例，如图3-19所示。
图3-19 字段命名的通用方式示例
下面，附上各部分的命名规范。
修饰词是对指标场景的描述，例如PV是一个原子指标，那么主页PV、列表页PV、详情页PV就是在PV基础上增加的修饰词，将原子指标包装成一个用于描述特定场景的数据。
原子指标可以理解为指标的内核、业务指标的最小颗粒度，例如PV、UV、人均PV、人均时长等。根据指标的类型，原子指标的命名规范如图3-20所示。
图3-20 原子指标命名规范
大多数情况下，指标描述的是当日的数据表现，但仍有些应用场景，需要记录过去或者未来一段时间的表现情况。例如，过去7日搜索PV、过去第7日搜索PV、未来7日搜索PV、未来第7日搜索PV等。对于这种需要跨度的时间修饰，命名需要遵循一定原则，用以区分过去/未来、 N 日内/第 N 日，如图3-21所示。
图3-21 时间修饰命名规范
在表的生成过程中，一般会用到SQL的内置函数，然而在面对一些复杂逻辑，内置函数无法满足需求时，往往需要自己创建函数，以满足对应的应用场景。为了便于应用及管理，自定义函数命名需要遵循一定规范。
自定义函数命名的通用方式为 [业务域]_udf/udaf/udtf_[内容描述] ，以“城市等级划分函数”为例，如图3-22所示。
图3-22 自定义函数命名的通用方式示例
扫盲
简单介绍一下udf/udaf/udtf的含义。
· udf函数：普通函数，表现为单行输入、单行输出。
· udaf函数：聚合类函数，类似sum()、avg()函数，表现为多行输入、单行输出。
· udtf函数：拆解类函数，类似explode()函数，表现为单行输入、多行输出。
表的生成代码往往需要配置一个调度任务加以完成，这里需要注意，调度任务命名需与表命名一致，建议采用相同的名称，如果已被占用，建议使用表命名作为基准，增加后缀作为任务命名，方便后续查找应用。
上面所介绍的设计规范、开发规范、命名规范，主要针对的是数据仓库建设内容的规范。而流程规范则是在此基础上针对人员之间如何配合制订的规范，主要涵盖需求流程规范、设计流程规范、开发流程规范、测试流程规范、发布流程规范、运维流程规范等。
鉴于不同企业在流程规范上会存在较大差异，这里不再赘述，大家可在工作中不断摸索，探索出一条高效率、低成本、分工明确的配合流程。
本节介绍了数据仓库建设过程中需要遵守的规范内容，虽然不同企业、部门之间存在一定差异，但整体思路是通用的。作为数据分析师，只有了解了其中的规则，才能更好地和数据仓库人员配合，搭建一个有序的数据仓库，为下游数据应用打下坚实的基础。