네이티브 메타데이터 지원 (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은 매번 소스시스템의 전체 데이터를 읽어서 타깃에 적재하는 패턴.