金融数仓产品主题LDM建模：十大主题拆解与落地实践

简介：金融业逻辑数据模型中产品主题的专题解析文档，面向数据仓库建模人员、金融行业数据分析师及架构师，用于理解数仓十大主题中产品主题的逻辑模型设计。文档系统阐述产品定义与准入原则、唯一标识、分类体系（银行类、投资类、保险类、产品组与产品包）以及金额、期限、数量、描述、率特征等五类产品特征；重点梳理产品与内部机构、协议、渠道、事件、营销活动、当事人和地域的关系历史，并说明产品包与产品组的区别、可变利率与固定利率的差异等建模细节。通过产品与其他主题的关联，可支撑协议层收益、成本、风险、利润贡献度分析，以及产品渠道使用情况分析，为产品管理、营销创新和风险管理提供数据基础。资源为单个doc文件，约50KB，内容精炼、结构完整，便于直接查阅与二次整理。当前已有178人学习下载，适合在金融数仓建模或业务数据梳理中快速建立产品主题框架的读者。 做数仓这几年，我越来越觉得一份好的逻辑数据模型文档，比几十张跑批任务还有价值。手里这份《金融业逻辑数据模型-数仓十大主题-LDM-产品主题.doc》，是我接手某银行数仓项目时从一堆资料里翻出来的。当时第一反应是“这玩意儿这么重，谁看得完”，后来被各种指标口径对不上、表关系理不清的问题折磨过几轮，回头再看这份文档，才明白主题域拆得清不清楚，直接决定了一个数仓能不能扛住业务变化。这篇文章我就拿产品主题当例子，聊聊LDM里的十大主题到底怎么理解、怎么落地，也把我在数仓建模调研和实践里踩过的坑一并整理出来，希望对正在做数仓建模或者准备做数仓平台建设的同学有帮助。

1. 从一份文档看数仓的底子：LDM为什么值得反复研究

1.1 什么是逻辑数据模型LDM

LDM，全称Logical Data Model，逻辑数据模型。在完整的数据建模体系里，它夹在概念模型和物理模型中间。概念模型解决“业务世界有哪些大对象”，物理模型解决“表怎么建、分区怎么设、索引怎么加”，而逻辑模型解决的是最核心的那个问题：业务事实上到底有哪些实体、每个实体有哪些属性、实体和实体之间是什么关系。

做数仓建模调研的时候，你会发现很多团队根本没有这层中间产物。他们要么直接从业务库同步表结构过来，要么是业务提一个需求就临时建一张表。短期看效率挺高，时间一长就乱了：客户表里混着机构信息，产品表里塞了合约数据，同一个“贷款余额”在两个报表里口径对不上。LDM的价值，就是用一个相对稳定的中间层，把业务对象的全貌固定下来，业务再变，模型的主体结构不容易散。

你可以把LDM理解成盖房子时的施工图设计规范。它不讨论用红砖还是灰砖，但会明确哪里是承重墙、哪里是门窗洞口、水管电管怎么走。砖可以换，承重墙不能乱拆。数仓也一样，数据库可以换、计算引擎可以换，逻辑模型一旦乱了，改起来伤筋动骨。

1.2 为什么金融数仓非要“十大主题”不可

金融行业的数据仓库，尤其银行核心数仓，业务域非常庞杂。客户、产品、合约、账务、渠道、机构、营销、风险、事件、公共，是我在各大模型方法论里见过最通用的一套主题划分。几乎每家做金融数仓的公司都有自己的主题命名，但万变不离其宗，核心思路都是“高内聚、低耦合”：把变化频率相近、业务含义内聚、彼此关系紧密的对象放到同一个主题域里。

十大主题的划分不是拍脑袋拍出来的，它是从金融业务的本质倒推的。比如客户主题管“人”的主数据，产品主题管“卖什么”，合约主题管“客户和产品之间签了什么关系”，账务主题管“关系发生之后产生的钱怎么走”。这些主题之间有天然的边界，混在一起会让模型变成一锅粥。

做个简单的表格看更直观：

这个表不一定要照抄，但思路可以参考。在数仓架构设计阶段，主题域的划分就是地基。地基歪了，后面做实时数仓项目也好、做数据服务API也好，都是在歪地上盖楼。

1.3 产品主题在十大主题里的位置

产品主题在十大主题里属于最容易被轻视、但坑最多的一块。为什么？因为产品的静态管理属性多，看起来就是个“小维表”，很多建模的人不愿意花精力在上面。但银行业务里，产品几乎和所有主题都挂钩：客户签约的是产品，交易记账靠的是产品规则，风险计量要看产品特征，营销活动也要圈选产品范围。

产品主题建模做得不好，下游客户主题、账务主题、风险主题全部跟着遭殃。一个最典型的例子：产品代码一变，全链路的口径就乱了。产品停售之后老客户还在持有，新老代码怎么映射、历史报表按哪个口径统计，这些问题都要在逻辑模型层面提前设计。产品主题薄，不代表它不重要，恰恰因为它是很多关联关系的锚点，才需要格外慎重。

2. 产品主题建模：核心要素与设计逻辑

2.1 产品主题拆解：从“业务对象”而不是“系统功能”出发

做产品主题建模，第一步是明确边界：我们建模的对象是“产品”本身，而不是“卖产品的流程”或者“管产品的系统”。很多团队容易犯的错，是把产品管理系统的功能菜单直接搬过来当实体，比如把“产品审批记录”“产品上线流程”这种流程性数据也硬塞进产品主题。

从业务对象出发，产品主档实体一般包含这些属性：产品代码、产品名称、产品大类（存款/贷款/财富/支付）、产品小类、币种、期限类型、利率类型、计息方式、发行机构、产品状态、建立日期、停售日期等。这些都是描述“产品是什么”的固有属性，不随具体客户和合约变化。

另外一个容易被忽略的点是产品分类。不同系统里产品分类口径经常不一致，网银系统一套分类、核心系统一套分类，报表要按统一口径统计产品规模时经常对不上。在逻辑模型里必须统一一个产品分类维，把各系统的分类映射到这个统一维度上，这件事本质上也是数仓建模调研的关键内容之一。

2.2 产品层级与产品生命周期：两个绕不开的问题

第一个问题是产品层级。银行产品体系一般是三级：产品大类、产品线、具体产品。比如“存款-个人活期存款-某活期一号”。建模时有两种做法：一种是把层级字段直接冗余在产品主档里，另一种是拆独立的层级维度表。我个人的倾向是，如果业务分类相对稳定、层级不深，用扁平结构加层级字段就够了，查询简单、下游好理解；如果产品线经常调整，分类体系可能重构，就拆成层级维度表，避免调整分类时去update一张大表。

第二问题是产品生命周期。一个产品从设计、审批、发布、在售、停售到最终下线，中间要经历多个状态。很多数仓只记录了产品当前的“在用/停用”状态，历史状态全丢了。等业务要统计“某个时间段内市场上到底有哪些产品在售”时，数据已经补不回来了。逻辑模型里要明确建议产品状态字段加有效时间区间（起始日期、截止日期），为后续拉链存储打下基础。

2.3 产品主题与客户、合约、账务主题的边界

产品主题建模里，最容易出现的边界混乱就是把不该放的关联关系放进来。我见过最夸张的模型，产品表里直接带上了客户数、余额汇总，理由是“报表要用”。这种设计短期看省事，长期看就是灾难。你把汇总值放在产品主题里，日终跑批一更新，历史状态没了，明细也关联不上。

更合理的分工是这样的：

• 客户主题管“谁买的”，存客户主档、客户分层、客户关系；
• 产品主题管“卖的是什么”，存产品定义、产品属性、产品定价规则；
• 合约主题管“客户和产品之间的契约”，比如开户、签约、授信合同；
• 账务主题管“契约发生后的钱”，比如分户账、流水、余额。

一句话类比：客户是“人”，产品是“菜单上的菜”，合约是“下的单”，账务是“吃完之后的账单”。四个主题各管一段，边界清晰了，逻辑模型才真正可用于指导物理建模。

3. 产品主题逻辑模型落地的实操步骤

3.1 圈实体：先列全，再收敛

逻辑模型设计不是一上来就画飞龙，而是要老老实实做信息收集。第一步是调研，找业务要产品目录、产品管理办法、产品参数表，把能见到的产品相关数据都列出来。第二步是圈候选实体，比如产品主档、产品分类、产品属性扩展、产品利率/费率、产品渠道适用关系、产品协议条款。这时候宁可多列，不要漏。

然后做收敛。收敛的原则是：属性差异不大的实体合并，管理独立性强的实体保留。举个例子，不同产品的利率规则差别很大，但“产品利率”本身作为一个独立实体是合理的，因为它和产品主档是一对多关系，一个产品可以对应多档利率；而“产品发行机构”如果只是产品主档上的一个属性，就没必要单独拆一张表，除非一个产品确实可以由多个机构联合发行。

3.2 定属性与主键：产品代码到底怎么设计

产品代码设计是产品主题里最容易踩坑的环节。银行老系统喜欢用有业务含义的编码，比如“1101”代表个人活期存款。这种编码读起来方便，但一旦产品数量爆炸，编码规则就撑不住了。而且业务收购、系统整合时，不同系统的产品编码经常冲突。

我建议的逻辑模型设计是双主键思路：业务主键保留原有产品代码，用于跟源系统对接；代理主键用自增ID或者无含义序列，用于数仓内部表关联。这样既保留业务识别的能力，又避免跨系统编码冲突。逻辑模型文档里要显式写明主键定义和唯一性约束，纯靠文档读者自己猜，后面实现必然五花八门。

属性设计上也有一点心得：产品名称、产品大类、产品小类这些高频筛选字段，逻辑模型阶段就要明确是“代码+名称”双字段，还是只存代码。我的经验是“代码加名称”一起落到模型里，代码用于关联，名称用于下游报表直接展示，省得每张报表都去join一次码表。

3.3 画关系：一对多、多对多要谨慎处理

实体关系设计是LDM区别于普通表结构设计的核心。产品主题里的主要关系，我总结下来有这几类：

多对多关系一定要用中间实体拆掉，这是逻辑模型的一条铁律。产品和多渠道之间就是典型的多对多，一个产品在手机银行、网银、柜台都能卖，一个渠道也卖很多产品，如果不拆中间表，下游join的时候会出现重复数据，而且非常难排查。

3.4 从逻辑模型到物理模型的映射规则

LDM设计完，不能直接拿实体建表。逻辑模型是业务视角，物理模型要考虑存储、查询和性能。产品主题的数据量相对不大，产品主档、产品层级这类维度表可以做全量表；但带了有效时间区间的产品状态数据，要做成拉链表，确保历史状态可回溯。

物理模型阶段还需要增加一些逻辑模型里不存在的技术字段，比如etl_insert_time、etl_update_time、batch_id等。另外要考虑分区方案，历史拉链表通常按截止日期分区，全量表可以按更新日期增量同步。这里补充一点，现在很多团队喜欢用列式存储，产品主档虽然小，但在关联场景里会被高频扫描，合理的压缩和排序键设计也会明显提升查询性能。

逻辑模型往物理模型映射，一定要写映射说明文档，哪张物理表对应哪个实体、哪个字段对应哪个属性、转换规则是什么，不然逻辑模型和物理模型很快又脱节了，变成两套体系。

4. 常见问题与排查技巧实录

4.1 产品维度退化到事实表，什么时候该做

数仓维度建模里有个“维度退化”的概念，就是把维度表的某些属性冗余到事实表里。产品维度属于典型的可退化维度。交易事实表里通常会带一个产品代码字段，甚至直接冗余产品大类、产品名称，这样做的好处是查询交易时不用每次join产品表，性能提升非常明显。

但退化不能没底线。如果产品属性变化频繁，比如产品名称改了、产品分类调整了，退化到事实表的历史数据就全部错了。我的判断标准是：看字段的变化频率和筛选需求。产品大类、产品线这类几乎不随着时间变化的属性，放心退化；产品名称、产品利率这类会变的，不要一股脑塞进事实表，优先保留产品代码，需要其他属性动态关联维度表。

4.2 产品“换代码”不改实质，别说你没被坑过

银行经常做产品整合。老产品停售，新产品代码承接存量客户，业务上其实是同一个实质产品。如果你在数仓里只拿产品代码做关联，历史数据和新数据的口径就断了。

我踩过这个坑之后，现在的做法是在产品主题里增加一张“产品代码映射表”。这张表记录新旧产品代码的替换关系，带生效时间。跑历史报表的时候，先通过映射表把新产品代码替换回历史时期的产品代码，口径就统一了。这件事在逻辑模型设计阶段就要预留，不然后期再补，数据都已经跑过了，回溯成本非常高。

4.3 实时数仓项目下，产品主题还要不要“建模”

最近实时数仓项目特别多，很多同学问我逻辑数据模型是不是过时了。我的看法恰恰相反，实时数仓更需要LDM。实时场景下的维表是动态刷新的，产品维表通过CDC（变更数据捕获）从源系统同步到实时计算引擎，产品属性的变更实时生效。如果没有逻辑模型提前定义产品维表的粒度、属性和关系，实时链路大概率就是各做各的，A任务里产品字段叫prod_id，B任务里叫product_code，对不上就开始扯皮。

逻辑数据模型在实时数仓里的作用不是约束，而是对齐。它规定了“产品”这个业务对象在实时计算里依然只有一张维表、一套字段定义、一组关联关系。批流一体的大前提，就是批和流共用同一套逻辑模型定义，否则“一体”就无从谈起。

我再说清楚一点，数仓平台的数据服务中的API服务是什么？它本质上是把数仓里加工好的维表和指标，通过API接口暴露给业务系统。产品主题的LDM质量，直接决定了API返回的字段命名、颗粒度和关联关系是不是清晰。有了LDM，API是模型的一层出口，字段从哪张表来、跟谁join、口径是什么，一目了然；没有LDM，API就是临时拼字段，今天能用明天就崩。

4.4 产品主题高频问题速查表

5. 数仓建模调研之后的几点复盘

5.1 十大主题LDM和维度建模到底什么关系

做数仓建模调研时，常有人把逻辑数据模型和维度建模对立起来。其实它们是两层的。LDM解决的是“企业级数据底座怎么组织”，偏主题域和实体关系，更像第三范式或Data Vault的思路；维度建模解决的是“分析需求怎么快速响应”，偏星型模型和事实表/维度表。

成熟的做法是先投入精力建设企业级LDM，把客户、产品、合约、账务这些主题做实，再基于LDM生成面向分析需求的维度模型。产品主题的LDM就是星型模型里产品维度表的权威来源。没有LDM直接上维度建模，遇到业务变化就会反复重构集市层，维护成本极高。

5.2 别把逻辑模型当物理模型设计

这是新手最容易犯的错。拿到LDM文档，看到实体列表和属性列表，直接就开始建表。逻辑模型里说产品跟利率是一对多，那就建两张表呗，这没错，但逻辑模型里没说的是：物理模型里要不要分区、按什么键分区、数据量有多大、要不要用压缩、要不要调整字段顺序以适配列式存储。

正确的路径是：LDM做业务边界的锚定，数仓分层设计做数据流向规划，物理模型做性能和存储优化。三步各干各的事，不要混在一起。逻辑模型是“做什么”，物理模型是“怎么做”，两者都重要，但不能互相替代。

5.3 建模规范最终要靠团队协作落地

文档写得再好，落不了地就是废纸。我在实践中发现，建模规范要真正生效，需要三件事：第一是评审机制，产品主题里每个实体、每个属性、每个关系的定义，都要找业务人员和数据团队一起过一遍，不是说架构师一个人拍板就行；第二是命名规范，主题域名、表名、字段名、主外键命名都要统一，不然后面每个开发都有自己的风格；第三是版本管理，像这样一份doc文档，其实对版本演进不够友好，我后来把模型文档都用Git管理，每次变更都能追溯。

数字化的金融业务变化越来越快，产品主题尤其需要持续维护。新产品上线、老产品下线、产品规则调整，这些都要在LDM里及时反映。定期复盘模型与实际业务的一致性，比一次做到位更现实。

最后再分享一点个人体会。产品主题在十大主题里只是其中一块，但把它做扎实了，后面客户主题、账务主题、风险主题的关联都会顺很多。做数仓不像写业务代码，今天上线明天见效，建模的收益往往要过很久才看得到。等到业务提一个新需求，模型清晰的团队两天就能给出报表，模型混乱的团队要扯皮两周，差距一下就出来了。所以无论是看别人家的LDM文档还是自己从头建模，先别急着画表写字段，找个业务同事把这个实体关系讲一遍，如果能顺顺利利讲通，这个模型就已经成功了一半。

本文还有配套的精品资源，点击获取