什么样的表适合做拉链表

适合做拉链表的表

|------------------|---------------------------------------------------|
| 特征 | 说明 |
| 实体有唯一标识 | 如 user_id、job_id、application_id 等 |
| 核心信息会随时间变更 | 比如用户信息、申请状态、收藏状态等 |
| 需要追溯历史状态 | 比如想知道:某用户 3 个月前的邮箱是什么?某职位申请当时是什么状态?某用户当时的技能标签是什么? |
| 变更不频繁但重要 | 比如用户信息、申请记录、收藏夹等,变更不是每秒发生,但每次变更都值得记录 |
| 不是纯粹的行为日志/流水 | 比如浏览、点击、搜索等行为,更适合用日志表/流水表存储 |

不适合做拉链表的表

|-----------------------|------------------------------------------------|
| 特征 | 说明 |
| 记录本身就是"事件"或"行为" | 比如浏览职位、搜索关键词、点击广告,每次都是新行为,不是状态的变更 |
| 每条记录仅代表一次操作,无持续状态 | 比如用户今天搜索了"Java开发",明天搜索了"大数据",这是两条记录,不是同一条记录的变更 |
| 数据量大且变化频繁 | 比如用户每天浏览 100 次职位,如果用拉链表,会导致表过于膨胀,不如用流水表 |

|---------------------------------|----------------|-------------------------------------------------------------------------|
| 表名 | 是否适合拉链表 | 原因说明 |
| ✅ ods_user_account | 适合 | 用户核心信息(如邮箱、手机号、用户名、性别等)可能会发生变化,且需要追溯历史,比如"用户一年前的手机号是什么?" |
| ✅ ods_user_job_applications | 适合 | 用户的职位申请会有状态变更(如已投递 → 面试 → 已拒绝/已录用),每个 application_id 的状态与时间需要记录,非常适合拉链表 |
| ✅ ods_user_job_favorites | 适合 | 用户可能收藏/取消收藏某个职位,收藏状态随时间变化,适合拉链表(也可考虑单独的行为表) |
| ❌ ods_user_job_views | 不适合(推荐流水表) | 浏览行为通常是"看了什么职位",属于用户行为日志,每次浏览是一条新记录,不需要维护状态,用普通日志表即可 |
| ✅ ods_user_profile | 适合 | 用户的技能、期望行业、期望薪资、工作年限等信息经常更新,是典型的用户画像信息,需要拉链表记录每次变更 |
| ❌ ods_user_search_history | 不适合(推荐流水表) | 搜索词、搜索时间等属于用户行为,每次搜索是独立事件,用拉链表会冗余,建议存为行为流水表 |

ODS 层 拉链表适配性分析

拉链表的核心价值是记录数据的历史版本、追踪数据变更轨迹,适合用于「数据会随时间更新、需保留历史状态」的场景;反之,纯增量 / 无更新的表无需做拉链表(只会增加存储和计算成本)。

|---------------------------|--------------|----------------------------------------------|-------------------------------------------------------|
| 表名 | 是否适合做拉链表 | 核心原因 | 典型变更场景 |
| ods_user_account | ✅ 强烈推荐 | 用户账户信息(手机号 / 邮箱 / 性别等)会更新,需保留历史版本 | 手机号修改、邮箱更换、性别更正等 |
| ods_user_profile | ✅ 强烈推荐 | 用户画像(学历 / 期望薪资 / 技能标签等)是核心变更维度,需追踪历史 | 期望城市从 "深圳" 改为 "上海"、技能标签新增 "Spark"、期望薪资从 15k 调整为 20k 等 |
| ods_user_job_applications | ✅ 推荐 | 投递状态(pending/accepted/rejected)会变更,需记录状态变更轨迹 | 投递状态从 "待审核"→"已录用"、"待审核"→"已拒绝" 等 |
| ods_user_job_favorites | ❌ 不适合 | 收藏行为是「一次性新增」,删除收藏可视为 "反向新增",无 "更新" 语义 | 收藏 = 新增记录,取消收藏 = 新增一条 "取消" 记录(或物理删除),无需保留历史版本 |
| ods_user_job_views | ❌ 不适合 | 浏览行为是「纯增量事件」,浏览时长 / 来源等字段录入后不会更新 | 一次浏览行为的记录是静态的,不会后续修改 |
| ods_user_search_history | ❌ 不适合 | 搜索记录是「纯增量事件」,搜索关键词 / 筛选条件录入后无更新场景 | 一次搜索行为的记录是静态的,不会后续修改 |

相关推荐
武子康4 小时前
大数据-242 离线数仓 - DataX 实战:MySQL 全量/增量导入 HDFS + Hive 分区(离线数仓 ODS
大数据·后端·apache hive
SelectDB1 天前
易车 × Apache Doris:构建湖仓一体新架构,加速 AI 业务融合实践
大数据·agent·mcp
武子康1 天前
大数据-241 离线数仓 - 实战:电商核心交易数据模型与 MySQL 源表设计(订单/商品/品类/店铺/支付)
大数据·后端·mysql
IvanCodes1 天前
一、消息队列理论基础与Kafka架构价值解析
大数据·后端·kafka
武子康2 天前
大数据-240 离线数仓 - 广告业务 Hive ADS 实战:DataX 将 HDFS 分区表导出到 MySQL
大数据·后端·apache hive
字节跳动数据平台3 天前
5000 字技术向拆解 | 火山引擎多模态数据湖如何释放模思智能的算法生产力
大数据
武子康3 天前
大数据-239 离线数仓 - 广告业务实战:Flume 导入日志到 HDFS,并完成 Hive ODS/DWD 分层加载
大数据·后端·apache hive
字节跳动数据平台4 天前
代码量减少 70%、GPU 利用率达 95%:火山引擎多模态数据湖如何释放模思智能的算法生产力
大数据
得物技术4 天前
深入剖析Spark UI界面:参数与界面详解|得物技术
大数据·后端·spark
武子康4 天前
大数据-238 离线数仓 - 广告业务 Hive分析实战:ADS 点击率、购买率与 Top100 排名避坑
大数据·后端·apache hive