数仓 Onedata 体系建设方法论

分享嘉宾｜邓成聪 数仓建模专家

编辑整理｜杨文铸 哈尔滨理工大学

出品社区｜DataFun

背景

• Ralph Kimball

• Bill Inmon

• OneID：致力于实现数据的标准与统一
• OneModel：致力于实现实体的统一，让数据融通而非孤岛存在，为精准的用户画像提供基础；
• OneService：致力于实现数据服务的统一，让数据复用而非复制。

3. 企业架构数据仓库的关系

前面Onedata体系中我们提到它是由整个企业架构来推导数据模型，那企业架构和数仓之间到底是什么关系呢？

企业架构稍微有点晦涩难懂，我们打个比方：一个企业的战略可以看作为一个城市的顶层规划或者定位；下一级则是城市的规划，城市规划就可以类比为企业架构，包含业务、应用、数据、技术四大架构。与数据相关的主要就是从业务流程推导业务对象或业务属性，梳理出数据模型中的数据实体。

在整个企业数据架构规划中，不可忽略的一块就是数仓的规划，数仓中有数据模型，数据模型在整个企业数据架构中会落地在数据仓库中，也是数仓的参考模型。

02

数据建模流程工艺

1. Onedata数据模型设计思路

• 建模的依据：整个建模流程中首先是建模的设计依据。上面我们讲建模依据来源于企业架构、业务架构，还有行业最佳实践、企业的应用需求；
• 模型层次划分：有了建模设计依据之后，接下来就是模型层次的划分，每一层用什么样的设计模式。比如最顶层应用层通常使用星型模型或雪花模型；汇总层一般使用星型模型；到基础层一般需要遵循数据三范式，提升数据稳定性和可用性。
• 模型设计思路：接下来就是整个模型的设计思路，设计理念（如统一共享、标准化等）、设计原则（可回溯、稳定性等）、设计策略、设计步骤等等。通过这样的路径产出的数据模型的复用性、稳定性等都会有比较高的提升。

2. 数据仓库数据模型设计流程

数据仓库数据模型的设计包括如下步骤：

• 需求分析：包括业务需求和数据需求

• 数据源的分析：会产生相应的分析报告

• 现有模型满足度及差异分析：每个行业每个领域中的企业可能会有自己的数据模型产品或行业解决方案，有沉淀的内容，我们的数据模型产品在需求及数据源侧（也就是前面第一、二步的需求分析和数据源分析）做相应的比对和差异分析；

• 概念模型设计、逻辑模型设计、逻辑模型物理化：必不可少的过程；

• 模型实施、模型验证及调优

03

接下来举三个例子与大家做交流分享。

1. 百度展示广告EDW建设

① 项目背景

2015年，百度高速发展，每个产品线、事业部都建了自己的数据集市，也发挥了很大的价值。但发展后期发现存在很多问题，烟囱式建设导致业务数据不全，虽然也能通过数据共享拿到数据，但各业务建设时有些共性指标定义不一致、标准不一致。所以启动了一个数据治理项目，但本质上没有解决这个问题。最后启动了EDW建设的项目，希望把企业级所有数据汇总起来加工并对外提供数据应用或数据服务。

②建设过程

在建设数据仓库的过程中，根据企业架构方法论，从顶层业务架构开始梳理，然后是应用架构。

在梳理业务架构时，我们参考了行业领先实践，把业务能力、业务流程、业务活动全部梳理出来后，把每个活动中涉及的业务信息（在华为叫业务对象）也梳理出来。梳理完之后通过业务对象的细化和展开规范化形成了数据的实体，最后把它进一步细化形成逻辑实体，针对数据存储组件形成物理表，最终形成数仓的数据模型。

业务信息（业务对象）的梳理是非常关键的动作，在这里我们可以参考行业领先的实践，在这个项目中主要对标了IAB的信息模型，提炼了关键的业务对象。

广告业务中有很多参与方，包括需求方（DSP）、供应方（媒体等APP对应的SSP），需求方和供应方之间进行交易则需要经过ADX（广告交易服务），针对用户推送个性化的广告则需要DMP（数据管理服务），还有风险管理（如反作弊）以及财务管理等，进而细分梳理出关键的业务对象。

2. 华为数据底座

数据底座最开始是华为提出的，因为华为认为无论是数仓建设还是大数据平台，都是数据管道。最关键的是数据管道里面流淌的数据或数据内容。

在华为做数据底座时做的比较好的地方就是数据入湖，建立了六大数据标准。所有能够获取到的数据都往数据湖汇聚，包括物理入湖和虚拟入湖（在数据量比较少的情况下或者对原系统影响不大的情况下采用了数据虚拟入湖，其实数据最终进入了数据中台中）；

在数据入湖治理方面的六大数据标准：

• 明确数据Owner：来自于哪个业务、哪个流程，需要由明确的业务组织认责。

• 发布数据标准

• 定义数据密级

• 明确数据源：数据需要有可信的数据源（源系统），尽量不要拿二手数据，有失真的风险；

• 数据质量评估：在数据湖中不会对数据做清洗、转换，保证入湖数据质量的达标、可靠；

• 元数据注册：所有数据入湖之前都需要采集元数据，编制数据目录，这样保证入湖的所有数据都是查找、可追溯、可管理的，也就是数据可用、可控，否则就是garbage in, garbage out, 数据湖变成数据沼泽。

金融行业的传统数据模型设计和数据仓库模型设计是存在差异的。

我们在做传统数据模型设计时，主要有以下几点问题：

• 自底向上：我们是根据业务部门的需求进行设计；

• 局部覆盖：由于是需求驱动，只能覆盖特定需求；

• 基于现状：基于当前的业务流程、功能现状去构建设计数据模型。

但是做数仓的时候，主要是以下几点：

• 自顶向下：从顶层规划开始，基于业务流程、业务对象、抽象实体、实体细化去设计模型的；

• 全局覆盖：全面覆盖业务场景，不局限于特定场景或需求；

• 考虑未来：从架构层面梳理，考虑行业通用性。

①优秀案例一（IBM数据仓库模型）

在银行业，IBM BDM的9大主题域分别是当事人（相关方）、产品、协议、事件、地址、位置、分类及渠道、条件、资源项、业务方向。

②优秀案例二（Teradata数据仓库模型）

在银行业，Teradata FS-LDM的10大主题域分别是当事人、产品、协议、事件、区域、渠道、行销活动、资产、财务、内部机构。

• 顶层设计：Onedata体系建设，需要顶层设计，从业务架构推导出数据模型。

• 数据分层：数据仓库中，需要不同的分层，来保证数据模型稳定性，可扩展性和可用性，以便数据模型适应业务场景的变化。

• 规范性：数据模型的设计规范性、数据标准化（命名、值域等）、服务接口。