들어가며 지난 글에서 Spark RDD에 대해서 알아보았다. 이번 글에서는 DataFrame에 대해서 알아보겠다. RDD의 문제점 DataFrame이 등장한 이유는 기존 RDD에 문제점이 있었기 때문일 것이다. 그렇다면 왜 RDD가 있었음에도 불구하고 DataFrame이라는 새로운 데이터 구조가 생긴 것일까? 여러가지 이유가 있었는데, 주된 내용은 성능 이슈였다. 메모리 사용 및 디스크 I/O RDD는 디스크에서 데이터를 읽고 쓸 수 있으며, RDD의 메모리 사용은 비효율적이다. 또한 메모리나 디스크에 용량이 충분하지 않으면 제대로 동작하지 않는다. 데이터 처리의 효율성이 떨어짐 스키마 개념이 없어, 구조화된 데이터와 비구조화 데이터를 함께 저장하여 효율성이 떨어진다. 객체 직렬화 오버헤드 RDD는 자바..

들어가며 이번 글에서는 Spark의 데이터 구조인 RDD를 알아볼 것이다. 최근에는 DataFrame과 DataSet을 주로 사용하지만 이는 다음글에서 다루겠다. RDD를 살펴보기에 앞서 하둡과 스파크의 관계를 간단하게 짚고 넘어가겠다. HDFS와 Map Reduce 하둡은 HDFS(Hadoop Distributed File System)라고 불리는 분산 파일 시스템을 기반으로 동작한다. 이를 통해 굉장히 방대한 양의 데이터를 저장/관리할 수 있게 되었고, MapReduce라고 불리는 데이터셋 병렬 처리 방식으로 데이터를 처리했다. 하지만 HDFS도 치명적인 문제점이 있었는데, 바로 HDFS가 Distk I/O를 기반으로 동작하는 것이었다. 또한 실시간(Realtime)에 대한 니즈가 크게 증가하기 시작..

들어가며 카프카의 내부 동작 원리와 구현에서 가장 중요한 부분 중 하나는 리플리케이션 동작이다. 카프카는 물론이고 일반적인 분산 시스템에서는 애플리케이션의 고가용성을 위해 내부적으로 리플리케이션 동작을 하게 되는데, 이러한 리플리케이션 동작의 구현은 매우 어려운 부분일 뿐만 아니라 애플리케이션의 성능 저하도 불러오게 된다. 이를 보완하기 위해 카프카는 안정성을 높임과 동시에 최대한 성능에 영향을 주지 않도록 설계되었다. 이번 글에서는 이러한 카프카 내부 동작을 살펴본다. 카프카 리플리케이션 카프카는 스스로를 고가용성 분산 스트리밍 플랫폼이라고 정의하는 만큼 무수히 많은 데이터 파이프라인의 정중앙에 위치하는 메인 허브 역할을 한다. 이렇게 중앙에서 메인 허브 역할을 하는 카프카 클러스터가 만약 하드웨어의 ..

들어가며 이번 글에서는 카프카의 큰 구성 요소인 프로듀서(Producer), 브로커(Broker), 컨슈머(Consumer)와 전달받은 메시지가 어떻게 관리되는지를 알아본다. Producer Producer는 메시지를 생성해서 카프카의 토픽으로 메시지를 보내는 애플리케이션이다. 여기서 Producer가 카프카에게 메시지를 전달하게 되면 카프카는 ACK/NACK로 응답을 반환한다. Brokers Kafka는 Producer와 Consumer 사이에서 메시지를 중계한다. Producer와 Consumer는 별도의 애플리케이션으로 만들어진 반면, Broker는 Kafka 그 자체이기 때문에 Kafka Broker는 일반적으로 Kafka라고 불리는 시스템을 의미한다. 따라서 Kafka와 Kafka Broker는..