範例資料 · SimEDW

企業規模 範例倉儲。

六座完整模擬 EDW——HKBC(香港全能銀行)、AYA(香港綜合保險公司)、Smire(香港綜合業權業主)、Hilson(全球飯店集團)、Cathea(香港客貨物流)與 P&C(消費品)——具備擬真廠商原生綱要、ClickHouse 中可銜接獎章架構的銅層,以及即時事件串流。為在 VibeBI 上測試語義層、維度建模與自助分析而建。

6
產業包
215
廠商來源系統
362
銅層資料表總數
60s
即時資料重新整理
32 廠商系統 60 銅層資料表 5 階段 DB hkbc_v2

公司簡介

虛構公司聲明: 「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_corebranch
產品目錄hkbc_coreproduct
客戶(CIF)hkbc_core · salesforcecustomer · account · contact
存款/貸款帳戶hkbc_coreaccount · posting · deposit_balance
FPS / CHATS / SWIFThkicl_fps · hkicl_chats · swiftproxy · payment · rtgs_payment · message
卡片fiserv_visionpluscard · authorization · clearing_transaction
PearlPay 錢包hkbc_paywallet · wallet_payment
貿易融資hkbc_tradedocumentary_credit · guarantee
外匯/市場murex · bloombergfx_trade · position · fx_rate
AML / 信用風險nice_actimize · moodys_riskaml_alert · case · credit_facility · ecl_provision
財富交易hkbc_wealthholding · securities_order
GL/COAsap_s4journal_entry · journal_line

OOP 領域模型

HkbcEnterpriseSimulation 串接當日;領域物件擁有產出邏輯。

PayToPostToBalance 是主要流程主軸。 FpsPayment.execute_lifecycle() (以及 PearlPay、卡、CHATS、SWIFT 對應類)走清算通道電文 → 核心複式記帳 → 可選 AML 預警 → 日終存款餘額 → 總帳。 HkbcPortfolio.publish_foundation() 在支付執行前主資料化分行、產品、CIF 客戶與帳戶。服務物件發出商業銀行貿易、環球市場外匯、財富、風險與企業列。

領域實體自然鍵生命週期方法
Branchbranch_code在 hkbc_core 中主資料化的分行 / 批發交易台
Productproduct_code往來/儲蓄、按揭、卡、錢包、貿易、外匯產品目錄
Customercustomer_idCIF + KYC 分群;Salesforce 中的 CRM 鏡像
Accountaccount_idpublish() → post_pair() 平衡分錄
FpsPaymentpayment_idexecute_lifecycle() → 清算通道 → 記帳 → AML
DocumentaryCreditlc_id商業銀行信用狀/保函簽發
FxTradetrade_idMurex 成交 → 美元/港元頭寸
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]
          

EDW 成熟階段

目錄 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 OOP 模擬 → ClickHouse 銅層;VibeBI 語義 → 銀層 → 金層,同一執行個體。

OOP 路徑: 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 — 60 秒一次的 tick,透過 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
          
39 廠商系統 60 銅層資料表 5 階段 DB aya_v2

公司簡介

虛構公司聲明: 「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_productline_of_business · product
持 IA 牌照代理人aya_agencyagent
投保人salesforceaccount · contact · address
數位報價/FNOLaya_digitalsession · quote · claim_submission
壽險/健康保單dxc_ingenium · swissre_magnumpolicy · coverage · premium · decision
一般保險保單/帳單guidewire_pc · guidewire_bcpolicy · coverage · invoice
一般保險賠案guidewire_ccclaim · claim_transaction
健康理賠/診所fineos · aya_healthhealth_claim · clinic_visit
保費/賠付現金fpspayment
佣金varicentcommission
再保險sap_fs_ricession
投資/估值bloomberg_aim · prophetholding · trade · valuation
總帳/IFRS 17sap_s4journal_entry · journal_line

OOP 領域模型

AyaEnterpriseSimulation 串接當日;領域物件擁有產出邏輯。

QuoteToBindToPremium 是新業務主軸; FnolToPay 是理賠主軸。 LifePolicy.execute_lifecycle() 走報價 → Magnum 核保 → Ingenium 出單 → FPS 收款 → 佣金 → 總帳。 GiPolicy.execute_lifecycle() 走報價 → PolicyCenter 承保 → BillingCenter 帳單 → ClaimCenter 上可選的當日 FNOL。 AyaPortfolio.publish_foundation() 在保單執行前主資料化產品、代理人、職場與投保人。

領域實體自然鍵生命週期方法
InsuranceProductproduct_codeaya_product 中的壽險/健康/一般保險費率
Agentagent_id保險業監管局牌照登記 + Salesforce 中介
Policyholdersf_account_id大眾/高淨值/中小企/雇主 CRM
LifePolicypolicy_numberpublish_quote() → 核保 → 承保 → 收款 → 佣金 → 總帳
GiPolicypolicy_numberpublish_quote() → 承保 → 帳單 → open_claim()
HealthClaimclaim_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]
          

EDW 成熟階段

目錄 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 OOP 模擬 → ClickHouse 銅層;VibeBI 語義 → 銀層 → 金層,同一執行個體。

OOP 路徑: 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 — 60 秒一次的 tick,透過 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
          

報價到承保與 FNOL 事件圖

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
          
39 廠商系統 60 銅層資料表 5 階段 DB smire_v2

公司簡介

虛構公司聲明: 「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_portfolioproperty · building · unit
租戶yardi_voyager · salesforcetenant · account · contact
租賃要約smire_leasingoffer
租約 / 租金台帳 / 發票yardi_voyagerlease · rent_roll · invoice
收租fpspayment
商場 POS / 人流smire_malltenant_sale · footfall
BMS / 門禁 / 停車honeywell_bms · nedap_aeos · smire_parktelemetry · badge_event · session
估值 / 可比argus_enterprise · costar_analyticsvaluation · comp
開發smire_devproject · capex_draw
酒店入住smire_hoteloccupancy
住宅銷售smire_residentialsale
會員smire_loyaltymember · earn
NOI / GLsap_s4journal_entry · journal_line

OOP 領域模型

SmireEnterpriseSimulation 串接當日;領域物件擁有產出邏輯。

LeaseToCollect 是租賃主軸; MallTradingDay 是零售營運主軸。 Lease.execute_lifecycle() 走要約 → Yardi 租約與租金台帳 → 發票(基本加抽成租金)→ FPS 收款 → NOI 分錄。 Tenant.publish() 在租約執行前先主資料化 Yardi 與 Salesforce。 SmirePortfolio.publish_foundation() 先主資料化物業、樓宇、可出租單元與據點。

領域實體自然鍵生命週期方法
Propertyproperty_codesmire_portfolio 中的園區 / 商場 / 酒店主資料
Unitunit_id可出租淨面積;入住台帳
Tenanttenant_codepublish() → Yardi + Salesforce CRM
Leaselease_idexecute_lifecycle() → offer → lease → invoice → FPS → GL
CorporateOfficelocation_idoracle_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]
          

EDW 成熟階段

目錄 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 OOP 模擬 → ClickHouse 銅層;VibeBI 語義 → 銀層 → 金層,同一執行個體。

OOP 路徑: 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 — 60 秒一次的 tick,透過 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
          
31 廠商系統 62 銅層資料表 5 階段 DB hilson_v2

公司簡介

虛構公司聲明: 「Hilson」為完全虛構的公司,僅供示範之用。與 Hilton Inc.、Hyatt Hotels Corporation 或任何真實旅宿企業均無關係、未經其背書,亦非意圖代表之。

Hilson Hospitality Group 是一家全球飯店營運商,約 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_operaproperty · room_type · occupancy_snapshot
品牌/CRShilson_brand · amadeus_hospbrand · property_profile
忠誠會員hilson_loyaltymember · point_transaction · redemption
訂房(PMS/CRS)oracle_opera · amadeus_hospreservation · reservation_change_event
帳單/計費oracle_operafolio_header · folio_charge
餐飲據點micros_simphonycheck_header · check_line
付款adyenpayment · refund
團體銷售salesforce · salesforce_cpqaccount · opportunity · quote
房務oracle_operaroom_status_event · housekeeping_task
業主/GLoracle_fusion · sap_s4owner_statement · journal_line
旅客體驗medallia · zendeskstay_survey · guest_case

OOP 領域模型

HilsonEnterpriseSimulation 串接當日;領域物件擁有產出邏輯。

ReservationToLoyaltyAndOwnerReporting 是主要流程主軸。 StayReservation.execute_lifecycle() 走完訂房 → PMS 同步 → 帳單費用 → 付款 → 忠誠點數 → 住房率快照 → 業主報表 → GL。 HilsonPortfolio.publish_foundation() 在訂房運行前先主檔化品牌、物業與 Honors 會員。

領域實體自然鍵生命週期方法
Brandbrand_code品牌層級主檔於 hilson_brand
Propertyhotel_codeOpera/CRS 中的物業+客房庫存
GuestMemberhonors_member_id橫跨訂房與住宿的忠誠檔案
StayReservationcrs_confirmation_nobook() → sync_pms() → open_folio() → settle() → award_points()
PropertyOccupancyhotel_code、日期每日 ADR/RevPAR 快照
PropertyFinanceowner_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]
          

EDW 成熟階段

目錄 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 OOP 模擬 → ClickHouse 銅層;VibeBI 語義 → 銀層 → 金層,同一執行個體。

OOP 路徑: 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 — 60 秒一次的 tick,透過 HilsonEnterpriseSimulation.generate().

即時頻率: 每個 tick 執行訂房到忠誠狀態機——領域物件產出相關的 CRS、PMS、帳單、餐飲、付款、忠誠與 GL 列;規模隨 tick 變化(預設基數 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
          
40 廠商系統 60 銅層資料表 5 階段 DB cathea_v2

公司簡介

虛構公司聲明: 「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_networkaircraft · route · flight
航站oracle_scmstation
NDC 訂單cathea_ndcorder
PNR / 電子客票amadeus_alteapnr · ticket
辦理登機 / 行李amadeus_dcscheckin · bag_scan
旅客銀行卡adyenpayment
貨運訂艙 / AWBchamp_cargospotbooking · awb
貨運站cathea_chtacceptance · uld_scan
航班動態sita_typebmovement
OFP / 機組navblue · aims_crewofp · duty
Pacific Milescathea_loyaltymember · accrual
貨運收款fpspayment
收入 / GLaccelya_ra · sap_s4document · journal_entry · journal_line

OOP 領域模型

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 執行前先主資料化飛機、航線、航站與香港時間航班。

領域實體自然鍵生命週期方法
Aircraftregistrationcathea_network 中的機隊主資料
Flightflight_id按香港時間運轉;SITA MVT + Navblue OFP
Pnrpnr_locatorexecute_lifecycle() → NDC → Altéa → DCS → Adyen → Miles → GL
AirWaybillawb_numberexecute_lifecycle() → Cargospot → CHT → ULD → FPS
LoyaltyMembermember_idPacific 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]
          

EDW 成熟階段

目錄 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 OOP 模擬 → ClickHouse 銅層;VibeBI 語義 → 銀層 → 金層,同一執行個體。

OOP 路徑: 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 — 60 秒一次的 tick,透過 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
          
34 廠商系統 60 銅層資料表 5 階段 DB pnc_v2

公司簡介

虛構公司聲明: 「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_brandbrand · category
製成品 SKUakeneo_pimsku · brand · category
工廠/配送中心主檔oracle_scmwarehouse · office
需求預測blueyonderforecast_daily
原物料採購單sap_aribapurchase_order · purchase_order_line
生產批次siemens_meswork_order
品質放行mastercontrolquality_incident
製成品庫存manhattan_wmsstock_balance · movement · pick_pack_event
零售客戶訂單manhattan_omsorder_header · order_line
出貨oracle_otmshipment · shipment_tracking_event
零售帳戶salesforceaccount · opportunity · sales_activity
GL/COAsap_s4journal_entry · journal_line

OOP 領域模型

PcEnterpriseSimulation 串接當日;領域物件擁有產出邏輯。

MakeToShipToSell 是主要流程主軸。 ProductionBatch.execute_lifecycle() 走完預測 → 採購 → 生產 → 品管放行 → 製成品; CustomerOrder.execute_lifecycle() 走完 OMS 接單 → WMS 履約 → OTM 出貨。 PcPortfolio.publish_foundation() 在批次與訂單運行前先主檔化 SBU、品牌、工廠、SKU 與零售帳戶。服務物件(PlantOperations, CommercialProgram, FinanceAndCorporate)產出配套的企業與行銷列。

領域實體自然鍵生命週期方法
Brandbrand_codepc_brand+PIM 中的 SBU/品類層級
ProductSkusku, material_numberPIM 發布 → MES 物料連結
Plantfacility_code製造工廠或配送中心登錄
ProductionBatchwork_order_idforecast_demand() → procure_materials() → run_production() → release_quality() → receive_finished_goods()
RetailCustomersf_account_idSalesforce 中的通路帳戶
CustomerOrderorder_numberplace_order() → fulfill() → ship()
Supplierariba_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
          

依部門劃分的職能組織

全球總部 Cincinnati 與直屬職能,搭配代表性來源系統。

範例組織結構: 此圖顯示主要報告線;完整 P&C 組織另含區域 SBU 團隊、工廠經理與共享服務職能,涵蓋全部 34 項廠商整合。

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]
          

EDW 成熟階段

目錄 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 OOP 模擬 → ClickHouse 銅層;VibeBI 語義 → 銀層 → 金層,同一執行個體。

OOP 路徑: 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 — 60 秒一次的 tick,透過 PcEnterpriseSimulation.generate().

即時頻率: 每個 tick 執行 MakeToShipToSell 狀態機——領域物件依生產批次與零售客戶訂單產出相關的預測、PO、MES、WMS、OMS、OTM 與 GL 列;規模隨 tick 變化(預設基數 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
          

開始為您的 BI 注入 Vibe。

下載桌面應用程式、伺服器與 SimEDW 範例資料——一個下午走完您第一次受治理倉儲建置。

快速入門 → 產品預覽 閱讀白皮書