OneData数据建模：建设企业级「好数据」

摘要：本文将介绍企业数据能力的建设和运营的整体方法论——OneData数据建模。本文的目标在于帮助读者：（1）明确数据建模的定义与主要目标；（2）了解通用的数仓分层模型；（3）掌握6条模型设计的原则；（4）知道模型开发的通用流程；（5）通过实例，理解22条数据建模的实操建议。

关键词：数据资产管理、数据治理、数据建模、OneData

一、数据建模及其目标

要讨论数据建模，我们首先要搞清楚“数据建模”是什么，以及数据建模的目标是什么。

（一）数据建模的定义：通过良好的结构设计，建设满足要求的数据集合

让我们从一个简单为问题开始讨论“什么是数据建模”—— 数据建模就是设计表，这个说法对吗？
——对，但不全对。
因为数据建模通常不是设计一张表，而是设计很多表。那么数据建模，是不是就是设计一系列的表呢？

——对，但不全对。
因为当表的数量变多之后，我们会面临一系列的问题，例如：数据质量的问题、可维护性的问题、开发效率的问题、计算存储成本的问题，等待。因此，用大白话来说，数据建模就是设计一系列满足要求的表。

当然在大数据时代，数据不仅仅包括数据表，因此，我们用一个内涵更加广泛的词“数据集合”来替代“一系列的表”这个说法。

那么数据建模是如何去满足要求的呢？是通过“抽象出良好的结构”来实现的。

所以，我们可以对数据建模给出如下定义：数据建模是一个“通过良好的结构设计，建设满足要求的数据集合”的过程。

（二）数据建模的目标：高质量、高效率、低成本

“满足要求”这个词有点笼统，因此我们把“要求”具象化为三个模块：数据质量、交付效率，以及整体成本。

保障数据质量：质量是数据的生命线，数据的质量决定了数据的价值。具体而言数据质量，可以概括为4类，正确性、完整性、时效性，以及一致性。

（1） 正确性：数据记录是否正确。
例如员工“郝向东”在【在职员工信息表】中的姓名字段的值，不应该是“好像东”。

（2） 完整性：数据记录是否完整。
例如全公司实际有301人，【在职员工信息表】中不能只有200条记录。当然也不能有305条记录，应该正正好好有301条记录。

（3） 时效性：数据记录是否及时（增、删、改都要及时）。
例如今天有一个新同事到岗，在新同事报道后，能否5分钟内，就在【在职员工信息表】中查到这个同事的信息，进而在各个系统内给这个同事赋权，以助于工作的开展。

（4）一致性：对于同一事实，在不同表、数据域中存储的数据，是否是一致的。
例如对员工身份的识别，在人力资源域是用[employee_id]这个唯一编码来代表的；那么在没有特殊需求的情况下，在销售员的销售管理系统中，管理销售员身份的id最好也是[employee_id]，而不是另起一套编码规则创造一个独立的[seller_id]。在指标层面，同样一个指标”DAU”，在经营过程中不应该出现多种指标统计口径；对于同一业务域，要实现“数同文”。

 提升交付效率：稳定性、适应性、简洁性和易用性，是影响数据研发效率的4个主要因素。

（1） 稳定性：数据中台要解决的核心问题之一，就是数据孤岛的串联与归一。已有的各个业务系统的数据，要能很好的接入（可接入）。未来新增的业务系统的数据，也要能够很好的接入，新数据的接入过程，不应该对已有的系统有过多的侵入和干扰（可扩展）。与此同时，这个数据模型，还要能够应对业务系统的变更，即使底层的源数据库有变化，也不应该对中台数据产生过多的影响（控制影响）。也就是说，好的数据模型，能够屏蔽原始业务系统的复杂性与变更，以保证模型的相对稳定性。做到“想不变，就不变”，进而保证交付效率。

（2） 适应性：在数据应用的过程中，经营逻辑的变更是不可避免的。比如说全国性经营的公司，原本是按照省域进行运营的，现在公司决策要按照大区进行管理。那就要对数据系统中涉及到的组织架构的信息进行修改，可能还要涉及到历史数据的回刷。如果说整个数据模型的耦合度非常高，那么回刷成本就会非常高。一方面会需要很多的数据开发工作，一方面因为涉及的表很多，还会存在影响历史数据的风险。一套好的数据模型，应该拥有足够的适应性。做到“想变就变，影响可控”，从而保证交付效率。

（3） 简洁性：随着业务的发展，数据变得越来越多，越来越复杂。原本只有少量线上数据的公司，进行了数字化的转型，在各个域都生产出了大量的数据。原本只有一个主营业务的公司，可能发展出混业经营的生意。大量复杂数据的生产、运营、管理，给数据研发工作带来了巨大的挑战。一套好的数据模型，应该能够简洁的抽象大量的、复杂的数据，从而降低维护的难度。

（4） 易用性：使用数据的人越来越多，在很多公司，几乎每个职员的工作中都会用到数据。数据的应用场景也越来越多，越来越复杂。与此同时，数据需求，本身就是灵活多变的，需要快速响应，才能支持业务决策。这些因素导致，我们对数据模型的易用性，提出了很高的要求。例如，公共的逻辑，在使用的时候不需要重复建设；常用的逻辑，沉淀在宽表内，不需要频繁的进行表关联，从而提升整体的交付效率。

降低整体成本：在确定的品质效率下，要尽可能的降低成本，把握好存储成本与计算成本之间的平衡。

简而言之，我们的目标是建立对于业务经营而言“好用、高效、且经济”的数据资产。

当然，与此同时，我们还要守好底线，保证数据合规、防止数据泄露。

注意：我们的目标是“好用高效且经济”的数据资产；因此不要过度的追求“漂亮”的数据资产。
不知道有多少同学刚参加工作时和好好一样，觉得公司里的表“不美”。具体而言，就是和教科书的表长得不像。这个表没有主键，那个表有几百个字段、大量的冗余存储。但这样的表被生产出来，往往是有其历史背景的。
我们判断一套数据模型、一张表是否“好”的第一标准，应该是好不好用，而不是这个模型符合多少规范，这张表符合多少范式。

二、模型设计

第一部分，我们介绍了什么是数据建模，以及模型最主要的10类性能目标。
现在我们来讨论一下 —— 什么样的分层结构，能够尽可能的满足上述数据建模的10个目标；以及在模型设计的时候，我们应该遵照哪些原则。

（一）数仓分层

数据仓库要分层建设，这个几乎是毫无争议的。

但具体分为哪几层，每一层的称呼是什么，各家的见解略有差异。
不过没关系，最重要的是抓住分层的本质：高内聚、低耦合、高复用、控依赖。
这里简要介绍一下OneData的核心架构 —— “3+5+n”：
• 整体分3层：贴源层（ODS – Operational Data Store）、公共层（CDM – Common Data Model）、应用层（ADS – Application Data Service）
• 细分为5层：贴源层、明细层（DWD – Data Warehouse Detail）、汇总层（DWS – Data Warehouse Summary）、维表层（DIM – Dimension）、应用层

其实就是对公共层（CDM）做了一个拆解，MDS拆分为了DWD、DWS、DIM。

如果应用层的数据建的非常厚，内部也有一些共性的逻辑的话，就增加一个MDS层（Middle Data Service）承载ADS中的一些共性需求。然后将ADS和MDS组合在一起，称之为集市层。如果中间层的数据非常复杂的话，就进一步的将DWD、DWS、DIM层做二级拆解。

ADS层拆分与CDM层拆分示意图（见紫色说明）

这个时候可能有同学就要问了：我们做了这样的设计以后，就能实现上述提到的10个性能目标吗？

让我们一一对照的看一下，每一层的数仓项目空间，分别的定位是什么？主要负责解决哪一类性能目标？

（二）模型设计原则

1. 高内聚低耦合：逻辑和物理模型的记录和字段组成方式，应该遵循最基本的软件设计方法论中的高内聚低耦合的原则。
 从业务特征而言：将业务近似或相关的数据，或是粒度相同的数据设计为一个逻辑或物理模型。
 从访问特征而言：将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。

2. MECE原则：数据域划分统一标准，尽可能遵照MECE原则，不重不漏。数据域之间的边界划分的越清晰，越能够延缓数据模型的腐化。

3. 公共处理逻辑，下沉且保持单一：所谓下沉是指，越是底层公用的处理逻辑，越应该在数据调度任务依赖的上游进行封装和实现，不可让公共的处理逻辑暴露给应用层实现。所谓保持单一是指，不可用让公共逻辑在多处存在，因为多处存在的逻辑，随着时间的推演，很难保持一致性。

4. 核心模型与扩展模型分离：建立核心模型与扩展模型体系，核心模型包括的字段支持常用核心的业务，扩展模型包括的字段支持个性化，或是少量应用的需要。不可让扩展字段过度侵入核心模型，以至于破坏核心模型的架构简洁性和可维护性。

5. 合理的层次依赖：各层数据空间之间，避免“反向应用”；例如DWD层应严格遵守层次依赖，理论上只可以引用ODS、DIM和部分的DWD层数据，不可引用处于下游层次的ADS层数据。ADS应用层各数据集市之间，也应该尽量避免频繁引用，如有高频共用的逻辑，应该向CMD中间层（含DWD、DWS、DIM）沉淀。

6. 清晰可理解的数据表命名，遵照一致性的字段命名：表命名需要遵照OneModel数据表命名规范，表名需要对于主要消费者而言，是清晰、易于理解和易于使用的。对于核心的指标（事实）、维度（对象），相同含义的字段，在不同表中的字段名必须保持一致，且须使用《模型命名规范》中的名称。

原则3与原则6示意图（见紫色文字说明）

三、实施过程

在第二部分，我们介绍了数仓分层，以及数仓分层模型设计的原则。接下来，我们要进入实施层面的讨论。首先，我们会介绍数据建模的开发流程，然后会就过去开发中遇到的一些问题、总结的一些经验，给出22条实操建议。

（一）开发流程
完整的数据开发流程可参照下图：

以上是从始至终的15个过程，大家在实际工作中，可以根据现存资产的状况进行剪枝。其中有3个比较容易忽视的过程，好好展开说明一下：“构建总线矩阵”、“数据对比”、“数据下线”。

1. 总线矩阵：是什么？如何搭建？

所谓需求调研，其实就是一个认识和理解业务的过程。（通常的做法就是梳理业务流程）

举个例子，现在我们要理解一家超市的经营过程，有4件重要的事：第一，我们要进货，然后把货摆上货架。第二，我们要让客户进店。紧接着，把商品卖给客户。最后，我们要提供售后，如果客户买的商品出了什么问题，我们要提供解决方案。

而数据域划分，其实是对业务的过程或对象的抽象，进而梳理出高内聚低耦合的业务模块。

例如，对于上述的超市业务。就过程而言我们可以抽象出4个模块来：采购、营销、交易、售后服务。就对象而言，我们也可以抽象3个模块：供货商、商品、客户。

梳理完数据域之后，紧接着要做的是对这个数据域所包含的业务过程和维度进行描述。例如：

我们之前提到数据域的划分，要尽可能的满足MECE原则。但按对象分，和按过程分，两者不可避免的会产生重叠，这种情况怎么处理？有两种方式：

（1）在过程域和对象域之间建立从属关系，看谁跟谁离得近就归给谁。例如供应商这个对象，虽然采购过程会有，营销、交易、售后过程也都会涉及。但是“供应商”这个对象离采购更近，我们归给采购这个域内。如果是非常负责的业务，我们则可以建立一个二级的数据域叫做“采购-供应商”，这个域以供应商为核心，不仅只包括采购的数据，也包括营销、交易、售后服务的数据。这样就可以保证数据域之间尽可能的不重不漏。

（2）接受数据域之间的重叠部分，并通过一致性维度来保证不同数据域之间数据的一致性。

那什么是总线矩阵呢？

大家可以把梳理总线矩阵理解为，通过一致性维度作为“线”，将一个个代表数据域的“点”关联起来。

一致性维度有2种：一种是通用的分析视角，例如时间、订单金额；另一种是具体的对象，例如客户、商品、订单。

“Y”表示这个过程域内，包括这个一致性的维度；“Y”则表示这个过程域内，不包括这个一致性维度。

这样做的目的是为了，从整体上看清我们有哪些数据域，这些数据域之间的关系是怎么样的。从而更好的开展后续的指标设计、维度构建、数据模型设计等工作。

2. 数据对比：怎么做？谁是第一责任人？

我们说质量是数据的生命线，所以在”ETL开发”之后，我们一定要做数据对比的工作。常见的数据对比的手段有：

（1） 经验判断：把统计数据和业务的经验数据做个判断。
比如说我们要开发一个字段，给订单的发货时间打标。在打标完成之后，我们统计一下48h内发货的订单占比，得到的结果是40%。这个40%和我们的业务经验严重不符，我们觉得至少有8成的订单是48h内能发货的。那我们就要做进一步的数据核查了。

（2） 交叉验证：如果不是重新埋点新建的数据，在开发一份新的数据前，我们通常已经有了一份现有的逻辑可以供参考。那么当新数据开发完之后，我们就可以把两份数据进行对比，交叉验证。

（3） 数据推演：如果是纯新开发的数据口径，如何进行验证呢？我们还可以通过逻辑进行数据推演。
例如我们要统计发货订单占所有下单订单的占比，发货的前置条件是支付订单。所有如果发货订单的占比，超过支付订单占比的话。数据口径就肯定需要重新检查一遍了。

（4） 抽样核验：还有一种方式，就是通过抽样明细数据去核验结果。

所以通常来说，我们做数据对比验收的过程大概是这样的——“这份数据，符合我的直觉吗？和已有的数据勾稽关系对得上吗？再抽几条明细看一下吧？”

还有一个问题，好好认为必须说明清楚，那就是——谁是数据对比过程中的第一责任人？

数据输出的最后出口方，承担”数据对比”的第一责任。

举个例子，现在有个数据开发的工作，涉及到3个同学：公共层数仓、应用层数仓、业务BI。当业务BI向外输出数据时，TA要对TA所统计的所有数据，承担“数据对比”的第一责任。即使这个问题可能是由于应用层数仓的表的问题导致的。

亦或是，现在有4位同学，ODPS层数仓、DWD层数仓、DWS层数仓、应用层数仓。应用层数仓数据表的任何一致性问题，应用层数仓是第一责任的。
简而言之，责任是不传递的。我们可以去推动上游优化问题，但是一旦我们对外输出了数据，我们就要承担起这份数据的第一责任。
只有大家就数据对比工作的责任归属达成共识，才能避免类似“BI出的数据就是这样的”（如果真的如此，请业务同学给BI出的数据结论把把关。）、“数仓开发的数据表质量很差，根本不可用。”（如果真的如此，请BI同学协助数仓把表建好。）这样的抱怨，从而提高组织整体的协作效率。

3. 数据下线：重要吗？怎么做好“数据下线”工作？

“数据下线”流程，非常重要！这不仅是出于存储、计算成本层面的考虑，更为重要的是废弃的数据资产长期在线上存在，会降低模型的易用性，破坏数据的一致性。
因此：
• 指标定义、表生产要设置（合理的）生命周期。
• 弃用的字段要注明，弃用的数据表要下线。
• 数据下线时，要通知下游相关方，并预留处置时间；避免因数据下线导致线上事故。
• ……

（二）实操建议

最后，根据自己和前辈们实操的经验，好好梳理了22条建议（及部分说明案例），供大家在实操过程中参考。
ODS层：
1. ODS贴源层不做，或只做简单的数据清洗工作：ODS层的表通常有大量的下游依赖，复杂数据清洗会带会影响表的稳定性和产出时间。而且这样做，还会损失和原业务系统的一致性；

CDM公共层：

2. CDM公共层的准入逻辑为是否存在复用的共性逻辑：就经验而言，当同一个指标逻辑被下游≥2个稳定产品/应用调用时，就可以向DWS层沉淀。当一个分析维度，有≥5个下游应用场景时，就可以向DWD层沉淀。

比如说对于电商业务的“发货问题”，现在我们有4个应用表，分布在两个集市内，分别是：

● 发货经营看板：这个是给到商家看的，在这个看板里面，商家能看到自己的发货物流状况。
● 商家服务分表：这个是一个内部模型，会根据商家的发货状况，给商家打发货体验分。
● 发货预警表：这个是一个产品应用，平台会将商家已经发货延迟或者即将发货延迟的订单明细推送给商家，敦促商家尽快发货。
● 延迟发货主动服务表：对于已经延迟了的订单，平台会对消费者做一些体验修复的动作。

“发货经营看板表”和“商家服务分表”都会用到每个商家，每个月的延迟发货订单量。因此我们可以向商家月粒度汇总的DWS表中沉淀[商家][每月]【延迟发货订单量】这个指标。

对于有5个稳定的上游用到了订单的发货状态，因此我们可以在订单明细表中沉淀[发货状态]这一打标字段。

3. 数据体量小的业务，先考虑交付效率（人力成本）：即优先建DWD层的数据表，后构建DWS层；在DWS层的建立过程中，先建立细颗粒的汇总数据，再建立粗颗粒的汇总数据。DWD明细层数据和细颗粒度DWS汇总层数据的好处在于，可以让模型的易用性更好，可以灵活的应用于各种场景。本质上来说是用小的计算和存储成本，来提升交付效率，降低人力成本。

4. 数据体量大的业务，优先考虑整体成本（存储计算）：当业务的数据体量很大的时候，交付效率优先的设计可能就不是那么适用了。比如说如果建大量的细颗粒的汇总数据，就会花费很高的存储资源。因此对于数据体量很大的业务，在承接业务需求时，可以优先建立DWS层的数据表，只在必要时建立DWD层数据表。在DWS层以内建设数据时，优先建设粗颗粒度的汇总数据，只在必要时建立细颗粒度的汇总数据。

5. 对于比率指标，进行可加性拆分，可提高易用性：在指标设计的过程中，我们会设计大量的比率型的指标，例如转化率、好评率等。预先在表中计算出这些比率指标的值，可以让下游直接调用，保持一致性。但如果数据表中只有比率指标，数据应用就会存在很大的局限性。其原因就在于，这些比率指标是不可加的。因此我们应该尽量保留比率型指标的分子分母，从而方便下游的使用。

例如，好评率。昨天的好评率是50%，今天的好评率是60%，请问这两天的好评率是多少？这是一个无法回答的问题。因此我们要将“好评率”这个不可加的比率指标，拆解成两个可加的指标：参评量，与好评量。

6. 通过面对对象的设计，抽象公共粒度（一致性维度）：这个不难理解，我们在构建总线矩阵的时候，其实就有抽象对象作为一致性的维度。例如对于电商而言，最常见的三个对象就是：商家、商品、消费者。我们把这三个对象抽象出来，作为所有分析的公共粒度seller_id、item_id、buyer_id，再以这些粒度来汇总DWS层数据表。通常而言，以公共粒度来汇总的表，能够覆盖下游非常多的应用场景，属于高复用的资产。

7. 应适当构建DIM分析维表，以满足分析维度的一致性、复用性问题，同时兼顾成本。

例如，对于电商业务而言，在各种业务域内，我们都会以“消费者的购买力”作为一个维度，进行拆解和分析。在未构建一致性的DIM分析维表时，不同的数据域可能采取不同的方式对消费者的购买力进行划分（简单的做法有根据消费者某个特定时间周期的GMV进行分层，复杂的做法如建立模型），从而导致跨域之间就“消费者购买力”这一维度很难展开对话。

如果构建一个《消费者购买力分层维表》，就能解决这一问题。

8. 在DWD层，应以星型模型为主，雪花模型为辅，这样可以提升模型易用性：实践经验表明，随着数据思维和能力的普及，数据使用者的激增，采用星型模型是更为恰当的选择。不仅如此，我们还要采用退化维度的方式，在事实表内冗余常用的维度信息，以减少用户的频繁关联。

星型模型是多张维度表直接连接事实表，维度表里存储对应维度的详细信息，因此维表会出现很多冗余数据，通过存储成本换计算成本；雪花模型在星型模型的基础上，把维度表中的一些字段进行进一步的拆分，因此不是存在维表间接连接事实表，这样可以减少冗余，使其更有层次，但增加了关联成本和设计实现成本。

【星型模型与雪花模型示意图】

9.在DWD表中，构建大字段，配备使用文档的方式，可以提升模型的易用性：给数据表增减字段是一个比较复杂的操作，但更改字段中值所存储的内容，则简单的多。因此对于经常变动的字段，例如“商家是否参加了各类营销活动的标记”，可以用大字段的方式存储，从而提升模型的易用性。

10.当DWD表的产出时效无法达到要求时，可以考虑“垂直拆分”：将下游引用较少但耗时的逻辑拆分出来。

11.当DWD表中存在不稳定的分析维度时，可以考虑“垂直拆分”：将其中不稳定的维度拆分出来。

12.当业务存在明显区隔时，可以对数据表采取“水平拆分”的方式：提升关联效率，降低计算成本。

ADS层：
13. 应用层要进行集市划分，集市之间要避免相互依赖，有共性逻辑向CDM层沉淀。

14. ADS应用层的设计遵循需求驱动，不做过度的扩展设计：其原因在于应用层数据紧贴业务，其需求往往是灵活多变的。对于3个月后的需求做扩展设计和开发，其实很难做到未雨绸缪。其结果往往是，既浪费了当前的开发资源、计算成本和存储成本；3个月后又要根据新的需求，重新开发。

15. 通过冗余设计，实现ADS层的相对稳定性：那么按照“建议14”，我们是不是在ADS层就是“要什么做什么呢”？也不尽然。对于3个月内可预见的灵活变动的需求，我们可以通过冗余的方式来提升ADS层的相对稳定性。常见的冗余有两种，一种是粒度冗余，另一种是维度冗余（修饰词冗余）。

16.尽量减少对ODS贴源层的依赖，以规避系统变更带来的影响

17. 易变动的字段逻辑，通过设计维表的方式，可以减少后期变动带来的维护成本，从而提升数据模型的适应性。

例如，在客服承接消费者的求助时，会调用各种各样的解决方案。每个解决方案，会调用不同的能力来解决消费者的问题，例如当商家虚假发货时，客服可以通过赔付能力给消费者赔款，与之对应的实体是ability_code。这些ability_id大约有上百条，不便于直接分析。

因此我们有一个字段需求是要把ability_code，归类为ability_type调用能力类型。比如说催促发货体验赔付、延迟发货规则赔付、虚假发货规则赔付，因为规则、金额不同，会有不同的ability_code；但它们调用的都是赔付的能力，所以ability_type要归为一类。

然后因为线上的解决方案其实是会频繁新增、变更、下线的，所以ability_code也会频繁的变动。因此如果用条件判断CASE WHEN的方式，来清洗ability_type，显然会带来巨大的维护成本。这时候，我们就可以通过维表关联的方式来清洗字段ability_type。

后续当上游产品变动时，直接调整维表，以实现维护成本的降低，从而提升数据模型的适应性。

18. 可能经常变动的逻辑，避免多次传递，可以降低未来数据回刷的影响和成本。

例如商品类目所归属的行业，是一个易变的字段，经常会因为外部市场变化，或者内部组织结构变化，而进行调整。所以对类似于“商品所属行业”这种容易变动的逻辑，应该设计维表屏蔽变化（如建议17），同时还要尽可能在数据模型应用靠接应用下游的地方匹配上。避免多次传递带来的数据回刷风险和成本。

19. 避免在ADS层长期同步复制DWD表，以节省存储成本：如有相对独特的打标字段存在长期的分析需求，应向DWD层的扩展模型中沉淀。
________________________________________

通用建议：
20. 扁平化的设计，可以显著提升数据模型的稳定性和可维护性：DWD层深度≤5；DWS层≤3，ADS层≤5。

一个比较常见的例子是对不同时间周期数据的汇总。例如我们要对每个商家的成交数据，做天、周、月、季度、年度的汇总。那么我们应该怎么构建表的关系呢？

有的同学为了节省计算资源，以及顺序逻辑，他会这样建立依赖关系：1d → 1w → 1m → 3m → 1y。这样的依赖关系会严重拖慢产出时效，同时让不同颗粒度之间的数据相互影响，损耗稳定性和可维护性。

我们更推荐，并行计算不同时间周期数据的扁平化设计，从而提升数据模型的稳定性和可维护性。

ADS层口径未及时向CDM层沉淀，导致ADS层过厚；为快速响应需求，ADS层内跨集市调用，集市内应用层表格相互调用，都是造成深度过深的常见原因，应在实际开发运营过程中尽量避免。

21. 构建大宽表，可以提升模型的易用性，同时还能保证数据口径的一致：用空间换时间和质量。

22. 用“一次做对”来保证质量，避免先污染后治理：因为如果先污染，通常直到出问题的前一刻，大家没有资源和意愿来进行治理。

小结一下~

本文的行文方式类似字典手册，建议大家收藏后按需搜索查看。以下5张图可帮助大家做纲要性的回顾：
数据建模的目标

数仓分层模型

各层数仓的定位

数据模型设计的原则

数据模型开发的流程

以上内容提供了，数据能力建设的一类基准。
当我们面对不同的实际情况，必须要做出相应的调整。
没有最好的架构，只有最适合的架构，实践是最重要的方法论！
另外向有志于了解更多技术细节的同学，推荐一下阿里云的 || 开发者藏经阁 || ~

在藏经阁内，可以查阅到以下参考资料：
• 《构建企业级好数据（Dataphin智能数据建设与治理）》
• 《全链路数据治理-智能数据建模（数据仓库规范化建设之路）》
• 《全链路数据治理-主动数据治理篇（2万字揭秘阿里数据治理平台建设实践）》

作者鄢维凡，淘天集团。

本文刊载于《客户世界》文集2023第四辑•数据与智能。

转载请注明来源：OneData数据建模：建设企业级「好数据」

本文链接地址：http://www.ccmw.net/article/188797.html