很多人刚接触数据建模时最容易被各种“层”绕晕。有人说数据建模要分概念模型、逻辑模型、物理模型有人又说数仓要分ODS、DWD、DWS、ADS真正进入项目以后还会听到客户主题域、交易主题域、供应链主题域。于是很容易把它们理解成一套从上到下的层级。其实不是。真正需要先分清的是两条线主题域、概念模型、逻辑模型、物理模型解决的是“业务怎样逐步翻译成数据结构”ODS、DWD、DWS、ADS解决的是“数据进入数仓以后怎样逐层加工”。前者是建模抽象层次后者是数据加工层次。把这两条线分开很多建模问题才真正开始变清楚。一、主题域不是先分表而是先给业务世界划边界很多项目所谓的“建模”第一步就是把ERP、CRM里的表全部盘出来再按照来源系统分目录。ERP一组CRM一组WMS一组。这其实还不是主题建模。源系统告诉你数据来自哪里主题域回答的是这些数据在业务上属于什么。例如一家零售企业可能存在客户主题商品主题交易主题库存主题供应链主题营销主题财务主题。这里最重要的不是名称而是边界怎么划。不要简单按照部门划主题域销售部、财务部、运营部分别建立主题看起来清楚实际很容易制造新的数据孤岛。因为“订单”并不只属于销售。销售关心订单金额运营关心履约供应链关心发货财务关心收入确认。如果每个部门都重新定义一遍订单最终往往会出现销售订单数、运营订单数、财务订单数三个数字。主题域应该尽量围绕稳定的业务对象和业务过程建立而不是照搬组织架构。判断主题域可以看三个东西第一是核心对象。客户主题围绕客户商品主题围绕商品交易主题围绕订单与交易。第二是业务事件。下单、支付、退款、发货、入库本质上都是业务发生过的事件。第三是主题之间的依赖关系。订单可以关联客户、商品、门店但客户和商品不应该因为出现在订单里就全部塞进交易主题。所以主题划分的本质是寻找哪些东西应该在一起维护哪些东西应该通过标准关系连接。真正实施时还会遇到一个现实问题主题域是按照业务划的而底层数据往往按照系统散着放。客户在CRM订单在ERP库存又在WMS。这种情况下通常会先利用FineDataLink 5.0把数据库、接口、文件等不同来源的数据汇入统一的数据环境再按照客户、交易、库存等主题重新组织。这样后面讨论的就不再是“ERP里有哪些表”而是“完成交易主题需要哪些数据”。二、概念模型先搞清楚业务里有什么不急着考虑数据库主题域确定以后第二步是建立概念模型。概念模型回答的是这个业务领域里有哪些关键对象它们之间是什么关系以交易主题为例可以先识别客户、订单、订单明细、商品、支付、优惠、退款。然后定义关系一个客户可以产生多张订单一张订单包含多条订单明细订单明细对应具体商品一张订单可能存在支付也可能发生退款。注意这一阶段一般还不需要纠结字段叫customer_id还是cust_id金额用decimal还是double表放MySQL还是ClickHouse。因为概念模型首先解决的是业务认知统一。这一步看似简单实际上非常重要。例如:“客户”到底是什么注册账号算客户还是只有发生购买的人才算企业客户如果存在多个联系人是一个客户还是多个客户“订单取消”和“订单退款”是不是同一个业务事件如果这些问题没有先统一后面再精细的数据库设计也只是把业务分歧固化了下来。所以好的概念模型重点不是画得多漂亮而是把三个东西讲清楚业务实体是什么、业务事件是什么、实体之间是什么关系。它本质上是一张企业的业务对象地图。三、逻辑模型真正决定数据“怎么算”到了逻辑模型建模开始从业务语言进入数据语言。这一步需要回答这些业务对象怎样组织成可计算的数据结构其中最重要的不是字段而是粒度。建事实表之前先写一句“一行代表什么”例如销售事实表如果定义为一行一张订单那么它可以直接分析订单数、订单金额、客单价。但如果要回答某个SKU卖了多少件哪个商品贡献了多少收入不同品类的折扣是多少订单级粒度就不够。此时更合理的粒度可能是一行一条订单商品明细。这就是为什么建模时必须先定粒度。因为粒度一旦混乱指标就很容易被重复计算。一张表里既有订单级金额又有商品明细级数量一张订单有5条明细那么订单金额很可能被重复5次。粒度确定以后再区分事实和维度事实描述的是发生了什么。例如销售金额、购买数量、支付金额、退款金额。维度描述的是这件事是在什么条件下发生的。例如客户、商品、地区、渠道、日期、门店。因此一个订单明细事实可能最终形成时间 × 客户 × 商品 × 门店 × 渠道 → 数量、金额、成本。这才是分析模型真正的骨架。还要考虑历史怎么保存现实世界并不是静态的。客户今天属于华东区下个月调整到华南区商品今天属于A品类半年以后重新分类门店可能更换所属区域。此时必须决定分析历史订单时是按照当时的归属还是按照现在的归属这就是逻辑模型里经常遇到的缓慢变化维问题。因此一个完整的逻辑模型至少应该明确业务粒度、事实、维度、主键、关联关系、历史变化以及指标来源。到了这里模型已经开始真正进入数据加工阶段。例如原始订单进入数仓以后需要先清洗状态、统一客户编码再关联商品和组织维度最终生成订单明细事实。使用FineDataLink 5.0时这类逻辑可以落成ETL或ELT数据开发任务来源表负责提供原始数据加工节点承接清洗、关联、转换和汇总再把结果写入目标模型。所以这里最重要的一点是工具负责执行模型不能替代模型本身。如果粒度没有定义清楚再完整的数据加工流程也只是稳定地产出错误数据。四、物理模型不是“建表”而是决定模型怎样跑得动逻辑模型设计完成后还要继续落到具体数据库中。这一步才是物理模型。例如逻辑模型中已经确定销售订单明细事实表一行代表一个订单中的一个商品明细。进入物理模型以后需要继续确定表叫什么名字字段采用什么数据类型主键如何生成是否分区按日期还是业务组织分区是否建立排序键、索引全量还是增量更新历史数据保留多久数据落MySQL、Doris还是ClickHouse。因此同一个逻辑模型在不同数据库中可能会形成完全不同的物理结构。这也是为什么逻辑模型应该尽量保持业务稳定物理模型则需要适应技术环境。如果更换一次数据库连客户、订单、商品之间的关系都需要重新定义那之前设计的其实并不是真正独立的逻辑模型。物理模型还有一个经常被忽略的问题表建出来不代表模型已经能够稳定生产。真正上线以后还需要处理ODS什么时候进数DWD什么时候开始加工上游任务失败以后下游要不要运行增量任务失败以后从哪里续跑字段增加以后哪些任务受到影响因此落地阶段通常还要把模型、数据任务和调度依赖放在一起看。在这类场景里FineDataLink 5.0承接的重点就从“模型设计”转到了“模型运行”定时数据开发负责批量加工实时数据开发可以持续处理变化数据再根据上下游依赖组织任务运行。对于需要实时落库的链路也能够通过实时任务把处理后的数据写入目标数据库。物理模型真正完成的标志不是CREATE TABLE成功而是这张表能够按照业务需要持续、稳定地产出数据。五、概念、逻辑、物理模型与ODS/DWD/DWS到底是什么关系这是整个数据建模里最容易混淆的问题。可以直接记住概念、逻辑、物理是模型抽象层次ODS、DWD、DWS、ADS是数据加工层次。两者不是上下级关系。举个完整例子。业务上发生了一件事客户购买商品。在概念模型里我们识别出客户、订单、商品。到了逻辑模型可能设计客户维、商品维、订单明细事实。到了物理模型进一步确定实际表名、字段类型、分区方式和存储引擎。而同样这批数据进入数仓以后还会经历ODS保留接近源系统的订单原始数据DWD完成清洗、去重、编码统一形成标准订单明细事实DWS按照客户、商品、地区等维度进行公共汇总ADS针对销售分析、经营看板等场景形成应用数据。所以逻辑模型并不等于DWD物理模型也不等于ODS。更准确的理解是一个模型可能贯穿多个数仓层而每个数仓层又会存在自己的物理表。项目做大以后真正麻烦的往往也不是建一张表而是这些层之间形成成百上千条依赖一个DWS指标到底来自哪张DWD表DWD字段又来自哪个源系统某张事实表结构变化哪些ADS会受到影响这时候仅靠表名和开发人员记忆已经很难维护。在FineDataLink 5.0中数据开发任务与库表之间形成的关系还可以继续用于数据血缘分析向上追来源、向下看影响范围。这样模型管理就不只是知道“现在有哪些表”还能够知道“这张表为什么存在以及改动以后会影响谁”。六、一套真正能落地的数据建模顺序如果企业从零开始建模可以按照下面的顺序推进。第一步梳理业务过程先回答企业到底发生了什么获客、下单、支付、采购、生产、发货、回款。不要从数据库表开始理解业务。第二步划分主题域根据稳定的业务对象和业务过程确定客户、商品、交易、库存等主题及边界。第三步建立概念模型确认核心实体、业务事件和实体之间的关系。这一步主要解决大家说的是不是同一个东西。第四步建立逻辑模型确定粒度 → 事实 → 维度 → 主键 → 历史变化 → 指标来源。其中一定要先定粒度再讨论字段。第五步形成物理模型根据数据库和实际数据规模设计字段类型、分区、索引、排序、更新方式和存储策略。第六步落到数仓分层通过ODS、DWD、DWS、ADS等层次组织数据采集、清洗、整合、汇总和应用。最后还要做一次反向验证。随便拿一个经营指标例如“销售收入”尝试往回追销售收入 → ADS指标 → DWS汇总 → DWD订单事实 → ODS订单 → ERP源字段。如果整条链路能够解释清楚说明模型真正形成了体系。如果追到中间只能得到一句“这张表以前的人建的不知道怎么算的。”那企业拥有的只是很多数据表还不能算真正拥有了一套数据模型。结语数据建模真正难的从来不是背下几个术语。而是完成一连串翻译把企业拆成主题把业务识别成对象把对象转成数据关系再把数据关系落成能够持续运行的物理结构。主题域解决边界概念模型解决业务认知逻辑模型解决数据如何组织和计算物理模型解决数据怎样真正存储和运行ODS、DWD、DWS、ADS再负责让数据按照不同加工阶段逐步流动。所以评价一个模型设计得好不好最终不应该只看表建得规不规范。而应该继续问三个问题业务能不能解释清楚指标能不能稳定算准一旦数据或者模型发生变化能不能快速知道影响在哪里做到这三点数据建模才真正从“画模型图”变成了企业长期能够复用的数据基础设施。