去年我接到一个内部代号叫 financial-services 的项目。名字很宏大最初的处境却相当朴素三个业务部门、六套外围系统客户信息散落在不同数据库里连这个客户在我们这儿到底有多少资产这种基础问题都答不上来。业务同事真正要的从来不是多一张报表而是我在服务客户的那一刻能不能直接把他的全景信息调出来。这个项目最终做成了一套客户数据服务平台——统一客户身份、统一标签口径提供实时画像查询和风险提示服务。整个过程踩坑无数也沉淀下不少经验。如果你在做金融科技、数据平台或者正被数据口径对不上折磨这篇复盘应该能派上用场。我会把从需求梳理、技术选型、模型设计到上线运营的完整链路讲清楚包括那些让我加班到凌晨的问题。1. 项目背景三套系统三套真相1.1 一个客户到底有多少资产都答不上来的尴尬我们单位有三套前端渠道系统柜台、网银、手机App。它们在不同时期由不同团队建设背后各自挂了数据库。客户在网点柜台上查到的资产总额和手机App上显示的经常对不上。原因不复杂网银统计的是本渠道绑定账户的资产柜台统计的是客户号下所有账户的资产App用的又是一套独立缓存。问题落到日常服务场景里就很尴尬。客户打电话来问我在你们这里到底放了多少钱客服人员要开三个系统分别查一遍最后手工加总。更头疼的是客户经理手上的高价值客户名单每个月用Excel从不同系统导出再人工合并经常出现同一个客户被统计成两个人或者大客户直接漏掉的情况。1.2 业务真正要的不是报表调研阶段我们访谈了客服、客户经理、分支行管理人员听到最多的不是帮我开发一张报表而是一个更基础的诉求能不能让我在接触客户的瞬间看到他完整的画像、历史交互记录、资产分布和风险提示报表是静态的而且按部门口径建同一批客户在不同报表里人数都不一样。业务想要的是围绕一个人的实时全景视图。这个认知差异决定了项目的走向——不是再做一堆报表而是搭一套数据服务。把分散在各业务系统的数据汇聚、清洗、关联、打标签再通过API把能力开放给客服工作台、客户经理App、运营分析后台。这个底层平台在我们内部就叫 financial-services 项目。1.3 目标边界和量化指标项目启动时我们定了几条边界避免做成什么都装的无底洞不碰核心账务和交易链路只做数据汇聚和服务输出不做风控决策主体但为风险提示提供数据支撑统一客户身份、统一指标口径提供实时与准实时的画像查询服务。量化指标定得很直接指标目标值画像查询API P99延迟 200ms数据从发生到可查询≤ 5分钟客户统一覆盖率99.5%以上指标口径一致率100%指标字典范围内日增量数据处理千万级记录这些指标在后面每个技术决策里都起到了锚的作用。为了P99延迟达标存储层做了读写分离为了5分钟时效实时链路上了Flink而不是纯靠T1批量。2. 技术选型我们为什么这么搭2.1 处理架构选择了 Lambda而不是 Kappa不少技术文章推崇Kappa架构——统一用流处理把批量当流的特例。思路很漂亮但金融服务场景有一个绕不开的需求数据修正确认。比如一笔交易因为渠道回调延迟凌晨才确认成功白天的实时统计已经算过了又比如新规则上线后要把历史三个月的标签全部重算一遍。Kappa在这种场景下要么变得极其复杂要么回刷成本高到难以接受。所以我们采用了Lambda架构实时路径Canal监听业务库binlog接入KafkaFlink消费后写宽表和在线存储离线路径每日凌晨批量抽取进入数仓清洗、关联、指标计算后回刷实时结果做校准。两条链路看起来是双份工作但换来的是可以回算。金融数据最怕改不回来。有一次业务方调整了高价值客户的判定阈值从月均资产50万降到30万存量客户名单要回溯重算。如果只有实时链路这种回溯根本没法做。离线重算后覆盖实时结果这是Lambda架构在金融场景里最值钱的地方。2.2 存储层没有银弹按读写路径拆分很多团队建这类平台时想用一个组件解决所有问题结果两边不讨好。我们一开始也想用统一数据湖加查询引擎实测下来发现在线查询和离线分析的读写模式完全不同离线分析大吞吐、长查询、支持复杂关联对延迟不敏感在线服务高并发、低延迟、查询路径短扛不住大Join。最终存储层这样拆数据用途存储组件理由明细归档、离线计算HDFS/Iceberg支持快照、回刷成本低标签宽表分析ClickHouse分析型查询快压缩比高在线画像查询StarRocks Redis并发高、延迟低Redis扛热数据关系图谱图数据库关联查询客户-家庭-企业这套组合不是一上来就定的中间换过组件。最初在线查询用普通关系型数据库做KV数据量过千万后P99延迟迅速恶化后来迁移到StarRocks做宽表引擎、Redis做缓存层线上延迟才压到目标以内。2.3 元数据中心最容易忽略却最重要的底座技术选型时差点漏掉一个东西——元数据中心。没有统一元数据管理表命名、字段类型、加工逻辑各写各的三个月后没人说得清某个字段怎么来的。后来我们不得不花大力气补建这是整个项目里最让我后悔的决策之一。如果重来我会把元数据中心当作和存储同等重要的一层一开始就要求所有表结构、指标定义、血缘关系登记在册。3. 客户统一视图最难的不是技术是同一个客户3.1 ID-Mapping金融场景的独特挑战统一客户视图的第一步是把不同系统里的同一个客户对上号。听起来简单做起来相当烧脑。一个客户可能有手机号、证件号、银行卡号、设备ID等多重标识分散在不同系统里。这个同人识别问题本质上是实体对齐。我们用了两轮策略第一轮确定性匹配以证件号、客户号这类强标识为准直接关联解决约70%的客户第二轮概率匹配对没有强标识的客户用设备指纹、常用地址、行为时间线做相似度打分配合图计算做连通分量归并。金融场景有一个特别敏感的约束宁可少合不要误合。因为把两个不同客户错误合并后果可能是资金安全级别的。所以我们设了很高的匹配置信度阈值不确定的客户进人工核查队列由运营人员在管理端逐条确认。流程虽然慢但安全边际必须守。3.2 OneID 模型怎么设计ID-Mapping跑通后我们建了一张全局客户主索引表把所有ID挂到统一客户ID下。核心结构思路主索引表one_id、客户类型、证件类型、证件号、手机号、创建时间客户维度表资产总览、风险等级、归属机构、客户经理、标签快照关系表one_id之间的关联边家庭、企业、担保关系。数据模型上没有做一张大宽表包打天下而是分成核心主索引维度扩展关系边表。金融客户关系比较复杂一个人可能既是个人客户又关联企业客户一张表装不下也装不灵活。3.3 服务层宽表优先动态扩展兜底在服务层我们把高频查询场景做了预聚合。客服工作台打开客户详情页需要一次性展示基本信息、资产、标签、近期行为等如果每个模块实时到底层分别查询网络开销加多次Join会让延迟失控。所以我们构建了一张客户画像宽表把高频字段全部冗余进去查询就是一次宽表点查加一次缓存命中。预留了扩展字段用JSON承载低频、非结构化的标签信息避免每次新增标签都改宽表结构。这个设计看起来不优雅但非常实用。金融标签数量增长很快如果每个标签都走结构变更流程成本太高。JSON扩展加版本号管理半年内平稳扛住了数百个标签的扩展需求。4. 标签体系衡量金融客户的尺子怎么做的4.1 标签不是拍脑袋贴上去的在金融服务场景里标签是业务人员理解客户的度量衡。我们内部把标签分为四层原子标签直接来自原始数据如账户余额、最近一次交易时间统计标签简单聚合得到如近30天转入金额、月均资产规则标签基于业务规则计算如近90天无交易沉睡客户模型标签基于机器学习打分如流失概率、价值分层。举一个例子业务方想要潜力客户标签。我们把它拆成可计算的规则——近90天净流入资金大于10万、持有产品数≥2、非睡眠状态、模型价值分处于前30%。规则写清楚后开发过程基本没有歧义。最怕的是业务方说你看着定义吧模糊需求最后一定返工。4.2 口径管理最大的坑没有之一如果这个项目只能总结一个教训我会选择口径管理。上线第一个季度我们发现活跃客户标签在三个部门眼里是三个定义运营部认为是近30天登录过App客户部认为是近30天有过交互或交易管理层认为是近90天日均资产超过1万。同一个词三个数字开会能吵一下午。后来强制推行指标字典每个指标必须登记名称、业务含义、计算公式、数据来源、更新频率、负责人。口径修改必须走评审不允许私下改SQL。这套机制看起来很重但正是它让后来所有报表和标签对得上。几个部门坐下来先把什么叫活跃、什么叫高价值、什么叫流失这类基础概念对齐后续开发才有效率。4.3 标签的灰度、上线与下线标签上线走了产品发布流程先评审、再灰度、最后全量。灰度阶段的做法是选取部分客户把标签结果和业务方手工计算结果对比准确率达到要求后才放量。还有一个容易被忽略的点标签下线时数据不能物理删除。金融场景经常要复盘历史必须保证任意时间点的客户标签可回溯。所以标签表按日分区下线只停更新不删历史。5. 数据质量金融数据不能差不多5.1 最容易脏的数据往往藏在细节里我印象最深的一个问题是时区。某上游系统把交易时间按UTC8存成了UTC导致实时链路凌晨两个小时的统计全部错位对账怎么都不平。查了整整一天最后发现是JDBC连接串里的timezone参数配错了。这类问题在金融数据里非常多渠道重复计数、客户合并后历史归属未迁移、上游系统延迟回调导致状态覆盖。所以质量监控不是出了问题再说而是前置校验加事后扫描双通道。前置校验跑在Flink任务里过滤明显异常数据事后扫描由离线任务每天检查核心字段质量异常直接推送值班群。5.2 四维质量监控完整性、一致性、时效性、准确性实际跑的质量规则供参考维度检查内容示例完整性关键字段空值率、主键重复率one_id不能为空证件号不能丢失一致性同指标多源比对A系统资产总额 vs B系统资产总额差值0.1%时效性数据产生到入库延迟实时链路延迟5分钟告警准确性抽样核对、规则校验抽100个客户人工比对标签正确率准确性监控不需要全量全量也做不到但抽样必须坚持。每个月固定抽500个客户由业务同事对照原始凭证逐项核对标签结果。这个土办法看起来笨却是发现系统性问题最可靠的手段。5.3 数据血缘出了问题能定位出了质疑能解释金融服务项目做数据血缘不是为了炫技是为了两条第一线上数据有问题时能从上到下快速定位是哪一环节出错第二业务方或审计对指标提出疑问时能拿出完整加工链路自证清白。血缘做到了字段级从看板或API的某个字段可以一直追溯到源系统的表和字段以及中间的每一步加工逻辑。实现上不复杂——在元数据中心登记每个任务的上游表和输出表再在SQL解析层自动抽取字段映射关系。难的是坚持每次任务上线都必须更新血缘登记否则图就断了。我后来把这条写进了发布检查清单不全量登记不允许上线。6. 踩坑实录那些让我加班到凌晨的问题6.1 Flink实时任务的背压上线第一个月赶上业务大促实时链路延迟从正常1分钟一路飙到40分钟。第一反应查Kafka消费Lag发现Flink任务消费速率断崖下跌。再看监控某个算子繁忙率顶到100%吞吐量反而降了——典型背压。原因是并行度在上线初期拍脑袋定的没针对数据倾斜做预判。某类高净值客户的事件特别多压力全打到一个Key上。最后做了三件事扩大分区数、针对热点Key加随机后缀做局部聚合再二次聚合、把串行外部调用改成异步IO。延迟才回到目标范围。这个坑说明Flink任务的并行度和状态设计必须在压力测试阶段就验证不能上线后再补救——补救的时候业务已经在骂人了。6.2 ClickHouse 数据倾斜一台机器拖垮全家我们用客户账号做ClickHouse分区键结果分片之间数据量严重不均有的分片数据量是其他的十倍CPU和磁盘被打满整个集群查询变慢。排查确认是分区键选择失误客户账号末位数字分布天然不均加上个别超大客户的行数特别多。修复方案是改成复合分区键并给超大客户所在的批次做了加盐处理。同时给ClickHouse集群加了分片数据量监控偏差超过阈值自动告警。数据倾斜这种事没有银弹只能靠监控和及时调整。6.3 调度依赖的假死离线链路有一次出现诡异场景凌晨调度任务全部卡住看着像死锁。排查半天发现任务A依赖任务B任务B又依赖A的后续版本形成环形依赖加上调度系统超时设置不合理任务互相等待到天亮才被整体拉起。结果所有任务同一时间开跑把计算资源直接挤爆。这个坑让调度规范多了一条铁律禁止跨环节循环依赖所有任务超时和重试策略必须显式配置每次新增任务都要做依赖图谱检查。调度平台本身有环检测但只是报警不阻断我们在配置层又强制加了一道校验。6.4 权限管控金融数据平台不能裸奔最让我后怕的是权限管控。项目前期为了开发效率大数据平台权限非常宽松几乎人人可查明细数据。直到一次内部审计发现某个临时账号可以访问全量客户明细才意识到问题严重性。随后补上库表级权限、行级权限按机构隔离、敏感字段脱敏、操作审计日志整整花了三个月。这三个月如果放在项目之初成本会低很多。金融数据没有内部人随便看这个说法权限越早收紧越好。7. 上线之后怎么让这套服务真正被用起来7.1 从推送报表到场景化服务平台上线初期业务方并不买账。你提供了一个再强大的数据中台业务打开工作台还是要自己查、自己凑体验比Excel快不了多少。后来我们意识到光有平台不够得把数据服务嵌入到具体场景里。我们做了两个落地场景一个是客服工作台的客户全景卡片客服接起电话瞬间就能看到客户基本信息、资产变动、最近交互记录和风险提示另一个是客户经理App的今日待办每天推送哪些客户需要回访——沉睡唤醒、大额变动、潜力挖掘。这两个场景一上线日活直接翻了几倍。数据服务的价值不在数据本身而在业务动作的转化。7.2 SLA 和容量承诺之前先掂量资源对外承诺的SLA是画像查询接口可用性99.9%P99延迟200ms实时数据链路延迟不超过5分钟离线任务在每日8点前完成。这些承诺背后是实打实的容量规划。我们测算过正常日峰和业务大促峰值的QPS差异预留3倍缓冲并给核心接口做了限流降级超过阈值时优先保证读多写少的画像查询临时下调标签更新频率。服务层扩机器容易但存储和实时计算的扩容周期长一定要提前做压力测试别等流量来了再买机器。7.3 重来一遍我会在第一天做什么如果现在再让我从零启动一个类似项目有三件事一定放在第一天第一先建指标字典再开发标签把口径争执前置到设计阶段而不是上线后扯皮 第二权限模型和元数据中心不能后补要作为基础设施和存储层同时建设 第三所有实时任务的压测在开发阶段就完成而不是上线前一周才做。这三点都是拿加班换来的教训写出来是希望同行们少走一点弯路。最后再分享一个操作细节。后来我们给所有标签都加了验证小样机制任何标签上线前业务方必须随机抽50个客户对照原始数据人工核对标签结果。一开始大家觉得流程太麻烦跑了大半年后因为标签错误导致的返工几乎绝迹。所谓快很多时候是慢下来换来的。