数据专栏 on 追风笔记

数据治理：从资产目录到口径统一

Sat, 08 Aug 2026 00:00:00 +0000

很多银行的数据治理项目，最后都沦为「补元数据、填责任表、交汇报 PPT」。运动一过，元数据过期、口径继续打架、下游照样不敢用这份数据。治理之所以失效，是因为它被当成了一份额外的「填表工作」，而不是数据生产流水线本身的属性。真正有效的治理，是让目录、血缘、口径和质量规则内建到系统里，而不是靠人肉维护。

治理为什么总做成运动

根本原因是把「治理」和「生产」割裂了。业务系统吐数据，治理团队在下游追着补标签、对口径。一旦人员变动或项目结项，治理成果立刻失真。

治理的目标不是「漂亮的报告」，而是让下游系统敢用这份数据。如果一份数据没人敢用来做决策，它就算被打了满分标签，也还是负债。

要扭转这个局面，得从三件最实在的事入手：盘清家底（资产目录）、追清来路（元数据血缘）、对齐说法（口径统一）。

资产目录：先盘清家底

资产目录回答的是「我们到底有哪些数据、归谁管、能不能用」。它不是 Excel 清单，而是带权属和分级的结构化注册表。

资产类型	例子	治理关注点
贴源表	核心系统流水	来源系统、更新频率
派生表	客户宽表	加工逻辑、依赖
指标	月活、不良率	口径定义、负责人
文件/接口	监管报送文件	敏感度、共享范围

目录必须和真实的元数据打通，否则就会出现「目录里说有、库里早就删了」的尴尬。一个可行的做法是：目录条目由采集任务自动生成，人工只补充业务语义，而不是反过来手工录入。

元数据与血缘：字段从哪来、到哪去

元数据解决「这个字段是什么」，血缘解决「它怎么变来的、又被谁用了」。两者合起来，才能做影响分析和溯源。

血缘怎么采

血缘最好自动采集，而不是靠文档口述。主流方式有两种：

静态解析：扫描 SQL、ETL 脚本、Spark/DAG 定义，提取表与字段级的输入输出关系。
运行时采集：在任务执行时记录实际读写的上下游，准确率最高但侵入性较强。

影响分析

有了血缘，一次核心系统字段口径变更，能立刻列出受影响的下游报表和指标。没有血缘，这类变更只能靠「老员工记忆」，风险极高。

血缘的价值不在炫技，而在于把「改一个字段要通知谁」从玄学变成可查询的图。它是治理能规模化的前提。

指标口径统一：最难的最后一公里

银行里「不良率」「活跃客户」「存款日均」这类指标，不同部门算出来常常不一样。根因不是谁算错，而是口径没有单一可信来源。

口径冲突的例子

「月活客户」可能被定义为：

渠道侧：当月登录 App 即算活跃；
零售侧：当月有动账交易才算活跃；
监管侧：按监管文件口径，且需去重。

三个数字放在一起对比，结论自然矛盾。更糟的是，没人说得清哪个是「官方版本」。

指标字典与单一来源

解决思路是建立指标字典：每个指标一条定义，包含口径 SQL、维度、过滤条件、负责人和生效时间。下游统一从字典取数，禁止各自重写逻辑。

-- 指标字典中「存款日均」的口径定义（单一来源）
SELECT cust_id,
 SUM(balance) / COUNT(DISTINCT cal_date) AS avg_daily_balance
FROM dwd_account_daily
WHERE cal_date BETWEEN :start AND :end
 AND balance_type = 'SAVING'
GROUP BY cust_id;

口径变更要走版本管理，旧口径保留可追溯，新口径标注生效日，避免历史报表被悄悄改义。

消息队列选型：Kafka vs Pulsar vs RabbitMQ

Sat, 28 Feb 2026 00:00:00 +0000

消息队列是分布式系统的神经系统，但 Kafka、Pulsar、RabbitMQ 三者的设计哲学差异极大。选错不是「换个客户端」的事，而是架构重做。下面从几个工程最关心的维度拆开看。

模型差异是根本

RabbitMQ：经典消息代理，面向「消息」和「队列」，支持丰富路由（直连、主题、头部、扇出）。适合任务分发、低延迟小消息。
Kafka：日志型、分区有序、拉取消费，面向「流」和「事件溯源」。适合高吞吐、可重放。
Pulsar：计算存储分离，分层架构，原生多租户和跨地域复制。适合既要 Kafka 的流、又要 RabbitMQ 的队列语义的统一平台。

# Kafka 顺序消费依赖分区
bin/kafka-console-consumer.sh \
 --topic orders --bootstrap-server b1:9092 \
 --partition 0 --offset earliest

关键维度对比

维度	Kafka	Pulsar	RabbitMQ
吞吐	极高	极高	中等
消息模型	流/日志	流+队列	队列
顺序性	分区内有序	分区/Key 有序	队列有序
运维复杂度	中	高（含 BookKeeper）	低
消费模型	拉取、可重放	拉取、可重放	推送

选型思路

事件流、日志、可重放 → Kafka 稳。审计、CDC、行为埋点这类场景它的重放能力几乎是刚需。
统一消息平台、多租户、跨地域 → Pulsar 更合适，但团队要扛得住运维。
任务队列、复杂路由、低延迟 → RabbitMQ 更直接。

// 用消息头做复杂路由（RabbitMQ 风格）
channel.basicPublish("orders.topic",
 "order.created.vip", // routingKey
 props, body);

别用 RabbitMQ 扛日均百亿事件流，也别用 Kafka 做需要复杂路由的任务分发——用对的工具，比用最强的工具重要。

分库分表策略与热点治理

Mon, 30 Mar 2026 00:00:00 +0000

当单表涨到几亿行、单库连接打满，分库分表就从「可选项」变成「生存项」。但分片一旦定错键，后期重构的代价接近重写。所以策略要在一开始就想清楚。

分片键是第一步，也是最重要的一步

分片键决定数据怎么散、请求怎么走。选错键，要么数据倾斜，要么跨分片查询泛滥。

选高频等值查询字段：比如账户号、客户号，保证大多数请求落单分片。
避免低基数或单调递增：性别这种分片键会制造大分片；自增 ID 做键会集中在最新分片，形成写入热点。
兼顾关联查询：同一客户的账户、交易最好同片，减少跨片 JOIN。

-- 按客户号哈希分 1024 片
SELECT * FROM trans_${hash(cust_id)%1024}
WHERE cust_id = ? AND trans_date >= ?;

扩容：预分片优于临时拆

一开始就按「未来三年规模」定足够多的逻辑分片（如 1024、4096），物理上先少后多。扩容只是把逻辑分片映射到新物理库，数据迁移量远小于重新分片。

策略	优点	缺点
预分片	扩容平滑	初期略冗余
范围分片	易理解	易热点
哈希分片	均衡	范围查询跨片

// 逻辑分片到物理库的映射可配置
String logic = "trans_" + (hash(custId) % 1024);
String phys = routeTable.lookup(logic); // 映射到具体物理库

热点治理

即使哈希均匀，业务上仍会有「明星账户」「大商户」成为单点热点。