실시간 물류 분석을 위한 스트리밍 Iceberg 테이블 구축

세션 노트

현대 물류의 과제:

• 트럭, 운전자, 경로, 연료, 유지보수, 배송 및 창고에 관한 여러 스트림 관리.
• 실시간 운영 뷰와 장기 분석의 필요성. 데이터 스토리지 요구 사항:
• 즉각적인 운영을 위한 최신 조인 뷰.
• 장기 분석을 위한 Apache Iceberg 사용. 기술 스택:
• RisingWave: 스트리밍 기능을 제공하는 데이터 플랫폼.
• Lakekeeper: 데이터 관리를 위한 개방형 REST 카탈로그.
• Kafka: 스트리밍 데이터의 이벤트 백본.
• 객체 스토리지(예: MinIO): 데이터를 위한 스토리지 솔루션. 목표:
• 지정된 오픈 스택을 사용하여 스트리밍 Iceberg 테이블을 구축하는 방법 시연.
• 현대적인 물류 데이터 관리를 위한 간단하고 효과적인 솔루션 제공. 물류 분석 문제
• 오늘날의 물류 플랫폼에서 생성되는 데이터:
• 트럭: 차량 인벤토리 및 위치
• 운전자: 명단 및 배정
• 배송: 출발지, 목적지 및 중량
• 창고: 용량 및 사업장
• 경로: ETA 및 거리
• 연료 및 유지보수: 비용 및 신뢰성 신호
• 과제:
• 운영 팀에는 이 모든 스트림을 아우르는 최신 조인 뷰가 필요합니다.
• 데이터 팀에는 BI, AI 및 이력 분석을 위해 Iceberg에 동일한 데이터가 필요합니다. 구축할 항목(스트리밍 Iceberg 패턴)
• Kafka가 7개의 물류 토픽을 RisingWave로 공급합니다.
• 다중 스트리밍 조인을 SQL로 표현하고 RisingWave 내부에서 지속적으로 구체화합니다.
• 결과는 RisingWave에서 MinIO 같은 S3 호환 객체 스토리지의 네이티브 Apache Iceberg 테이블로 영구 저장됩니다.
• Spark, Trino, DuckDB 같은 엔진은 개방형 REST 카탈로그를 통해 동일한 Iceberg 테이블을 쿼리합니다. RisingWave로 스트리밍 Iceberg 테이블을 구축하는 이유
• [ 1 ] 배치 우선 워크플로:
• 주기적 작업, 오래된 조인 및 무거운 파이프라인.
• Iceberg에 쓰기 위한 별도의 ETL 도구.
• [ 2 ] RisingWave + 스트리밍 Iceberg 테이블:
• RisingWave MV에서 지속적으로 업데이트되는 조인 및 집계.
• 항상 “거의 최신” 상태인 Iceberg 스냅샷.
• 실시간 대시보드와 오프라인 분석을 모두 지원하는 하나의 RisingWave 파이프라인.
• 목표: RisingWave가 스트리밍 파이프라인과 Iceberg 쓰기를 담당하게 하여 Iceberg를 데이터베이스처럼 활용.

상위 수준 아키텍처

• 엔드투엔드 스택:
• Kafka — 7개 물류 토픽의 이벤트 백본.
• RisingWave(스트리밍 데이터베이스) — SQL로 수집, 조인 및 집계하고 구체화된 뷰 관리.
• RisingWave Iceberg Table Engine + Lakekeeper — Iceberg 테이블을 위한 개방형 REST 카탈로그.
• MinIO — S3 호환 객체 스토리지.
• 패턴: Kafka → RisingWave → MinIO의 Iceberg → REST 카탈로그를 통해 모든 엔진에서 쿼리. RisingWave의 물류 스트림 및 다중 스트리밍 조인
• RisingWave의 7개 물류 스트림
• 예시에서는 RisingWave의 소스가 되는 7개의 Kafka 토픽을 사용합니다:
• trucks — 차량 인벤토리, 적재 용량, 현재 위치.
• driver — 운전자 세부 정보 및 assigned_truck_id.
• shipments — 출발지, 목적지, 중량, 트럭 연결.
• warehouses — 창고 위치 및 용량.
• route — route_id, truck_id, driver_id, ETD/ETA, distance_km.
• fuel — 주유 이벤트(시간, 리터, 주유소).
• maint — 유지보수 이력 및 비용.
• RisingWave는 각각을 스트리밍 테이블로 취급하므로 간단한 PostgreSQL 스타일 SQL로 바로 조인할 수 있습니다. 패턴 1: RisingWave의 다중 스트리밍 조인
• RisingWave에서는 핵심 물류 로직을 하나의 다중 스트리밍 조인으로 표현합니다.
• 일치하지 않는 운전자도 표시되도록 drivers → trucks에 LEFT JOIN.
• 작업량과 목적지를 연결하기 위해 shipments에 JOIN.
• 용량과 위치를 가져오기 위해 warehouses에 JOIN.
• ETD/ETA와 거리를 위해 route에 JOIN.
• 비용 및 신뢰성 신호를 위해 fuel과 maint에 JOIN.
• 이 결과는 logistics_joined_mv가 됩니다. 즉, RisingWave 내부에서 트럭/운전자/경로별로 지속적으로 업데이트되는 비정규화된 물류 레코드입니다.

차량 KPI, 네이티브 Iceberg 테이블 및 엔진 간 읽기

패턴 2: RisingWave의 차량 KPI 뷰

• 조인된 MV 위에 차량 KPI를 위한 또 하나의 RisingWave MV를 정의합니다:
• 트럭별 적재 용량 활용률(%).
• 트럭별 총연료비 및 유지보수비.
• 통합 총운영비.
• 현재 경로 컨텍스트(ID, ETD, ETA, distance_km).
• 관련 운전자 세부 정보. RisingWave의 개요는 Grafana 및 운영 대시보드를 위한 실시간 차량 성능 테이블이 됩니다. 패턴 3: RisingWave에서 네이티브 Iceberg로 스트리밍
• 사용자 지정 작성기 서비스 대신:
• [ 1 ] logistics_joined_iceberg를 RisingWave에서 관리하는 네이티브 Iceberg 테이블로 정의합니다.
• [ 2 ] 스키마는 logistics_joined_mv를 그대로 반영합니다.
• [ 3 ] RisingWave의 간단한 설정으로 스트리밍 변경 사항을 Iceberg 스냅샷으로 커밋하는 빈도를 제어합니다. 패턴 4: REST 카탈로그를 통한 엔진 간 읽기
• RisingWave에서 생성하고 Lakekeeper REST 카탈로그에 등록한 Iceberg 테이블을 사용하면:
• [ 1 ] Spark가 lakekeeper를 카탈로그로 연결
• [ 2 ] Trino / DuckDB / Dremio는 각자의 Iceberg 커넥터로 동일한 테이블을 읽을 수 있습니다.
• [ 3 ] 모든 엔진이 RisingWave에서 지속적으로 업데이트하는 동일한 Iceberg 데이터를 확인합니다.
• 복사본도, 독점 테이블 형식도 없이 RisingWave에서 작성한 순수 Iceberg만 사용합니다.

로컬 노트북에서 프로덕션 클러스터까지: 배포 옵션

• 배포 옵션: 노트북에서 클러스터까지
• [ 1 ] 로컬(학습 및 프로토타이핑용):
• Docker로 RisingWave, Kafka, MinIO 및 Lakekeeper를 실행합니다.
• 노트북에서 스트리밍 조인과 Iceberg 테이블을 실험하기에 적합합니다.
• [ 2 ] 프로덕션(실제 워크로드용):
• Kubernetes + Helm을 통해 RisingWave와 나머지 스택을 배포합니다.
• 환경에 적합한 스토리지 클래스, 리소스 제한 및 영속성을 사용합니다.
• RisingWave에서 동일한 SQL과 패턴을 사용하면서 내구성, 확장성 및 자동화를 강화합니다. 기존 Iceberg 스택 간소화
• 기존 Iceberg 배포에는 흔히 다음이 필요합니다:
• 별도의 스트림 처리 엔진.
• 독립 실행형 Iceberg 작성기 작업.
• 외부 컴팩션 및 유지보수 워크플로.
• 카탈로그, 작성기 및 스토리지를 일관되게 유지하기 위한 추가 연결 작업.
• RisingWave를 사용하면:
• [ 1 ] 스트리밍 데이터베이스가 수집, 조인, 구체화된 뷰 및 Iceberg 쓰기를 처리합니다.
• [ 2 ] REST 카탈로그 + MinIO가 모든 요소의 완전한 개방성과 상호운용성을 유지합니다.
• 구성 요소 수와 운영 오버헤드가 줄어듭니다. RisingWave를 사용한 참조 아키텍처
• RisingWave를 중심으로 시스템을 세 계층으로 생각할 수 있습니다:
• [ 1 ] 스트림 → RisingWave 테이블.
• Kafka 토픽이 RisingWave의 스트리밍 테이블이 됩니다.
• [ 2 ] 테이블 → RisingWave 구체화된 뷰.
• 스트리밍 조인과 집계가 실시간 MV(logistics_joined_mv, truck_fleet_overview)가 됩니다.
• [ 3 ] 뷰 → 스트리밍 Iceberg 테이블.
• RisingWave는 간단한 설정과 INSERT....SELECT를 통해 MV를 스트리밍 Iceberg 테이블로 변환합니다.
• RisingWave를 “스트리밍 SQL + Iceberg 엔진”으로 이해하면 이 모델을 다양한 도메인에서 재사용할 수 있습니다. 물류 이외의 재사용 가능한 패턴
• RisingWave + Iceberg 패턴의 적용 분야:
• 전자상거래: 주문, 재고, 가격 책정, 고객 이벤트.
• 핀테크: 거래, 잔액, 위험 신호.
• 산업용 IoT: 기계, 센서, 알림, 유지보수.
• 통신: 세션, 사용량, QoS 지표.
• 여러 실시간 스트림과 개방형 장기 스토리지가 필요한 곳이라면 어디서나 같은 방식으로 RisingWave MV와 Iceberg 테이블을 사용할 수 있습니다. 핵심 요점(RisingWave + Iceberg)
• Kafka, RisingWave, REST 카탈로그, MinIO 및 Iceberg를 결합한 참조 아키텍처.
• 실용적인 패턴: 다중 스트리밍 조인, KPI 뷰 및 RisingWave의 네이티브 Iceberg 쓰기.
• 사용자 지정 작성기, 임시 컴팩션 작업 또는 강한 벤더 종속성 없이 실시간 물류 분석을 구현합니다.