티스토리 뷰

반응형

Kafka 의 장점은 메시지큐인데 휘발성이 아니라 파일에 저장되고 offset 형태로 과거의 데이터도 읽어오는게 가장 큰 장점이 아닌가 싶다. 

그래서, 스트림데이터에 대한 재집계 문제를 offset 을 돌려서 처리할수 있고 자체적으로 병렬처리를 위한 개념들이 존재해서 사실상 스트림데이터를 다룰때 표준 플랫폼으로 사용한다. (배치용 스토리지는 hdfs , 스트림 스토리지는 카프카의 topic)

 

토픽(TOPC) 이란 무엇인가?

카프카에서는 데이터를 넣기 위한 공간을 topic 이라고 이야기 한다. (mysql, oracle 같은 dbms의 table을 생각하면 쉽다)

가장큰 다른점이라면, topic 에는 스키마가 존재하지 않는점이다. 쉽게 생각해서 byte 덩어리를 담아서 사용자가 serializable/deserialize 해서 사용한다는 말이다.

 

하지만, 일반적으로는 스키마가 있는 데이터를 다루는게 일반적이라서 문자열(String) 을 Json 포맷으로 저장하거나, 아니면 Avro포맷을 사용하는게 일반적이다.

kafka 의 생산자/소비자 구조에서 토픽의 위치 / 쉽게 생각해서 저장소라고 보면 된다

 

- 토픽의 가장큰 장점은 테이블처럼 용도별로 여러개를 만들수 있고,

- 파일기반에 저장되다보니 offset 을 통해 과거시점에서 읽어낼 수도 있고 (물론, 기간이나 용량제한해서 무제한은 아니다)

- 1개의 토픽에 N개의 consumer 를 만들어서 다양한 시점으로 데이터를 다루는 것도 가능하다

 

이건 일반적인 메시지큐 형태에서와 다른 가장큰 장점이다.

그리고 1개의 토픽은 N개의 파티션으로 분리되고, 병렬처리되는 단위가 되는데 이건 별도의 글로 포스팅 하겠다.

 

스키마 레지스트리(schema-registry)는 무엇인가?

topic은 스키마 없이 무엇이든(?) 담을수 있다고 했다. 

하지만, 규모가 커져서 여러팀에서 클러스터를 사용하다보면, 담당자가 아니면 알수 없는 데이터 난장판(?)이 되버린다.

 

그래서 confluent.io 에서 나오는 kafka 버전은 schema-registry 라는 스키마 정보를 매니징하는 솔루션과 연동해서 사용하게 된다.

(참고로, avro 헤더에 스키마 id 값을 박아 놓고, 데이터를 읽는 형태로 사용한다)

- 스키마레지스트리 :  스키마 정보 
- 토픽(Topic) : 스키마아이디 + 데이터(보통: avro 포맷)

헤더에 schema.id 가 추가되기  avro 포맷이라도 serializable/deserialize 가 달라지므로 주의해야 한다.

그래서 스키마가 없이 사용하는것보다는 매니징이 중앙관리되고, 이력도 관리되서 규모가 커지면 도입하는게 당연하게 된다.

 

그럼 왜 avro 를 주로 쓰는지 궁금할텐데.. 스키마의 변경이 용이하고, json 보다 컴팩트하기 때문이다.

(Json 은 필드명이 매번 반복해서 써야 하는데, avro는 필드명정보는 한번만 정의하고, 그 이후에는 값만 저장한다)

 

마치며

카프카는 초기에는 단순히 data 를 생산하고 소비하는 용도로 사용되었는데, 워낙 유용해서 점점 스트림플랫폼으로 커지고 있다. 여기서 이야기 한것처럼 스키마레지스트리를 붙여 스키마가 있는 데이터를 다루기 쉬워졌는데 점점 이 생태계 위에서 다양한것을 할 수 있게 발전되고 있다. 

 

과거에 hadoop 위에서 다양한 에코시스템이 나왔는데 (hive, hbase 등등)

kafka 에서도 이와 유사하게 해당 기술스택위에 다양한 솔루션들이 계속 추가되고 있다 (KafkaStrems, ksql, ksqldb 등등)

 

앞으로 스트림데이터를 다루는 플랫폼은 kafka가 사실상 중심이 되고 있기 때문에 관련된 용어나 개념을 미리 알아두면 좋을듯 하다.

 

반응형
댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/05   »
1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31
글 보관함