示例数据 · SimEDW

企业级 示例数仓。

五套完全仿真的 EDW——Amazing(全渠道电商)、Hilson(全球酒店集团)、P&C(快消制造)、HKBC(香港全能银行)与 AYA(香港综合保险公司)——配有逼真的厂商原生模式、ClickHouse 中可进入 Medallion 的青铜层,以及实时事件流。用于在 VibeBI 上测试语义层、维度建模与自助分析。

5
行业包
182
厂商源系统
321
青铜表合计
60s
实时数据刷新
46 厂商系统 79 青铜表 5 阶段 DB amazing_v2

公司简介

虚构公司声明: 「Amazing」是仅为演示目的创建的完全虚构公司。与 Amazon.com, Inc. 或任何真实公司均无关联、背书或意图代表关系。

Amazing 是一家全球全渠道零售商,通过自营第一方库存、第三方卖家市场与 Prime 订阅计划销售数千万种商品。顾客经由网站店面、移动应用与实体零售地点购物;订单由全球履约中心网络与直运供应商履约。

业务覆盖广告、金融服务以及与消费者电商并行的 B2B 批发业务——典型工作日约产生 2,800 张订单头与 4,200 行明细,并伴有 Prime Day 需求高峰(7 月 11–13 日)覆盖零售、网站、营销与市场平台渠道。

示例实体: 下表展示代表性业务实体及其源系统;完整 EDW 还包含额外实体、子类型与专用表(例如退货、订阅、推荐、物流跟踪)覆盖全部 79 张青铜表。在 V2 中,每个实体都是拥有生命周期方法并通过以下方式产出行的领域类 SourceSystem 适配器——而非中央过程式生成器。

实体源系统表示例
客户(CRM)salesforceaccount · contact · address
Prime / 订阅zuoraprime_membership · subscription_event
SKU / 产品akeneo_pimsku · category · brand
订单(OMS)manhattan_omsorder_header · order_line · return_authorization
仓库(WMS)manhattan_wmsstock_balance · movement
支付stripepayment · refund
GL / COAsap_s4gl_account · journal_line
支持 / 客户之声zendesk · qualtricsticket · nps_response

面向对象领域模型

AmazingEnterpriseSimulation 编排当日节奏;领域对象拥有产出逻辑。

OrderToCash 是主要流程主轴。 CommerceOrder.execute_lifecycle() 走完状态机——捕获、支付、拣货/打包、发票、GL——每一步调用 runtime.record(system, object, payload) 于相应的厂商适配器上。组合引导(AmazingPortfolio.publish_foundation())在订单运行前主数据化 CRM 账户、PIM SKU 与履约节点。

领域实体自然键生命周期方法
CustomerAccountsf_account_idCRM 账户在 Salesforce 中主数据化
ProductSkusku, asinPIM 发布 → OMS/WMS 关联
FulfillmentNodefacility_code库存节点注册
CommerceOrderorder_numbercapture()authorize_payment()fulfill()invoice()post_gl()
AccountingDocumentinvoice_id, belnr平衡发票 + 凭证过账
flowchart LR
  PORT[AmazingPortfolio.publish_foundation]
  ORD[CommerceOrder.execute_lifecycle]
  PORT --> ORD
  ORD --> CAP[capture in OMS]
  CAP --> PAY[authorize in Stripe]
  PAY --> FUL[pick/pack in WMS]
  FUL --> INV[invoice in Oracle Billing]
  INV --> GL[post journal in SAP S/4]
          

业务价值链

能力层从左到右;箭头为主要流向。

示例视图: 此图展示组织的主要价值链;完整生成的 EDW 包含全部 46 套源系统及其此处未展示的跨职能集成与次级数据流。

%%{init: {"flowchart": {"htmlLabels": false}} }%%
flowchart LR
  subgraph cust["Customer & growth"]
    direction TB
    SF[salesforce]
    ZU[zuora Prime]
    HS[hubspot]
    GA[analytics]
    SF ~~~ ZU
    ZU ~~~ HS
    HS ~~~ GA
  end
  subgraph product["Product"]
    direction TB
    PIM[akeneo_pim]
    ADS[amazon_ads]
    PIM ~~~ ADS
  end
  subgraph commerce["Commerce"]
    direction TB
    OMS[manhattan_oms]
    STR[stripe]
    SC[seller_central]
    OMS ~~~ STR
    STR ~~~ SC
  end
  subgraph supply["Supply chain"]
    direction TB
    ARIBA[sap_ariba]
    WMS[manhattan_wms]
    OTM[oracle_otm]
    ARIBA ~~~ WMS
    WMS ~~~ OTM
  end
  subgraph corp["Corporate"]
    direction TB
    WD[workday]
    S4[sap_s4]
    WD ~~~ S4
  end
  cust --> product --> commerce --> supply --> corp
          

按部门划分的职能组织

企业总部及直接汇报职能,配有代表性源系统。

示例组织结构: 此图展示主要汇报线;完整 Amazing 电商组织还包括跨全部 46 套厂商集成的额外团队、子部门与矩阵角色。

flowchart TB
  CEO[Amazing EC]
  CEO --> COM[Commerce]
  CEO --> MKT[Marketing]
  CEO --> SC[Supply chain]
  CEO --> FIN[Finance]
  CEO --> HR[HR]
  CEO --> OPS[Operations]
  CEO --> LEG[Legal & security]
          

EDW 成熟度阶段

目录 stage 将表从基础层分组到企业层。

所示示例子集: 这是完整 79 表清单按成熟度层分布的代表性切片;实际分布反映从基础层到企业黄金表的完整数据血缘。

flowchart LR
  F["foundation
~21 tables"] C["commercial
~11 tables"] R["revenue
~15 tables"] O["operations
~14 tables"] CO["corporate
~18 tables"] F --> C --> R --> O F -.-> CO R -.-> CO

核心业务实体

逻辑关系与锚点键。青铜层取值因源而异,直至 VibeBI 白银层将其对齐。

示例示意图: 此实体关系图展示核心逻辑模型;完整生成的 EDW 包含 79 张青铜表 覆盖 46 套厂商系统 以及数千张额外明细表与血缘分支。V2 中的实体实例携带 entity_refs 于每一条发出的事件上,以便进行可关联性测试。

erDiagram
  CUSTOMER ||--o{ ORDER : places
  CUSTOMER ||--o{ SUBSCRIPTION : prime
  CUSTOMER ||--o{ PAYMENT : pays
  PRODUCT ||--o{ ORDER_LINE : contains
  ORDER ||--|{ ORDER_LINE : lines
  ORDER ||--o{ RETURN : may
  ORDER ||--o{ SHIPMENT : fulfills
  SELLER ||--o{ ORDER_LINE : fulfills
  SUPPLIER ||--o{ PO : issues
  LOCATION ||--o{ INVENTORY : stocks
          

源系统全景

46 个厂商前缀,79 张青铜表。

所示示例系统: 下图展示代表性厂商系统;完整生成数据集包含全部 46 套系统及其在历史回填与实时流中的完整表血缘与集成点。

每张表遵循 {source_system_}__{entity} 命名约定(例如 salesforce__account, manhattan_oms__order_header),保留各产品真实导出模式中的厂商原生列形态与外键。VibeBI 在将记录提升至白银层与黄金层时推断主数据对齐。

flowchart TB
  subgraph foundation["Foundation"]
    direction TB
    f1["salesforce · workday
akeneo_pim · zuora"] end subgraph commercial["Commercial"] direction TB c1["hubspot · marketo
amazon_ads · cpq"] end subgraph revenue["Revenue"] direction TB r1["manhattan_oms · stripe
oracle_billing"] end subgraph operations["Operations"] direction TB o1["manhattan_wms · sap_ariba
oracle_otm"] end subgraph corporate["Corporate"] direction TB co1["sap_s4 · adp
servicenow · okta"] end foundation --> commercial --> revenue --> operations foundation --> corporate

端到端数据流

V2 面向对象仿真 → ClickHouse 中的青铜层;VibeBI 语义 → 白银 → 黄金,均在同一实例上。

面向对象路径: kb/industries/amazing/ 定义运营主轴与实体模型; AmazingEnterpriseSimulation 编排领域生命周期; SourceSystem 适配器将厂商原生行导出到 amazing_v2.

flowchart LR
  subgraph kb["kb/industries/amazing"]
    SPINE[entity + process models]
  end
  subgraph sim["sim/industries/amazing"]
    ORCH[AmazingEnterpriseSimulation]
    DOM["CommerceOrder.execute_lifecycle()
CustomerAccount · ProductSku …"] end subgraph simedw["SimEDW V2"] ADP[SourceSystem adapters] CHB[("ClickHouse amazing_v2
79 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-amazing — 60s 节拍经由 AmazingEnterpriseSimulation.generate().

实时频率: 每一节拍为该营业日运行 OrderToCash 状态机——领域对象产出相关联的 OMS、支付、WMS、结算与 GL 行;规模随节拍变化(默认基数 5)。可回填您需要的任意历史跨度(--days N 于实时脚本或 CLI)。

flowchart LR
  START([60s tick]) --> SIM[AmazingEnterpriseSimulation.generate]
  SIM --> FOUND[Portfolio.publish_foundation]
  FOUND --> ORD[CommerceOrder lifecycles]
  ORD --> EVT[SourceSystem events]
  EVT --> BRZ[Append bronze rows]
  BRZ --> WAIT[Sleep] --> START
          

实时事件图

OrderToCash 状态机 — 每一次转移都是产出厂商行的领域方法。

流程主轴: 定义于 kb/industries/amazing/process_model.yaml。迟到模式(支付 webhook 延迟、WMS 扫描延迟)与异常模式(部分退款、拆分发运)建模为同一实体生命周期上的备选路径。

flowchart LR
  CRE[created] --> AUTH[authorized]
  AUTH --> ALLOC[allocated]
  ALLOC --> PICK[picked]
  PICK --> PACK[packed]
  PACK --> INV[invoiced]
  INV --> POST[posted]
  AUTH -.->|payment_failure| FAIL[payment_failed]
  PACK -.->|split| SPLIT[partial_shipment]
          

青铜表类别

每张表使用相同的血缘包络;类别驱动实时行为。

示例类别: 全部 79 张青铜表遵循这一三类模式(快照、事务、事件),并具备一致的元数据与状态跟踪;示意图展示了贯穿整仓的该模式。

flowchart LR
  subgraph snap["snapshot"]
    direction TB
    S1["Master / dimension"]
    S2[Daily full refresh]
  end
  subgraph txn["transaction"]
    direction TB
    T1["Orders · payments · POs"]
    T2[Append each tick]
  end
  subgraph evt["event"]
    direction TB
    E1["Sessions · movements"]
    E2[Append each tick]
  end
  BRONZE[("amazing_v2 bronze row")]
  snap --> BRONZE
  txn --> BRONZE
  evt --> BRONZE
          
31 厂商系统 62 青铜表 5 阶段 DB hilson_v2

公司简介

虚构公司声明: 「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_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

面向对象领域模型

HilsonEnterpriseSimulation 编排当日节奏;领域对象拥有产出逻辑。

ReservationToLoyaltyAndOwnerReporting 是主要流程主轴。 StayReservation.execute_lifecycle() 走完预订 → PMS 同步 → 账单费用 → 支付 → 忠诚度积分 → 入住率快照 → 业主报表 → GL。 HilsonPortfolio.publish_foundation() 在预订运行前主数据化品牌、物业与 Honors 会员。

领域实体自然键生命周期方法
Brandbrand_code品牌阶梯在 hilson_brand 中主数据化
Propertyhotel_code物业 + 客房库存于 Opera/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 面向对象仿真 → 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
          
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 中, ProductionBatchCustomerOrder 领域类驱动 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

面向对象领域模型

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
          

按部门划分的职能组织

全球总部位于辛辛那提及直接汇报职能,配有代表性源系统。

示例组织结构: 此图展示主要汇报线;完整 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]
          

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 面向对象仿真 → 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
          
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

面向对象领域模型

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 面向对象仿真 → 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
          
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 中, LifePolicyGiPolicy 领域类驱动 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

面向对象领域模型

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 面向对象仿真 → 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
          

报价到承保与 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
          

开始让你的 BI 律动起来。

下载桌面应用、服务器与 SimEDW 示例数据——用一个下午完成您的第一次受治理数仓构建。

快速开始 → 产品预览 阅读白皮书