[Apache Kafka] KSQL ?

Dragony·2023년 4월 5일

Kafka

목록 보기

2/7

장점
- 데이터의 정확성, 일관성을 제공함과 동시에 최소의 지연으로 실시간적인 결과를 사용자에게 제공
단점
- 배치레이어와 스피드레이어의 분리로 인한 관리포인트의 증가
- 배치처리와 실시간처리시의 개발언어나 오픈소스 인프라의 컨셉자체가 틀려 고려할 사항이 많고 이에 따라 기능이 중복되고 관리/유지보수에 많은 공수가 투입되며 복잡

→ 람다 아키텍처의 배치레이어와 스피드레이어의 기능적 중복성와 복잡성을 제거하기 위해 “카파 아키텍처” 제안

→ 카파 아키텍쳐에서 사용하는 기술 중 하나가 KSQL

카프카는 내부 토픽을 Sub하여 분석하거나, Sub 한 토픽을 정제하여 다시 토픽으로 Pub 할 수 있습니다.
그렇다면 이러한 파이프라인을 구축할 때, 어떤 방법을 고려할 수 있을까요? 카프카에서는 다음 3가지 방법을 고려할 수 있습니다.

1번 방식은 추상화가 가장 낮은 단계이고, 1번 방식을 라이브러리 형태로 추상화한 것이 2번 스트림즈 방식입니다. 3번 방식인 KSQL은 2번 스트림즈 방식을 더욱 추상화한 형태입니다.

즉, KSQL은 1번, 2번 방식보다 사용자들이 쉽게 사용할 수 있다는 것인데, 그 이유는 다음 특징을 가지기 때문입니다.

일단, 가장 큰 특징으로 KSQL은 유사 SQL 문을 이용하여 로직을 구현합니다. 그렇기 때문에 API 등 프로그래밍 지식이 많이 요구되지 않습니다.

그리고 구현된 KSQL 문을 기존에 배포되어 구동되고 있는 KSQL 엔진(서버)에 배포하면, 엔진 내에서 로직에 맞춰 구동됩니다. 그렇기 때문에 사용자가 직접 서버 배포까지 고려할 필요가 없게 됩니다.

이처럼 KSQL은 기존 카프카 스트림즈에서 발전하여 사용자가 더욱 손쉽게 데이터 파이프라인을 구축할 수 있도록 도와줍니다. 이러한 특징 때문에 카프카 토픽에 대한 데이터 분석에 자주 고려됩니다.

사용자로부터 쿼리를 받을 수 있는 REST API 서버와 넘겨받은 쿼리를 직접 실행하는 KSQL 엔진 클래스로 구성
RDBMS 와 유사하게 사용자의 쿼리를 논리적/물리적 실행 계획으로 변환하여 쿼리 실행 (일반적인 데이터베이스가 하는 쿼리 실행 절차를 따름)
- 논리/물리계획을 작성할 떄 필요한 테이블 메타정보(컬럼 이름, 컬럼타입)은 별도의 저장소에 저장하는 것이 아니라 KSQL 서버의 메모리에 있음
- 필요한 경우 ksql__commands 라는 카프카 토픽에 저장하는 것이 일반적
- ksql_commands 토픽에는 KSQL 서버 생성 후에 실행한 테이블 관련 명령어가 들어있기 때문에, KSQL 인스턴스나 서버가 추가되었을때 메타데이터를 클러스터간에 복제하는 것이 아니라, 토픽을 읽어 자신의 메모리에 생성.
지정된 카프카 클러스터의 토픽으로부터 데이터를 읽거나 토픽을 생성해 데이터를 생성하는 역할을 함

KSQL은 스트림을 처리하는 엔진이므로 기존 SQL 에서 지원하는 테이블 외에 연속된 정형화된 데이터를 의미하는 스트림(Stream) 이라는 데이터 모델도 제공
파이프라인을 통해 지속적으로 생성되고 흐르는 데이터
스트림에는 데이터가 계속 기록될 수 있지만, 한번 기록되면 이벤트는 변경될 수 없음
일련의 시퀀스가 중요한 데이터는 스트림으로 생성
- eg) “철수가 10원을 썼다. 그리고 철수가 10원을 벌었다.”