스파크 성능 튜 닝 (성능 개선)

클 러 스 터 에 있 는 Spark Streaming application 에서 최고의 성능 을 얻 으 려 면 조정 이 필요 합 니 다. 이 절 은 여러 개의 parameters (매개 변수) 와 configurations (설정) 를 소개 하여 응용 프로그램의 성능 을 향상 시 킵 니 다. 높 은 차원 에서 두 가지 일 을 고려 해 야 합 니 다.

클 러 스 터 자원 을 효과적으로 이용 하여 Reducing the processing time of each batch of data (각 데이터 의 처리 시간 감소).

정확 한 batch size (대량 크기) 를 설정 하여 batches of data (대량 데이터) 가 receive (수신) 처리 처럼 빠 를 수 있 도록 합 니 다 (즉, data processing (데이터 처리) 와 data ingestion (데이터 섭취) 이 일치 합 니 다).

일괄 처리 시간 감소 (일괄 처리 시간 감소)
Spark 에 서 는 the processing time of each batch 를 최소 화하 기 위해 최적화 할 수 있 습 니 다. 튜 닝 가이드 (튜 닝 가이드) 에서 상세 하 게 토론 한 적 이 있다. 이 절 은 가장 중요 한 것들 을 두 드 러 지게 했다.
Level of Parallelism in Data Receiving (데이터 수신 의 병렬 단계)
네트워크 를 통 해 데 이 터 를 수신 (예 를 들 어 Kafka, Flume, socket 등) 하려 면 deserialized (역 직렬 화) 데이터 가 필요 하 며 Spark 에 저장 되 어야 합 니 다. 데이터 수신 이 시스템 의 병목 이 되면 parallelizing the data receiving (병렬 화 데이터 수신) 을 고려 하 십시오. 각 input DStream 은 single stream of data (단일 데이터 흐름) 를 수신 하 는 single receiver 를 만 드 는 것 에 주의 하 십시오.(단일 수신 기) (work machine 에서 실행). 따라서 여러 개의 input DStreams 를 만들어 Receiving multiple data streams (여러 데이터 흐름 수신) 를 실현 하고 source (s) 에서 data stream (데이터 흐름) 을 받 는 different partitions (파 티 션 별) 를 설정 할 수 있 습 니 다. 예 를 들 어 two topics of data (두 데이터 테마) 를 받 습 니 다.하나의 Kafka input DStream 은 두 개의 Kafka input streams (입력 스 트림) 로 나 눌 수 있 으 며, 각각 하나의 topic (테마) 만 받 을 수 있 습 니 다. 이 는 두 개의 receivers (수신 기) 를 실행 하여 parallel (병렬) 에서 데 이 터 를 받 을 수 있 도록 허용 하여 overall throughput (전체 삼투 량) 을 높 일 수 있 습 니 다. 이 multiple DStreams 는 유 니 온 (연합) 할 수 있 습 니 다.single DStream 을 만 듭 니 다. 그리고 transformations (전환) 를 single input DStream 에 사용 하면 유 니 피 드 stream 에 사용 할 수 있 습 니 다. 다음 과 같 습 니 다.

1 val numStreams = 5
2 val kafkaStreams = (1 to numStreams).map { i => KafkaUtils.createStream(...) }
3 val unifiedStream = streamingContext.union(kafkaStreams)
4 unifiedStream.print()

고려 해 야 할 또 다른 매개 변 수 는 receiver 's block interval (수신 기의 블록 간격) 입 니 다. 이것 은 configuration parameter (설정 매개 변수) 입 니 다. 의  spark.streaming.blockInterval  대부분의 receivers (수신 기) 에 대해 서 는 받 은 데이터 coalesced (통합) 가 Spark 메모리 에 저 장 된 Blocks of data (데이터 블록) 입 니 다. 각 batch (일괄) 의 blocks (블록) 수 는 받 은 데 이 터 를 map - like (map 와 유사 한) transformation (변환) 으로 처리 하 는 task (작업) 를 확인 합 니 다.각각 receiver (수신 기) 의 batch (일괄) 작업 수 는 약 (batch interval (일괄 간격) / block interval (블록 간격) 입 니 다. 예 를 들 어 200 ms 의 block interval (블록 간격) 은 2 초 마다 batches (일괄) 10 개의 tasks (작업) 를 만 듭 니 다. tasks (작업) 수량 이 너무 적 으 면 (즉, 각 기계 의 커 널 수 보다 적 습 니 다)사용 가능 한 모든 커 널 에서 처리 데 이 터 를 사용 하지 않 기 때문에 유효 하지 않 습 니 다. given batch interval (주어진 간격) 의 tasks (작업) 수 를 늘 리 려 면 block interval (블록 간격) 을 줄 여 주 십시오. 단, 추천 하 는 block interval (블록 간격) 의 최소 값 은 약 50ms 입 니 다. 이 작업 의 시작 비용 보다 낮은 것 이 문제 일 수 있 습 니 다.
multiple input streams (여러 입력 흐름) / receivers (수신 기) 를 사용 하여 데 이 터 를 받 는 대체 방법 은 repartition (재배 치) input data stream (입력 데이터 흐름) (사용) 을 명 확 히 하 는 것 입 니 다.  inputStream.repartition()  ）. 이것 은 further processing (추가 처리) 전에 received batches of data (받 은 일괄 데이터) distributes (배포) 를 클 러 스 터 에서 지정 한 수량의 컴퓨터 로 보 냅 니 다.
Level of Parallelism in Data Processing (데이터 처리 의 병행 도 수준)
모든 computation (계산) 단계 에서 number of parallel tasks (병렬 작업 의 수량) 를 사용 하면 Cluster resources (클 러 스 터 자원) 가 충분히 이용 되 지 않 을 수 있 습 니 다. 예 를 들 어 distributed reduce (분포 식 reduce) 작업 은 다음 과 같 습 니 다.  reduceByKey  화해시키다  reduceByKeyAndWindow  , 기본 병렬 작업 의 수 는  spark.default.parallelism  configuration property 제어. parallelism (병렬 도) 를 매개 변수 로 사용 할 수 있 습 니 다 (참조).  PairDStreamFunctions  문서  spark.default.parallelism  configuration property 기본 값 변경.
데이터 직렬 화 (데이터 직렬 화)
serialization formats (직렬 화 형식) 를 조정 하여 데이터 serialization (직렬 화) 의 비용 을 줄 일 수 있 습 니 다. streaming 의 경우 두 가지 유형의 데이터 가 serialized (직렬 화) 되 어 있 습 니 다.

Input data (입력 데이터): 기본적으로 Receivers 를 통 해 받 은 input data (입력 데이터) 를 통 해 StorageLevel.MEMORY_AND_DISK_SER_2 executors 메모리 에 저 장 됩 니 다. 즉, 데이터 serialized (직렬 화) 를 bytes (바이트) 로 하여 GC 비용 을 줄 이 고 executor failures (실행 기 고장) 를 용인 하도록 복사 합 니 다. 또한 데 이 터 는 메모리 에 우선 저장 되 며, 메모리 가 부족 하여 streaming computation (스 트림 컴 퓨 팅) 에 필요 한 모든 입력 데 이 터 를 수용 할 때 만 spilled over(넘 침) 디스크 에 있 습 니 다. 이 serialization (직렬 화) 은 분명히 비용 이 있 습 니 다. - receiver (수신 기) 는 받 은 데 이 터 를 deserialize (반 직렬 화) 하고 Spark 의 serialization format (직렬 화 형식) 을 사용 하여 다시 직렬 화 해 야 합 니 다.

Persisted RDDs generated by Streaming Operations (스 트림 작업 으로 생 성 된 영구적 인 RDDs): streaming computations (스 트림 컴 퓨 팅) 를 통 해 생 성 된 RDD 는 메모리 에 오래 저 장 될 수 있 습 니 다. 예 를 들 어 window operations (창 작업) 는 여러 번 처리 되 기 때문에 데 이 터 를 메모리 에 보관 합 니 다. 단, StorageLevel.MEMORY_ONLY 의 Spark Core 기본 상황 이 다 르 기 때문에 스 트림 컴 퓨 팅 을 통 해 생 성 된 지구 화 RDD 는 StorageLevel.MEMORY_ONLY_SER (즉, 직렬 화) GC 비용 을 최소 화 합 니 다.

이 두 가지 상황 에서 Kryo serialization (Kryo 직렬 화) 을 사용 하면 CPU 와 메모리 비용 을 줄 일 수 있 습 니 다. 자세 한 정 보 는 참고 하 시기 바 랍 니 다. Spark Tuning Guide .Kryo 에 대해 서 는 registering custom classes 를 고려 하고 대상 참조 추적 을 비활성화 하 십시오 (참조 하 십시오) Configuration Guide 크 리 오 관련 설정).
streaming application 이 유지 해 야 할 데이터 양 이 많 지 않 은 특정 상황 에서 데이터 (두 가지 유형) 를 deserialized objects (반 직렬 화 대상) 로 오래 지속 시 킬 수 있 습 니 다. 예 를 들 어 몇 초 동안 batch interval (일괄 간격) 을 사용 하고 window operations (창 작업) 가 없 으 면그러면 storage level (저장 단계) 을 명확 하 게 설정 하여 serialization in persisted data (지구 화 데이터 의 직렬 화) 를 사용 하지 않 으 려 고 시도 할 수 있 습 니 다. 이 는 직렬 화 로 인 한 CPU 소 비 를 줄 이 고 잠재 적 으로 성능 을 향상 시 키 며 GC 소 비 를 많이 필요 로 하지 않 습 니 다.
작업 시작 오 버 헤드 (작업 시작 비용)
1 초 에 시작 하 는 작업 의 수량 이 매우 높다 면 (예 를 들 어 1 초 에 50 개 이상) 이 비용 은 slaves 에 작업 을 보 내 는 것 이 중요 할 수 있 으 며, sub - second latencies (부차적인 지연) 를 실현 하기 어 려 울 것 입 니 다. 다음 변경 을 통 해 비용 을 줄 일 수 있 습 니 다.

Execution mode (실행 모드): Standalone mode (독립 모드) 또는 coarse - grained Mesos 모드 로 Spark 가 fine - grained Mesos 모드 보다 더 좋 은 작업 시작 시간 을 실행 합 니 다. 자세 한 정 보 는 fine - grained Mesos 모드 를 참조 하 십시오. Running on Mesos guide .

이 변경 사항 들 은 batch processing time (일괄 처리 시간) 을 100 밀리초 단축 시 켜 sub - second batch size (차 초 일괄 크기) 를 허용 할 수 있 습 니 다.
Setting the Right Batch Interval (올 바른 일괄 간격 설정)
클 러 스 터 에서 안정 적 으로 실행 되 는 Spark Streaming application 에 대해 서 는 가능 한 한 빨리 데 이 터 를 받 아들 일 수 있어 야 합 니 다. 다시 말 하면 일괄 데 이 터 를 생 성 하 는 것 처럼 빨리 처리 해 야 합 니 다. 이것 은 application 에 적용 되 는 지 여부 입 니 다. monitoring streaming web UI 의 processing times 에서 찾 을 수 있 습 니 다. processing time (일괄 처리 시간) 은 batch interval (일괄 간격) 보다 작 아야 합 니 다.
streaming computation (스 트림 컴 퓨 팅) 의 특성 에 따라 사용 되 는 batch interval (일괄 간격) 은 응용 프로그램 에서 고정된 cluster resources (클 러 스 터 자원) 의 데이터 속 도 를 처리 하 는 데 큰 영향 을 미 칠 수 있 습 니 다. 예 를 들 어 초기 WordCountNetwork 예제 를 고려 합 니 다. 특정한 data rate (데이터 속도)시스템 은 2 초 마다 워드 counts (즉 2 초의 batch interval (일괄 간격) 를 추적 할 수 있 으 나 500 밀리초 마다 보고 할 수 없습니다. 따라서 예상 되 는 데이터 속 도 를 생산 할 수 있 도록 batch interval (일괄 간격) 을 설정 해 야 합 니 다.
응용 프로그램 에 정확 한 batch size (대량 크기) 를 찾 는 좋 은 방법 은 conservative batch interval (보수 적 인 일괄 간격) (예 를 들 어 5 - 10 초) 과 low data rate (낮은 데이터 속도) 를 테스트 하 는 것 입 니 다. 시스템 이 data rate (데이터 속도) 를 따라 갈 수 있 는 지 검증 하고 만 나 는 end - to - end delay (엔 드 에서 엔 드 까지 지연) 를 검사 할 수 있 습 니 다.의 값 은 각각 processed batch (처 리 된 일괄) (Spark driver log4j 로그 에서 "Total delay" 를 찾 거나 사용 합 니 다. StreamingListener 인터페이스). delay (지연) 가 batch size (대량 크기) 와 비슷 하 게 유지 된다 면 시스템 은 안정 적 입 니 다. 그 밖 에 지연 이 계속 증가 하면 시스템 이 따라 갈 수 없 기 때문에 불안정 합 니 다. stable configuration (안정 적 인 설정) 이 있 으 면의 생각, data rate 를 증가 시 키 거나 / 또는 batch size 를 줄 일 수 있 습 니 다. momentary increase (순간 증가) 는 지연 으로 인해 일시 적 으로 증가 하기 때문에 지연 이 low value (낮은 값) 로 낮 아 지면 임시 데이터 속도 가 증가 하면 좋 습 니 다 (즉, batch size (일괄 크기) 보다 작 습 니 다).
다음으로 전송:https://www.cnblogs.com/hmy-blog/p/7799379.html