[SPARK] 아파치 스파크란?

아파치 스파크는 빅데이터처리를 위한 오픈소스 병렬분산처리 플랫폼입니다. "스트림처리" 수요 등에 대응하고자 스파크는 성능/편의성을 모두 고려하여 개발이 이뤄지고 있습니다. 스파크는 복수의 컴포넌트로 구성이 됩니다.  스파크 코어는 데이터소스로 HDFS(Hadoop Distributed File System) 뿐만 아니라 Hive, HBase, PostgreSQL, MySQL, CSV 파일 등도 처리할 수 있습니다.

[ SQL처리용 라이브러리(스파크 SQL) + 스트림처리용 라이브러리(스파크 스트리밍) .. ]

[ 병렬분산처리 엔진(스파크 코어) ]

[ HDFS/하이브(Hive)/HBase/PostgreSQL/MySQL/CSV(데이터소스) ] 

스파크는 대량의 데이터를 고속 병렬분산처리한다. 스파크는 데이터소스로부터 데이터를 읽어 들인 뒤 스토리지 I/O와 네트워크 I/O를 최소화하도록 처리한다. 따라서 스파크는 동일한 데이터에 대한 변환처리가 연속으로 이루어지는 경우와 머신러닝처럼 결과셋을 여러 번 반복해 처리하는 경우에 적합하다. 지연이 작게 동작하는 특성을 이용해 스트림처리를 할 수 도 있다. 

---

[업무처리 적용 사례]

엔터프라이즈 시스템에 등장하는 업무처리 중에는 대량의 데이터로부터 늑정 컬럼이나 조건에 맞는 레코드만 추출하고 해당 레코드를 반복해서 변환처리한 뒤 최종 집계하는 처리가 있다. 이런 업무처리를 구현하는 데 스파크가 적합한 경우가 있는데, 반복해서 실행되는 처리가 메모리 용량을 넘지 않는 경우가 그에 해당한다. 처리할 데이터 크기가 클러스터의 메모리 총량을 넘지 않고 반복처리하는 경우 특히 위력을 발휘한다.

[스트림처리 적용 사례]

비디오를 스트리밍할 때 출력되는 로그 해석에 스파크 스트리밍을 활용할 뿐만 아니라 배치처리도 이용하고 있다. Ooyala 사가 이용하는 스파크는 동작 기반으로 YARN을 채용했는데, 다음과 같은 점을 어필하고 있다.

- 하둡클러스터와는 다른 독자적인 스파크 전용 클러스터를 구축/운용할 필요가 없다.

- 클러스터의 리소스 관리가 가능하다.

- 처리 계통의 업그레이드가 용이하다.

---

[스파크의 특징]

스파크는 특정한 데이터셋에 대하여 반복처리와 연속적으로 이루어지는 변환처리를 고속화할 목적으로 개발되었다.

- 반복처리 + 연속으로 이루어지는 변환처리의 고속화

- 시행착오에 적합한 환경 제공

- 서로 다른 처리를 통합해 이용할 수 있는 환경

1. 반복처리와 연속으로 이루어지는 변환처리의 고속화

---

스파크가 등장하기 전에는 계속해서 그 양이 늘어나는 데이터를 처리하기 위해 MapReduce가 널리 활용되었다. 

내결함성: Fault Tolerance. 결함 또는 고장이 발생해도 정상적 혹은 부분적으로 기능을 수행할 수 있는 능력.

맵리듀스는 기본적으로 입력데이터를 스토리지에서 읽고 복수의 머신에서 분산처리를 수행한 후 그 결과를 스토리지에 보존한다. 이 처리가 한 번에 끝나지 않은 경우에는 데이터가 flow 형식으로 처리되어 '읽기 -> 분산처리 -> 보존'을 반복 수행한다.

맵리듀스를 활용한 데이터처리 플로는 각 처리의 중간 결과가 항상 스토리지에 보존되므로 데이터 크기가 커져도 문제없이 작동하며, 시스템 장애가 발생해도 비교적 쉽게 복구되는 만큼 강력한 처리 모델이라 할 수 있다. 하지만, 특정 데이터의 부분집합에 대해 여러번 처리하는 애플리케이션은 맵리듀스로 효율적인 처리가 어렵다.

'연속해 이루어지는 데이터의 분석처리'는 특정 데이터의 부분 집합에 대해 반복해서 쿼리를 발생하는 경우다. 맵리듀스는 중간 결과의 데이터셋을 메모리에 유지한 상태로 다시 처리할 수 있는 수단이 제공되지 않으므로, 매번 쿼리를 발행하고 얻은 결과를 디스크에 보존하고, 다시 읽어 메모리에 로드해야 한다.

맵리듀스가 연속으로 이루어지는 처리를 매번 모든 데이터를 디스크에 출력하는 것과는 달리, 스파크는 연속으로 이루어지는 처리에서 매번 불필요한 디스크와 네트워크 I/O가 발생하지 않도록 처리한다.

(디스크 I/O를 발생시키지 않아 처리가 빨라지는 특성은 본질적으로 내결함성과 트레이드오프 관계가 있다? 디스크에 데이터를 보존하면 장애가 발생했을때 해당 데이터가 출력된 처리 직후까지는 복구할 수 있지만, 디스크에 데이터가 없으면 복구를 위한 특별한 작업이 필요하다. (스파크의 경우 장애가 발생하면 과거 보존한 데이터를 가지고 부분적으로 처리를 재실행함으로써 복구를 시도한다.) 다시 말해, 이 특별한 복구처리에서 발생하는 비용의 크기에 따라 맵리듀스에 비해 좋은지 나쁜지를 판단할 수 있다.)

연속으로 이루어지는 처리 전체를 검토한 뒤에 그에 맞는 최적화 처리를 끼워넣는 방식으로 설계하여 맵리듀스보다 고속으로 처리할 수 있고 완전히 대체할 수 있다고 한다.

(실제로는 설계 방식대로 구현되지 않은 부분도 존재한다. 특히 메모리 용량을 크게 넘는 데이터를 다루는 경우, 대량의 디스크 I/O와 네트워크 I/O를 발생시키며 OOME가 발생하기 쉬워지거나, 셔플이라 불리는 노드 간 데이터 교환을 위한 처리가 최적화되지 않는 등, 구현 레벨로 보면 맵리듀스가 더 안정적이기는 하다.)

여러번 반복해 이루어지는 처리와 연속으로 이루어지는 변환처리에서 스파크의 고속처리 능력이 빛을 발한다. 반면 최적화의 여지가 없이 단 한 번만 실행되는 변환처리와 추출/가공처리에서는 별 이득이 없다.

2. 시행착오에 적합한 환경 제공

---

스파크는 한 대의 머신으로 처리할 수 있는 용량보다 더 큰 데이터셋에 대해 시행착오 가능한 환경을 제공한다.

한 대의 서버에서 처리할 수 있는 용량을 넘어서는 데이터셋에 대해서는 이런 종류의 툴이 현실적이진 한다. 거대한 용량의 데이터를 다룰 때는 스케일아웃과 같은 방법을 선택하고 여러 대의 머신으로 구성해 병렬분산처리를 수행할 필요가 있다. 다만 이 경우에도 이용하는 입장에서 보면, 애플리케이션을 병렬분산용의 특수한 기술로 변경해야 하는 상황 만큼은 피하는 것이 바람직하다.

스파크는 병령 분산 환경을 의식하지 않고 처리를 기술할 수 있는 것을 목표로 한다. 스파크에는 데이터셋을 추상적으로 다루기 위한 RDD (Resilient Distributed Dataset: 내결함성 분산 데이터셋)이라는 데이터셋이 있으며, RDD가 제공하는 API로 변환을 기술하기만 하면 처리되게끔 구현되었다.

스파크에는 대화식으로 기술을 처리할 수 있는 CLI(SparkShell)가 제공된다. 데이터 분석을 위한 방법의 하나로 한정적으로 쿼리를 발행해 결과를 확인하는 작업을 반복적으로 수행하고 최종적으로 원하는 결과를 얻는다. 이를 이용함으로써 스파크는 한대의 서버에서 처리할 수 있는 용량을 넘어서는 데이터셋이라 해도 커맨드라인을 이용한 시행착오를 반복할 수 있는 환경울 제공한다.

3. 다양한 처리를 통합할 수 있는 유연한 환경

---

배치처리, 스트림처리, SQL처리와 같은 서로 다른 형태의 애플리케이션을 하나의 환경에서 통합적으로 다룰 수 있는 점도 스파크의 큰 특징 중 하나다.

기존에는 배치처리, 스트림처리 등을 각각 구현하려면 개별적으로 미들웨어를 준비하고 각 프로그래밍 모델에 따라 애플리케이션을 기술해야 했다. 또한, 이들 애플리케이션을 하나의 시스템으로 다루려면 운용자가 여러 개의 미들웨어를 준비해야 하는데, 이는 운용 부담이 높아지는 요인이 되었다.

스파크는 하나의 애플리케이션에 이 같은 여러 종류의 처리를 혼합해 기술할 수 있다. SQL로 클렌징과 필터링처리를 하고 그 결과에 대해 머신러닝을 하며, 또 그 결과에 대해 다시 SQL처리를 구현해야 한다고 하자. 기존에는 미들웨어 간에 데이터를 이동시켜가며 각 처리를 기술해야 했지만, 스파크는 하나의 동일한 애플리케이션에서 실현 가능하다. 스파크는 SQL과 유사한 쿼리를 처리할 수 있는 스파크 SQL과 머신러닝 라이브러리인 MLib을 제공한다. 이들을 함께 사용함으로써 서로 다른 처리를 통합적으로 구현할 수 있다.

스파크는 배치처리와 스트림처리를 하나의 환경에서 다룰 수도 있다. 끊임없이 유입되는 스트림 데이터로부터 최신 정보와 부정한 값을 취득하면서, 다른 한편으로는 해당 데이터를 축적해 일정한 가격으로 배치처리를 실행해 집계할 수도 있다.