六套完全仿真的 EDW——HKBC(香港全能银行)、AYA(香港综合保险公司)、Smire(香港综合业权业主)、Hilson(全球酒店集团)、Cathea(香港客货物流)与 P&C(消费品)——配有逼真的厂商原生模式、ClickHouse 中可进入 Medallion 的青铜层,以及实时事件流。用于在 VibeBI 上测试语义层、维度建模与自助分析。
虚构公司声明: 「HKBC」是仅为演示目的创建的完全虚构公司。它不隶属、不获汇丰控股、香港上海汇丰银行有限公司或任何真实银行背书,也不意在代表它们。
HKBC (Hong Kong Banking Corporation)是一家总部位于中环的香港全能银行,涵盖财富及个人银行、商业银行、环球银行及市场。该特许经营吸收港元存款、发放 HIBOR 按揭与无担保信贷、发卡、全天候运行更快支付系统与 PearlPay(PayMe 级)清算通道、为粤港澳大湾区贸易融资,并在 7.75–7.85 兑换波幅内记账美元/港元及离岸人民币外汇。
账簿覆盖港岛、九龙与新界约 10 家分行,外加前海大湾区批发交易台与伦敦市场交易台——每个仿真日产生相关联的 FPS 贷记、卡授权、CHATS/SWIFT 汇款、核心复式记账、AML 预警与 SAP 分录,并带有 农历新年 / 第一季税务贷款高峰 推升 PearlPay 点对点量、FPS 收款与个人贷款发放。
示例实体: 下表展示代表性业务实体及其源系统;完整 EDW 在全部 60 张青铜表中还包含更多实体、子类型与专用表(如 AML 案件、ECL 拨备、证券订单、授信红线)。在 V2 中, FpsPayment 及相关领域类驱动 PayToPostToBalance 主轴。
| 实体 | 源系统 | 表示例 |
|---|---|---|
| 分行 / 交易台 | hkbc_core | branch |
| 产品目录 | hkbc_core | product |
| 客户(CIF) | hkbc_core · salesforce | customer · account · contact |
| 存款 / 贷款账户 | hkbc_core | account · posting · deposit_balance |
| FPS / CHATS / SWIFT | hkicl_fps · hkicl_chats · swift | proxy · payment · rtgs_payment · message |
| 卡片 | fiserv_visionplus | card · authorization · clearing_transaction |
| PearlPay 钱包 | hkbc_pay | wallet · wallet_payment |
| 贸易融资 | hkbc_trade | documentary_credit · guarantee |
| 外汇 / 市场 | murex · bloomberg | fx_trade · position · fx_rate |
| AML / 信用风险 | nice_actimize · moodys_risk | aml_alert · case · credit_facility · ecl_provision |
| 财富交易 | hkbc_wealth | holding · securities_order |
| GL / COA | sap_s4 | journal_entry · journal_line |
HkbcEnterpriseSimulation 编排当日节奏;领域对象拥有产出逻辑。
PayToPostToBalance 是主要流程主轴。 FpsPayment.execute_lifecycle() (以及 PearlPay、卡、CHATS、SWIFT 对应类)走清算通道报文 → 核心复式记账 → 可选 AML 预警 → 日终存款余额 → 总账。 HkbcPortfolio.publish_foundation() 在支付运行前主数据化分行、产品、CIF 客户与账户。服务对象发出商业银行贸易、环球市场外汇、财富、风险与企业行。
| 领域实体 | 自然键 | 生命周期方法 |
|---|---|---|
Branch | branch_code | 在 hkbc_core 中主数据化的分行 / 批发交易台 |
Product | product_code | 往来/储蓄、按揭、卡、钱包、贸易、外汇产品目录 |
Customer | customer_id | CIF + KYC 分群;Salesforce 中的 CRM 镜像 |
Account | account_id | publish() → post_pair() 平衡分录 |
FpsPayment | payment_id | execute_lifecycle() → 清算通道 → 记账 → AML |
DocumentaryCredit | lc_id | 商业银行信用证 / 保函签发 |
FxTrade | trade_id | Murex 成交 → 美元/港元头寸 |
flowchart LR
PORT[HkbcPortfolio.publish_foundation]
PAY[FpsPayment.execute_lifecycle]
PORT --> PAY
PAY --> RAIL[FPS / PearlPay / card / CHATS / SWIFT]
RAIL --> CORE[post_pair in hkbc_core]
CORE --> AML[Actimize AML]
CORE --> EOD[EOD deposit balance]
EOD --> GL[SAP S/4 journal]
从 CIF 与产品主数据,经清算通道、核心记账、风险到财务关账。
示例视图: 此图展示贯穿 HKBC 生态系统的主要价值链;完整生成的 EDW 包含全部 32 套源系统及其此处未展示的跨职能集成、财富交易与大湾区贸易走廊。
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph master["CIF & product master"]
direction TB
CORE[hkbc_core CIF / account]
SF[salesforce]
CORE ~~~ SF
end
subgraph rails["Payments rails"]
direction TB
FPS[hkicl_fps]
PP[hkbc_pay PearlPay]
CARD[fiserv_visionplus]
CHATS[hkicl_chats · swift]
end
subgraph book["Core & risk"]
direction TB
POST[hkbc_core posting]
AML[nice_actimize]
ECL[moodys_risk]
POST ~~~ AML
AML ~~~ ECL
end
subgraph franchise["CMB · GBM · WPB"]
direction TB
TRD[hkbc_trade]
FX[murex]
WLT[hkbc_wealth]
TRD ~~~ FX
FX ~~~ WLT
end
subgraph corp["Corporate"]
direction TB
WD[workday]
S4[sap_s4 GL]
WD ~~~ S4
end
master --> rails --> book --> franchise --> corp
Harbourview Tower 总部及直属职能,配有代表性源系统。
示例组织结构: 此图展示主要汇报线;完整 HKBC 组织还包括全部 32 套厂商集成中的更多区域分行、大湾区交易台以及共享服务职能。
flowchart TB
CEO[HKBC Hong Kong]
CEO --> WPB[Wealth & Personal Banking]
CEO --> CMB[Commercial Banking]
CEO --> GBM[Global Banking & Markets]
CEO --> RISK[Risk & AML]
CEO --> FIN[Finance & ALM]
CEO --> HR[Human resources]
CEO --> OPS[Operations & branches]
CEO --> LEG[IT / legal / security]
目录 stage 将表从基础层分组到企业层。
所示示例子集: 这是完整 60 表清单按成熟度层分布的代表性切片;实际分布反映从基础层到企业黄金表的完整数据血缘。
flowchart LR F["foundation
~13 tables"] P["payments
~11 tables"] M["markets & risk
~12 tables"] C["commercial
~6 tables"] CO["corporate
~18 tables"] F --> P --> M --> C F -.-> CO P -.-> CO
逻辑关系与锚键。客户(customer_id) 与账户(account_id) 是主轴;支付通过 source_txn_id.
示例示意图: 此实体关系图展示核心逻辑模型;完整生成的 EDW 包含 60 张青铜表 覆盖 32 套厂商系统 以及额外的明细表与血缘分支。实体实例携带 entity_refs 于每一条发出的事件上,以便进行可关联性测试。
erDiagram
CUSTOMER ||--o{ ACCOUNT : holds
PRODUCT ||--o{ ACCOUNT : defines
BRANCH ||--o{ ACCOUNT : books
ACCOUNT ||--o{ PAYMENT : pays
ACCOUNT ||--o{ POSTING : ledgers
ACCOUNT ||--o{ DEPOSIT_BALANCE : snapshots
PAYMENT ||--o{ AML_ALERT : screens
COMMERCIAL_CLIENT ||--o{ TRADE_CREDIT : finances
ACCOUNT ||--o{ FX_TRADE : hedges
ACCOUNT ||--o{ WEALTH_ORDER : deals
32 个厂商前缀,60 张青铜表。
所示示例系统: 下图展示代表性厂商系统;完整生成的数据集包含全部 32 套系统及其在历史回填与实时流中的完整表血缘与集成点。共享源系统清单位于 kb/source_systems/ 跨行业复用 — HKBC 增加 hkbc_core, hkbc_pay, hkbc_trade,以及 hkbc_wealth 作为行业特有内部系统,外加香港市场清算通道。
每张表遵循 {source_system_}__{entity} 命名约定(例如 hkbc_core__account, hkicl_fps__payment),保留各产品真实导出模式中的厂商原生列形态与外键。VibeBI 在将记录提升至白银层与黄金层时推断主数据对齐。
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["hkbc_core branch · product · CIF · account"]
f2["salesforce · workday · sap_s4 dimensions"]
end
subgraph payments["Payments"]
direction TB
p1["hkicl_fps · hkbc_pay · fiserv_visionplus"]
p2["hkicl_chats · swift · core posting"]
end
subgraph markets["Markets & risk"]
direction TB
m1["murex · bloomberg · hkbc_trade · hkbc_wealth"]
m2["nice_actimize · moodys_risk"]
end
subgraph commercial["Commercial"]
direction TB
c1["salesforce pipeline · hubspot · marketo"]
end
subgraph corporate["Corporate"]
direction TB
co1["sap_s4 journals · anaplan · adp · ukg"]
co2["genesys · zendesk · servicenow · okta"]
co3["splunk · ironclad · onetrust · greenhouse"]
end
foundation --> payments --> markets --> commercial
foundation --> corporate
payments --> corporate
V2 面向对象仿真 → ClickHouse 中的青铜层;VibeBI 语义 → 白银 → 黄金,均在同一实例上。
面向对象路径: kb/industries/hkbc/ 定义运营主轴与实体模型; HkbcEnterpriseSimulation 编排领域生命周期; SourceSystem 适配器将厂商原生行导出到 hkbc_v2.
flowchart LR
subgraph kb["kb/industries/hkbc"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/hkbc"]
ORCH[HkbcEnterpriseSimulation]
DOM["FpsPayment.execute_lifecycle()
Account · Customer · FxTrade …"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse hkbc_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-hkbc — 60s 节拍经由 HkbcEnterpriseSimulation.generate().
实时频率: 每个节拍运行 PayToPostToBalance 状态机 — 领域对象发出相关联的 FPS、PearlPay、卡、CHATS、SWIFT、核心记账、AML 与总账行;今日的实时节拍只发出截至香港 as_of 以便支付流水在一天内增长。每拍规模可变(默认基数 5)。按需回填任意历史跨度(--days N 于实时脚本或 CLI)。
flowchart LR
START([60s tick]) --> SIM[HkbcEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> PAY[Payment lifecycles]
FOUND --> MKT[Trade · FX · wealth · risk]
PAY --> EVT[SourceSystem events]
MKT --> EVT
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
PayToPostToBalance 状态机 — 每次转移都是发出厂商行的领域方法。
流程主轴: 定义于 kb/industries/hkbc/process_model.yaml. 迟到模式(SWIFT 回执时滞、授权后的卡清算、AML 案件时滞、总账批处理延迟)与例外模式(FPS 拒绝、卡片拒付、AML 冻结、余额不足、信用证不符)从同一实体生命周期分支,而不是独立随机插入。
flowchart LR
OPEN[account_opened] --> INIT[payment_initiated]
INIT --> POST[core_posted]
POST --> AML[aml_screened]
AML --> CLR[cleared]
CLR --> BAL[balance_snapshot]
BAL --> GL[posted_to_gl]
INIT -.->|fps_reject| REJ[fps_rejected]
INIT -.->|card_decline| DEC[card_declined]
POST -.->|aml_hold| HOLD[aml_hold]
每张表使用相同的血缘包络;类别驱动实时行为。
示例类别: 全部 60 张青铜表遵循这一三类模式(快照、事务、事件),并具备一致的元数据与状态跟踪;示意图展示了贯穿整仓的该模式。
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["CIF · product · branch · account"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["Payments · postings · LC · FX · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["AML · card auth · access · NPS"]
E2[Append each live tick]
end
BRONZE[("hkbc_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
虚构公司声明: 「AYA」是仅为演示目的创建的完全虚构公司。它不隶属、不获 AXA SA、AXA 香港及澳门或任何真实保险公司背书,也不意在代表它们。
AYA 是一家香港综合保险公司——寿险及储蓄、健康(含自愿医保与雇员福利)及一般保险——经专属代理、银保、经纪、Aria by AYA 数字应用与嵌入式电子钱包伙伴分销。总部位于鰂鱼涌,中环设顾问中心,尖沙咀设 AYA 医疗中心,另有澳门分公司与前海大湾区销售办事处。
业务覆盖产品工厂、Magnum 级核保、拆分 PAS(寿险走 Ingenium 级、一般保险走 Guidewire)、FPS 保费收款、Varicent 佣金、全天候车险/旅游 FNOL、FINEOS 健康理赔、再保险分出、Prophet IFRS 17 估值与 SAP S/4 分录——并带有 台风季一般保险理赔上升 (六月至十月)以及数字与代理渠道上的农历新年旅游/北上汽车险高峰。
示例实体: 下表展示代表性业务实体及其源系统;完整 EDW 在全部 60 张青铜表中还包含更多实体、子类型与专用表(如 Prophet BEL/CSM、合约分出、医疗中心就诊、CLM 红线)。在 V2 中, LifePolicy 和 GiPolicy 领域类驱动 QuoteToBindToPremium 与 FnolToPay 主轴。
| 实体 | 源系统 | 表示例 |
|---|---|---|
| 业务条线 / 产品 | aya_product | line_of_business · product |
| 持 IA 牌照代理人 | aya_agency | agent |
| 投保人 | salesforce | account · contact · address |
| 数字报价 / FNOL | aya_digital | session · quote · claim_submission |
| 寿险 / 健康保单 | dxc_ingenium · swissre_magnum | policy · coverage · premium · decision |
| 一般保险保单 / 账单 | guidewire_pc · guidewire_bc | policy · coverage · invoice |
| 一般保险赔案 | guidewire_cc | claim · claim_transaction |
| 健康理赔 / 诊所 | fineos · aya_health | health_claim · clinic_visit |
| 保费 / 赔付现金 | fps | payment |
| 佣金 | varicent | commission |
| 再保险 | sap_fs_ri | cession |
| 投资 / 估值 | bloomberg_aim · prophet | holding · trade · valuation |
| 总账 / IFRS 17 | sap_s4 | journal_entry · journal_line |
AyaEnterpriseSimulation 编排当日节奏;领域对象拥有产出逻辑。
QuoteToBindToPremium 是新业务主轴; FnolToPay 是理赔主轴。 LifePolicy.execute_lifecycle() 走报价 → Magnum 核保 → Ingenium 出单 → FPS 收款 → 佣金 → 总账。 GiPolicy.execute_lifecycle() 走报价 → PolicyCenter 承保 → BillingCenter 账单 → ClaimCenter 上可选的当日 FNOL。 AyaPortfolio.publish_foundation() 在保单运行前主数据化产品、代理人、职场与投保人。
| 领域实体 | 自然键 | 生命周期方法 |
|---|---|---|
InsuranceProduct | product_code | aya_product 中的寿险 / 健康 / 一般保险费率 |
Agent | agent_id | 保险业监管局牌照登记 + Salesforce 中介 |
Policyholder | sf_account_id | 大众 / 高净值 / 中小企 / 雇主 CRM |
LifePolicy | policy_number | publish_quote() → 核保 → 承保 → 收款 → 佣金 → 总账 |
GiPolicy | policy_number | publish_quote() → 承保 → 账单 → open_claim() |
HealthClaim | claim_number | 诊所就诊 → FINEOS → FPS 赔付 |
flowchart LR
PORT[AyaPortfolio.publish_foundation]
LIFE[LifePolicy.execute_lifecycle]
GI[GiPolicy.execute_lifecycle]
PORT --> LIFE
PORT --> GI
LIFE --> Q[Aria quote]
Q --> UW[Magnum UW]
UW --> PAS[Ingenium / PolicyCenter]
PAS --> FPS[FPS collect]
GI --> FNOL[ClaimCenter FNOL]
FNOL --> RI[reinsurance cession]
FPS --> GL[SAP S/4 IFRS 17]
从产品工厂经分销、承保、收款、理赔到财务关账。
示例视图: 此图展示贯穿 AYA 生态系统的主要价值链;完整生成的 EDW 包含全部 39 套源系统及其此处未展示的跨职能集成、医疗中心无现金就诊与合约会计。
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph factory["Product & distribution"]
direction TB
PRD[aya_product]
AG[aya_agency]
DIG[aya_digital Aria]
PRD ~~~ AG
AG ~~~ DIG
end
subgraph bind["Underwrite & bind"]
direction TB
MAG[swissre_magnum]
LIFE[dxc_ingenium]
PC[guidewire_pc]
MAG ~~~ LIFE
LIFE ~~~ PC
end
subgraph cash["Collect & commission"]
direction TB
BC[guidewire_bc]
FPS[fps]
VAR[varicent]
BC ~~~ FPS
FPS ~~~ VAR
end
subgraph claims["Claims & health"]
direction TB
CC[guidewire_cc]
FN[fineos]
CLIN[aya_health]
CC ~~~ FN
FN ~~~ CLIN
end
subgraph corp["Investments & close"]
direction TB
AIM[bloomberg_aim]
PR[prophet]
S4[sap_s4]
AIM ~~~ PR
PR ~~~ S4
end
factory --> bind --> cash --> claims --> corp
鰂鱼涌 AYA Tower 总部及直属职能,配有代表性源系统。
示例组织结构: 此图展示主要汇报线;完整 AYA 组织还包括全部 39 套厂商集成中的更多代理区域、澳门与大湾区团队以及共享服务职能。
flowchart TB
CEO[AYA Hong Kong]
CEO --> LIFE[Life & Savings]
CEO --> HLTH[Health & Employee Benefits]
CEO --> GI[General Insurance]
CEO --> DIST[Agency / banca / digital]
CEO --> CLM[Claims]
CEO --> FIN[Finance & actuarial]
CEO --> HR[Human resources]
CEO --> LEG[IT / legal / security]
目录 stage 将表从基础层分组到企业层。
所示示例子集: 这是完整 60 表清单按成熟度层分布的代表性切片;实际分布反映从基础层到企业黄金表的完整数据血缘。
flowchart LR F["foundation
~12 tables"] D["distribution
~10 tables"] P["policy & premium
~9 tables"] C["claims
~6 tables"] CO["finance & corporate
~23 tables"] F --> D --> P --> C F -.-> CO P -.-> CO
逻辑关系与锚键。产品(product_code) 与保单(policy_number) 是主轴;理赔通过 FNOL 与赔案号关联。
示例示意图: 此实体关系图展示核心逻辑模型;完整生成的 EDW 包含 60 张青铜表 覆盖 39 套厂商系统 以及额外的明细表与血缘分支。实体实例携带 entity_refs 于每一条发出的事件上,以便进行可关联性测试。
erDiagram
PRODUCT ||--o{ LIFE_POLICY : tariffs
PRODUCT ||--o{ GI_POLICY : tariffs
AGENT ||--o{ LIFE_POLICY : sells
AGENT ||--o{ GI_POLICY : sells
POLICYHOLDER ||--o{ LIFE_POLICY : owns
POLICYHOLDER ||--o{ GI_POLICY : owns
LIFE_POLICY ||--o{ HEALTH_CLAIM : incurs
GI_POLICY ||--o{ GI_CLAIM : notifies
GI_POLICY ||--o{ INVOICE : bills
LIFE_POLICY ||--o{ PREMIUM : collects
GI_CLAIM ||--o{ CESSION : cedes
39 个厂商前缀,60 张青铜表。
所示示例系统: 下图展示代表性厂商系统;完整生成的数据集包含全部 39 套系统及其在历史回填与实时流中的完整表血缘与集成点。共享源系统清单位于 kb/source_systems/ 跨行业复用 — AYA 增加 aya_product, aya_agency, aya_digital,以及 aya_health 作为行业特有内部系统,外加拆分 PAS(Guidewire + Ingenium)。
每张表遵循 {source_system_}__{entity} 命名约定(例如 aya_product__product, guidewire_cc__claim),保留各产品真实导出模式中的厂商原生列形态与外键。VibeBI 在将记录提升至白银层与黄金层时推断主数据对齐。
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["aya_product · aya_agency · oracle_scm"]
f2["salesforce · workday · sap_s4 dimensions"]
end
subgraph distribution["Distribution"]
direction TB
d1["aya_digital · salesforce_cpq"]
d2["hubspot · marketo · google_analytics"]
end
subgraph policy["Policy & premium"]
direction TB
p1["swissre_magnum · dxc_ingenium"]
p2["guidewire_pc · guidewire_bc · fps · varicent"]
end
subgraph claims["Claims"]
direction TB
c1["guidewire_cc · fineos · aya_health · sap_fs_ri"]
end
subgraph corporate["Finance & corporate"]
direction TB
co1["prophet · bloomberg_aim · sap_s4 journals"]
co2["anaplan · adp · ukg · concur · coupa"]
co3["servicenow · okta · splunk · ironclad · onetrust"]
end
foundation --> distribution --> policy --> claims
foundation --> corporate
policy --> corporate
V2 面向对象仿真 → ClickHouse 中的青铜层;VibeBI 语义 → 白银 → 黄金,均在同一实例上。
面向对象路径: kb/industries/aya/ 定义运营主轴与实体模型; AyaEnterpriseSimulation 编排领域生命周期; SourceSystem 适配器将厂商原生行导出到 aya_v2.
flowchart LR
subgraph kb["kb/industries/aya"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/aya"]
ORCH[AyaEnterpriseSimulation]
DOM["LifePolicy · GiPolicy
execute_lifecycle()"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse aya_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-aya — 60s 节拍经由 AyaEnterpriseSimulation.generate().
实时频率: 每个节拍运行 QuoteToBindToPremium 与 FnolToPay — 领域对象发出相关联的报价、核保决定、PAS 承保、FPS 收款、佣金、FNOL 与总账行;今日的实时节拍只发出截至香港 as_of 以便报价、FNOL、FPS 与分录在一天内增长。每拍规模可变(默认基数 5)。按需回填任意历史跨度(--days N 于实时脚本或 CLI)。
flowchart LR
START([60s tick]) --> SIM[AyaEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> LIFE[LifePolicy lifecycles]
FOUND --> GI[GiPolicy lifecycles]
LIFE --> CORP[Health + investments + finance]
GI --> CORP
CORP --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
QuoteToBindToPremium 与 FnolToPay 状态机 — 每次转移都是发出厂商行的领域方法。
流程主轴: 定义于 kb/industries/aya/process_model.yaml. 迟到模式(PAS 出单时滞、FPS 清算、佣金批处理、隔夜 FNOL、再保险账单)与例外模式(核保转介/拒保、保费失效、拒赔、部分赔付)从同一实体生命周期分支,而不是独立随机插入。
flowchart LR
Q[quoted] --> UW[underwritten]
UW --> BIND[bound]
BIND --> BILL[billed]
BILL --> COL[collected]
COL --> COMM[commissioned]
COMM --> GL[posted_to_gl]
UW -.->|uw_decline| DEC[declined]
BILL -.->|lapse| LAPSE[premium_lapse]
flowchart LR
FNOL[fnol_submitted] --> OPEN[claim_opened]
OPEN --> RSV[reserved]
RSV --> PAY[paid]
PAY --> CLOSE[closed]
OPEN -.->|denied| DENY[claim_denied]
PAY -.->|partial| PART[partial_settlement]
每张表使用相同的血缘包络;类别驱动实时行为。
示例类别: 全部 60 张青铜表遵循这一三类模式(快照、事务、事件),并具备一致的元数据与状态跟踪;示意图展示了贯穿整仓的该模式。
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Product · agent · policyholder masters"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["Policies · premiums · claims · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["Digital sessions · FNOL · clinic visits"]
E2[Append each live tick]
end
BRONZE[("aya_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
虚构公司声明: “Smire” 是仅为演示而创建的完全虚构公司。它与太古地产有限公司、太古股份有限公司或任何真实房地产公司均无关联、背书或意图代表关系。
Smire Properties 是一家总部位于鲗鱼涌 Smire Tower 的香港综合业权业主——甲级写字楼园区(Eastgate Place、Harbour Place)、商场(Harbourplaza、Peakgate Outlets、Eastgate Li)、住宅与 Harbour House 酒店,以及北京、上海、广州、成都的太古里式零售。
账套覆盖从租赁要约进入 Yardi 租约与每日租金台账、基本租金加商场 POS 抽成租金、香港 FPS / 人民币收款、SAP S/4 NOI 分录、近实时 BMS、Nedap 门禁、停车场与 11:00–22:00 HKT 商场客流,以及 Argus GAV/NAV、CoStar 风格可比、开发资本支出提取与酒店入住/ADR/RevPAR——伴随 春节商场交易高峰 推高 Harbourplaza 与 Eastgate Li 客流、抽成租金与 FPS 收款。
示例实体: 下表展示代表性业务实体及其源系统;完整 EDW 在全部 60 张青铜表中还包含更多实体、子类型与专用表(如 ESG 表计、资本支出提取、酒店入住、CLM 红线)。在 V2 中, Lease 和 Tenant 领域类驱动 LeaseToCollect 与 MallTradingDay 主轴。
| 实体 | 源系统 | 表示例 |
|---|---|---|
| 物业 / 楼宇 / 单元 | smire_portfolio | property · building · unit |
| 租户 | yardi_voyager · salesforce | tenant · account · contact |
| 租赁要约 | smire_leasing | offer |
| 租约 / 租金台账 / 发票 | yardi_voyager | lease · rent_roll · invoice |
| 收租 | fps | payment |
| 商场 POS / 客流 | smire_mall | tenant_sale · footfall |
| BMS / 门禁 / 停车 | honeywell_bms · nedap_aeos · smire_park | telemetry · badge_event · session |
| 估值 / 可比 | argus_enterprise · costar_analytics | valuation · comp |
| 开发 | smire_dev | project · capex_draw |
| 酒店入住 | smire_hotel | occupancy |
| 住宅销售 | smire_residential | sale |
| 会员 | smire_loyalty | member · earn |
| NOI / GL | sap_s4 | journal_entry · journal_line |
SmireEnterpriseSimulation 编排当日节奏;领域对象拥有产出逻辑。
LeaseToCollect 是租赁主轴; MallTradingDay 是零售运营主轴。 Lease.execute_lifecycle() 走要约 → Yardi 租约与租金台账 → 发票(基本加抽成租金)→ FPS 收款 → NOI 分录。 Tenant.publish() 在租约运行前先主数据化 Yardi 与 Salesforce。 SmirePortfolio.publish_foundation() 先主数据化物业、楼宇、可出租单元与站点。
| 领域实体 | 自然键 | 生命周期方法 |
|---|---|---|
Property | property_code | smire_portfolio 中的园区 / 商场 / 酒店主数据 |
Unit | unit_id | 可出租净面积;入住台账 |
Tenant | tenant_code | publish() → Yardi + Salesforce CRM |
Lease | lease_id | execute_lifecycle() → offer → lease → invoice → FPS → GL |
CorporateOffice | location_id | oracle_scm 中的总部与物业管理站点 |
flowchart LR
PORT[SmirePortfolio.publish_foundation]
TNT[Tenant.publish]
LS[Lease.execute_lifecycle]
PORT --> TNT
TNT --> LS
LS --> OFF[leasing offer]
OFF --> YAR[Yardi lease / invoice]
YAR --> FPS[FPS collect]
FPS --> GL[SAP S/4 NOI]
PORT --> MALL[Mall POS + footfall]
MALL --> YAR
从组合主数据经租赁、商场交易、资产运行到财务关账。
示例视图: 这展示 Smire 生态中的主价值链;完整生成的 EDW 包含全部 39 套源系统及其跨职能集成、酒店 RevPAR 与此处未展示的开发资本支出。
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph portfolio["Portfolio"]
direction TB
PORT[smire_portfolio]
SCM[oracle_scm]
PORT ~~~ SCM
end
subgraph lease["Lease & collect"]
direction TB
OFF[smire_leasing]
YAR[yardi_voyager]
FPS[fps]
OFF ~~~ YAR
YAR ~~~ FPS
end
subgraph ops["Operate asset"]
direction TB
MALL[smire_mall]
BMS[honeywell_bms]
AEOS[nedap_aeos]
MALL ~~~ BMS
BMS ~~~ AEOS
end
subgraph value["Value & hotels"]
direction TB
ARG[argus_enterprise]
HOT[smire_hotel]
DEV[smire_dev]
ARG ~~~ HOT
HOT ~~~ DEV
end
subgraph close["NOI close"]
direction TB
S4[sap_s4]
CST[costar_analytics]
S4 ~~~ CST
end
portfolio --> lease --> ops --> value --> close
鲗鱼涌 Smire Tower 总部及配备代表性源系统的直接汇报职能。
示例组织结构: 这展示主要汇报线;完整 Smire 组织还包括更多物业管理办公室、内地商场团队,以及全部 39 套厂商集成上的共享服务职能。
flowchart TB
CEO[Smire Properties]
CEO --> OFF[Office]
CEO --> RET[Retail]
CEO --> RES[Residential]
CEO --> HOT[Hotels]
CEO --> DEV[Development]
CEO --> FIN[Finance]
CEO --> HR[Human resources]
CEO --> LEG[IT / legal / security]
目录 stage 将表从基础层分组到企业层。
所示示例子集: 这是完整 60 表清单按成熟度层分布的代表性切片;实际分布反映从基础层到企业黄金表的完整数据血缘。
flowchart LR F["portfolio
~10 tables"] L["leasing
~8 tables"] O["operations
~10 tables"] V["valuation
~8 tables"] CO["corporate
~24 tables"] F --> L --> O --> V F -.-> CO L -.-> CO
逻辑关系与锚点键。物业(property_code) 与单元(unit_id) 构成主轴;租约通过 lease_id 以及经发票的 FPS。
示例示意图: 此实体关系图展示核心逻辑模型;完整生成的 EDW 包含 60 张青铜表 覆盖 39 套厂商系统 以及额外的明细表与血缘分支。实体实例携带 entity_refs 于每一条发出的事件上,以便进行可关联性测试。
erDiagram
PROPERTY ||--o{ BUILDING : contains
BUILDING ||--o{ UNIT : lets
UNIT ||--o{ LEASE : occupies
TENANT ||--o{ LEASE : signs
LEASE ||--o{ INVOICE : bills
INVOICE ||--o{ FPS_PAYMENT : collects
TENANT ||--o{ MALL_SALE : trades
PROPERTY ||--o{ VALUATION : values
39 个厂商前缀,60 张青铜表。
所示示例系统: 下图展示代表性厂商系统;完整生成的数据集包含全部 39 套系统及其在历史回填与实时流中的完整表血缘与集成点。共享源系统清单位于 kb/source_systems/ 跨行业复用 — Smire 增加 smire_portfolio, smire_leasing, smire_mall,以及 smire_hotel 作为行业特有内部系统,外加 Yardi Voyager 与 Argus。
每张表遵循 {source_system_}__{entity} 命名约定(例如 smire_portfolio__unit, yardi_voyager__lease),保留各产品真实导出模式中的厂商原生列形态与外键。VibeBI 在将记录提升至白银层与黄金层时推断主数据对齐。
flowchart TB
subgraph foundation["Portfolio"]
direction TB
f1["smire_portfolio property · building · unit"]
f2["oracle_scm · salesforce · workday · sap_s4 dimensions"]
end
subgraph leasing["Leasing"]
direction TB
l1["smire_leasing · yardi_voyager · fps"]
end
subgraph operations["Operations"]
direction TB
o1["smire_mall · honeywell_bms · nedap_aeos · smire_park"]
o2["smire_hotel · smire_esg · smire_loyalty"]
end
subgraph valuation["Valuation"]
direction TB
v1["argus_enterprise · costar_analytics · smire_dev · smire_residential"]
end
subgraph corporate["Corporate"]
direction TB
co1["sap_s4 journals · anaplan · adp · ukg · concur"]
co2["hubspot · marketo · zendesk · servicenow · okta"]
co3["splunk · ironclad · onetrust · greenhouse"]
end
foundation --> leasing --> operations --> valuation
foundation --> corporate
leasing --> corporate
V2 面向对象仿真 → ClickHouse 中的青铜层;VibeBI 语义 → 白银 → 黄金,均在同一实例上。
面向对象路径: kb/industries/smire/ 定义运营主轴与实体模型; SmireEnterpriseSimulation 编排领域生命周期; SourceSystem 适配器将厂商原生行导出到 smire_v2.
flowchart LR
subgraph kb["kb/industries/smire"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/smire"]
ORCH[SmireEnterpriseSimulation]
DOM["Lease.execute_lifecycle()
Tenant · Property · Unit"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse smire_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-smire — 60s 节拍经由 SmireEnterpriseSimulation.generate().
实时频率: 每个 tick 运行 LeaseToCollect 与 MallTradingDay — 领域对象发出相关的要约、租约、发票、FPS 收款、商场 POS、客流、门禁事件与 GL 行;今日实时 tick 只发出截至香港 as_of 时刻的事件,因此租金台账、商场交易、BMS 与分录会随当天推进。每 tick 规模可变(默认基数 5)。可回填任意所需历史跨度(--days N 于实时脚本或 CLI)。
flowchart LR
START([60s tick]) --> SIM[SmireEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> TNT[Tenant.publish]
TNT --> LS[Lease lifecycles]
FOUND --> OPS[Mall · BMS · hotel]
LS --> CORP[NOI + valuation + finance]
OPS --> CORP
CORP --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
LeaseToCollect 与 OperateAsset 状态机——每次转换都是发出厂商行的领域方法。
流程主轴: 定义于 kb/industries/smire/process_model.yaml。迟到模式(FPS 清算延迟、GL 批量入账延迟、夜间 BMS、工单延迟)与异常模式(空置、欠租、门禁拒绝、设备告警)从同一实体生命周期分支,而非独立随机插入。
flowchart LR
OFF[offered] --> LS[leased]
LS --> OCC[occupied]
OCC --> INV[invoiced]
INV --> COL[collected]
COL --> GL[posted_to_gl]
LS -.->|vacancy| VAC[vacancy]
INV -.->|arrears| ARR[arrears]
flowchart LR
MTR[metered] --> ACC[accessed]
ACC --> WO[work_ordered]
WO --> VAL[valued]
ACC -.->|denied| DEN[access_denied]
MTR -.->|alarm| ALM[plant_alarm]
每张表使用相同的血缘包络;类别驱动实时行为。
示例类别: 全部 60 张青铜表遵循这一三类模式(快照、事务、事件),并具备一致的元数据与状态跟踪;示意图展示了贯穿整仓的该模式。
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Property · unit · tenant masters"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["Leases · invoices · FPS · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["Footfall · badge · BMS · park"]
E2[Append each live tick]
end
BRONZE[("smire_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
虚构公司声明: 「Hilson」是仅为演示目的创建的完全虚构公司。与 Hilton Inc.、Hyatt Hotels Corporation 或任何真实酒店集团均无关联、背书或意图代表关系。
Hilson 酒店集团 是一家全球酒店运营商,约 680 家物业、18 个品牌——从奢华旗舰(Waldorf 级、Conrad 级)到全服务(Hilson、DoubleTree 级),再到精选服务与长住层级。每家物业运行本地 Opera PMS 与中央 Amadeus CRS,服务散客休闲、协议公司与团队/会议宾客的组合。
业务覆盖忠诚度(拥有数百万会员的 Hilson Honors)、团队与会议销售(Salesforce 管道、CPQ 房块)、餐饮门店(MICROS Simphony POS)、业主/加盟报告(Oracle Fusion 报表)以及企业职能——典型工作日约产生 1,900 条 PMS 预订与 1,750 张账单头,并伴有 夏季出行高峰 (6–8 月),提升各物业的入住率、ADR、餐饮消费与忠诚度活动。
示例实体: 下表展示代表性业务实体及其源系统;完整 EDW 还包含额外实体、子类型与专用表(例如 OTA 渠道事件、房价计划限制、加盟法律协议、交易台红线)覆盖全部 62 张青铜表。在 V2 中, StayReservation 及相关领域类在入住生命周期推进时,通过源系统适配器产出 PMS、CRS、账单与忠诚度行。
| 实体 | 源系统 | 表示例 |
|---|---|---|
| 物业主数据 | oracle_opera | property · room_type · occupancy_snapshot |
| 品牌 / CRS | hilson_brand · amadeus_hosp | brand · property_profile |
| 忠诚度会员 | hilson_loyalty | member · point_transaction · redemption |
| 预订(PMS/CRS) | oracle_opera · amadeus_hosp | reservation · reservation_change_event |
| 账单 / 结算 | oracle_opera | folio_header · folio_charge |
| 餐饮门店 | micros_simphony | check_header · check_line |
| 支付 | adyen | payment · refund |
| 团队销售 | salesforce · salesforce_cpq | account · opportunity · quote |
| 客房服务 | oracle_opera | room_status_event · housekeeping_task |
| 业主 / GL | oracle_fusion · sap_s4 | owner_statement · journal_line |
| 宾客体验 | medallia · zendesk | stay_survey · guest_case |
HilsonEnterpriseSimulation 编排当日节奏;领域对象拥有产出逻辑。
ReservationToLoyaltyAndOwnerReporting 是主要流程主轴。 StayReservation.execute_lifecycle() 走完预订 → PMS 同步 → 账单费用 → 支付 → 忠诚度积分 → 入住率快照 → 业主报表 → GL。 HilsonPortfolio.publish_foundation() 在预订运行前主数据化品牌、物业与 Honors 会员。
| 领域实体 | 自然键 | 生命周期方法 |
|---|---|---|
Brand | brand_code | 品牌阶梯在 hilson_brand 中主数据化 |
Property | hotel_code | 物业 + 客房库存于 Opera/CRS |
GuestMember | honors_member_id | 贯穿预订与入住的忠诚度档案 |
StayReservation | crs_confirmation_no | book() → sync_pms() → open_folio() → settle() → award_points() |
PropertyOccupancy | hotel_code,日期 | 每日 ADR / RevPAR 快照 |
PropertyFinance | owner_statement_id | 业主报表 + 平衡 GL 过账 |
flowchart LR
PORT[HilsonPortfolio.publish_foundation]
STAY[StayReservation.execute_lifecycle]
PORT --> STAY
STAY --> BOOK[CRS booking]
BOOK --> PMS[PMS sync]
PMS --> FOL[folio charges]
FOL --> PAY[Adyen settlement]
PAY --> LOY[Honors points]
LOY --> OWN[owner statement + GL]
从品牌与物业主数据,经分销、入住、结算到业主报告。
示例视图: 此图展示贯穿 Hilson 生态系统的主要价值链;完整生成的 EDW 包含全部 31 套源系统及其此处未展示的跨职能集成、次级收入流与忠诚度生命周期流。
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph master["Brand & property master"]
direction TB
BR[hilson_brand]
PROP[oracle_opera property]
RMS[ideas_rms rate plans]
BR ~~~ PROP
PROP ~~~ RMS
end
subgraph dist["Distribution & booking"]
direction TB
AMA[amadeus_hosp CRS]
SM[siteminder OTA]
AMA ~~~ SM
end
subgraph stay["Stay & revenue"]
direction TB
RES[oracle_opera reservation]
FOL[folio header / charges]
SIM[micros_simphony F&B]
PAY[adyen payments]
end
subgraph loy["Loyalty & VoC"]
direction TB
HON[hilson_loyalty member]
MED[medallia · qualtrics]
HON ~~~ MED
end
subgraph corp["Owner & corporate"]
direction TB
OWN[oracle_fusion owner stmt]
SAP[sap_s4 GL]
GRP[salesforce group sales]
OWN ~~~ SAP
SAP ~~~ GRP
end
master --> dist --> stay --> loy
stay --> corp
企业总部及直接汇报职能,配有代表性源系统。
示例组织结构: 此图展示主要汇报线;完整 Hilson 组织还包括跨全部 31 套厂商集成的额外区域管理、品牌专属团队与共享服务职能。
flowchart TB
CEO[Hilson Hospitality Group]
CEO --> BRAND[Brand & marketing]
CEO --> DIST[Distribution & revenue mgmt]
CEO --> PROP[Property operations]
CEO --> SALES[Group sales]
CEO --> LOY[Loyalty program]
CEO --> FIN[Finance & owner reporting]
CEO --> HR[Human resources]
CEO --> GX[Guest experience]
CEO --> LEG[IT / security / legal]
目录 stage 将表从基础层分组到企业层。
所示示例子集: 这是完整 62 表清单按成熟度层分布的代表性切片;实际分布反映从基础层到企业黄金表的完整数据血缘。
flowchart LR F["foundation
~15 tables"] C["commercial
~7 tables"] GR["guest_revenue
~17 tables"] PO["property_ops
~7 tables"] CO["corporate
~16 tables"] F --> C --> GR --> PO F -.-> CO GR -.-> CO
逻辑关系与锚点键。物业(hotel_code)是主轴;宾客身份经由 Honors 与入住表。
示例示意图: 此实体关系图展示核心逻辑模型;完整生成的 EDW 包含 62 张青铜表 覆盖 31 套厂商系统 以及数千张额外明细表与血缘分支。
erDiagram
PROPERTY ||--o{ RESERVATION : hosts
PROPERTY ||--o{ RATE_PLAN : offers
BRAND ||--o{ PROPERTY : flags
MEMBER ||--o{ RESERVATION : books
MEMBER ||--o{ POINT_TXN : earns
MEMBER ||--o{ REDEMPTION : redeems
RESERVATION ||--|| FOLIO : bills
FOLIO ||--o{ FOLIO_CHARGE : lines
RESERVATION ||--o{ FNB_CHECK : posts
CORP_ACCOUNT ||--o{ OPPORTUNITY : pursues
SUPPLIER ||--o{ PO : supplies
PROPERTY ||--o{ WORK_ORDER : maintains
31 个厂商前缀,62 张青铜表。
所示示例系统: 下图展示代表性厂商系统;完整生成数据集包含全部 31 套系统及其在历史回填与实时流中的完整表血缘与集成点。
每张表遵循 {source_system_}__{entity} 命名约定(例如 oracle_opera__reservation, hilson_loyalty__member),保留各产品真实导出模式中的厂商原生列形态与外键。VibeBI 在将记录提升至白银层与黄金层时推断主数据对齐。
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["hilson_brand · oracle_opera property · room_type"]
f2["amadeus_hosp · ideas_rms · hilson_loyalty member"]
f3["salesforce account · workday · sap_s4 · coupa supplier"]
end
subgraph commercial["Commercial"]
direction TB
c1["salesforce pipeline · CPQ · hubspot · marketo"]
end
subgraph guest_rev["Guest revenue"]
direction TB
g1["oracle_opera reservation · folio · events"]
g2["amadeus_hosp · siteminder · micros_simphony"]
g3["adyen · loyalty points · oracle_fusion owner"]
end
subgraph prop_ops["Property ops"]
direction TB
p1["housekeeping · occupancy · ibm_maximo · coupa PO"]
end
subgraph corporate["Corporate"]
direction TB
co1["sap_s4 journals · adp · ukg · anaplan"]
co2["medallia · qualtrics · zendesk · concur"]
co3["servicenow · okta · splunk · ironclad · onetrust"]
end
foundation --> commercial --> guest_rev --> prop_ops
foundation --> corporate
guest_rev --> corporate
V2 面向对象仿真 → ClickHouse 中的青铜层;VibeBI 语义 → 白银 → 黄金,均在同一实例上。
面向对象路径: kb/industries/hilson/ 定义运营主轴与实体模型; HilsonEnterpriseSimulation 编排领域生命周期; SourceSystem 适配器将厂商原生行导出到 hilson_v2.
flowchart LR
subgraph kb["kb/industries/hilson"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/hilson"]
ORCH[HilsonEnterpriseSimulation]
DOM["StayReservation.execute_lifecycle()
Property · GuestMember …"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse hilson_v2
62 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-hilson — 60s 节拍经由 HilsonEnterpriseSimulation.generate().
实时频率: 每一节拍运行预订到忠诚度状态机——领域对象产出相关联的 CRS、PMS、账单、餐饮、支付、忠诚度与 GL 行;规模随节拍变化(默认基数 5)。可回填您需要的任意历史跨度(--days N);Hilson 在预订锚点表上包含缺口检测。
flowchart LR
START([60s tick]) --> SIM[HilsonEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> STAY[StayReservation lifecycles]
STAY --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
ReservationToLoyaltyAndOwnerReporting 状态机 — 每一次转移都产出厂商行。
流程主轴: 定义于 kb/industries/hilson/process_model.yaml。异常模式(未入住、拒付、房型升级)从同一实体生命周期分支,而非独立的随机插入。
flowchart LR
BOOK[booked] --> SYNC[synced_to_pms]
SYNC --> CHKIN[checked_in]
CHKIN --> HOUSE[in_house]
HOUSE --> CHKOUT[checked_out]
CHKOUT --> SET[settled]
SET --> PTS[points_posted]
PTS --> OCC[occupancy_snapshotted]
OCC --> OWN[owner_reported]
OWN --> GL[posted_to_gl]
SYNC -.->|no_show| NS[no_show]
SET -.->|chargeback| CB[chargeback]
每张表使用相同的血缘包络;类别控制实时刷新与微批追加。
示例类别: 全部 62 张青铜表遵循这一三类模式(快照、事务、事件),并具备一致的元数据与状态跟踪;示意图展示了贯穿整仓的该模式。
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Property · brand · member masters"]
S2[Daily full refresh]
end
subgraph txn["transaction"]
direction TB
T1["Reservations · folios · payments"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["HK · OTA · surveys · access"]
E2[Append each live tick]
end
BRONZE[("hilson_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
虚构公司声明: “Cathea” 是仅为演示而创建的完全虚构公司。它与国泰航空有限公司、国泰集团或任何真实航空公司均无关联、背书或意图代表关系。
Cathea Pacific 是一家总部位于赤鱲角 Cathea City 的香港枢纽航司——高端客运(HP)、航空货运与 Cathea Cargo Terminal、廉航 Peak Express(PX)、Air Harbour Express 货机(AH),以及 Pacific Miles 生活。网络按香港时间运转:A350/777 长航线轮班、夜间 747-8F 波次、A321neo 区域跳点。
当天流程为 NDC 订单 → Altéa 级 PNR 与 168 字头电子客票 → Adyen 刷卡 → DCS 值机与行李扫描 → Navblue OFP、AIMS 机组执勤与 SITA MVT(含 01:00–05:00 HKT 夜间货运)→ Pacific Miles 累计与 Accelya 结算 → SAP S/4 分录。货运走 Cargospot 订舱 → AWB → 货站收运 → ULD 扫描 → 动态 → OTM 拖车 → FPS 收款——伴随 春节出行 / 台风不正常运行抬升 推高 Peak Express 客座率、行李扫描与货运候补。
示例实体: 下表展示代表性业务实体及其源系统;完整 EDW 在全部 60 张青铜表中还包含更多实体、子类型与专用表(如加油、TRAX 工单、ULD 扫描、会员累计)。在 V2 中, Pnr 和 AirWaybill 领域类驱动 OfferToFlyToRevenue 与 BookToDeliverCargo 主轴。
| 实体 | 源系统 | 表示例 |
|---|---|---|
| 飞机 / 航线 / 航班 | cathea_network | aircraft · route · flight |
| 航站 | oracle_scm | station |
| NDC 订单 | cathea_ndc | order |
| PNR / 电子客票 | amadeus_altea | pnr · ticket |
| 值机 / 行李 | amadeus_dcs | checkin · bag_scan |
| 旅客银行卡 | adyen | payment |
| 货运订舱 / AWB | champ_cargospot | booking · awb |
| 货运站 | cathea_cht | acceptance · uld_scan |
| 航班动态 | sita_typeb | movement |
| OFP / 机组 | navblue · aims_crew | ofp · duty |
| Pacific Miles | cathea_loyalty | member · accrual |
| 货运收款 | fps | payment |
| 收入 / GL | accelya_ra · sap_s4 | document · journal_entry · journal_line |
CatheaEnterpriseSimulation 编排当日节奏;领域对象拥有产出逻辑。
OfferToFlyToRevenue 是旅客主轴; BookToDeliverCargo 是货运主轴。 Pnr.execute_lifecycle() 走 NDC 订单 → Altéa PNR 与电子客票 → Adyen 收单 → DCS 值机 → 已飞票联 → Pacific Miles → Accelya → GL。 AirWaybill.execute_lifecycle() 走 Cargospot 订舱 → AWB → CHT 收运 → ULD → SITA 动态 → OTM 拖车 → FPS 收款。 CatheaPortfolio.publish_foundation() 在 PNR 与 AWB 运行前先主数据化飞机、航线、航站与香港时间航班。
| 领域实体 | 自然键 | 生命周期方法 |
|---|---|---|
Aircraft | registration | cathea_network 中的机队主数据 |
Flight | flight_id | 按香港时间运转;SITA MVT + Navblue OFP |
Pnr | pnr_locator | execute_lifecycle() → NDC → Altéa → DCS → Adyen → Miles → GL |
AirWaybill | awb_number | execute_lifecycle() → Cargospot → CHT → ULD → FPS |
LoyaltyMember | member_id | Pacific Miles 在已飞票联上累计 |
flowchart LR
PORT[CatheaPortfolio.publish_foundation]
PNR[Pnr.execute_lifecycle]
AWB[AirWaybill.execute_lifecycle]
PORT --> PNR
PORT --> AWB
PNR --> NDC[NDC order]
NDC --> PSS[Altéa PNR / ticket]
PSS --> DCS[DCS check-in]
DCS --> GL[SAP S/4 journal]
AWB --> CS[Cargospot AWB]
CS --> CHT[CHT + ULD]
CHT --> FPS[FPS collect]
从网络主数据经旅客、货运、运行到财务关账。
示例视图: 这展示 Cathea 生态中的主价值链;完整生成的 EDW 包含全部 40 套源系统及其跨职能集成、夜间货运波次与此处未展示的 TRAX MRO。
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph network["Network"]
direction TB
NET[cathea_network]
SCM[oracle_scm station]
NET ~~~ SCM
end
subgraph fly["Offer to fly"]
direction TB
NDC[cathea_ndc]
PSS[amadeus_altea]
DCS[amadeus_dcs]
ADY[adyen]
NDC ~~~ PSS
PSS ~~~ DCS
end
subgraph cargo["Cargo"]
direction TB
CS[champ_cargospot]
CHT[cathea_cht]
OTM[oracle_otm]
FPS[fps]
CS ~~~ CHT
CHT ~~~ OTM
end
subgraph ops["Ops"]
direction TB
NAV[navblue]
AIMS[aims_crew]
SITA[sita_typeb]
NAV ~~~ AIMS
AIMS ~~~ SITA
end
subgraph close["Revenue & close"]
direction TB
PM[cathea_loyalty]
RA[accelya_ra]
S4[sap_s4]
PM ~~~ RA
RA ~~~ S4
end
network --> fly --> cargo --> ops --> close
赤鱲角 Cathea City 总部及配备代表性源系统的直接汇报职能。
示例组织结构: 这展示主要汇报线;完整 Cathea 组织还包括更多外站、大湾区货运台,以及全部 40 套厂商集成上的共享服务职能。
flowchart TB
CEO[Cathea Pacific]
CEO --> PREM[Premium Travel]
CEO --> CARGO[Cargo & Logistics]
CEO --> LCC[Peak Express LCC]
CEO --> LIFE[Pacific Miles]
CEO --> OPS[Flight ops]
CEO --> FIN[Finance]
CEO --> HR[Human resources]
CEO --> LEG[IT / legal / security]
目录 stage 将表从基础层分组到企业层。
所示示例子集: 这是完整 60 表清单按成熟度层分布的代表性切片;实际分布反映从基础层到企业黄金表的完整数据血缘。
flowchart LR F["network
~8 tables"] P["passenger
~10 tables"] C["cargo
~8 tables"] O["operations
~6 tables"] CO["corporate
~28 tables"] F --> P --> C --> O F -.-> CO C -.-> CO
逻辑关系与锚键。航班(flight_id) 与 PNR(pnr_locator) 构成旅客主轴;AWB(awb_number) 通过订舱与 FPS 连接货运。
示例示意图: 此实体关系图展示核心逻辑模型;完整生成的 EDW 包含 60 张青铜表 覆盖 40 套厂商系统 以及额外的明细表与血缘分支。实体实例携带 entity_refs 于每一条发出的事件上,以便进行可关联性测试。
erDiagram
AIRCRAFT ||--o{ FLIGHT : operates
ROUTE ||--o{ FLIGHT : schedules
FLIGHT ||--o{ PNR : carries
PNR ||--o{ TICKET : issues
TICKET ||--o{ CHECKIN : boards
FLIGHT ||--o{ AWB : uplifts
AWB ||--o{ FPS_PAYMENT : collects
PNR ||--o{ LOYALTY_ACCRUAL : earns
40 个厂商前缀,60 张青铜表。
所示示例系统: 下图展示代表性厂商系统;完整生成数据集包含全部 40 套系统及其在历史回填与实时流中的表血缘与集成点。共享源系统清单位于 kb/source_systems/ 跨行业复用 — Cathea 增加 cathea_network, cathea_ndc, cathea_cht,以及 cathea_loyalty 作为行业特有内部系统,外加 Altéa PSS 与 Cargospot。
每张表遵循 {source_system_}__{entity} 命名约定(例如 cathea_network__flight, amadeus_altea__pnr),保留各产品真实导出模式中的厂商原生列形态与外键。VibeBI 在将记录提升至白银层与黄金层时推断主数据对齐。
flowchart TB
subgraph foundation["Network"]
direction TB
f1["cathea_network aircraft · route · flight"]
f2["oracle_scm · salesforce · workday · sap_s4 dimensions"]
end
subgraph passenger["Passenger"]
direction TB
p1["cathea_ndc · amadeus_altea · amadeus_dcs"]
p2["adyen · cathea_loyalty"]
end
subgraph cargo["Cargo"]
direction TB
c1["champ_cargospot · cathea_cht · oracle_otm · fps"]
end
subgraph operations["Operations"]
direction TB
o1["navblue · aims_crew · sita_typeb · trax_mro · cathea_fuel"]
end
subgraph corporate["Corporate"]
direction TB
co1["accelya_ra · sap_s4 journals · anaplan · adp · ukg"]
co2["hubspot · marketo · zendesk · servicenow · okta"]
co3["splunk · ironclad · onetrust · greenhouse"]
end
foundation --> passenger --> cargo --> operations
foundation --> corporate
cargo --> corporate
V2 面向对象仿真 → ClickHouse 中的青铜层;VibeBI 语义 → 白银 → 黄金,均在同一实例上。
面向对象路径: kb/industries/cathea/ 定义运营主轴与实体模型; CatheaEnterpriseSimulation 编排领域生命周期; SourceSystem 适配器将厂商原生行导出到 cathea_v2.
flowchart LR
subgraph kb["kb/industries/cathea"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/cathea"]
ORCH[CatheaEnterpriseSimulation]
DOM["Pnr · AirWaybill
execute_lifecycle()"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse cathea_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-cathea — 60s 节拍经由 CatheaEnterpriseSimulation.generate().
实时频率: 每个 tick 运行 OfferToFlyToRevenue 与 BookToDeliverCargo — 领域对象发出相关的 NDC 订单、PNR、客票、DCS 扫描、货运 AWB、SITA 动态、FPS 收款与 GL 行;今日实时 tick 只发出截至香港 as_of 时刻的事件,因此值机、行李扫描、夜间货运与分录会随当天推进。每 tick 规模可变(默认基数 5)。可回填任意所需历史跨度(--days N 于实时脚本或 CLI)。
flowchart LR
START([60s tick]) --> SIM[CatheaEnterpriseSimulation.generate]
SIM --> FOUND[Portfolio.publish_foundation]
FOUND --> PNR[Pnr lifecycles]
FOUND --> AWB[AirWaybill lifecycles]
PNR --> CORP[Loyalty + RA + finance]
AWB --> CORP
CORP --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
OfferToFlyToRevenue 与 BookToDeliverCargo 状态机——每次转换都是发出厂商行的领域方法。
流程主轴: 定义于 kb/industries/cathea/process_model.yaml。迟到模式(DCS 扫描延迟、MVT 延迟、RA 批处理延迟、GL 批量入账延迟)与异常模式(未登机、IRROPS 延误、拒卡、短装、运力候补)从同一实体生命周期分支,而非独立随机插入。
flowchart LR
OFF[offered] --> PNR[pnr_created]
PNR --> TKT[ticketed]
TKT --> CKIN[checked_in]
CKIN --> BRD[boarded]
BRD --> FLN[flown]
FLN --> ACC[accrued]
ACC --> RA[rated]
RA --> GL[posted_to_gl]
TKT -.->|card_refuse| REF[card_refused]
CKIN -.->|no_show| NS[no_show]
flowchart LR
BK[booked] --> AWB[awb_issued]
AWB --> ACC[accepted]
ACC --> ULD[uld_built]
ULD --> DEP[departed]
DEP --> TRK[trucked]
TRK --> DLV[delivered]
DLV --> COL[collected]
COL --> GL[posted_to_gl]
BK -.->|waitlist| WL[capacity_waitlist]
ACC -.->|short| SH[short_shipment]
每张表使用相同的血缘包络;类别驱动实时行为。
示例类别: 全部 60 张青铜表遵循这一三类模式(快照、事务、事件),并具备一致的元数据与状态跟踪;示意图展示了贯穿整仓的该模式。
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Aircraft · route · station · loyalty masters"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["PNRs · tickets · AWBs · FPS · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["DCS scans · SITA MVT · bag events"]
E2[Append each live tick]
end
BRONZE[("cathea_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE
虚构公司声明: 「P&C」是仅为演示目的创建的完全虚构公司。与 The Procter & Gamble Company 或任何真实快消制造商均无关联、背书或意图代表关系。
P&C 是一家全球消费品制造营销商——以 B2B2C 模式,通过大众零售、仓储会员、商超与电商渠道,在约 180 个国家销售日用产品。五个事业部(SBU)覆盖织物与家居护理、婴幼儿/女性/家庭护理、美容、健康护理与剃须护理,约 12 个旗舰品牌(TidalWave、ComfortWrap、BrightSmile、EdgePro 等),以及八座制造工厂和三座区域配送中心。
业务覆盖需求计划、原材料采购、MES 生产、质量放行、产成品分销、零售客户订单、贸易营销与财务——每个仿真日产出相关联的 MES 工单、Ariba 采购订单、OMS 订单头、OTM 发运与 SAP 凭证行,并伴有 春季大扫除高峰 (3–4 月),拉动北美与 EMEA 的织物/家居护理需求、工厂吞吐与零售进货。
示例实体: 下表展示代表性业务实体及其源系统;完整 EDW 还包含额外实体、子类型与专用表(例如物联网传感器读数、维护工单、贸易促销、CLM 红线)覆盖全部 60 张青铜表。在 V2 中, ProductionBatch 和 CustomerOrder 领域类驱动 MakeToShipToSell 主轴。
| 实体 | 源系统 | 表示例 |
|---|---|---|
| SBU / 品牌阶梯 | pc_brand | brand · category |
| 产成品 SKU | akeneo_pim | sku · brand · category |
| 工厂 / 配送中心主数据 | oracle_scm | warehouse · office |
| 需求预测 | blueyonder | forecast_daily |
| 原材料采购订单 | sap_ariba | purchase_order · purchase_order_line |
| 生产批次 | siemens_mes | work_order |
| 质量放行 | mastercontrol | quality_incident |
| 产成品库存 | manhattan_wms | stock_balance · movement · pick_pack_event |
| 零售客户订单 | manhattan_oms | order_header · order_line |
| 出库发运 | oracle_otm | shipment · shipment_tracking_event |
| 零售账户 | salesforce | account · opportunity · sales_activity |
| GL / COA | sap_s4 | journal_entry · journal_line |
PcEnterpriseSimulation 编排当日节奏;领域对象拥有产出逻辑。
MakeToShipToSell 是主要流程主轴。 ProductionBatch.execute_lifecycle() 走完预测 → 采购 → 生产 → 质检放行 → 产成品; CustomerOrder.execute_lifecycle() 走完 OMS 捕获 → WMS 履约 → OTM 发运。 PcPortfolio.publish_foundation() 在批次与订单运行前主数据化 SBU、品牌、工厂、SKU 与零售账户。服务对象(PlantOperations, CommercialProgram, FinanceAndCorporate)产出配套的企业与营销行。
| 领域实体 | 自然键 | 生命周期方法 |
|---|---|---|
Brand | brand_code | pc_brand + PIM 中的 SBU/品类阶梯 |
ProductSku | sku, material_number | PIM 发布 → MES 物料关联 |
Plant | facility_code | 制造工厂或配送中心注册 |
ProductionBatch | work_order_id | forecast_demand() → procure_materials() → run_production() → release_quality() → receive_finished_goods() |
RetailCustomer | sf_account_id | Salesforce 中的贸易账户 |
CustomerOrder | order_number | place_order() → fulfill() → ship() |
Supplier | ariba_supplier_id | 采购主数据 + 发票关联 |
flowchart LR
PORT[PcPortfolio.publish_foundation]
BATCH[ProductionBatch.execute_lifecycle]
ORDER[CustomerOrder.execute_lifecycle]
PORT --> BATCH
PORT --> ORDER
BATCH --> FCST[BlueYonder forecast]
FCST --> PO[Ariba PO]
PO --> MES[SIEMENS MES work order]
MES --> QC[MasterControl release]
QC --> WMS[WMS finished goods]
ORDER --> OMS[OMS order]
OMS --> SHIP[OTM shipment]
SHIP --> GL[SAP S/4 journal]
从品牌组合,经计划、制造、物流、销售到企业关账。
示例视图: 此图展示 P&C 生态系统的主要价值链;完整生成的 EDW 包含全部 34 套源系统及其此处未展示的跨职能集成、工厂物联网遥测与贸易营销流。
%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
subgraph portfolio["Portfolio & R&D"]
direction TB
PCB[pc_brand SBU ladder]
PIM[akeneo_pim SKU]
PCB ~~~ PIM
end
subgraph plan["Plan & procure"]
direction TB
BY[blueyonder forecast]
ARB[sap_ariba PO]
BY ~~~ ARB
end
subgraph make["Make & quality"]
direction TB
MES[siemens_mes work order]
MC[mastercontrol QC]
MES ~~~ MC
end
subgraph move["Store & ship"]
direction TB
WMS[manhattan_wms inventory]
OTM[oracle_otm TMS]
WMS ~~~ OTM
end
subgraph sell["Sell to retail"]
direction TB
SF[salesforce trade]
OMS[manhattan_oms orders]
SF ~~~ OMS
end
subgraph corp["Corporate"]
direction TB
WD[workday]
S4[sap_s4 GL]
WD ~~~ S4
end
portfolio --> plan --> make --> move --> sell --> corp
全球总部位于辛辛那提及直接汇报职能,配有代表性源系统。
示例组织结构: 此图展示主要汇报线;完整 P&C 组织还包括跨全部 34 套厂商集成的区域 SBU 团队、工厂经理与共享服务职能。
flowchart TB
CEO[P&C Global]
CEO --> SBU[SBU portfolio & R&D]
CEO --> MFG[Supply chain & manufacturing]
CEO --> COMM[Commercial & retail sales]
CEO --> MKT[Marketing & brand]
CEO --> FIN[Finance & controller]
CEO --> HR[Human resources]
CEO --> QUAL[Quality & regulatory]
CEO --> LEG[IT / legal / security]
目录 stage 将表从基础层分组到企业层。
所示示例子集: 这是完整 60 表清单按成熟度层分布的代表性切片;实际分布反映从基础层到企业黄金表的完整数据血缘。
flowchart LR F["foundation
~13 tables"] SC["supply_chain
~10 tables"] D["distribution
~6 tables"] C["commercial
~16 tables"] CO["corporate
~15 tables"] F --> SC --> D --> C F -.-> CO C -.-> CO
逻辑关系与锚点键。品牌(brand_code)与工厂(facility_code)构成主轴;物料编号将 PIM 与 MES 相连。
示例示意图: 此实体关系图展示核心逻辑模型;完整生成的 EDW 包含 60 张青铜表 覆盖 34 套厂商系统 以及额外的明细表与血缘分支。实体实例携带 entity_refs 于每一条发出的事件上,以便进行可关联性测试。
erDiagram
BRAND ||--o{ PRODUCT : owns
PRODUCT ||--o{ PRODUCTION_BATCH : produces
PLANT ||--o{ PRODUCTION_BATCH : runs
SUPPLIER ||--o{ PO : supplies
PRODUCTION_BATCH ||--o{ PO : triggers
PLANT ||--o{ INVENTORY : stocks
RETAIL_CUSTOMER ||--o{ CUSTOMER_ORDER : places
PRODUCT ||--o{ ORDER_LINE : contains
CUSTOMER_ORDER ||--|{ ORDER_LINE : lines
CUSTOMER_ORDER ||--o{ SHIPMENT : ships
CUSTOMER_ORDER ||--o{ JOURNAL : posts
34 个厂商前缀,60 张青铜表。
所示示例系统: 下图展示代表性厂商系统;完整生成数据集包含全部 34 套系统及其在历史回填与实时流中的完整表血缘与集成点。共享源系统清单见 kb/source_systems/ 跨行业复用——P&C 增加 pc_brand 作为行业专用的内部系统。
每张表遵循 {source_system_}__{entity} 命名约定(例如 pc_brand__brand, siemens_mes__work_order),保留各产品真实导出模式中的厂商原生列形态与外键。VibeBI 在将记录提升至白银层与黄金层时推断主数据对齐。
flowchart TB
subgraph foundation["Foundation"]
direction TB
f1["pc_brand · akeneo_pim
oracle_scm · workday"]
f2["sap_s4 dimensions"]
end
subgraph supply_chain["Supply chain"]
direction TB
s1["blueyonder · sap_ariba
siemens_mes · mastercontrol"]
s2["ibm_maximo · aws_iot"]
end
subgraph distribution["Distribution"]
direction TB
d1["manhattan_wms
oracle_otm"]
end
subgraph commercial["Commercial"]
direction TB
c1["salesforce · manhattan_oms
hubspot · marketo"]
c2["google_analytics · qualtrics · zendesk"]
end
subgraph corporate["Corporate"]
direction TB
co1["sap_s4 journals · coupa
adp · ukg · concur"]
co2["servicenow · okta · splunk
ironclad · onetrust · greenhouse"]
end
foundation --> supply_chain --> distribution --> commercial
foundation --> corporate
commercial --> corporate
V2 面向对象仿真 → ClickHouse 中的青铜层;VibeBI 语义 → 白银 → 黄金,均在同一实例上。
面向对象路径: kb/industries/pnc/ 定义运营主轴与实体模型; PcEnterpriseSimulation 编排领域生命周期; SourceSystem 适配器将厂商原生行导出到 pnc_v2.
flowchart LR
subgraph kb["kb/industries/pnc"]
SPINE[entity + process models]
end
subgraph sim["sim/industries/pnc"]
ORCH[PcEnterpriseSimulation]
DOM["ProductionBatch · CustomerOrder
execute_lifecycle()"]
end
subgraph simedw["SimEDW V2"]
ADP[SourceSystem adapters]
CHB[("ClickHouse pnc_v2
60 bronze tables")]
end
subgraph vibebi["VibeBI"]
SEM[("semantic")]
SIL[("silver views")]
GLD[("gold views")]
end
DASH["Dashboards & agents"]
SPINE --> DOM
ORCH --> DOM --> ADP --> CHB
CHB --> SEM --> SIL --> GLD --> DASH
./live-v2-pnc — 60s 节拍经由 PcEnterpriseSimulation.generate().
实时频率: 每一节拍运行 MakeToShipToSell 状态机——领域对象按生产批次与零售客户订单产出相关联的预测、PO、MES、WMS、OMS、OTM 与 GL 行;规模随节拍变化(默认基数 5)。可回填您需要的任意历史跨度(--days N 于实时脚本或 CLI)。
flowchart LR
START([60s tick]) --> SIM[PcEnterpriseSimulation.generate]
SIM --> FOUND[PcPortfolio.publish_foundation]
FOUND --> BATCH[ProductionBatch lifecycles]
FOUND --> ORDER[CustomerOrder lifecycles]
BATCH --> CORP[PlantOps + Finance + Commercial]
ORDER --> CORP
CORP --> EVT[SourceSystem events]
EVT --> BRZ[Append bronze rows]
BRZ --> WAIT[Sleep] --> START
MakeToShipToSell 状态机 — 每一次转移都是产出厂商行的领域方法。
流程主轴: 定义于 kb/industries/pnc/process_model.yaml。异常模式(批量报废、质量扣留、部分发运、供应商延迟)从同一实体生命周期分支,而非独立的随机插入。
flowchart LR
FCST[forecasted] --> PROC[materials_procured]
PROC --> PROD[production_started]
PROD --> QC[quality_released]
QC --> FG[finished_goods_received]
FG --> ORD[customer_ordered]
ORD --> FUL[fulfilled]
FUL --> SHIP[shipped]
SHIP --> GL[posted_to_gl]
PROD -.->|scrap| SCRAP[batch_scrap]
QC -.->|hold| HOLD[quality_hold]
FUL -.->|short| PART[partial_shipment]
每张表使用相同的血缘包络;类别驱动实时行为。
示例类别: 全部 60 张青铜表遵循这一三类模式(快照、事务、事件),并具备一致的元数据与状态跟踪;示意图展示了贯穿整仓的该模式。
flowchart LR
subgraph snap["snapshot"]
direction TB
S1["Brand · plant · SKU masters"]
S2[Daily foundation refresh]
end
subgraph txn["transaction"]
direction TB
T1["POs · work orders · OMS · GL"]
T2[Append each live tick]
end
subgraph evt["event"]
direction TB
E1["IoT · WMS movement · OTM tracking"]
E2[Append each live tick]
end
BRONZE[("pnc_v2 bronze row")]
snap --> BRONZE
txn --> BRONZE
evt --> BRONZE