1. KSQL의 등장 배경

• 카프카 → 데이터 버스(데이터를 전송하는 영역) → 데이터 가공 → 다른 Storage나 DB에 저장

• 카프카가 다른 MQ에 비해 부족한 기능이 바로 다른 큐로 전달하는 큐 라우팅 기능

  • 아파치 삼자가 대표적인 이 영역의 소프트웨어

• 카카오 케미 서비스처럼 Raw 데이터를 처리해서 기간과 용량에 따라 별도의 저장소를 가져가는 것을 람다 아키텍쳐라고 한다

  카카오의 전사 리소스 모니터링 시스템 - KEMI(Kakao Event Metering & monItoring)

람다 아키텍쳐 장점

• 파이프라인을 통해 큰 어려움 없이 적절한 기술들을 연결해서 단기 데이터와 장기 데이터를 동시에 관리할 수 있다.
• 병목이 생길 경우 특정 컴포넌트만 증가시키면 된다.
• 데이터 조회 영역에서 큰 어려움 없이 단기/장기데이터를 한 번에 조회할 수 있다.

람다 아키텍쳐 단점

• '적절한 기술들을 연결'하기 위해 너무 많은 기술들을 사용해야 한다.
• 단기 데이터와 장기 데이터를 별도로 관리해야 하기 때문에 관리비용 측면에서 부담이 된다.

→ 이러한 몇 가지 단점때문에 람다 아키텍처는 예산이 부족하고 인원이 작은곳에 적용하기 어려움

• 간단한 계산과 필터링은 카프카에서 직접 수행하고, 계산 프로그램 역시도 장기나 단기 구분없이 동일한 프로그램을 사용하길 원함
• 그렇게 등장한 것이 바로 카파 아키텍처이고, 이때 사용하는 기술 중 하나가 바로 카프카 SQL, 즉 KSQL이다.

2. KSQL과 카파 아키텍처

• 람다 아키텍처와의 가장 큰 차이점
  • 장기 데이터를 계산해서 빨리 조회할 수 있도록 배치 작업을 써서 '장기 데이터를 따로 저장'하는 것이 아니라 장기 데이터 조회가 필요할 경우에 '계산'해서 결과를 그때 그때 전달
  • 데이터 제공 영역이 없어지고 계산이라는 영역이 남음
  • 단기 데이터 : 카프카 토픽에 저장하고 아파치 스파크나 스톰, 또는 삼자를 통해 결과 데이터 생성
  • 장기 데이터 : 하둡에 복사한 다음 맵리듀스나 스파크를 통해 결과를 만들어냄
• KSQL이 만들어지게 된 출발점
  • 카파 아키텍처에 카프카를 적용해서 카프카 토픽들을 단기, 장기로 저장할 수 있게 함
  • SQL 기반의 쿼리문으로 조회할 수 있게 하자

3. KSQL 아키텍처