导读 本文分享主题为数仓Onedata体系建设的方法论。主要内容包括：

全文目录：

1. 方法论体系

2. 数据建模流程工艺

3. 实践案例

4. 心得总结

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

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

出品社区｜DataFun

01/背景

首先来看数仓的方法论体系。

1. 数据仓库

① 数据仓库是什么

先通过一个生活场景中的案例来理解、认识数仓。

例如一家企业是做食品加工进出口业务的，需要采购大米、小麦等食品加工必需的原材料，采购时则需要通过运输至货品集中处进行卸货，并按一定类别分类储存，再通过处理将原材料加工成面粉、米粉等半成品，最终在通过一道加工程序将半成品处理加工为成品进行销售。

在数仓、数据中台、湖仓一体的应用场景下，对外展现数据或提供数据服务时也需要将企业内外部把非结构化或半结构化的数据进行汇总到一个地方，无论是叫ODS（结构化数据）或暂存区，接下来会在数仓基础数据区把数据根据不同的主题域（如客户、产品、交易等）进行分类成明细数据，然后在汇总区依据共性维度把一些公共指标进行加工汇总或关联聚合以保证数据指标的一致性，并减少冗余重复工作量，最后按业务的应用主题（如客户分析、产品分析、风险分析等）进行深度加工汇总，最终对外提供服务（如固定报表、多维分析、对外的dataAPI、算法能力等）。

其实数仓架构与生活场景的案例差不多，主要是对数据做相应的分层，每一层都有不同的作用。

② 数据仓库方法论

数据仓库从方法论角度看，在这个领域中主要分为两种流派，分别由Bill Inmon及Ralph Kimball所倡导。

• Ralph Kimball

基于整个原始数据源之上，通过ODS集成结构化的数据，再建设数据集市，数据集市做相应的数据展现或数据分析应用。

优势在于根据分析应用目的去建设主题分析的速度较快，前期建设成本、门槛低；不足在于经过长期累积，因各数据集市业务数据指标重复建设、口径不一致而导致数据质量的下降，同时治理成本也比较高；

• Bill Inmon

站在整个企业架构之上，汇总企业内外部的全部数据，根据业务属性和业务要求建设统一的数仓模型，在模型内数据覆盖比较广且数据存在相互关联、数据标准是一致的，通过对数据的标准化处理再把数据分发至数据集市做相应的应用。

不足之处在于：首先，前期对建模人员的要求较高、需要站在整个企业架构之上了解企业全部业务；其次，因为覆盖范围比较广，建设成本高和周期较长；

2003年Bill Inmon提出CIF架构，融合了两派方法论，目前大部分企业主要使用的也是CIF体系架构。

2. 数据模型

数据模型在数据仓库中起到非常重要的作用，我们把数仓比作一辆汽车，数据模型就担当了这辆汽车中的发动机角色。

一个数据模型的稳定性、可扩展性、数据模型易用性等，是衡量数据建模水平的关键标准。

① Onedata体系

Onedata体系最初由阿里巴巴提出，最终的实现目标是数据的全局完整、含义一致、避免重复建设、对外提供统一的数据服务，目的是挖掘数据的价值、让数据驱动业务创新。

归结起来，整个Onedata的理念与Bill Inmon的理念、企业架构的思想是一致的。

Onedata的建设是要在底层由业务架构出发来推导、设计数据模型，从数据研发到数据服务，做到数据可管理、可追溯、可规避重复建设。

Onedata中有三个重要的特征：

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

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

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

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

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

02 /数据建模流程工艺

1. Onedata数据模型设计思路

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

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

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

• 需求分析：包括业务需求和数据需求
• 数据源的分析：会产生相应的分析报告
• 现有模型满足度及差异分析：每个行业每个领域中的企业可能会有自己的数据模型产品或行业解决方案，有沉淀的内容，我们的数据模型产品在需求及数据源侧（也就是前面第一、二步的需求分析和数据源分析）做相应的比对和差异分析；
• 概念模型设计、逻辑模型设计、逻辑模型物理化：必不可少的过程；
• 模型实施、模型验证及调优

03 /最佳实践

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

1. 百度展示广告EDW建设

① 项目背景

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

② 建设过程

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

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

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

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

梳理出关键的业务对象后，对其进行了相应的沉淀，并最终得到了关键的数据实体。这些关键的数据实体将近有八九十个，最后对其进行相应的逻辑划分、聚合，最终形成了10大主题域。这10大主题域构成了EDW数仓的基础层，由此之上再进行公共维度的加工形成汇总层，另外针对用户或业务部门的分析需求形成了数据集市应用。

2. 华为数据底座

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

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

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

• 明确数据Owner：来自于哪个业务、哪个流程，需要由明确的业务组织认责。
• 发布数据标准
• 定义数据密级
• 明确数据源：数据需要有可信的数据源（源系统），尽量不要拿二手数据，有失真的风险；
• 数据质量评估：在数据湖中不会对数据做清洗、转换，保证入湖数据质量的达标、可靠；
• 元数据注册：所有数据入湖之前都需要采集元数据，编制数据目录，这样保证入湖的所有数据都是查找、可追溯、可管理的，也就是数据可用、可控，否则就是garbage in, garbage out, 数据湖变成数据沼泽。

3. 银行数据仓库模型设计

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

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

• 自底向上：我们是根据业务部门的需求进行设计；
• 局部覆盖：由于是需求驱动，只能覆盖特定需求；
• 基于现状：基于当前的业务流程、功能现状去构建设计数据模型。

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

• 自顶向下：从顶层规划开始，基于业务流程、业务对象、抽象实体、实体细化去设计模型的；
• 全局覆盖：全面覆盖业务场景，不局限于特定场景或需求；
• 考虑未来：从架构层面梳理，考虑行业通用性。

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

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

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

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

04 /心得总结

• 顶层设计：Onedata体系建设，需要顶层设计，从业务架构推导出数据模型。
• 数据分层：数据仓库中，需要不同的分层，来保证数据模型稳定性，可扩展性和可用性，以便数据模型适应业务场景的变化。
• 规范性：数据模型的设计规范性、数据标准化（命名、值域等）、服务接口。