샘플 데이터 · SimEDW

엔터프라이즈 규모 샘플 웨어하우스.

완전히 시뮬레이션된 EDW 다섯 개 — Amazing(옴니채널 이커머스), Hilson(글로벌 호텔 그룹), P&C(CPG 제조), HKBC(홍콩 유니버설 뱅크), AYA(홍콩 복합 보험사) — 현실적인 벤더 고유 스키마, ClickHouse의 메달리온 준비 브론즈, 라이브 이벤트 스트림. VibeBI에서 시맨틱 레이어, 디멘셔널 모델링, 셀프서비스 분석을 시험하기 위해 만들었습니다.

5
산업 팩
182
벤더 소스 시스템
321
브론즈 테이블 합계
60초
라이브 데이터 새로고침
46 벤더 시스템 79 브론즈 테이블 5 단계 DB amazing_v2

회사 프로필

가상 회사 안내: "Amazing"은 시연 목적으로만 만든 가상의 회사입니다. Amazon.com, Inc. 또는 실제 어떤 기업과도 제휴되어 있지 않으며, 보증하거나 대표하지 않습니다.

Amazing 은 자사 1P 재고, 3P 셀러 마켓플레이스, 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
지원 / VoCzendesk · qualtricsticket · nps_response

OOP 도메인 모델

AmazingEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.

OrderToCash 이 기본 프로세스 중추입니다. CommerceOrder.execute_lifecycle() 상태 머신(캡처, 결제, 피킹/패킹, 송장, GL)을 진행하며, 각 단계가 다음을 호출합니다 runtime.record(system, object, payload) 해당 벤더 어댑터에서. 포트폴리오 부트스트랩(AmazingPortfolio.publish_foundation())가 주문 실행 전에 CRM 계정, PIM SKU, 풀필먼트 노드를 마스터합니다.

도메인 엔터티자연 키라이프사이클 메서드
CustomerAccountsf_account_idSalesforce에서 마스터된 CRM 계정
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
          

부서별 기능 조직

엔터프라이즈 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]
          

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 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
          
31 벤더 시스템 62 브론즈 테이블 5 단계 DB hilson_v2

회사 프로필

가상 회사 안내: "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_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
Folio / 청구oracle_operafolio_header · folio_charge
F&B 매장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 동기화 → folio 요금 → 결제 → 로열티 포인트 → 점유 스냅샷 → 오너 명세서 → GL 순으로 진행합니다. HilsonPortfolio.publish_foundation() 예약 실행 전에 브랜드, 숙박 시설, Honors 회원을 마스터합니다.

도메인 엔터티자연 키라이프사이클 메서드
Brandbrand_codehilson_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
          

부서별 기능 조직

엔터프라이즈 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]
          

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초 틱 경유 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
          
34 벤더 시스템 60 브론즈 테이블 5 단계 DB pnc_v2

회사 프로필

가상 회사 안내: "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에서는 ProductionBatchCustomerOrder 도메인 클래스가 MakeToShipToSell 중추를 구동합니다.

엔터티소스 시스템예시 테이블
SBU / 브랜드 사다리pc_brandbrand · category
완제품 SKUakeneo_pimsku · brand · category
공장 / DC 마스터oracle_scmwarehouse · office
수요 예측blueyonderforecast_daily
원자재 POsap_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() 예측 → 조달 → 생산 → QC 출고 → 완제품 순으로 진행합니다. 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제조 공장 또는 DC 등록
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에는 여기에 표시되지 않은 교차 기능 통합, 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]
          

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초 틱 경유 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
          
32 벤더 시스템 60 브론즈 테이블 5 단계 DB hkbc_v2

회사 프로필

가상 회사 안내: 「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_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
FX / 마켓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 알림 → EOD 예금 잔액 → GL 순으로 진행합니다. HkbcPortfolio.publish_foundation() 결제가 돌기 전에 지점, 상품, CIF 고객, 계좌를 마스터합니다. 서비스 객체가 CMB 무역, GBM FX, 웰스, 리스크, 코퍼레이트 행을 방출합니다.

도메인 엔터티자연 키라이프사이클 메서드
Branchbranch_codehkbc_core에서 마스터된 지점 / 도매 데스크
Productproduct_codeCASA, 주택담보, 카드, 월렛, 무역, FX 카탈로그
Customercustomer_idCIF + KYC 세그먼트; Salesforce CRM 미러
Accountaccount_idpublish()post_pair() 균형 원장
FpsPaymentpayment_idexecute_lifecycle() → 레일 → 분개 → AML
DocumentaryCreditlc_idCMB LC / 보증 발행
FxTradetrade_idMurex 티켓 → 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]
          

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초 틱 경유 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
          

Pay-to-post 이벤트 그래프

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
          
39 벤더 시스템 60 브론즈 테이블 5 단계 DB aya_v2

회사 프로필

가상 회사 안내: 「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에서는 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
GL / IFRS 17sap_s4journal_entry · journal_line

OOP 도메인 모델

AyaEnterpriseSimulation 하루를 순서대로 실행하며, 도메인 객체가 방출 로직을 소유합니다.

QuoteToBindToPremium 는 신계약 중추입니다. FnolToPay 는 클레임 중추입니다. LifePolicy.execute_lifecycle() 견적 → Magnum UW → Ingenium 발행 → FPS 수금 → 수수료 → GL 순으로 진행합니다. GiPolicy.execute_lifecycle() 견적 → PolicyCenter 인수 → BillingCenter 청구서 → ClaimCenter의 선택적 당일 FNOL 순으로 진행합니다. AyaPortfolio.publish_foundation() 증권이 돌기 전에 상품, 설계사, 사무소, 계약자를 마스터합니다.

도메인 엔터티자연 키라이프사이클 메서드
InsuranceProductproduct_codeaya_product의 생명 / 건강 / 일반보험 요율
Agentagent_idIA 라이선스 등록 + Salesforce 프로듀서
Policyholdersf_account_id매스 / HNW / SME / 고용주 CRM
LifePolicypolicy_numberpublish_quote() → UW → 인수 → 수금 → 수수료 → GL
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개 전반의 추가 에이전시 지구, 마카오·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]
          

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초 틱 경유 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
          

Quote-to-bind 및 FNOL 이벤트 그래프

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
          

BI를 바이브하기 시작하십시오.

데스크톱 앱, 서버, SimEDW 샘플 데이터를 다운로드하고, 오후에 첫 거버넌스 웨어하우스 구축을 진행하십시오.

빠른 시작 → 제품 미리보기 백서 읽기