2.1.1 Spark Intro
Last updated
Last updated
Apache Spark 는 데이터 처리를 위한 범용 프레임워크 입니다. 데이터 파이프라인을 위해 많이 사용되며, 산업 표준에 가깝습니다.
Scala 이외에도 Python, R 등 다양한 언어를 지원하며 데이터 처리를 위한 라이브러리가 많이 존재합니다. (Spark 관련 Third Party 프로젝트 목록)
Spark SQL / Dataframe / Dataset API 등 다양한 형태의 API 를 제공해 사용자 편의 및 개발 환경에 따라 자유롭게 선택할 수 있습니다.
다양한 Storage 와 연동되는 Connector 가 존재합니다.
다양한 실행 모드 및 환경을 지원해 어느 환경에서나 사용할 수 있습니다.
Spark Shell / Jupyter Notebook
Local Mode / Client Mode / Cluster Mode
Spark Batch / Stream Streaming
Standalone / Yarn / Kubernetes Environment
요약하면 Spark 는
여러 환경과 모드를 지원하며
다양한 커넥터를 이용해 데이터를 추출 및 저장이 가능하고
사용자 편의에 맞추어 언어와 API, 그리고 라이브러리를 선택해
분산처리를 수행할 수 있는 범용 데이터 처리 도구입니다.
예를 들어 위 코드에서는 Spark 를 이용해
JDBC (MySQL) Driver 로 데이터를 읽어
다른 데이터와 Join 하고
Row 필터링 / Column 선택 등을 수행한 뒤
원하는 기준으로 집계 연산 (Group By) 를 수행하고
마지막으로는 Kafka 로 내보냅니다.
이 과정에서 사용자는 Spark 만 알아도 다양한 저장소 (Hive, S3, Kafka, MySQL) 와 다양한 Format (Avro, Parquet, CSV) 을 이용할 수 있고, Pandas 프레임워크 또는 RDB 의 SQL 이 제공하는 거의 유사한 API 와 문법을 이용해 데이터를 가공할 수 있습니다.
또한 컴퓨팅은 분산처리되어 발생하므로, 기존의 단일 머신에서 수행되는 Pandas 컴퓨팅 / RDB SQL 컴퓨팅 보다 더 큰 데이터를 빠른 시간 내에 처리할 수 있습니다.
다음 질문은 전통적인 RDB 와 Spark 의 컴퓨팅 관점에서의 차이를 보여줍니다.
RDB 를 사용하는것과 Spark 를 사용하는것은 어떤 차이점이 있나요? RDB 와 다르게 Spark 의 explain() 결과는 충분하지 않은 것 같습니다. 일반적으로 Spark 작업은 어떻게 튜닝하나요?
RDB 에서 실행되는 쿼리와 Spark 작업은 다음의 차이점이 있습니다.
서비스로 나가는 RDB 쿼리는 많아야 수개 테이블을 조인하지만, Spark Job 은 수십개의 테이블을 Join 할 수 있습니다.
서비스로 나가는 RDB 쿼리는 수십-수백 millis 내로 결과를 내야하지만, Spark Job 은 작업에 따라 짧게는 5분, 머신러닝 집계는 수십 시간까지 걸릴 수 있습니다.
서비스로 나가는 RDB 쿼리는 단일머신에서 수행되고 RDB 의 메모리는 많아봐야 ‘인스턴스 전체’ 에서 최대 수백기가지만, Spark 작업은 ‘하나의 Job’ 이 수백기가 / 수테라의 메모리를 사용할 수 있습니다.
서비스로 나가는 RDB 쿼리는 단일머신에서 수행되므로, 중간 집계를 위한 네트워크 이동이 없습니다. 반면 Spark 작업은 분산처리가 기본이며, Shuffle 로 인한 네트워크 데이터 이동은 물론 메모리 부족으로 인한 Disk Spill 이 발생할 수 있습니다.
RDB 는 일반적으로 단일머신에서 고성능을 내기 위한 언어로 만들어졌지만, Spark 는 JVM 위에서 동작합니다.
RDB 는 ‘쿼리’ 단위로 튜닝이 일반적으로 쿼리 실행 시간이 중요한 요소가 되며, 테이블의 DDL (인덱스) 등을 DBA 와 같이 논의할 수 있습니다. 반면 Spark 는 하나의 작업에 걸리는 소요 시간이 긴 만큼 ‘작업’ 단위로 튜닝이 될 수 있습니다. 작업 내에서의 일부 Spark SQL 의 국소적인 최적화는 큰 의미가 없을수도 있습니다.
서비스 백엔드 엔지니어는 QueryDSL / JPQL 등으로 감싸진 ‘쿼리’ 를 수백개 작성하고, 운영할 수 있겠지만 데이터 엔지니어는 개별 Table 에 데이터를 적재하는 ‘Spark Job’ 을 한명의 엔지니어가 수백-수천개 관리할 수 있습니다.
따라서 다음의 관점으로 튜닝이 진행됩니다.
리소스 측면에서 실행하는 컴퓨팅 종류에 따라 Driver 및 Executor 의 CPU / Memory 설정과 인스턴스 타입, 그리고 Network / Disk 등 리소스가 충분한지 확인합니다.
Disk Spill / Shuffle Write 등이 메모리에 비해 과다할 경우 혹은 GC 가 너무 잦게 발생할 경우 메모리를 늘립니다.
머신러닝 등 컴퓨팅이 많이 필요한 Spark Job 은 CPU 를 늘릴 수 있습니다. 일반적으로는 작업마다 다른 EC2 인스턴스 타입을 사용하게끔 데이터 인프라가 설계됩니다. (머신러닝은 c5.8xlarge, 일반 집계는 r5.4xlarge 등)
네트워크 대역폭이 모자랄 경우 c5n, r5n 등 네트워크 전용 인스턴스 타입을 고려할 수 있습니다. 다만 AWS 특정 Region / Zone 에서는 지원되지 않을 수 있습니다.
Disk 가 모자랄 경우 Spill 이 더이상 불가능해 Executor 가 종료될 수 있으므로 Shuffle Write / Memory 부족으로 인한 Spill 등 Disk 사용량을 모니터링 해 부족하면 Executor 숫자를 늘려 사이즈를 분산하거나, 더 큰 사이즈의 Disk (AWS EBS) 를 사용할 수 있습니다. 필요에 따라 높은 성능의 IO 를 가진 EBS 클래스를 선택할 수 있습니다.
RDB 는 리소스를 변경하려면 (Spec Up) Downtime 이 필요하지만, Spark 는 Node 를 쉽게 버튼 눌러 추가하면 됩니다. 따라서 리소스를 추가하는데 부담을 갖지 말고, 내 시간을 아끼는 것에 더 집중하는 편이 낫습니다.