[정리] 최신 데이터 인프라 이해하기_#7 - Kafka Streams, kSQL, ksqlDB, Apache Flink, Spark Structured Streaming

Ingestion and Transformation

Streaming Processing

kafka는 real time, spark는 마이크로 배치 

Kafka Streams

kafka streams는 JVM client library이다.

스트림에 대해서 처리한다음에 다시 kafka에 저장한다. 카프카에 올라가는 event stream에 대해서 어떤 처리를 하는 것들인데, 카프카 스트림즈는 JVM client library를 활용해서 JAVA로 코딩을 할수있다.

 

kafka cluster에서 streams API를 통해, 우리의 앱은 실제로 kafka cluster 밖에 있지만.

밖에서 kafka cluster에서 카프카에 이벤트가 올라오면 streams API 가져다가 우리 앱이 처리하고 그걸 다시 저장하는 형태로 실행된다.

kafka streams API는 이벤트 데이터를 받아서 그걸 처리를 통해 굉장히 빠르게 stream processing을 해서 저장하는데

stateless, stateful, windowing operation이라고 한다.

 

stateless -한 이벤트 streams에서 기존상태와 상관없이 무조건 처리(연산)

stateful - 기존의 상태를 이해해야지만 되는것.(특정 이벤트가 몇번 일어났나)

windowing operation - 숫자를 어느 기간 동안 셀거냐, 기간을 정해서 그동안 일어난 일들을 처리(1시간동안이냐 10분이냐 등등)

 

stateful은 join같은 행동을 하는데  -> stream에 대해서도 처리가 가능하다.(데이터 베이스에서 inner&Outer join 하는것 처럼)

노출과 클릭은 서로 다른 이벤트이지만 서로 연결되어야지만, 어떤광고가 어떻게 노출되었고 언제 클릭이 됐다. 이런걸 체킹하고 싶으면 stateful. 

java api를 써서 이벤트 스트림을 처리할 수 있다. 

kSQL

조금 더 쉽게 해주는게 KSQL

이 스트림에 대해서 잘 아는 sql 문장으로 stream처리 가능. 

 

KSQL  처리하는 별도의 cluster가 있다.여길 통해서 JVM에서 러닝해서 Kafka cluster 쿼리를 날려야한다.

이처럼 따로따로 관리해야된다는 단점때문에 KSQL DB가 생김.

 

ksqlDB

KSQL DB는 메인으로 두가지를 추가하게 된다. 

1. Pull queries

- KSQL DB 전에, KSQL쓴는게 좋았던 이유는 기존의 우리가 쓰던 쿼리문 말고 KSQL을 썼을때 push aueries를 썼기 때문

push aueries는 쭉 계속 변경한 것들을 받을 수 있는 쿼리를 만들어서, 위치를 빠꿀 수 있다. 

- 기존 데이터 베이스 Pull queries(현재있는 데이터만 가져와봐), KSQL DB로 오면서 이것도 가능해졌다. 완벽하게 데이터 베이스처럼 기능이 발전했다.

- KSQL은 streaming SQL 방식으로 데이터가 계속 전달되는 방식만 지원했었는데,  KSQL DB로 오면서 현재 kafka에 있는 이벤트, 데이터들을 데이터베이스처럼 pulling,싹 긁어와서 처리할 수 있게 됨. 

 

2. connector management 

- KSQL은 kafka cluster 밖에 있었기 때문에 어떤 데이터를 가져올지에 대해서 카프카 클러스터 내에서 설정을 해줬어야한다.

그런데 KSQL DB는 안에서 connector 자체를 만들 수 있다. 

-내부에서 어떤 데이터를 가져와서 sql로 처리하고 다시 넣을거다 라는걸 KSQL DB내에서 처리할 수 있어 엄청 간단해졌다.

  

 

--> 모든걸 KSQL DB안에서 처리할 수 있게 되니까, kafka cluster를 만들고 거기 위에 kafka streams용 cluster를 만들거나 

KSQL용 cluster 따로 만드는 작업 필요 없이 KSQL DB 하나만으로 전체 처리가 가능해진다. 

 

KSQL DB

모든 stream processing connector 이런것들을 하나로 묶어서 처리하는게 KSQL DB.

kafka에 올라가는 모든 데이터들은, 이벤트 스트림들을 처리해서 내가 만든 sql로 조작 후 조인 셀렉트 트랜스폼 하는 처리를 kafka stream에 올리거나 DB에 저장하거나 하는 것들을 sql 문장 가지고만 처리할 수 있게 만든게 KSQL DB

 

Flink

data stream에 대해서 stateful한 computations

apache flink -> stateful은 특정 이벤트 하나가 아니라, 다양한 이벤트를 조인해서 처리하는 그런 computations 들을 stream에 대해서 처리할 수 있게 해주는 것 . (?)

Spark Structured Streaming

spark도 스트리밍 처리가 있다. 스파크는 마이크로 배치.

apache flink나 kafka는 무한 반복하면서 record가 하나들어오면 바로바로 처리하는 native streaming 방식.

spark는 아주 짧은 시간동안 들어오는 이벤트를 모아서 처리하는 non-native streaming 방식

스파크는 마이크로 배치, 카프카는 실시간 프로세싱.

비교

flink & storm은 좀 더 빠르게 전문적으로 stream processing을 하겠다라면 쓰는것임.

 

stream processing은 내부에서 stream으로 쏟아지는 데이터들을 엮어서 처리해야될 때(ex-광고의 조회와 클릭을 엮을떄. 이벤트 스트림으로 들어온것들을 다른데이터와 묶어서 join해서 데이터를 봐야할때) 쓸수있는 엔진들임. 

 

사내에 spark플랫폼이 있으면 스파크 자체 stream processing을 얹어서 쓰고 카프카도 마찬가지. 

그러면 소스에서 받아오는 모든 이벤트 스트림에 대해서 처리하고 그걸 다시 data lake 나 data warehouse에 저장하는 구조로 구현하면 됨. 

 

 

다음은  data lake 나 data warehouse에 대한 내용인데 아직 영상이 올라오지 않았다.. 1년전껀데..😱