완전히 시뮬레이션된 EDW 다섯 개 — Amazing(옴니채널 이커머스), Hilson(글로벌 호텔 그룹), P&C(CPG 제조), HKBC(홍콩 유니버설 뱅크), AYA(홍콩 복합 보험사) — 현실적인 벤더 고유 스키마, ClickHouse의 메달리온 준비 브론즈, 라이브 이벤트 스트림. VibeBI에서 시맨틱 레이어, 디멘셔널 모델링, 셀프서비스 분석을 시험하기 위해 만들었습니다.
가상 회사 안내: "Amazing"은 시연 목적으로만 만든 가상의 회사입니다. Amazon.com, Inc. 또는 실제 어떤 기업과도 제휴되어 있지 않으며, 보증하거나 대표하지 않습니다.
Amazing 은 자사 1P 재고, 3P 셀러 마켓플레이스, Prime 구독 프로그램에 걸쳐 수천만 개 상품을 판매하는 글로벌 옴니채널 리테일러입니다. 고객은 웹 스토어프론트, 모바일 앱, 오프라인 매장에서 쇼핑하며, 주문은 전 세계 풀필먼트 센터와 드롭십 공급사 네트워크에서 이행됩니다.
사업은 소비자 커머스와 함께 광고, 금융 서비스, B2B 도매를 포괄합니다. 일반적인 평일에는 주문 헤더 약 2,800건, 라인 약 4,200건이 발생하며, Prime Day 수요 급증(7월 11–13일)이 소매, 웹, 마케팅, 마켓플레이스 채널 전반에 발생합니다.
샘플 엔터티: 아래 표는 대표 비즈니스 엔터티와 소스 시스템을 보여 줍니다. 완전한 EDW에는 추가 엔터티, 하위 유형, 특수 테이블(예: 반품, 구독, 추천, 물류 추적)이 브론즈 테이블 79개 전반에 포함됩니다. V2에서 각 엔터티는 라이프사이클 메서드를 소유하고 다음을 통해 행을 방출하는 도메인 클래스입니다 SourceSystem 어댑터이며, 중앙 절차형 생성기가 아닙니다.
| 엔터티 | 소스 시스템 | 예시 테이블 |
|---|---|---|
| 고객 (CRM) | salesforce | account · contact · address |
| Prime / 구독 | zuora | prime_membership · subscription_event |
| SKU / 제품 | akeneo_pim | sku · category · brand |
| 주문 (OMS) | manhattan_oms | order_header · order_line · return_authorization |
| 웨어하우스 (WMS) | manhattan_wms | stock_balance · movement |
| 결제 | stripe | payment · refund |
| GL / COA | sap_s4 | gl_account · journal_line |
| 지원 / VoC | zendesk · qualtrics | ticket · nps_response |
AmazingEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.
OrderToCash 이 기본 프로세스 중추입니다. CommerceOrder.execute_lifecycle() 상태 머신(캡처, 결제, 피킹/패킹, 송장, GL)을 진행하며, 각 단계가 다음을 호출합니다 runtime.record(system, object, payload) 해당 벤더 어댑터에서. 포트폴리오 부트스트랩(AmazingPortfolio.publish_foundation())가 주문 실행 전에 CRM 계정, PIM SKU, 풀필먼트 노드를 마스터합니다.
| 도메인 엔터티 | 자연 키 | 라이프사이클 메서드 |
|---|---|---|
CustomerAccount | sf_account_id | Salesforce에서 마스터된 CRM 계정 |
ProductSku | sku, asin | PIM 게시 → OMS/WMS 연결 |
FulfillmentNode | facility_code | 재고 노드 등록 |
CommerceOrder | order_number | capture() → authorize_payment() → fulfill() → invoice() → post_gl() |
AccountingDocument | invoice_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
엔터프라이즈 HQ와 직속 기능, 대표 소스 시스템.
샘플 조직 구조: 이는 주요 보고 체계를 보여 줍니다. 전체 Amazing EC 조직에는 벤더 통합 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]
카탈로그 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 OOP 시뮬 → ClickHouse 브론즈, VibeBI 시맨틱 → 같은 인스턴스에서 실버 → 골드.
OOP 경로: 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 — 60초 틱 경유 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. 지연 도착 모드(결제 웹훅 지연, 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개 모두 이 3범주 패턴(스냅샷, 트랜잭션, 이벤트)과 일관된 메타데이터·상태 추적을 따릅니다. 다이어그램은 전체 웨어하우스에 쓰이는 패턴을 보여 줍니다.
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
가상 회사 안내: "Hilson"은 시연 목적으로만 만든 가상의 회사입니다. Hilton Inc., Hyatt Hotels Corporation 또는 실제 어떤 호스피탈리티 기업과도 제휴되어 있지 않으며, 보증하거나 대표하지 않습니다.
Hilson Hospitality Group 은 18개 브랜드에 걸쳐 약 680개 숙박 시설을 운영하는 글로벌 호텔 사업자입니다. 럭셔리 플래그(Waldorf급, Conrad급)부터 풀서비스(Hilson, DoubleTree급), 셀렉트 서비스, 장기 숙박 티어까지 포함합니다. 각 숙박 시설은 온프레미스 Opera PMS와 중앙 Amadeus CRS를 운영하며, 단기 레저, 기업 협상, 단체/컨벤션 투숙객이 섞여 있습니다.
사업은 로열티(수백만 회원의 Hilson Honors), 단체·컨벤션 영업(Salesforce 파이프라인, CPQ 객실 블록), 식음료 매장(MICROS Simphony POS), 오너/프랜차이즈 리포팅(Oracle Fusion 명세서), 전사 기능을 포괄합니다. 일반적인 평일에는 PMS 예약 약 1,900건, folio 헤더 약 1,750건이 발생하며, 여름 여행 급증 (6–8월)으로 전 숙박 시설의 점유율, ADR, F&B 매출, 로열티 활동을 끌어올립니다.
샘플 엔터티: 아래 표는 대표 비즈니스 엔터티와 소스 시스템을 보여 줍니다. 완전한 EDW에는 추가 엔터티, 하위 유형, 특수 테이블(예: OTA 채널 이벤트, 요금제 제한, 프랜차이즈 법률 계약, 딜데스크 레드라인)이 브론즈 테이블 62개 전반에 포함됩니다. V2에서는 StayReservation 관련 도메인 클래스가 숙박 라이프사이클이 진행됨에 따라 소스 시스템 어댑터를 통해 PMS, CRS, folio, 로열티 행을 방출합니다.
| 엔터티 | 소스 시스템 | 예시 테이블 |
|---|---|---|
| 숙박 시설 마스터 | 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 |
| Folio / 청구 | oracle_opera | folio_header · folio_charge |
| F&B 매장 | 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 동기화 → folio 요금 → 결제 → 로열티 포인트 → 점유 스냅샷 → 오너 명세서 → 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
엔터프라이즈 HQ와 직속 기능, 대표 소스 시스템.
샘플 조직 구조: 이는 주요 보고 체계를 보여 줍니다. 전체 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 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초 틱 경유 HilsonEnterpriseSimulation.generate().
라이브 주기: 각 틱이 예약-로열티 상태 머신을 실행합니다. 도메인 객체가 상관된 CRS, PMS, folio, F&B, 결제, 로열티, 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개 모두 이 3범주 패턴(스냅샷, 트랜잭션, 이벤트)과 일관된 메타데이터·상태 추적을 따릅니다. 다이어그램은 전체 웨어하우스에 쓰이는 패턴을 보여 줍니다.
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
가상 회사 안내: "P&C"는 시연 목적으로만 만든 가상의 회사입니다. The Procter & Gamble Company 또는 실제 어떤 CPG 제조사와도 제휴되어 있지 않으며, 보증하거나 대표하지 않습니다.
P&C 은 글로벌 소비재 제조·마케팅 기업입니다. 약 180개국에서 대형 유통, 클럽, 식료품, 이커머스 채널로 일상 제품을 판매하는 B2B2C 모델입니다. 5개 Sector Business Unit(SBU)이 Fabric & Home Care, Baby/Feminine/Family Care, Beauty, Health Care, Grooming을 포괄하며, 약 12개 플래그십 브랜드(TidalWave, ComfortWrap, BrightSmile, EdgePro 등)와 제조 공장 8곳, 지역 물류센터 3곳을 운영합니다.
사업은 수요 계획, 원자재 조달, MES 생산, 품질 출고, 완제품 유통, 소매 고객 주문, 트레이드 마케팅, 재무를 포괄합니다. 각 시뮬레이션 일에 상관된 MES 작업 지시, Ariba PO, OMS 헤더, OTM 출하, SAP 분개 라인이 생성되며, Spring Clean 급증 (3–4월)으로 북미와 EMEA에서 패브릭/홈케어 수요, 공장 처리량, 소매 셀인(sell-in)을 끌어올립니다.
샘플 엔터티: 아래 표는 대표 비즈니스 엔터티와 소스 시스템을 보여 줍니다. 완전한 EDW에는 추가 엔터티, 하위 유형, 특수 테이블(예: IoT 센서 측정, 유지보수 작업 지시, 트레이드 프로모션, CLM 레드라인)이 브론즈 테이블 60개 전반에 포함됩니다. V2에서는 ProductionBatch 및 CustomerOrder 도메인 클래스가 MakeToShipToSell 중추를 구동합니다.
| 엔터티 | 소스 시스템 | 예시 테이블 |
|---|---|---|
| SBU / 브랜드 사다리 | pc_brand | brand · category |
| 완제품 SKU | akeneo_pim | sku · brand · category |
| 공장 / DC 마스터 | oracle_scm | warehouse · office |
| 수요 예측 | blueyonder | forecast_daily |
| 원자재 PO | 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() 예측 → 조달 → 생산 → QC 출고 → 완제품 순으로 진행합니다. 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 | 제조 공장 또는 DC 등록 |
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에는 여기에 표시되지 않은 교차 기능 통합, IoT 공장 텔레메트리, 트레이드 마케팅 흐름을 포함한 소스 시스템 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
신시내티 글로벌 HQ와 직속 기능, 대표 소스 시스템.
샘플 조직 구조: 이는 주요 보고 체계를 보여 줍니다. 전체 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 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초 틱 경유 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개 모두 이 3범주 패턴(스냅샷, 트랜잭션, 이벤트)과 일관된 메타데이터·상태 추적을 따릅니다. 다이어그램은 전체 웨어하우스에 쓰이는 패턴을 보여 줍니다.
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
가상 회사 안내: 「HKBC」는 데모 목적으로만 만들어진 완전히 가상의 회사입니다. HSBC Holdings plc, The Hongkong and Shanghai Banking Corporation Limited 또는 실제 은행과 제휴·후원·대변하지 않습니다.
HKBC (Hong Kong Banking Corporation)는 Central에 본사를 둔 홍콩 유니버설 뱅크로, Wealth and Personal Banking, Commercial Banking, Global Banking and Markets를 운영합니다. HKD 예금을 받고 HIBOR 주택담보대출과 무담보 신용을 취급하며, 카드를 발행하고 24×7 Faster Payment System과 PearlPay(PayMe급) 레일을 운영하며, Greater Bay Area 무역을 금융하고 7.75–7.85 태환 밴드 안에서 USD/HKD 및 CNH FX를 장부에 올립니다.
장부는 홍콩섬·구룡·신계의 약 10개 지점과 첸하이 GBA 도매 데스크, 런던 마켓 데스크를 아우릅니다. 각 시뮬레이션 일에 상관된 FPS 입금, 카드 승인, CHATS/SWIFT 이체, 코어 복식 분개, AML 알림, SAP 분개를 생성하며, 설날 / 1분기 세금대출 급증 PearlPay P2P 거래량, 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 |
| FX / 마켓 | 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 알림 → EOD 예금 잔액 → GL 순으로 진행합니다. HkbcPortfolio.publish_foundation() 결제가 돌기 전에 지점, 상품, CIF 고객, 계좌를 마스터합니다. 서비스 객체가 CMB 무역, GBM FX, 웰스, 리스크, 코퍼레이트 행을 방출합니다.
| 도메인 엔터티 | 자연 키 | 라이프사이클 메서드 |
|---|---|---|
Branch | branch_code | hkbc_core에서 마스터된 지점 / 도매 데스크 |
Product | product_code | CASA, 주택담보, 카드, 월렛, 무역, FX 카탈로그 |
Customer | customer_id | CIF + KYC 세그먼트; Salesforce CRM 미러 |
Account | account_id | publish() → post_pair() 균형 원장 |
FpsPayment | payment_id | execute_lifecycle() → 레일 → 분개 → AML |
DocumentaryCredit | lc_id | CMB LC / 보증 발행 |
FxTrade | trade_id | Murex 티켓 → USD/HKD 포지션 |
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에는 여기에 표시되지 않은 교차 기능 통합, 웰스 딜링, GBA 무역 회랑을 포함한 소스 시스템 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개 전반의 추가 지구 지점, GBA 데스크, 공유 서비스 기능이 포함됩니다.
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 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초 틱 경유 HkbcEnterpriseSimulation.generate().
라이브 주기: 각 틱은 PayToPostToBalance 상태 머신을 실행합니다. 도메인 객체가 상관된 FPS, PearlPay, 카드, CHATS, SWIFT, 코어 분개, AML, GL 행을 방출합니다. 오늘 라이브 틱은 홍콩 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 ack 지연, 승인 후 카드 클리어링, AML 케이스 지연, GL 배치 지연)와 예외 모드(FPS 거절, 카드 거절, AML 보류, 잔액 부족, LC 불일치)는 독립 난수 삽입이 아니라 같은 엔터티 라이프사이클에서 분기합니다.
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개 모두 이 3범주 패턴(스냅샷, 트랜잭션, 이벤트)과 일관된 메타데이터·상태 추적을 따릅니다. 다이어그램은 전체 웨어하우스에 쓰이는 패턴을 보여 줍니다.
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 Hong Kong and Macau 또는 실제 보험사와 제휴·후원·대변하지 않습니다.
AYA 는 홍콩 복합 보험사입니다. Life & Savings, Health(VHIS 및 직원 복리 포함), General Insurance를 전속 설계사, 방카슈랑스, 브로커, Aria by AYA 앱, 임베디드 e월렛 파트너로 판매합니다. 본사는 쿼리베이이며 Central 자문 센터, 침사추이 AYA Medical Centre, 마카오 지점, 첸하이 GBA 영업소가 있습니다.
사업은 상품 팩토리, Magnum급 언더라이팅, 분할 PAS(생명은 Ingenium급, 일반보험은 Guidewire), FPS 보험료 수금, Varicent 수수료, 24×7 자동차/여행 FNOL, FINEOS 건강 클레임, 재보험 출재, Prophet IFRS 17 평가, SAP S/4 분개를 아우르며, 태풍철 일반보험 클레임 증가 (6–10월)과 디지털·에이전시 채널 전반의 설날 여행 / 북향 자동차보험 급증.
샘플 엔터티: 아래 표는 대표 비즈니스 엔터티와 소스 시스템입니다. 전체 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 |
| GL / IFRS 17 | sap_s4 | journal_entry · journal_line |
AyaEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.
QuoteToBindToPremium 는 신계약 중추입니다. FnolToPay 는 클레임 중추입니다. LifePolicy.execute_lifecycle() 견적 → Magnum UW → Ingenium 발행 → FPS 수금 → 수수료 → GL 순으로 진행합니다. GiPolicy.execute_lifecycle() 견적 → PolicyCenter 인수 → BillingCenter 청구서 → ClaimCenter의 선택적 당일 FNOL 순으로 진행합니다. AyaPortfolio.publish_foundation() 증권이 돌기 전에 상품, 설계사, 사무소, 계약자를 마스터합니다.
| 도메인 엔터티 | 자연 키 | 라이프사이클 메서드 |
|---|---|---|
InsuranceProduct | product_code | aya_product의 생명 / 건강 / 일반보험 요율 |
Agent | agent_id | IA 라이선스 등록 + Salesforce 프로듀서 |
Policyholder | sf_account_id | 매스 / HNW / SME / 고용주 CRM |
LifePolicy | policy_number | publish_quote() → UW → 인수 → 수금 → 수수료 → GL |
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개 전반의 추가 에이전시 지구, 마카오·GBA 팀, 공유 서비스 기능이 포함됩니다.
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 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초 틱 경유 AyaEnterpriseSimulation.generate().
라이브 주기: 각 틱은 QuoteToBindToPremium과 FnolToPay를 실행합니다. 도메인 객체가 상관된 견적, UW 결정, PAS 인수, FPS 수금, 수수료, FNOL, GL 행을 방출합니다. 오늘 라이브 틱은 홍콩 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, 재보험 보더로)와 예외 모드(UW 회부/거절, 보험료 실효, 청구 거절, 부분 지급)는 독립 난수 삽입이 아니라 같은 엔터티 라이프사이클에서 분기합니다.
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개 모두 이 3범주 패턴(스냅샷, 트랜잭션, 이벤트)과 일관된 메타데이터·상태 추적을 따릅니다. 다이어그램은 전체 웨어하우스에 쓰이는 패턴을 보여 줍니다.
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