数据仓库架构，数据仓库是什么？

「起始篇」

大家在做数据开发（数仓）的过程中有没有思考过下面两个问题：

一、为什么要做数据仓库？

二、做数据仓库能为公司带来什么价值？

在聊之前先跟说一下在数仓行业能一些术语，以便后续大家在阅读过程中容易理解。也同时工作当中同事闲聊提专业术语尴尬场面（联想起刚刚入数仓行业面试官提起各种术语，但有些是面试官自己的理解）。

总结一句：叫什么有的时候并不重要，重要的是通俗易懂，见字见意即可。

一、为什么要做数据仓库？

（图1）

大家看了（图1）发现理想很丰满，现实很骨感。上图反应其实是非常普遍的一种现象。从数据的角度来看就是各个部门数据不能互通、相互独立，形成数据孤堡（各自为政）。久而久之就会让需要办理业务（需求方）的人哀声道怨（俗称：“跑断腿”）。

（图2）

为了彻底解决“数据孤堡”问题，数据仓库解决方案应运而生。一站式解决“跑断腿”问题（但想要彻底解决是一个漫长的过程）。

二、做数据仓库能为公司带来什么价值？

数据仓库价值可分为两大类来看，一类是业务侧，一类是技术侧（数据将是公司未来最核心的资产，得数据者得）。

1、业务侧

1.1、数据获取、运算成本，需要同步不同系统数据和数据运算。

1.2、避免查看数据，需要在不同系统之间来回登录查看。

1.3、数据驱动业务，如：标签平台、营销平台、推荐系统、AB实验平台、用户画像中心、AB实验平台、数据挖掘等等。

2、技术侧

2.1、数据资产统一管理，避免企业内部各个烟囱式开发（各部门都成立数据组）。大大降低企业数据资产成本，如：开发人员、服务器等。

2.2、数据统一形成规范化、标准化、服务化；为企业降本增效。

2.3、统一数据产品，提供面向不同对象的数据产品，如：Ad-Hoc（即席查询、报表平台、分析平台）

三、让数据产生价值才是王道

（图3）

数据部门存在的意义就是让数据产生价值，让数据数据价值最大化。

「方法论篇」

构建数据仓库目前在业界已经有非常成熟的方法论，方法论可分为两大派系。分别是：

比尔·恩门（Bill Inmon）：自上而下（DWDM）方式

拉尔夫·金博尔（Ralph Kimball）：自下而上（DMDW）的方式

为了更好的理解这两套方法论，本文从实际业务场景实践进行讨论。

• 数据仓库特征

1、主题性

主题是一个抽象的概念，是在较高层次将企业信息系统的数据综合、归类并进行分析利用的抽象。每一个主题对应一个宏观的分析领域

2、集成性

数据仓库通常是结合多个异种数据源构成，异种数据源可能包含数据库、文本、Excel等

3、时变性

数据仓库大多数是保留历史数据。都含有时间属性，反应数据历史变化的

4、易失性

数据仓库数据通常只有两种操作：数据载入和数据查询，在任意时间点查看数据是保持没有变化

• 自上而下构建数仓

Bill Inmon的模型从流程上看是自上而下的，即从分散异构的数据源->数据仓库->数据集市。
Bill Inmon流程类似瀑布式开发。需要对源数据进行数据探查来确定数据是否符合预期。其次，明确数据清理规则通过ETL中的Stage将数据转化到DW层。

（图1）

实践场景：在实际工作中当你对业务不太熟悉的情况下，可以对业务进行分析了解，根据业务按3NF方式来进行实施。

• 自下而上构建数仓

Ralph Kimball的模型从流程是自下而上的，即从数据集市->数据仓库-> 分散异构的数据源。
Ralph Kimball流程快速交付、敏捷迭代，不会对数据仓库架构做过多复杂的设计，在变换莫测的互联网行业，这种架构方式逐渐成为一种主流范式。

（图2）

实践场景：在实际工作中，当你需要快速构建数据仓库，但又对业务不太熟悉的情况下，可以根据业务需求按维度建模方式来进行实施。

• 2345数仓构建实践

根据公司现状情况，想采用基于自下而上方式（需求应用）构建数据仓库。但是考虑到没有足够的人力、时间且避免反复性的同步数据问题。就直接采用混合模式来构建数据仓库（注：最开始是没有DWS层）。

（图3）

实践场景：两种方法论各取所长且根据公司现状来进行分析考虑。（有时间可以单独开一篇来聊一聊2345数仓演进史）

• 总结

两种方法论各有所长，但是具体实践应用需要根据企业的现状来进行实施。比如：

互联网行业采用自下而上构建比较符合公司发展需要，因为有些APP就是需要快迭代试水，一方面是想根据数据分析是否符合市场需要，另一方面是想基于数据迭代优化产品（业务流程、APP使用习惯）。因为有很多APP还没上线几个月就下线了。

传统行业已经有非常成熟的数据模型（金融行业），比较适合采用自上而下的方式。因为已经有成熟的模型，只需要对数据进行探查然后构建数仓。

思考：构建数仓的本质都是解决供需关系，只有很好的理解公司战略、产品发展、业务需求才构建更好的数据仓库。

「分层篇」

数仓分层是数仓架构中是非常重要的一部分，为什么说是非常重要的一个部分呢？

主要原因如下几点：

• 清晰明确分层职能边界：每层都有对应的职能和边界，数据应用时方便理解和定位。
• 减少重复开发：合理的数据分层，能够避免数据应用（表）重复开发、运算、存储等。
• 统一数据出口：通过分层明确数据统一服务（输出），避免数据出现二议问题。
• 复杂问题简单化：将复杂的任务分解成多个步骤来完成，每一层解决特定的问题。

1、数仓模型分层

（图1）

数仓分层整体可分为三层，分别是：ODS、DW、DM层，只是在实施过程中有些分层不是核心部分则省略了。如：BUFFER、TEMP层，业务有些层只是临时过渡的数据层，不对外提供数据服务或功能说明。

注：有时候不必过度注重层命名，只有明确层的职能边界即可，无需注重叫什么，为什么大家都喜欢参考阿里分层命名？答案是因为分层职能达成共识、减少沟通过程中分层理解、沟通成本。

2、数仓分层定义

2.1、数据缓冲阶段层（Data Buffer Stage Layer）

描述： 源数据采集临时过渡，存储业务表数据有更新、删除操作 和 用户行为日志非结构化数据。为增加数据识别度分存储策略、更新周期、数据来源。

2.2、操作数据存储层（Operational Data Store Layer）

描述： 存放企业接入的最原始的数据，是其他下游层数据的源数据。为增加数据识别度分存储策略、更新周期、数据来源。

2.3、公共维度数据层（Public Dimension Data Layer）

描述： 用于各种维度模型的存储，基于维度建模构建全域一致性维度，采用宽表设计的原则。

2.4、数据仓库明细层（Data Warehouse Detail Layer ）

描述： 明细数据层是按贴源的建模方式，分数据域存储最明细的数据，以适应业务快速发展和变化带来的横向扩展，并保障数据的可回溯。统一的数据存储、命名规则、有限的数据扩展，并按规则要求进行清洗。允许数据的扩展清洗，为使用方便从次层开始提供敏感数据的加密、脱敏、MD5三列。

2.5、数据仓库汇总层（Data Warehouse Summary Layer）

描述： 基于分析的主题对象作为建模驱动，分业务主题域的数据宽表处理及轻度汇总，减少业务使用上的关联，为重度汇总层或应用服务提供相对稳定的数据模型。也通过对通用需求得沉淀，建立易用的数据模型，提升开发效率，节约计算资源。

2.6、应用数据存储层（Application Data Store Layer）

描述： 根据数据应用需求，跨主题域集成、汇总、扩展衍生及根据需要的多粒度的重度汇总数据，建立准确、易用、统一指标体系与口径。

2.7、临时数据处理层（Temporary Data Processing Layer）

描述： 存放数仓各层数据运算处理临时会话表数据，具体临时表数据根据数据处理需要决定。方便统一管理临时表数据的生命周期。

总结

数仓分层设计，在一定的程度上需要通过表命名来体现，本文的核心在于讲解数据分层职能和边界，后面会有单独的文章来分享数仓模型设计和数仓命名规范。

「命名篇」

数仓中为什么要在数据开发过程中强调遵守数仓开发命名规范呢？

主要原因如下几点：

a、养成良好的编程习惯

b、写出清楚、易懂、易维护的程序代码

c、提高代码质量与生产率

d、减少编码中的不必要的错误

1、库命名规范

2、表命名规范

• 命名全部采用小写字母和数字构成，只能以字母开头，并且尽量避免使用数字。
• 命名应采用能够准确反映其中文含义的英文单词或英文单词缩写构成，避免出现英文单词和汉语拼音混用的局面。
• 命名长度尽量控制在30个字符以内，考虑可读性、易懂性、规范性；如果超过30个字符，尽量把长单词转换成缩略词。
• 名称的各部分之间以"_"(下划线)拼接。
• 数据域、主题域命名统一管理
• 缩略词请统一参考【字典库】
• 【禁止】禁止缩写英文单词的首字母的元音

3、离线模型表

3.1、BUF层表命名规范

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

3.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）

3.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）

3.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）。

3.5、ADS层表命名规范

表名规范：ads_应用类型_业务主题_业务描述_统计周期_装载周期表名示例：ads.ads_rpt_channel_user_1d_d规范说明：- 存储库名：ads- 应用类型：固定报表、分析报表、标签系统、用户画像、数据接口- 业务主题：看板、驾驶仓、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）

3.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）

3.7、TEMP层表命名规范

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

4、字段命名规范

通用规范

• 命名全部采用小写、字母和数字构成，且只能以字母开头，并且尽量避免使用数字；不允许使用除数字、字母、下划线之外的特殊字符
• 命名应采用能够准确反映其中文含义的英文单词或英文单词缩写构成，避免出现英文单词和汉语拼音混用的局面，尽量达到见字知意效果。
• 命名长度尽量控制在30个字符以内，特殊字段除外
• 名称的各部分之间以"_"(下划线)连接
• 约定俗成的业务缩略词，统一参考【字典库】
• 实体名称作为前缀
• 字段属性的名称尽量保留实体的名称作为前缀，比如"channel_id/渠道编号"
• 【禁止】除ods层，不能使用"id/name/title"的无实体的名称；无实体含义的自增id除外
• 实体编号/名称带标识/名称(id/name)为强制规范，如country_id,country_name; 不能以country命名 对于编号做为标识符的属性/列，一般统一命名为“××编号”的属性/列，后缀应是id，如"渠道编号/channel_id"等；另外有些已经习惯了的叫法，比如uid，我们不用user_id，但这种情况不多，如果遇到需要单独提出来交组内统一批准;
• 正例：city_id, city_name, country_id, country_name, province_id, province_name, province_short_name, city_level(公共城市维度表)
• 反例：id,name,country(公共城市维度表)

常用字段规范