维度建模简言

什么是建模

建模的本质是通过数仓建模完成对复杂业务过程的抽象，清晰完整准确的描述业务场景。（建模的四要素：一个过程(抽象)和三个目标(清晰、准确、完整)。）

抽象：是指从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。通过抽象我们可以屏蔽繁琐的底层细节，聚焦业务本质，同时提升模型的稳定性，减少业务系统变更带来的冲击。

清晰：清晰是指模型信息必须是清楚、明了有条理的；通过抽象，我们可以将繁杂无章的数据进行归纳总结，以结构化的方式清晰的描述业务。

准确：准确是指模型表达的语义和用户理解的语义是一致的；通过理清业务关系，明确统一业务概念，就可以对业务活动进行准确的描述。

完整：完整是指业务信息必须是完整的，没有信息丢失的；信息丢失会造成业务描述的不完整，最终导致无法满足业务诉求。

模型的好处

质量: 通过数据集成和一致性建设，提升数据指标的一致性及及时性

效率：提升计算、存储、查询效率，提升用户体验

成本：减少不必要的数据冗余、提升模型复用度，降低存储、计算以及维护开发、降低成本

扩展：屏蔽业务及上游系统的变更影响，能灵活快速兼容业务变更以及支撑新业务

建模的方法

范式建模(Normal Forms)：符合数据库规范化设计的数据模型，强调模型的规范性，减少数据冗余，增强一致性，目前有1NF~6NF，大部分场景要求达到3NF。

维度建模：从便于分析的角度，按照维度、事实的形式来构建数据模型，主要以星型模式来展现。

维度建模

1. 基本概念

数据域：从业务的角度，对数据进行总体的归类和划分，形成的有边界的数据范围。面向业务分析，将业务过程或者维度进行抽象的集合。

业务过程：业务操作活动或事件，如下单、支付、退款等。业务过程一般是一个不可拆分的事务行为事件。

维度：是观察事物的视角或角度，包含与业务过程度量事件有关的环境信息。它们用于描述与“谁、什么、哪里、何时、如何、为什么”有关的事件。有时候实体对象也可以是维度。

事实：即度量。基于某一个业务活动事件下的规格、指数及度量标准，一般是数值类型。指标一般具有明确的业务含义的名词，如支付金额，用户数等

维度使用主键标识，主键分两种：代理键和自然键

1. 为啥选择维度建模（优缺点）

1. 优点

• 模型简单易理解：维度建模通过事实表和维度表的构建，将数据仓库中的数据以直观、易于理解的方式组织起来。事实表记录了业务过程中的度量值和事件，如销售额、库存变动等，而维度表则提供了描述这些度量值和事件的环境和上下文，如时间、地点、产品等。这种模型结构使得数据分析师和业务人员能够更容易地理解和解释数据。

• 可扩展性好：维度建模具有非常好的可扩展性，能够容纳不可预知的新数据源和新的设计决策。在维度建模中，维度表可以随时添加或修改，而不会对整个数据仓库的结构造成太大的影响。

• 支持高效的数据分析：维度建模为数据分析提供了高效的数据组织方式。通过事实表和维度表的关联查询，可以轻松地实现多维度的数据分析和挖掘。同时，维度建模还支持复杂的数据聚合和计算操作，使得数据分析师能够更深入地挖掘数据背后的规律和趋势。

• 可解释性强-标准框架：数据仓库工具书，定义了业界广泛理解的概念。新员工可以快速的掌握数仓的结构，不需要熟悉具体的业务系统数据。工程师和分析师对事实、维度、粒度这些概念都比较了解，可以促进协作。维度建模通过直观的维度和度量，使得数据分析师能够更方便地理解和解释数据的意义。在数据分析过程中，分析师可以根据业务需求选择不同的维度和度量进行组合和分析，从而得出有价值的业务洞察。

• 快速的响应业务：面向分析构建的，每次不需要编写冗长的SQL，查询大宽表，减少join，方便分析人员和业务人员（不太懂技术，不会写复杂SQL）使用，能快速的响应业务需求。

• 性能优化：维度建模通过合理的维度设计和规范化，能够显著提高查询性能和数据压缩比。维度表通常包含大量的数据，但这些数据是按照一定的层次和关系组织的，因此在查询时可以利用索引、分区等技术来优化查询性能。

• 降低ETL负担：维度建模简化了数据的结构和关系，因此在ETL（Extract, Transform, Load）过程中可以减少数据的转换和整合工作量。在ETL过程中，可以将源数据按照维度建模的要求进行预处理和转换，然后加载到数据仓库中。由于维度建模的数据结构相对简单且规范，因此可以降低ETL过程的复杂性和错误率。

1. 缺点

• 数据冗余：维度建模可能导致数据冗余。由于维度表通常包含了多个维度级别的详细信息，比如省、市、县等都放在一起，以及事实表与维度表之间的多对多关系，这可能导致相同的数据在多个表中重复存储。在大数据环境下，这种冗余可能会显著增加存储成本，并影响数据的一致性管理。

• 数据不一致性：由于数据冗余和多个数据源的存在，维度建模中可能会出现数据不一致的问题。例如，当事实表和维度表中的数据更新不同步时，可能会导致查询结果的不准确。为了解决这个问题，需要定期执行数据清洗和一致性检查，但这会增加额外的维护成本。还有一致性维度发生变化，每个主题表都要同步相关维度，对模型冲击比较大，相比范式建模扩展性不好。

• 难以反向推导：维度建模通常侧重于优化查询性能和分析需求，而可能忽略了数据的原始结构和关系。这导致在需要反向推导或理解数据原始状态时遇到困难。一旦模型设计有误或需要调整，可能需要重新加载和处理大量数据，这既耗时又可能影响业务系统的正常运行。

• 灵活性和可扩展性受限：维度建模在设计之初就需要明确数据的维度和事实，这限制了模型的灵活性和可扩展性。当业务需求发生变化时，可能需要重新设计维度表或事实表，这会增加维护成本并可能影响数据仓库的性能和稳定性。

• 对业务变化的适应性差：当业务逻辑发生变化时，维度建模可能需要重新进行维度的定义和数据的预处理。这可能导致大量的工作量和数据冗余，同时也难以保证数据来源的一致性和完整性。

• 如果只是依靠单纯的维度建模， 不能保证数据来源的一致性和准确性，而且在数据仓库的底层，不是特别适用于维度建模的方法。在建设数据仓库的过程中，明细层和集市层分别采用不同的建模方法，比如：明细层采用传统的三范式关系模型：将业务过程描述清楚，将源数据（即业务系统）中隐含的、有歧义的概念进行清晰化。此层灵活地表达业务过程，要保证数据一致性、唯一性、正确性，以尽量少的代价与源数据保持数据同步。（面向技术人员）集市层采用维度模型。集市层是按照业务主题、分主题构建出来的、面向特定部门或人员的数据集合，该层次的数据模型会开放给业务人员使用，进行数据挖掘及业务分析。（面向不懂技术的业务人员，需要简单易理解）

1. 维度建模-星型模型

星型模型VS雪花模型，根据事实表和维度表之间的关系，我们将常见的模型分为星型模型和雪花模型。星型模型更适用于做指标分析，而雪花模型更适用于做维度分析。

	星型模型	雪花模型
概念	当所有的维度表都是和事实表直接相连的时候，整个图形看上去就像是一个星星，我们称之为星型模型。	当有多个维度表没有直接和事实表相连，而是通过其它的维度表，间接的连接在事实表上，其图形就像是一个雪花，因此我们称之为雪花模型，雪花模型的优点是减少了数据冗余，在办进行数据统计或分析的时候，需要和其他的表进行关联
图
查询速度	快有数据的冗余，很多的统计情况下，不需要和外表关联进行查询和数据分析，因此效率相对较高。	慢在分析数据的时候，需要join的表⽐较多所以其性能并不⼀定⽐星型模型⾼。
冗余度	高星型架构是⼀种⾮正规化的结构，多维数据集的每⼀个维度都直接与事实表相连接，不存在渐变维度，所以数据有⼀点的冗余。如在地域维度表中，存在国家 A 省 B 的城市 C 以及国家 A 省 B 的城市 D 两条记录，那么国家 A 和省 B 的信息分别存储了两次，即存在冗余	低它对星型模型的维表进⼀步层次化，原有的各维表可能被扩展为⼩的事实表，形成⼀些局部的 "层次 " 表，去重冗余。如将地域维表分解为国家，省份，城市等维表。
可读性	容易	差
表数量	少	多

1. 维度建模-维度

1. 维度之缓慢变化维

什么是缓慢变化维：随着业务的发展，维度表中的属性会随着业务的发展而变化，但变化的频率一般比较慢，故称为缓慢变化维。

处理缓慢变化维的方法：a直接覆盖更新，b增加有效期字段记录属性变化，c全量分区快照。

1. 维度层次

1）固定深度的层次

层次已固定的维度属性，例如右侧的日期维度，日、月，季度，年。处理方案：采用列打平的方式来设计

2）可变深度的层次

层次不固定的维度属性，

例如物流业务线的组织架构，不仅层次不一致，而且会在某一个层次中间和末尾增加一层。

处理方案：

1.采用类似固定深度层次的方案，提前预留足够的列打平设计。

2.采用递归父子关系方式，同时保存每个叶子节点到各个层次的关系和深度值。

1. 维度建模-事实

1. 事实的分类

可加型事实： 可以按维度进行聚合，例如金额、件数

半可加型事实：仅在特定的维度下有含义，例如账户余额

不可加型事实：不具备可加性，例如比率值

1. 事实表的分类

事务事实表、周期快照事实表、累计快照事实表

1、事务事实：记录的事务操作过程的事实，最原子的数据，粒度通常是每个事务记录一条记录，只有当天数据才会进入当天的事实表中，相当于每个分区里面都是每天的数据。

id	name	regist_time	dt
100356	张XX	2021-10-01 08:02:10	20211001
200389	李xxx	2021-10-02 11:09:20	20211002

2、周期快照事实表

具有规律性的、可预见的时间间隔来记录事实，用来观察在间隔周期内的度量，时间间隔如每天、每月、每年等，粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表。

id	order_cnt	user_cnt	dt
130000356	32	28	20211001
224000389	12	12	20211002

3、累积快照事实表

适合流水线过程中的已明确关键里程信息或已建立好的可预测的工作流，不存储发生的每一个事务信息，累积事实表源于事务，提供了关键过程时间的连续场景描述，代表的是完全覆盖一个事件或产品的生命周期时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。

例如订单累计快照事实表会有下单日期、付款日期，发货日期，收货日期等时间点。

order_id	poi_id	user_id	push_time	grap_time	arrived_time	status	dt
16589600009723	300876	100356	2021-10-01 11:02:10	2021-10-01 08:02:10	9999-01-01 01:00:00	30	20211001
16200000003455	300087	200389	2021-10-01 09:10:33	2021-10-01 09:12:33	2021-10-01 10:02:09	50	20211001

	事务事实表	周期快照事实表	累积快照事实表
时间特点	离散事务时间点	固定的时间间隔	时间跨度不确定
粒度	每行代表一个事务度量事件	每行代表一个周期内的实体状态	每行代表一个实体的生命周期
日期维度	事务事件
适用场景	针对业务过程的事务分析	针对实体的状态分析	针对实体的生命周期分析
更新策略	不更新	周期结束时定期更新	业务过程更新时同步更新

1. 维度建模-建模步骤

业务建模=>逻辑建模=>物理建模。

1. 业务建模（Conceptual Data Model）

梳理业务流程、统一业务概念、收集业务指标。

• 梳理业务流程

输入：（1）阅读BRD/MRD/PRD、技术方案、ER模型文档深入了解业务背景知识、各个系统的数据存储关系。（2）对相关业务人员进行调研，了解业务操作和日常工作，收集业务对数据的诉求，收集存量的报表。

输出：（1）业务流程图；（2）业务知识文档；（3）特殊业务场景和坑点；（4）业务指标定义。

• 业务建模-划分主题

主题：指面向业务分析的场景下，将业务数据或分析视角数据进行重新抽象组织的集合，是从较高层次对企业业务进行划分的方式和组织。

为什么划分主题？（1）明确主题边界，确认主题建设范围，分而治之，达成共识。例如：物流主题负责物流承运相关流程的核心数据，派单相关的划分到调度。（2）便于用户从较高层次理解使用数仓，提升检索数据效率。例如：数据地图提供按主题引导。（3）数据仓库管理的基础。例如：主题分工各负其责、业务过程归属，指标体系归类，元数据管理。

• 如何划分主题？

（1）按主业务流程进行划分

例如：提供物流履约服务就是主业务流程，根据业务上下游相关性，提供物流履约服务可以进一步拆解为销售、定价、交易、调度、履约、结算、售后(体验)等不同业务领域，可以对相应的业务领域构建对应的主题。

此类主题的特点是有多个参与主体参与；例如：履约主题需要由商家、配送员、用户等共同参与。

（2）对支撑业务流程按参与主体划分

例如：对于物流来说，参与主体有商家、配送员、用户等；可以对参与主体分别构建主题，用于存放与参与主体相关的支撑性业务流程。

例如：对人员招募、人员注册、人员入职、人员在职、人员离职等业务过程构建人员运营主题。

（3）按分析的视角划分

结合业务分析的场景进行抽象的主题，例如：人员体验、盈亏分析，人员留存，可以对这些分析主题进行专题的建设。

• 主题划分的依据

业务相关性原则：主题应该与业务需求密切相关，按照业务过程或业务功能进行划分。确保主题能够满足用户对特定业务领域的数据需求，便于业务分析和决策。

数据可比性原则：将具有相似属性和含义的数据放在同一个主题下，以便于数据的比较和分析。主题内的数据应该具有一致的定义和格式，方便用户进行数据的比较和统计。

数据可扩展性原则：主题应该具有良好的扩展性，能够适应业务的变化和扩展。在划分主题时，需要考虑到未来可能的业务需求和数据增长，避免频繁的主题调整和数据迁移。

数据可维护性原则：主题应该具有良好的可维护性，方便数据的更新和维护。在划分主题时，需要考虑到数据的来源和更新频率，确保数据的及时性和准确性。

1. 逻辑建模（Logical Data Model）

梳理总线矩阵、划分业务过程、确定粒度/维度/事实/维度表/事实表设计。

1. 1、构建总线矩阵

一致性维度：在数据仓库体系内部统一的维度关键字、一致的列名称、属性定义和属性值

一致性事实：在数据仓库体系内部每个度量统一的统计口径，对应唯一的业务概念术语

业务流程是由各个具体的事务流程组成，而事务是由各个业务系统支撑的业务过程来组成的，

可以转换成总线矩阵上的行、列最终形成维度模型

行：代表公司组织的一个业务过程

列：一致性维度

通过总线矩阵，可以清晰地识别出哪些业务过程需要哪些公共维度，并据此设计相应的维度表和事实表。这样，不仅能够保证数据的一致性和准确性，还能够提高数据仓库的查询性能和分析效率。

1. 2、维度表设计

确定维度、填充维度属性、审查相关属性。

是否应该分层，是否可以拆分或整合。

1. 3、事实表设计

1）选择业务过程：通过对业务的梳理和可用数据源的总和考虑，决定对那个业务过程展开建模，在主题域内根据情况会抽象新增/合并业务过程。

2）声明粒度：对于事务表，尽量保持最明细的粒度，原子数据能够提供最佳的分析灵活性。

3）确定维度：事实表的粒度确认完毕后，维度的选择就比较直接了。尽可能包含业务过程下所有维度；考虑是否退化维度；识别剩余的维度或维度属性是否必须； 避免出现蜈蚣表；

4）确定事实：确定将那些事实放到事实表中，事实必须和粒度吻合。注意同一类指标的单位要统一。尽可能包含业务过程下所有原子指标，只选择和业务过程相关的原子指标，统一同类指标的单位。

1. 物理建模（Physical Data Model）

定义物理模型、存储方式。

确定表名称/表文件格式/字段名称/字段类型及存储路径等

确定分区方式，一级分区/双分区/多级分区，分区字段的选择(时间年月日、业务字段)

确定数据初始范围

数仓整体分层

1. 分层规范

层次	定义	对各层含义的具体理解	引擎
ODS	ods接入层,主要负责各种数据源的接入	接入层由工具完成，当前主要有mysql 和流量日志数据源。该层不对外开放	hive
	ods准备区，主要完成进入dwd数据的准备工作，完成和接入层的解耦合。	由于接入层由工具完成，不受我们控制。我们需要在此基础上做一些解耦操作(生成快照表)，同时完成进入dwd的准备工作，例如过滤压测数据、脱敏操作等。 在建模方式上基本和源系统结构保持一致。对于部分临时性探索分析，不一定会构建dwd，可以考虑对外开放这部分数据权限；其它场景均应该访问dwd处理过后的数据	hive
DIM	一致性维度层，对业务过程中的维度进行统一定义，消除不一致性，是实现总线架构基础。维度分为普通维度和衍生维度，区别在于衍生维度需要通过复杂计算(跨事实表、跨时间周期汇总）等才能产生	基于维度建模理念思想，建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表，维度和维度逻辑表通常一一对应	hive
DWD	Data Warehouse Detail 明细数据层，作为数据仓库最核心的区域，主要作用是通过数据加工与整合，完成对业务的抽象，对外提供简单、准确、详尽、一致的数据模型。	这部分主要完成以下工作： 按业务主题域，采用维度建模面向业务过程构建明细事实表，完成对业务的抽象，及逻辑的封装，屏蔽数据源变化 2）完成统一指标的定义，指标定义规范 注：DWD层的原子指标、衍生指标均不跨业务主题 3）数据质量保证	hive
DWS	Data Warehouse Summary汇总数据层，完成明细数据的汇总	主要对DWD层按照常用维度组合进行预聚合，不做任何逻辑封装，提升查询性能。 时间类的衍生指标也存于该层，例如最近30天接单量。 对于不可加指标(例如count distinct)，有三种实现方案，基于doris的ROLAP，基于kylin的MOLAP和基于hive的cube表，具体可以根据实际场景选择 通常会有三类汇总表，分别是最近1天、最近N天、历史截止当天 注：为了保证低耦合，高内聚，DWS层的聚合不跨业务主题	hive、kylin、doris
DM	为满足具体分析场景的数据特点和易用性，而构建的面向不同垂直领域的数据集市层，例如盈亏集市、AB集市、运力集市、商集市等	基于DWD、DWS层和DIM的数据构建，内部数据可跨B3层主题域整合，或基于商业模型进行场景化的数据加工，满足业务、商分和产研的具体分析诉求，达成低成本、易使用的获取和分析数据的诉求	hive、kylin、doris
APP	Application数据应用层，面向具体应用(报表、数据服务)构建，用于满足不同应用的个性化需求（例如行列转换，特殊排序要求)	面向具体应用构建，满足性能和客户化展示需求	kylin、doris、mysql、es

1. 为什么分层（分层好处）

复杂问题简单化：通过将复杂的任务分解成多个步骤完成，每一层只处理单一的步骤，使得整个数据处理流程更加清晰和易于管理。这种分层设计有助于降低问题的复杂度，提高数据处理的效率。

结构更清晰：每个数据分层都有其特定的作用域和职责，使得数据在使用和维护时更加方便和理解。例如，数据源层负责数据的采集和接入，数据加工层负责数据的整合和清洗等。这种清晰的层次结构有助于技术人员更好地协调开发和数据共享。

数据血缘追踪：分层设计使得数据的来源和流向更加明确，便于进行数据血缘追踪。当数据出现问题时，可以快速定位到问题所在，并了解其对其他层次的影响范围，从而及时采取措施进行修复。

用空间换时间：通过大量的预处理来提升商分、业务的用户体验（效率），数据仓库会存储大量的冗余数据。这种设计虽然增加了存储空间的需求，但能够显著提高数据查询和分析的效率，满足用户对数据实时性和准确性的要求。

数据重复使用，减少重复开发：规范数据分层，开发一些通用的中间层数据，能够极大地减少重复计算和数据开发的工作量。不同的业务部门或项目可以共享这些中间层数据，避免了数据的重复采集和处理，提高了数据资源的利用效率。

数据隔离，屏蔽原始数据的异常：分层设计有助于将原始数据与加工后的数据隔离开来，避免原始数据的异常对后续数据处理和分析的影响。同时，通过分层可以对不同层的数据进行权限管理，确保数据的安全性和隐私性。

数据安全：通过分层设计，可以更方便地对不同层的数据进行安全控制。例如，对敏感数据进行加密存储和访问控制，防止数据泄露和非法访问。

增强扩展性，利于后期维护：分层设计使得数据仓库具有良好的扩展性和灵活性。随着业务的发展和变化，可以方便地调整和优化数据仓库的结构和层次，以满足新的业务需求和数据处理要求。同时，分层设计也有助于降低数据仓库的维护成本和提高维护效率。

综上所述，数据仓库分层设计是出于提高数据处理效率、降低问题复杂度、优化数据结构、实现数据血缘追踪、减少重复开发、保障数据安全以及增强扩展性和维护性等多方面的考虑。这种设计方式在现代数据管理和分析中发挥着重要作用。

1. 数仓分层设计原则

1. 贴源层设计原则

ODS主要实现统一接入，在合规的基础上实现接入效率和性能稳定。 设计过程使用数据集成工具实现接入高效性和唯一性；并且只做简单清洗，不做过度加工，保持与业务库的一致性；采用合理的同步方式，保障数据的时效性。

1. 公共层设计原则

公共层在架构中的定位为抽象复用，降低应用层的开发成本，并确保口径一致性，因此公共层的准入门槛在于需求上是否是共性逻辑。公共层共性需求的识别方法一般由事前专家经验判断、事后沉淀。

1）DWS准入逻辑：DWS核心是通过空间换时间，提升效率节约成本的同时实现数据口径的统一。

专家经验：判断指标是否业务的KPI指标，或者实现KPI指标的核心过程指标；

事后沉淀：需求指标是否已经覆盖了>=2个以上的稳定产品或应用。

2）DWD准入逻辑：DWD核心是以维度建模重构基础模型，降低统计分析中频繁关联，提升基础数据模型的易用性。

专家经验：判断是否是业务核心业务过程（如电商主干业务过程浏览、加购、交易等）；

事后沉淀：是否覆盖下游>=5稳定的应用场景。

1. 应用层设计原则

1. 应用层需要进行集市域划分，降低各集市的复杂度

1. 应用集市需要扁平化设计提升稳定性降低运维成本

造成深度过深原因一般有：

a、缺少扁平化设计导致ADS依赖链路深，如多种长周期累计型指标场景1D->7D->1M->1Q-1Y；

b、为了快速响应业务，导致不同场景间互相依赖引用；

c、缺少共性集市中间层的沉淀构建，导致ADS依赖深度加深。

1. 应用层设计上也需要进行共性抽象下沉，以提升效率和口径一致性。

1）集市内构建MDS确保集市内口径一致性和研发效率。

2）跨集市共性指标下沉DWS确保全域口径一致性

a）事前-专家经验判断下沉：基于业务目标和策略拆解出来的KPI和KP|过程指标，各业务团队会重点关注，可以提前进

b）事后：致据吸动判断下況：从两个箱度判断，一是因不合理的跨集市依赖驱动下沉DWS，二是根据救据選银相似度评估，结合专系经验判断进行广办。

1. 公共层共建机制

1. 机制目标

提高协同效率、降低开发成本，提升数据开发质量。

1. 核心角色

有业务方、应用层数据开发、公共层数据开发。

1. 协作流程

分为六个环节：需求收集、方案设计、数据开发、数据测试、数据运维、數据治理。

1. 协作分工

为了提高协同效率，分为2种模式：

1.公共层研发主导开发

针对DWD、DIM核心模型或整体性的公共层开发，由公共层同学主导设计和开发，确保公共层设计的复用性和易用性。

2.应用层研发主导开发

1）针对一些DWD、DIM非核心模型或离散型的公共层需求或者口径变更，应用层研发主导开发。

2） 针对DWS数据，可以由应用层开发直接对公共层数据进行开发，但是必须由对应的公共层开发进行评审，同时进行代码Review，实现公共层数据的稳定性和变更的灵活性的兼顾，当DWS数据跨集市复用后转交给公共层研发开发和维护。

1. 机制保障

为了保障共建机制的有效执行，通过以下方式进行管控：

1.统一方法论

2.统一使用智能建模

公共层开发统一使用智能建横工具，从产品测进行设计、开发、发布保障，通过评审流程、开发推荐、上线管控等方式实现设计和开发的规范。

3.评估体系&治理

4.统一数据专辑

实施

1. OneData体系的核心组成

OneID：致力于实现实体的统一，让数据融通而非孤立存在，为精准用户画像提供坚实基础。

OneModel：专注于数据的标准与统一，确保数据的一致性和准确性。

OneService：专注于数据服务的统一，实现数据的复用而非复制，提高数据利用效率。

1. 实施过程

首先，在建设大数据数据仓库时，要进行充分的业务调研和需求分析，这是数据仓库建设的基石，业务调研和需求分析做得是否充分直接决定了数据仓库建设是否成功。

其次，进行数据总体架构设计，主要是根据数据域对数据进行划分；按照维度建模理论，构建总线矩阵、抽象出业务过程和维度。

再次，对报表需求进行抽象整理出相关指标体系，使用 OneData 工具完成指标规范定义和模型设计。最后，就是代码研发和运维。