빅데이터를 공부해야할 일이 생겨서, 하둡을 먼저 공부했다. 쌩으로 클러스터를 만들고, 설정값을 변경해보고… 그렇게 클러스터를 만드는 일부터 맵리듀스 어플리케이션을 만드는 일까지 공부하는게 쉽지만은 않았다. 여기서 약간 빅데이터의 벽(?)같은걸 1차로 느꼈다.
그러다가 스파크를 만났다. 공부하다 보니 스파크가 그렇게 어렵지도 않고, 그런데 활용성은 굉장히 좋고, 성능도 좋다는 생각이 든다. 여기서 포인트는 그닥 어렵지 않다는 점이다. 자료들이 주로 scala라는 생소한 언어로 설명이 되어있지만, scala가 별로 어렵지 않다. 언어자체가 직관적이면서 간결하다. 그리고 scala로 배우는 스파크도 그닥 어렵지가 않다. 많은 기능을 제공하고 좋은 성능을 제공하지만, 기능들의 추상화가 잘 되어있어서 단순히 api만 호출하면 된다.
이거 사긴데? 쉽고 빠른 빅데이터 처리 엔진이라니…
그 동안 하둡을 공부하면서 느낀 어떤 답답함 같은게 해소되는 느낌이랄까. 맵리듀스를 짜면서 뭔가 병렬처리로 성능이 향상된다는건 알겠는데 코드 작성이 상당히 번거로웠다.(책에는 간단하다고 나와있는데 원리야 간단하지만 코드짜는건 안간단함 ㅇㅇ) 물론 하둡에는 맵리듀스 외에도 빠르게 분석할 수 있는 엔진들이 있지만, 그 중에 스파크가 가장 매력적으로 보인다.
쉽고 빠른 빅데이터 처리엔진 스파크, 그래서 나는 스파크로 빅데이터를 시작하는 것도 좋다고 생각한다. 스파크가 하둡의 모든것을 대체하지는 못하지만, 스파크를 중심으로 빅데이터 처리에 필요한 것들을 배워나가는 것이 효율?이 좋을 것 같다는 생각이다. 스파크의 이러저러한 기능들을 살펴보다보면, 빅데이터 처리라는 단어에서 느껴지는 거리감이 조금은 해소되지 않을까 한다.
나랑 비슷한 생각을 하셨는지 빅데이터 - 스칼라, 스파크로 시작하기라는 책도 공개되어 있다. 아마 앞으로 정리할 내용들이 이 책을 상당부분 참고할 것 같고, 그렇기 때문에 유사할 수도 있다.
그래서 이 글에는 일단 스파크에 대한 전반적인 내용을 담아보려고 한다.
빅데이터 그리고 하둡
스파크가 뭔지를 설명하려면 어쩔 수 없이 하둡얘기를 해야한다. 어쩔 수 없는건 아니고 그냥 이게 설명이 편하다. 심지어 스파크 홈페이지에서도 맨 처음 나오는 설명이 하둡보다 100배 빠르다는 설명이다.
하둡보다 100배나 빠르다는데 하둡은 뭘까. 하둡을 얘기하려면 빅데이터를 얘기해야한다. 하둡이 빅데이터 처리를 위한 플랫폼이니까.
빅데이터란 무엇인가…?
그렇다고 빅데이터란 무엇인가에 대해서 얘기를 하자니 좀 부담스럽다. 블록체인이 그렇고 인공지능이 그렇듯, 4차산업혁명을 바라보는 시선이 나는 약간 부담스럽다. 관심이 쏠려서 부담스럽기도 하고, 내 설명이 그 기대에 부응하지 못할까봐 부담스럽기도 하고.
빅데이터는 그냥 커다란 데이터이다. 한줄의 레코드도 데이터이고 수억건의 레코드도 데이터인데 여기서 빅데이터는 당연히 후자이다. 그러면 도대체 어느정도 큰 데이터가 빅데이터인가. 데이터는 당연히 그 처리하는 방법론이 데이터의 사이즈에 따라 달라진다. 크지 않은 데이터들은 기존의 RDBMS, 혹은 엑셀 등에서도 충분히 분석과 레포팅이 가능했다. 그런데 사이즈가 커지면 이러한 기존 틀로 분석하기가 어려워진다. 엑셀에 100mb 이상 넘어가는 데이터를 넣어본 사람은 이해할 것이다. 똑같은 구조의 테이블이지만 그냥 사이즈가 크다는 이유만으로 뭔가 다른 처리방법이 필요하다. 즉, 엔지니어 입장에서 빅데이터를 다시 정의하자면 뭔가 다른 처리방법이 필요할만큼 큰 데이터이다.
‘뭔가 다른 처리방법’ => 하둡
그래서 이렇게 커다란 데이터를 처리하기 위한 방법들을 고안해냈고, ‘뭔가 다른 처리방법’ 중 대표적인 것이 하둡 이라는 것이다. 아주 간단히 설명하자면, 단일 컴퓨터에서의 데이터 처리가 버겁고 비싸다는 사실을 깨달은 엔지니어들이 크지 않은 여러 컴퓨터의 자원을 사용해 데이터를 분산저장, 분산처리 할 수 있게끔 만들어놓은 것이 하둡이다.
‘하둡’은 사실 단일 솔루션을 얘기하지 않는다. 하둡이라는 에코시스템은 수집을 위한 솔루션, 저장을 위한 솔루션, 분석을 위한 솔루션, 자원 관리를 위한 솔루션 등이 포함되어 있는 거대한 생태계이다. 이러한 생태계는 공통적으로 Hadoop에서 제공하는 파일시스템(HDFS), 자원관리매니저(YARN), 맵리듀스 등을 사용한다.
즉, 하둡은
- 저장은 HDFS에 저장하고,
- 분석작업은 맵리듀스를 통해 수행하고,
- 이러한 작업들이 사용하는 자원의 관리는 YARN이 맡는다.
이렇게 말하면 간단해 보이지만 각 구성요소는 굉장히 복잡한 내부 아키텍쳐를 갖고있다. 어쨌든, 그 중에서도 맵리듀스 작업은 하둡의 근-본 이면서도 명확한 한계를 갖고있다. 맵리듀스 잡(작업)의 결과물은 hdfs에 저장해야만 하는데 hdfs는 분산파일시스템이기 때문에 저장과 로드에 상당한 비용(시간/자원소모)이 든다.
물론 하둡 생태계의 많은 솔루션들이 이를 상당부분 개선했지만, 근본적으로 필요한 데이터를 디스크에서 매번 가져오고 저장해야 한다는 문제점이 있다. 앞서 말했지만 HDFS는 고가용성을 고려한 분산스토리지이기 때문에 저장시에 복제가 이루어지기도 한다. 또한 파일 하나를 여러 블록에 나누어 저장하기 때문에 이에 대한 메타데이터 관리도 필요하다. 이 과정이 지나야 비로소 파일저장이 되기 때문에, 이러한 작업이 많으면 많을수록 성능에 엄청난 영향을 미친다.
스파크
그럼 이제(드디어) 스파크 얘기를 해보자. 하둡도 빅데이터를 다루기 위한 강력한 에코시스템이지만, 스파크도 하둡을 빠르게 대체하고 있을만큼 강력한 엔진이다. (정확히 말하면 하둡을 대체한다기 보단, 하둡의 분석 어플리케이션을 대체하고 있다.) 스파크가 가진 장점은 다음과 같다.
장점
위에서 봤듯이 MapReduce는 디스크에 저장하는 과정이 성능에 영향을 끼친다. 그런데 스파크는 필요한 데이터를 메모리(ram)에 저장해서 이러한 문제를 해결한다. 당연히 디스크보다 메모리가 더 빠르다. 그러니 스파크는 빠르다. 아래 그림을 보자.
스파크는 위 그림처럼 작업이 끝나면 이를 RDD라는 분산 메모리에 저장한다. 이 RDD라는 객체가 바로 스파크의 핵심이다. 이것을 통해 빠른 속도를 내고, 내결함성을 구현하고, 고수준의 api를 제공한다. RDD를 이해하는 것이 스파크를 이해하는 것이다. 여기서는 이것만 기억하자. 스파크는 RDD라는 것을 구현해 메모리 상에서 연산한다. 그래서 빠르다.
스파크는 단순히 빠르기만 한게 아니라, 여러가지 편의성도 제공한다. 빠른데 쓰기가 어렵다면 무슨소용이겠는가 맵리듀스 어플리케이션을 개발하려면 우선 맵퍼와 리듀서라는 것을 따로 구현을 해야하고 이를 통합하는 메인 클래스를 구현해야 한다. 그런데 스파크는 이러한 작업을 위한 고수준 api를 제공한다. 예를들어 filter() 같은 api를 통해 간단하게 데이터를 필터링할 수 있고. map(), flatmap()등을 통해 데이터를 맵핑할 수 있다. 이를 구동시키기 위한 언어도 java, python, scala, R 등으로 그 범위가 넓다.
또한 활용범위도 넓다. Hadoop에도 다양한 컴포넌트가 있듯이 Spark에도 다양한 컴포넌트가 존재한다. SQL, ML, Graph, Streaming 등 다양한 활용이 가능하다.
즉, 빠르고, 쉽고, 활용범위가 넓다. 무슨 말만 들으면 만병통치약 같은데, 사실 이게 ‘맵리듀스에 비해서’ 쉽고 ‘맵리듀스에 비해서’ 빠른 것이다. 어쨌든 스파크가 강력한건 사실이지만, 당연히 단점도 있다.
단점
우선 메모리를 사용하기 때문에 상대적으로 비싸다. 데이터를 모두 메모리에서 처리하기 때문에 클러스터의 메모리가 넉넉해야한다.
엄밀한 의미에서의 스트리밍을 지원하지 않는다. 스파크에도 Spark Streaming 이라는게 있어서 스트리밍 데이터 처리를 지원하지만 (꽤 널리 쓰이지만) spark streaming은 micro batch로 구현이 된다. 즉 배치작업을 작게 하는 방식으로 스트리밍 처리를 구현한다. 이게 먹히는 워크로드도 있겠지만 초단위의 분석을 요구하는 워크로드에는 다른 솔루션(flink 등)이 필요하다.
정리
스파크는 빅데이터를 입문하기에 적절한 쉽고 빠른 솔루션이다. 데이터를 메모리에 올려놓고 쓰기에 빠르고 이를 복원가능하도록 만들기 위해 RDD라고 불리는 것을 구현했다. 적용할 수 있는 범위도 넓지만 메모리를 쓰기때문에 클러스터에 메모리가 많이 필요하고, 아주 짧은 단위의 스트리밍 분석은 어렵다. 이 정도면 아주 대략적인 정리가 된듯 하다. 다음에는 조금 더 깊숙한 내용을 정리해보겠다.
사실, 스파크의 특징에 대한 내용은 이 글(Why Apache Spark is Fast and How to Make It Run Faster)에 매우 잘 정리가 되어있다. 시간이 된다면 그냥 번역글을 쓰는 것도 큰 도움이 될듯…?