数据链路盘点

mercury 原始层 → SaaS 中间表 → REST API → Web · 2026-09-18 · 财务源表化改造后

一句话结论：屏蔽层存在（SaaS 侧 27+ 张中间表就是"清洗后的干净库"，Web 不直接读 mercury raw）。真正的问题不是"缺一层"，而是中间表有多套、口径没对齐——这次 onno 漏单就是 amazon_orders（订单视图灌）与 finance_monthly（财务事件灌）两张中间表口径不一致导致的。

raw 原始层（mercury） SaaS 中间表（清洗/转换） API / Web（消费）

01链路总图

raw 原始层 · mercury (222)

zipforce_amazon.spapi_orders / spapi_finances / spapi_settlements / spapi_order_items / spapi_refunds

onno_amazon.spapi_* · fittingirls_amazon.spapi_*

zipforce_noon.* / onno_noon.*

shared.mapping_zipforce / mapping_onno / mapping_fittingirls

→

mercury 视图 · 清洗逻辑①

v_onno_orders_unified

v_fittingirls_order_finance_detail

v_inventory_health / v_asin_daily

→ingest222 灌入时转换
汇率fx · 状态 · 品牌 · SKU聚合

SaaS 中间表 · 清洗逻辑②

amazon_orders / order_fees

finance_monthly / monthly_pl

amazon_settlement_monthly / amazon_refund_monthly

ads_* / noon_* / rankings_daily / inventory_health / sku_mapping / products

→

REST API → Web

finance.py 等（源表直读 amazon_orders+order_fees）

FastAPI → Next.js

关键：清洗逻辑散落在两处——mercury 视图（①）和 ingest222 灌入 SQL（②）。口径没人统一管，是漂移根源。

02中间表明细（27+ 张，按平台分组）

SaaS 中间表	mercury 源	转换	消费方
amazon_orders	raw v_onno_orders_unified 等视图	汇率fx→revenue_usd · days_waiting · is_abnormal · SKU聚合sku_list · 状态中文	API 财务/订单/看板
order_fees	raw spapi_finances + noon	费用 abs() · 逐单 commission/fba/promo/other（USD）	API 财务
finance_monthly	raw spapi_finances	SKU×marketplace×月聚合 · 汇率fx · 漏onno	已弃用财务已改源表
monthly_pl	raw spapi_finances + settlements	三方对账口径（posted_date）· 项目×月 P&L	API /finance/monthly（保留）
amazon_settlement_monthly	raw spapi_settlements	按月聚合回款 payout_usd	API 财务
amazon_refund_monthly	raw spapi_refunds	按月/SKU 聚合退货 units	API 财务
ads_daily / amazon_ads_daily / noon_ads_daily	raw ads_* 各表	按日/SKU/国家聚合 spend/sales	API 广告
noon_orders / noon_inventory / noon_sku_*	raw noon_orders / inventory_aging / ads_skus	Noon 专用口径 · n2p SKU映射 · 库龄桶	API Noon 模块
sku_mapping / products	raw shared.mapping_*	品牌映射（zipforce/onno/fittingirls）· 成本 cost_rmb	API 全站
sales_hourly / rankings_daily / inventory_health	raw spapi_* / rankings / inventory_fba	分时订单 · 排名 · 库存健康（stock_days/状态）	API 看板

03核心转换口径（写死）

口径	规则	位置
汇率折算	revenue_usd = amount / fx(currency)	222 官方 fx() 函数
有效订单	order_status NOT IN ('Canceled','Cancelled')	ingest222 + 接口统一
品牌映射	shared.mapping_{zipforce,onno,fittingirls}	sku_mapping
净额	net = revenue_usd − commission − fba − promo − other	order_fees（USD）
SKU 拆分	金额/费用按 sku_list 逗号展开平摊（多SKU单约9%）	接口层
country→marketplace	marketplaces 表映射（GB→UK 特例）	接口层
灌入方式	upsert（ON CONFLICT DO UPDATE）· amazon_orders 全量时 DELETE 幽灵行	ingest222 · 每日 04:30

04对照理想架构的缺口

缺口① 清洗逻辑分散在两处。mercury 视图（①）+ ingest222 SQL（②）各管一摊，改一处不知道影响哪些表。这次 onno 漏单就是 amazon_orders 与 finance_monthly 口径不一致的直接后果。

缺口② 无订单状态快照。amazon_orders 是当前状态，历史报表会随后续退款/状态变更漂移（说明书第6节的快照机制可解）。

缺口③ 无系统化对账审计。有 audit_log 但无金额勾稽/库存平衡等规则引擎（说明书第9节）。

缺口④ 无原始报文溯源。raw 在 mercury，SaaS 不存完整 API 报文（说明书第12节的对象存储方案）。

05建议（等你拍板）

不重复建设：raw 在 mercury 是架构事实，SaaS 不再建 raw 镜像（数据翻倍+双源不一致风险）。
治本方向：把散落在 mercury 视图 + ingest SQL 的清洗口径收拢成一套统一管理的清洗逻辑，所有中间表从它出，raw 变化只改一处、不穿透 web。
优先级：缺口②（订单快照）最契合当前痛点（历史报表漂移），可独立做；缺口①需逐模块重构 ingest，工程大。

本页为盘点文档，供决策参考。具体改造范围与时机由用户拍板后执行。