简介金融业逻辑数据模型中产品主题的专题解析文档面向数据仓库建模人员、金融行业数据分析师及架构师用于理解数仓十大主题中产品主题的逻辑模型设计。文档系统阐述产品定义与准入原则、唯一标识、分类体系银行类、投资类、保险类、产品组与产品包以及金额、期限、数量、描述、率特征等五类产品特征重点梳理产品与内部机构、协议、渠道、事件、营销活动、当事人和地域的关系历史并说明产品包与产品组的区别、可变利率与固定利率的差异等建模细节。通过产品与其他主题的关联可支撑协议层收益、成本、风险、利润贡献度分析以及产品渠道使用情况分析为产品管理、营销创新和风险管理提供数据基础。资源为单个doc文件约50KB内容精炼、结构完整便于直接查阅与二次整理。当前已有178人学习下载适合在金融数仓建模或业务数据梳理中快速建立产品主题框架的读者。 做数仓这几年我越来越觉得一份好的逻辑数据模型文档比几十张跑批任务还有价值。手里这份《金融业逻辑数据模型-数仓十大主题-LDM-产品主题.doc》是我接手某银行数仓项目时从一堆资料里翻出来的。当时第一反应是“这玩意儿这么重谁看得完”后来被各种指标口径对不上、表关系理不清的问题折磨过几轮回头再看这份文档才明白主题域拆得清不清楚直接决定了一个数仓能不能扛住业务变化。这篇文章我就拿产品主题当例子聊聊LDM里的十大主题到底怎么理解、怎么落地也把我在数仓建模调研和实践里踩过的坑一并整理出来希望对正在做数仓建模或者准备做数仓平台建设的同学有帮助。1. 从一份文档看数仓的底子LDM为什么值得反复研究1.1 什么是逻辑数据模型LDMLDM全称Logical Data Model逻辑数据模型。在完整的数据建模体系里它夹在概念模型和物理模型中间。概念模型解决“业务世界有哪些大对象”物理模型解决“表怎么建、分区怎么设、索引怎么加”而逻辑模型解决的是最核心的那个问题业务事实上到底有哪些实体、每个实体有哪些属性、实体和实体之间是什么关系。做数仓建模调研的时候你会发现很多团队根本没有这层中间产物。他们要么直接从业务库同步表结构过来要么是业务提一个需求就临时建一张表。短期看效率挺高时间一长就乱了客户表里混着机构信息产品表里塞了合约数据同一个“贷款余额”在两个报表里口径对不上。LDM的价值就是用一个相对稳定的中间层把业务对象的全貌固定下来业务再变模型的主体结构不容易散。你可以把LDM理解成盖房子时的施工图设计规范。它不讨论用红砖还是灰砖但会明确哪里是承重墙、哪里是门窗洞口、水管电管怎么走。砖可以换承重墙不能乱拆。数仓也一样数据库可以换、计算引擎可以换逻辑模型一旦乱了改起来伤筋动骨。1.2 为什么金融数仓非要“十大主题”不可金融行业的数据仓库尤其银行核心数仓业务域非常庞杂。客户、产品、合约、账务、渠道、机构、营销、风险、事件、公共是我在各大模型方法论里见过最通用的一套主题划分。几乎每家做金融数仓的公司都有自己的主题命名但万变不离其宗核心思路都是“高内聚、低耦合”把变化频率相近、业务含义内聚、彼此关系紧密的对象放到同一个主题域里。十大主题的划分不是拍脑袋拍出来的它是从金融业务的本质倒推的。比如客户主题管“人”的主数据产品主题管“卖什么”合约主题管“客户和产品之间签了什么关系”账务主题管“关系发生之后产生的钱怎么走”。这些主题之间有天然的边界混在一起会让模型变成一锅粥。做个简单的表格看更直观主题域核心业务对象举例典型实体客户主题个人客户、对公客户、客户分层客户主档、客户标签、客户关系产品主题存款、贷款、理财、支付产品产品主档、产品层级、产品费率合约主题开户、签约、授信合同合约主档、合约状态、合约参与人账务主题分户账、流水、余额账户、交易流水、日终余额渠道主题网点、手机银行、网银渠道主档、渠道交易机构主题总行、分行、支行、部门机构树、部门主档营销主题营销活动、客户响应活动、 campaign、响应记录风险主题风控指标、反洗钱、授信风险事件、名单、限额事件主题业务事件、系统事件事件日志、事件流水公共主题参数、码表、日期通用码表、日历维度这个表不一定要照抄但思路可以参考。在数仓架构设计阶段主题域的划分就是地基。地基歪了后面做实时数仓项目也好、做数据服务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_idB任务里叫product_code对不上就开始扯皮。逻辑数据模型在实时数仓里的作用不是约束而是对齐。它规定了“产品”这个业务对象在实时计算里依然只有一张维表、一套字段定义、一组关联关系。批流一体的大前提就是批和流共用同一套逻辑模型定义否则“一体”就无从谈起。我再说清楚一点数仓平台的数据服务中的API服务是什么它本质上是把数仓里加工好的维表和指标通过API接口暴露给业务系统。产品主题的LDM质量直接决定了API返回的字段命名、颗粒度和关联关系是不是清晰。有了LDMAPI是模型的一层出口字段从哪张表来、跟谁join、口径是什么一目了然没有LDMAPI就是临时拼字段今天能用明天就崩。4.4 产品主题高频问题速查表现象根因解决办法产品规模统计各系统对不上产品分类口径不统一在LDM中建立统一产品分类维产品join后出现大量空值事实表产品代码脏数据建模时定义默认产品“未知产品”过滤前先清洗产品名称改了历史报表跟着变维度表直接update产品维度改为拉链表保留历史版本客户持仓明细重复产品与合约粒度不一致导致一对多join明确事实表粒度为合约或交易明细实时产品维表数据不生效CDC链路未覆盖产品变更核对源库日志捕获范围补齐产品表变更订阅5. 数仓建模调研之后的几点复盘5.1 十大主题LDM和维度建模到底什么关系做数仓建模调研时常有人把逻辑数据模型和维度建模对立起来。其实它们是两层的。LDM解决的是“企业级数据底座怎么组织”偏主题域和实体关系更像第三范式或Data Vault的思路维度建模解决的是“分析需求怎么快速响应”偏星型模型和事实表/维度表。成熟的做法是先投入精力建设企业级LDM把客户、产品、合约、账务这些主题做实再基于LDM生成面向分析需求的维度模型。产品主题的LDM就是星型模型里产品维度表的权威来源。没有LDM直接上维度建模遇到业务变化就会反复重构集市层维护成本极高。5.2 别把逻辑模型当物理模型设计这是新手最容易犯的错。拿到LDM文档看到实体列表和属性列表直接就开始建表。逻辑模型里说产品跟利率是一对多那就建两张表呗这没错但逻辑模型里没说的是物理模型里要不要分区、按什么键分区、数据量有多大、要不要用压缩、要不要调整字段顺序以适配列式存储。正确的路径是LDM做业务边界的锚定数仓分层设计做数据流向规划物理模型做性能和存储优化。三步各干各的事不要混在一起。逻辑模型是“做什么”物理模型是“怎么做”两者都重要但不能互相替代。5.3 建模规范最终要靠团队协作落地文档写得再好落不了地就是废纸。我在实践中发现建模规范要真正生效需要三件事第一是评审机制产品主题里每个实体、每个属性、每个关系的定义都要找业务人员和数据团队一起过一遍不是说架构师一个人拍板就行第二是命名规范主题域名、表名、字段名、主外键命名都要统一不然后面每个开发都有自己的风格第三是版本管理像这样一份doc文档其实对版本演进不够友好我后来把模型文档都用Git管理每次变更都能追溯。数字化的金融业务变化越来越快产品主题尤其需要持续维护。新产品上线、老产品下线、产品规则调整这些都要在LDM里及时反映。定期复盘模型与实际业务的一致性比一次做到位更现实。最后再分享一点个人体会。产品主题在十大主题里只是其中一块但把它做扎实了后面客户主题、账务主题、风险主题的关联都会顺很多。做数仓不像写业务代码今天上线明天见效建模的收益往往要过很久才看得到。等到业务提一个新需求模型清晰的团队两天就能给出报表模型混乱的团队要扯皮两周差距一下就出来了。所以无论是看别人家的LDM文档还是自己从头建模先别急着画表写字段找个业务同事把这个实体关系讲一遍如果能顺顺利利讲通这个模型就已经成功了一半。本文还有配套的精品资源点击获取