锋识文档中心

深色模式

第一章 产品总览:它是什么、为谁而造、一条数据的一生 ​

第一次打开本平台的人,常见的困惑不是"这个按钮在哪",而是"我到底站在一台什么机器面前"。这一章不教任何一个具体操作,只做一件事:像一位老带新的工程师站在白板前,把整台机器的轮廓、它服务的人、以及一条数据从进来到变成一次出分的完整旅程,一次讲清楚。

这一章刻意写得比后面各章"高"一层:它给的是地图,不是路书。地图看熟了,后面每一章的手把手操作才有位置感——知道自己在拧流水线上的哪一颗螺丝。至于具体怎么点、填什么、有哪些坑,都留到第三、四、五章去讲。

1.1 它是什么:让数据变成"一次 HTTP 调用就能拿到的风控结论" ​

场景切入: 一个下游信贷系统的工程师,手上只有申请人的年龄、月收入、负债率、历史逾期次数,想问平台"这单能不能放款"。他不想懂数仓怎么分层、模型怎么训练、规则怎么写,只想发一次请求、拿一个答复。本平台就是为了让这次"发一次请求、拿一个答复"成立而存在的。

一句话: 本平台把企业数据「接进来 → 治理好 → 建成模型和规则 → 发布成对外 API」串成一条流水线。下游系统不需要懂数仓、不需要懂模型,只要发一次带凭证的 HTTP 调用,就能拿回一个决策结论(如"通过 / 拒绝")和一个分数。

它由三大模块首尾相接,各管一段:

  • 数据中台——产出干净、及时的数据。
  • 决策引擎——把数据变成"会下判断的逻辑"。
  • 数据网关——把逻辑安全地对外开放。

有点像一条食品加工流水线:数据中台是清洗切配,决策引擎是烹饪,数据网关是打包出餐的窗口。下游只感知到"点了一次餐、拿到一份结论",看不见后厨的三道工序。

mermaid
flowchart LR
    A[数据中台<br/>接入·建模·治理·编目] -->|喂数据| B[决策引擎<br/>指标·模型·规则·决策流]
    B -->|发布| C[数据网关<br/>应用·路由·鉴权]
    C -->|一次 HTTP 调用<br/>返回决策结论 + 分数| D[业务系统<br/>下游消费方]

为什么这样设计: 传统上,"原始数据"和"可直接消费的风控决策"之间隔着建模、工程化、发布、鉴权好几道墙,每道墙由不同团队、不同工具接力,交接缝里最容易丢数据、丢权限、丢时效。本平台把这条链路收进一个平台内闭环——数据在同一套存储里流动,权限在同一套模型里传递,发布在同一个网关上收口。结果就是下游一次调用即可拿到结论,不必关心背后走了几张表、跑了哪个模型。

说明: 当前形态是批处理平台——定时同步、定时加工按天或按周期跑,暂不含实时流处理。

1.2 三大模块,各管一段 ​

三个模块是一条流水线,各有归属、各有入口。这里只讲每个模块"解决什么、给谁用",具体怎么操作,进对应章节。

数据中台(详见第三章) 让数仓里始终有一份干净、及时的数据:把散落各处的库表接进来,按数仓分层建模,定标准、查质量、编成资产,再配定时同步。它是整条流水线的地基——后面两个模块吃的都是它的产出,数据脏、来得晚,决策再聪明也是"垃圾进、垃圾出"。主要给数据管理部用(数仓组负责接入与建模、治理组负责标准与质量)。

决策引擎(详见第四章) 把中台产出的数据,变成一段"给个申请、还我一个决策"的打分逻辑:用指标、模型、规则集搭出打分链,编排成决策流,再发布成对外 API,支持"规则 + 机器学习"双决策。本版新增的核心入口是模型 / 规则列表操作列里的**「接口」按钮**——发布后点开即弹出接口文档,还能在线试调。主要给风险管理部、信息科技部用(风险管理部出模型与规则,信息科技部定指标并编排、发布打分流)。

数据网关(详见第五章) 把决策引擎发布的能力安全地对外开放:管住"谁能调、走哪条路由、拿什么凭证"。下游拿到的只是一个应用凭证(apiKey),发一次 HTTP 调用即可出分,拿不到任何内部地址。主要给信息科技部、下游业务方用(信息科技部接口组管路由与发布,业务线持凭证消费)。

说明: 三模块虽首尾相接,但资源可见性各自隔离——决策引擎、数据网关的人未必看得到数据中台的数据源。这是设计使然,不是页面缺东西;为什么这样,见 1.3。

1.3 为谁而造:五个部门 ​

场景切入: 新人常问"这平台到底给谁用"。答案是五个部门,各守流水线的一段——三个建设部门接力把数据变成能出分的 API:数据管理部供数据、风险管理部出模型与规则、信息科技部把各产品串成打分流并对外发布;两个消费部门只在末端拿结论:信贷业务部、金融市场部。看懂这五个部门,后面"我为什么看得到 / 看不到某个页面"就有了参照系。

部门(代表演示账号)在平台里做什么对数据的权限
数据管理部(data_admin 韩梅 / dwh_lin 林伟东 / gov_wu 吴静)供数据:数仓组接入数据源、分层建模、发起建表工单;治理组定标准、查质量、配脱敏、编目;部门负责人做建表与数据申请审批中台数仓 OWNER + 审批人
信息科技部(dev_engineer 孙浩 / metric_xu 徐磊 / gw_ma 马丽)串流程:指标组定指标数据集;工作流组把模型与规则编排成打分流、配定时调度;接口组配路由、对外发布对别人的数据是 READ(敏感列是否掩码,先看分享时怎么配、没配的看平台有没有把它登记成敏感列);对自己建出来的表是 OWNER
风险管理部(model_zhao 赵雪 / strategy_feng 冯燕)出模型与规则:建模组训练模型出通过概率;策略组写规则集 / 评分卡 / 决策流;首席风险官拍板阈值与模型上线对别人的数据是 READ(敏感列是否掩码,先看分享时怎么配、没配的看平台有没有把它登记成敏感列);对自己建出来的表是 OWNER
信贷业务部(credit_biz 李强)只做下游消费只读需求方角色(经网关应用凭证消费)
金融市场部(stock_biz 张伟)只做下游消费只读需求方角色(经网关应用凭证消费)

说明: 上表两类下游消费方(信贷业务部 credit_biz、金融市场部 stock_biz)在流程里只做消费——通过网关应用凭证(apiKey,演示中每类消费按业务线各持一个网关应用凭证——信贷消费经 RISK-CONSUMER-001、金融市场消费经 STOCK-CONSUMER-001)发起调用;其演示账号本身是只读需求方角色,不直接建 / 写平台数据。

权限怎么发(记住两句话就够): 平台不给每个人配一堆零散权限,而是把权限打包成少数几个模块角色(要哪块给哪块),再由资源层授权决定能动哪些数据——资源默认私有,分 OWNER(建 / 写 / 管 / 分享给别人)与 READ(读,敏感列是否掩码另有判定,见下)两级。所以"能进页面"和"能动这份数据"是两回事:信息科技部、风险管理部的人能进所有建模页,但没授权的数据源,在下拉里就是空的。角色体系与授权的完整细节,见第二章。

说明: 字段级脱敏只对中台自建数仓生效(外部源不归它管),而且当前口径是默认明文:一张表的数据默认不被改写,资产属主本人看到的永远是明文;只有当属主把表分享给别人,受让人才可能读到掩码——具体掩成什么样,先看属主在分享时给这一列配了什么规则,没配的列再落到"平台有没有把这一列登记成敏感列"的兜底一层。超级管理员另有免脱敏白名单,读中台库为明文。所以看到明文时先别急着报"脱敏失效",先问一句"我是不是这张表的属主"。这三档判定的完整讲法见第二章 2.5.2,操作见第三章 3.7。

1.4 一条数据的一生:从每天定时同步到一次真实出分 ​

场景切入: 前面把三个模块拆开讲了,难免有"零件都认识、装起来什么样"的悬空感。这一节把它们焊回一条线,用"信贷准入评分"这个最典型的场景,跟着一条数据走完全程,让每个模块回到它在流水线上的位置。

整条旅程里:数据中台保证"有数据",决策引擎保证"会判断",数据网关保证"安全地对外",下游只感知一次 HTTP 调用。

mermaid
sequenceDiagram
    participant D as 下游信贷系统
    participant G as 对外消费网关
    participant F as 决策流(决策引擎)
    participant M as 机器学习模型
    D->>G: ① POST /score/credit + 凭证(请求体带扁平特征)
    G->>G: ② 校验 apiKey / 应用-路由绑定
    G->>F: ③ 转发,切成打分服务身份执行
    F->>M: ④ 把请求体特征喂给模型算通过概率
    M-->>F: ⑤ 通过概率
    F->>F: ⑥ 规则集判定命中
    F-->>G: ⑦ 返回决策结论 / 分数
    G-->>D: 出分原样送回下游

注:信贷示例的四个特征由下游在请求体里直接传入,决策流本身没有"读数仓"这一类节点(可用节点只有开始 / 结束 / 规则集 / 分支 / 子流 / 机器学习模型)。打分链路若确需取中台数据,走的是一个专用的打分服务账号——它是最小权限身份,和普通用户一样受同一套脱敏规则约束,并不自带"看明文"的特权(见第二章 2.5)。

平时每天在跑(数据中台): 业务库经定时同步任务每天搬进数仓贴源层,再经两步 SQL 加工——清洗标准化成明细层、按申请人汇总成特征宽表;治理侧已给身份证 / 手机号等敏感列配好脱敏、给关键字段配好质量规则。结果:数仓里始终有一份干净、及时、可打分的数据。

一次性搭好(决策引擎): 信息科技部指标组在特征宽表上定义指标;风险管理部建模组训练一个模型输出通过概率、策略组配一套按优先级、命中即返回的规则集,把概率翻译成结论(通过 / 拒绝 / 复核);最后由信息科技部工作流组用决策流把"算概率 → 过规则 → 出结论"编排成一条打分流,交接口组对外发布。

一次性开放(数据网关): 把打分流发布成对外路由 /score/credit,给下游注册一个应用拿 apiKey,并把路由绑定给它。

运行时 · 一次真实调用: 下游只需持有应用凭证,发一次扁平 JSON 的调用,不需要平台账号、也不需要懂模型编排:

bash
curl -X POST http://<对外消费网关地址>/score/credit \
  -H "X-APP-ID: <应用标识>" \
  -H "X-API-Key: <系统下发的 apiKey>" \
  -H "Content-Type: application/json" \
  -d '{"age":35,"monthly_income":15000,"debt_ratio":0.3,"overdue_count":0}'

平台内部依次:网关校验凭证与路由绑定 → 转发并切成打分服务身份执行 → 模型算出通过概率 → 规则集判定命中 → 返回结论。下游拿到的响应就是:

json
{
  "code": 200,
  "msg": "操作成功",
  "data": {
    "outputs": {"decision": "通过", "approveProb": "0.744778", "admission_score": "90.0"},
    "instanceId": "...",
    "success": true,
    "status": "SUCCESS"
  }
}

注意响应结构: 上面是完整响应体——三个业务值(决策 / 通过概率 / 准入分)裹在 data.outputs 里,外层还有 code / msg / data 外壳;而且通过概率、准入分返回的是字符串("0.744778" / "90.0")而非数字。消费端若 JSON.parse 后按数字型断言,需自行做一次类型转换,以免踩坑。

同一条链路对不同申请画像,给出可复现的决策,可当"这台机器真能出分"的直观证据:

画像关键特征决策结论分数
优质月收入高 / 负债低 / 无逾期通过90
高逾期逾期多次拒绝20
高负债负债率高拒绝20
边缘通过概率偏低拒绝40

说明: 上述参数与出分仅用于本节演示,不代表任何真实风控标准;实际以业务方正式的风控策略为准。另外,不是每张表都要走这套完整建模——只想"搬来查一眼"的边角表,有更轻的"同步直用"路径,详见第三章。

至此,整台机器的轮廓已经清楚:三大模块串成一条"接数据 → 会判断 → 安全对外"的流水线,五个部门各守一段,一条信贷申请从每天的定时同步一路走到一次真实出分。

从下一章起,先讲怎么登录进来、看懂菜单、认清自己的角色(第二章),再回到流水线的第一环——数据中台,手把手把功能从零跑通。

© 2026 锋识科技 ifengsee.com