KSQL
KSQL 등장 배경
- Kafka를 데이터베이스로 사용하고, 여기에 있는 데이터를 가공해서 다시 다른 스토리지나 데이터베이스에 저장하는 경우가 많아짐
람다 아키텍처
- 일정 주기의 배치 처리와 실시간 스트림 처리를 혼합해서 사용하는 방식
- 장점
- 데이터의 정확성, 일관성을 제공함과 동시에 최소의 지연으로 실시간적인 결과를 사용자에게 제공
- 단점
- 배치레이어와 스피드레이어의 분리로 인한 관리포인트의 증가
- 배치처리와 실시간처리시의 개발언어나 오픈소스 인프라의 컨셉자체가 틀려 고려할 사항이 많고 이에 따라 기능이 중복되고 관리/유지보수에 많은 공수가 투입되며 복잡
→ 람다 아키텍처의 배치레이어와 스피드레이어의 기능적 중복성와 복잡성을 제거하기 위해 “카파 아키텍처” 제안
카파 아키텍처
- 모든 데이터가 실시간 스트림으로 처리되는 아키텍처
- 실시간으로 데이터 처리를 위한 스피드 레이어와 쿼리 요청에 대한 결과 제공 서빙 레이어로만 구성
- 장점
- 레이어 구성이 단순해지면서 운영/유지보수 용이
- 리소스 절감
- 단점
- 스피드 레이어의 이상이나 장애 발생시의 실시간 서비스 제공에 대한 부분과 데이터의 유실등에 대한 보완 필요
→ 카파 아키텍쳐에서 사용하는 기술 중 하나가 KSQL
KSQL
- confluent에서 Streaming Processing을 위해 만든 솔루션(DB, SQL)
- SQL문을 이용하여 내부 토픽에 대한 조회, 집계 등의 연산을 쉽고 간편하게 도와준다.
카프카는 내부 토픽을 Sub하여 분석하거나, Sub 한 토픽을 정제하여 다시 토픽으로 Pub 할 수 있습니다.
그렇다면 이러한 파이프라인을 구축할 때, 어떤 방법을 고려할 수 있을까요? 카프카에서는 다음 3가지 방법을 고려할 수 있습니다.
- Kafka Client를 이용한 Consumer/Producer 직접 구현 배포
- Kafka Streams API 라이브러리를 이용한 어플리케이션 구현 배포
- KSQL 문으로 로직 구현하고 KSQL 서버에 배포
1번 방식은 추상화가 가장 낮은 단계이고, 1번 방식을 라이브러리 형태로 추상화한 것이 2번 스트림즈 방식입니다. 3번 방식인 KSQL은 2번 스트림즈 방식을 더욱 추상화한 형태입니다.
즉, KSQL은 1번, 2번 방식보다 사용자들이 쉽게 사용할 수 있다는 것인데, 그 이유는 다음 특징을 가지기 때문입니다.
- 유사 SQL(KSQL)문을 이용한 로직 구현
- 구현된 KSQL문을 KSQL 엔진에 배포
일단, 가장 큰 특징으로 KSQL은 유사 SQL 문을 이용하여 로직을 구현합니다. 그렇기 때문에 API 등 프로그래밍 지식이 많이 요구되지 않습니다.
그리고 구현된 KSQL 문을 기존에 배포되어 구동되고 있는 KSQL 엔진(서버)에 배포하면, 엔진 내에서 로직에 맞춰 구동됩니다. 그렇기 때문에 사용자가 직접 서버 배포까지 고려할 필요가 없게 됩니다.
이처럼 KSQL은 기존 카프카 스트림즈에서 발전하여 사용자가 더욱 손쉽게 데이터 파이프라인을 구축할 수 있도록 도와줍니다. 이러한 특징 때문에 카프카 토픽에 대한 데이터 분석에 자주 고려됩니다.
KSQL 아키텍쳐
KSQL 엔진 (서버)
- 사용자로부터 쿼리를 받을 수 있는 REST API 서버와 넘겨받은 쿼리를 직접 실행하는 KSQL 엔진 클래스로 구성
- RDBMS 와 유사하게 사용자의 쿼리를 논리적/물리적 실행 계획으로 변환하여 쿼리 실행 (일반적인 데이터베이스가 하는 쿼리 실행 절차를 따름)
- 논리/물리계획을 작성할 떄 필요한 테이블 메타정보(컬럼 이름, 컬럼타입)은 별도의 저장소에 저장하는 것이 아니라 KSQL 서버의 메모리에 있음
- 필요한 경우
ksql__commands라는 카프카 토픽에 저장하는 것이 일반적 ksql_commands토픽에는 KSQL 서버 생성 후에 실행한 테이블 관련 명령어가 들어있기 때문에, KSQL 인스턴스나 서버가 추가되었을때 메타데이터를 클러스터간에 복제하는 것이 아니라, 토픽을 읽어 자신의 메모리에 생성.
- 지정된 카프카 클러스터의 토픽으로부터 데이터를 읽거나 토픽을 생성해 데이터를 생성하는 역할을 함
KSQL 클라이언트
- KSQL에 연결하고, SQL 문을 KSQL 서버에 전달하고 결과를 받음
- KSQL 클라이언트 역시, DDL/DML 지원
스트림과 테이블
스트림
- KSQL은 스트림을 처리하는 엔진이므로 기존 SQL 에서 지원하는 테이블 외에 연속된 정형화된 데이터를 의미하는 스트림(Stream) 이라는 데이터 모델도 제공
- 파이프라인을 통해 지속적으로 생성되고 흐르는 데이터
- 스트림에는 데이터가 계속 기록될 수 있지만, 한번 기록되면 이벤트는 변경될 수 없음
- 일련의 시퀀스가 중요한 데이터는 스트림으로 생성
- eg) “철수가 10원을 썼다. 그리고 철수가 10원을 벌었다.”
테이블
- 스트림의 상태 정보 (state)를 모아놓은 것 (이벤트에 따른 현재 상태를 나타냄)
- 테이블에 기록된 이벤트는 스트림과 달리 변경이 가능.
- eg) “철수가 10원을 써서 현재는 20원이다. 그리고 철수가 10원을 벌어서 현재는 30원이다.”
스트림과 테이블의 상관관계
- 테이블은 스트림의 상태 정보의 축적
- 스트림은 테이블의 변경 로그 (changelog)
여기서 중요한 것은 토픽으로 스트림되는 데이터들을 일정 기준을 통해 상태 정보를 생성하고 관리할 수 있다는 것
