kafka

broker실행된 카프카 애플리케션 서버 중 1대3대 이상의 브로커로 클러스터 구성주키퍼와 연동(주키퍼는 메타데이터를 저장)n개 브로커 중 1대는 컨트롤러 기능 수행(컨트롤러 : 각 브로커에게 담당 파티션 할당 수행, 브로커 정상 동작 모니터링 관리, 누가 컨트롤러 인

소스에서 생성되는 데이터를 어느 타깃으로 보낼 것인지 고민하지 않고 카프카에 넣으면 됨프로듀서에서 메시지를 보내면, 여러 파티션에서 하나의 파티션에 데이터가 적재적재된 데이터를 하나씩 가져가더라도 파티션의 데이터는 삭제되지 않음특정 컨슈머가 파티션에서 가져가는 데이터를

초기 빅데이터 플랫폼은 end-to-end유연하지 못하고 빠른 전달 불가히스토리 파악 어려움데이터의 가공으로 데이터가 파편화되면서 데이터 거버넌스를 지키기 어려움배치 레이어 : 원하는 시간, 타이밍에 배치하여 일괄 처리서빙 레이어 : 가공된 데이터 저장 공간스피드 레이

그동안 내가 다뤄온 데이터 파이프라인은 대부분 배치 기반이었다.일 단위 혹은 시간 단위로 데이터를 모아서 처리하고,필요한 경우 재실행(catchup)과 멱등성을 고려해 안정성을 확보하는 구조였다.이 방식은 대부분의 요구사항을 잘 만족했지만,운영을 하다 보니 한 가지 질

솔직히 처음엔 CDC가 뭐가 그렇게 대단한지 잘 몰랐다.“결국 테이블 하나 더 만들고, ETL 한 번 더 돌리는 거 아닌가?”내 사고는 거기까지였다.나는 그동안 배치 기반으로 대부분의 문제를 해결해왔다.하루 한 번 정리하고, overwrite 하고, 정합성 맞추고.틀리