Spark Streaming 이 kafka 를 연결 하 는 두 가지 방식

Spark 는 Kafka 에 대한 연결 은 주로 두 가지 방식 이 있 는데 하 나 는 DirectKafkaInputDStream 이 고 다른 하 나 는 KafkaInputDStream 이다.
  【Receiver-based】     이 방법 은 Receiver 를 사용 하여 데 이 터 를 받 습 니 다.이 Receiver 구현 에는 Kafka high - level consumer API 가 사용 됐다.Receiver 가 kafka 에서 받 은 데 이 터 는 Spark executor 에 저장 되 며, 이후 시 작 된 job 는 이 데 이 터 를 처리 합 니 다.    기본 설정 에서 이 방법 이 실패 하면 데 이 터 를 잃 어 버 립 니 다 (executor 메모리 에 저 장 된 데 이 터 는 application 이 실패 한 후에 사 라 졌 습 니 다). 데 이 터 를 잃 어 버 리 지 않도록 하려 면 WAL (즉, HDFS, S3 등 으로 미리 쓰기 로그) 을 사용 해 야 합 니 다. 실패 하면 로그 파일 에서 데 이 터 를 복원 할 수 있 습 니 다.  이 함수 에 서 는 Receiver InputDStream 에 KafkaInputDStream 대상 을 새로 만 듭 니 다.KafkaInputDStream 은 getReceiver 방법 을 실현 하여 수신 기의 인 스 턴 스 를 되 돌려 줍 니 다.

  def getReceiver(): Receiver[(K, V)] = {
    if (!useReliableReceiver) {
      //<     WAL
      new KafkaReceiver[K, V, U, T](kafkaParams, topics, storageLevel)
    } else {
      //<    WAL
      new ReliableKafkaReceiver[K, V, U, T](kafkaParams, topics, storageLevel)
    }
  }

    Kafka Topic 의 partitions 는 RDD 의 partitions 와 직접적인 관계 가 없어 일일이 대응 할 수 없다.topic 의 partition 개 수 를 늘 리 면 하나의 Receiver 가 데 이 터 를 받 는 스 레 드 만 증가 합 니 다.사실 이 방법 을 사용 하면 하나의 executor 에서 Receiver 만 사용 합 니 다. 이 Receiver 는 하나의 스 레 드 탱크 를 포함 하고 스 레 드 탱크 의 스 레 드 개 수 는 모든 topics 의 paritions 갯 수 와 일치 하 며 각 스 레 드 는 하나의 topic 의 파 티 션 데 이 터 를 받 습 니 다.데 이 터 를 처리 할 때의 병행 도 를 증가 시 키 지 않 는 다.    WAL 을 사용 하면 받 은 데 이 터 를 로그 방식 으로 지정 한 저장 시스템 에 백업 할 수 있 도록 입력 한 데이터 의 저장 등급 을 'StorageLevel. MEMORY' 로 지정 해 야 합 니 다.AND_DISK_SER
StorageLevel.MEMORY_AND_DISK_SER_2`
  [Direct - based] Spark - 1.3.0 부터 Receiver 가 필요 없 는 방법 을 제공 합 니 다.receivers 를 사용 하여 데 이 터 를 수신 하 는 대신 이 방법 은 각 topic + partition 의 lastest offset 를 정기 적 으로 조회 하고 이에 따라 각 batch 가 받 을 offset 범 위 를 결정 합 니 다.    이 방식 은 Receiver 를 사용 하 는 방식 보다 다음 과 같은 장점 이 있 습 니 다.
    1. 간략화 병렬: 더 이상 kafka input DStream 을 만 들 지 않 고 유 니 온 이 input DStream 을 만 들 필요 가 없습니다.directStream 을 사용 하면 Spark Streaming 은 Kafka partitions 와 같은 수량의 paritions 의 RDD 를 만 들 고 RDD 의 partition 은 Kafka 의 partition 과 일일이 대응 하여 이해 하고 조정 하기 쉽다.
    2. 효율 성: 방식 1 에서 데이터 의 분실 을 확보 하려 면 WAL (미리 쓰기 로그) 을 사용 해 야 합 니 다. 이것 은 더 많은 공간 을 차지 합 니 다.방식 2 에 서 는 Kafka 가 지정 한 topic 의 지정 한 offsets 에서 데 이 터 를 직접 복구 할 수 있 으 며 WAL 을 사용 하지 않 아 도 됩 니 다.
    3. 딱 한 번 의 의미 보증: Receiver 방식 을 바탕 으로 Kafka 의 high level API 를 사용 하여 Zookeeper 에 소 비 된 offsets 를 저장 합 니 다.이 는 어떤 경우 에 일부 데 이 터 를 두 번 소비 하 게 할 수 있 습 니 다. 예 를 들 어 streaming app 은 특정한 batch 에서 받 은 데 이 터 를 처리 하 는 과정 에서 끊 었 지만 데 이 터 는 일부분 을 처 리 했 습 니 다. 그러나 이 경우 처 리 된 데 이 터 를 Zookeeper 에 업데이트 할 수 없습니다. 다음 에 다시 시작 할 때 이 데 이 터 는 다시 소비 되 고 처 리 됩 니 다.direct 방식 을 바탕 으로 kafka 의 간단 한 api 를 사용 하고 Spark Streaming 은 스스로 소비의 offset 를 추적 하여 checkpoint 에 저장 합 니 다.Spark 자신 은 반드시 동기 화 되 어 있 기 때문에 데이터 가 한 번 소비 되 고 한 번 만 소비 된다 는 것 을 보증 할 수 있다.이러한 방식 에 서 는 output 작업 과 offsets 작업 을 하나의 원자 작업 으로 밀봉 하면 실패 후의 중복 소비 와 처 리 를 피 할 수 있어 적절 한 의미 (Exactly - once) 에 도달 할 수 있다.