극점매크로｜Financial Cloud Cloud · AWS Amarathon 2025
극점매크로｜Amarathon 2025 정리 33：실시간 물류 분석을 위한 스트리밍 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 쓰기.
● 사용자 지정 작성기, 임시 컴팩션 작업 또는 강한 벤더 종속성 없이 실시간 물류 분석을 구현합니다.