소프트웨어 엔지니어링의 Decorator/Wrapper 패턴과 같은 아이디어입니다. 원본 객체를 감싸는 envelope을 추가하는 것입니다.

네이티브 메타데이터 지원 (Kafka headers)

Exchange hashpartitioning이 보이면 shuffle이 발생하는 것입니다.

Local Aggregator는 shuffle 없이 로컬에서 집계를 수행하는 패턴

핵심 도전: 하나의 세션이 여러 파티션에 걸쳐 존재할 수 있습니다. 예를 들어 시간당 파티션에서 한 사용자의 세션이 3시간 지속되면, 3개 파티션에 레코드가 분산됩니다. 이를 증분 처리로 해결합니다.

Stateful Sessionizer는 스트리밍 파이프라인에서 세션을 생성하는 패턴입니다. Incremental Sessionizer의 “pending sessions 저장소” 역할을 State Store가 대신합니다.

-> 순서를 깨지 않는 범위에서 레코드를 batch로 묶어서 처리하기

Concept

멱등한 파이프라인이란 결국 두 가지 중 하나를 보장하는 것

메타데이터 한계 — 여러 파이프라인에서 이 패턴을 쓰면 한계에 빠르게 도달. freezing 스텝을 따로 두어서, 변경이 없는 오래된 주간 테이블을 월간/연간 테이블로 병합 가능

불변 키 필수 — 데이터 프로바이더가 row를 고유하게 식별할 수 있는 불변 속성을 제공해야함. I/O 비용 — Fast Metadata Cleaner와 달리 데이터 블록 수준에서 동작. 현대 DB와 OTF는 데이터를 활용해 관련 파일만 스캔하도록 최적화가능

키 기반 저장소뿐 아니라 파일이나 파티션 이름에도 같은 원칙이 적용됩니다.

방식 1: 뷰 기반 (View-based)

Key Takeaway

간단한 상태검사를 통해 어플리케이션이 살아있는지 여부 확인

다음 주제에 대해 다룬다.

ChatGPT, Claude, DeekSeek 과 같은 LLM 에 대한 대중적인 관심이 높아지면서 일상적으로 LLM을 쓰는 사람도 예전보다 훨씬 늘어났고 그에 따라 어떻게 활용하면 좋을지에 대한 고민도 많아진 것 같습니다. 개인적으로는 LLM이 기본적으로 어떤 방식으로 구축되는지에 대한 이해가 있어야 LLM의 기본적인 매커니즘과 그 한계를 알고 LLM을 더 나은 방식으로 보다 더 적합한 분야에 적용할 수 있을 것이라고 생각합니다. 여기서는 LLM을 구축할때 거치는 단계에 대해 간략하게 정리해보았습니다.

여러 클러스터가 필요한 주요 시나리오:

Full Load Pattern은 매번 소스시스템의 전체 데이터를 읽어서 타깃에 적재하는 패턴.