한빛출판네트워크

2011년에 마크 안드레센Marc Andreessen은 많은 기업이 디지털 전환에 대한 도전에 직면하고 있던 시기에 급속히 발전하는 디지털 경제를 언급하며 ‘소프트웨어가 세상을 집어삼키고 있다’는 유명한 말을 남겼다. ‘온라인’과 ‘모바일’ 동작 모드를 사용하는 성공적인 온라인 비즈니스는 전통적인 ‘오프라인 거래’ 방식으로 존재하던 경쟁자들을 점령하기 시작했다.

예를 들어 카메라 판매점에서 카메라를 구매한 경험을 상상해보자. 가게를 방문하고, 상품을 둘러보고, 점원에게 몇 가지 질문을 하고, 어떤 것을 살지 결정하고, 결국 욕구와 기대를 충족시키는 모델을 구매할 것이다. 구매가 이루어지면 상점에서는 신용카드나 현금을 받을 것이고 해당 카메라 모델의 재고 품목이 하나 줄어들 게 될 것이다.

이제 온라인 환경을 경험해보도록 하자. 먼저 웹 검색을 시작하고 몇몇 온라인 상점을 방문하며 한 곳에서 다른 곳으로 옮겨감에 따라 디지털 흔적을 남기게 된다. 그러면 웹사이트 상에 우리가 찾고 있는 카메라뿐 아니라 대안으로 선택할 수 있는 다른 제품에 대한 프로모션(물론 광고다)을 보여주기 시작한다. 마침내 우리는 최고의 조건을 제공하는 온라인 상점을 발견하고 카메라를 구매한다. 개인 정보를 등록하면 구매 관련 정보와 연결된다. 구매를 하는 동안 추가 옵션이 제공된다. 웹에서의 키워드 검색, 링크 클릭 또는 특정 페이지를 읽는 데 시간을 소요하는 것과 같은 각각의 디지털 상호작용은 개인화된 광고 또는 연쇄 판매 추천과 같은 비즈니스 가치로 변환되는 일련의 이벤트를 생성한다.

2015년 드루팔 창시자인 드리스 보이타르트Dries Buytaert는 안드레센의 명언을 언급하며 ‘아뇨, 실제로는 데이터가 세상을 집어삼키고 있습니다’라는 말을 남겼다. 그의 말이 의미하는 것은 오늘날의 파괴적인 회사들은 더 이상 그들의 소프트웨어 때문에 파괴적인 것이 아니라 그들이 수집한 고유 데이터와 그 데이터를 가치로 변환하는 능력으로 인해 파괴적이라는 것이다.

스트림 처리 기술의 채택은 운영 환경 변화에 대응하고 적응하는 데 필요한 시간을 개선하기 위한 비즈니스의 필요성이 증가함에 따라 이루어진다. 이러한 방식의 데이터 처리는 기술적이고 전략적인 이점을 제공한다. 기술적인 채택이 진행 중인 예로 인터넷 상거래와 같이 24시간 연중무휴 고객과 상호작용하는 비즈니스에 의해 생성된 끊임없이 실행되는 데이터 파이프라인 또는 사기행위를 감지하고 중지하기 위해 발생하는 트랜잭션을 분석하는 신용카드 회사 등이 있다.

스트림 처리를 주목받게 하는 또 다른 요소는 데이터를 생성하는 능력이 데이터를 이해하는 능력을 훨씬 능가한다는 점이다. 우리는 텔레비전, 커넥티드 자동차, 스마트폰, 자전거 계기판, 스마트워치, 감시 카메라, 온도 조절 장치 등 개인 및 전문적인 환경에서 사용하는 컴퓨팅 가능 장치를 끊임없이 증가시키고 있다. 컨텍스트에서 장치 기록의 일부를 구성하는 동작 및 사건을 나타내는 메시지 스트림과 같은 이벤트 로그를 생성하기 위한 장치로 우리 주변을 둘러싸고 있다. 이러한 장치들을 서로 연결함으로써 해당 이벤트 로그에 접근하여 분석하는 기능을 만들 수 있게 된다. 이 현상은 이러한 분석을 다루기 쉽게 만들 수 있는 방법을 찾았다는 조건하에 거의 실시간에 가까운 데이터 분석 영역에서 놀라운 창의성과 혁신의 문을 열어준다. 집계 이벤트 로그 세계에서 스트림 처리는 데이터 스트림의 분석을 용이하게 하는 가장 리소스 친화적인 방법을 제공한다.

데이터가 세상을 집어삼키는 것뿐만 아니라 스트리밍 데이터 역시 그렇게 한다는 것 또한 놀라운 일이 아니다.

이 장에서는 아파치 스파크를 사용하는 스트림 처리의 여정을 시작한다. 스트림 처리 영역에서 스파크의 기능에 대해 논의할 수 있도록 준비하려면 스트림 처리가 무엇인지, 스트림 처리 애플리케이션 및 그것의 문제점에 대한 일반적인 이해를 확립해야 한다. 이러한 내용들에 대한 공통적인 용어를 구성한 후 통합 모델을 사용하여 배치 및 스트리밍 워크로드의 요구 사항을 처리할 수 있는 일반 데이터 처리 프레임워크로서 아파치 스파크를 소개한다.

마지막으로 스파크의 스트리밍 기능을 주목하여 살펴볼 것이며, 이와 관련하여 스파크 스트리밍과 구조적 스트리밍이라는 두 가지 사용 가능한 API를 제시할 것이다. 이 책의 나머지 부분에서 발견할 내용을 미리 살펴볼 수 있도록 주요 특징을 간략하게 설명하겠다.

1. 스트림 처리란

스트림 처리는 무한 데이터unbounded data로부터 정보를 추출하는 데 사용하는 규율 및 관련 기술 집합이다.

타일러 아키도Tyler Akidau는 자신의 저서 『Streaming Systems스트리밍 시스템』(오라일리, 2018)에서 무한 데이터를 다음과 같이 정의했다.

(적어도 이론적으로는) 크기가 무한한 유형의 데이터셋

정보 시스템은 메모리 및 스토리지 용량과 같은 유한 리소스를 가진 하드웨어에 구축되기 때문에 무한 데이터셋을 보유할 수는 없다. 대신 시간 경과에 따른 이벤트 흐름 형태로 처리 시스템 에서 수신되는 데이터를 관찰하며, 이것을 데이터 스트림이라 한다.

그에 반해 우리는 유한 데이터bounded data를 알려진 크기의 데이터셋으로 간주하며, 유한 데이터셋을 이루는 요소 수를 셀 수 있다.

1.1 배치 처리와 스트림 처리

두 가지 유형의 데이터셋을 어떻게 처리할 수 있을까? 배치 처리batch processing에서는 유한 데이터셋의 계산 분석을 참조한다. 현실적인 측면에서 이는 유한 데이터셋이 일부 스토리지 형식에서 전체적으로 사용 가능하고 검색 가능하다는 것을 의미한다. 우리는 계산 과정 시작 시점의 데이터셋 크기와 해당 프로세스의 지속 시간은 제한되어 있다는 것을 알고 있다.

반대로 스트림 처리stream processing에서는 데이터가 시스템에 도착할 때의 데이터 처리에 대해 관심 있다. 데이터 스트림의 무한한 특성을 고려할 때 스트림 프로세서는 스트림이 새로운 데이터를 제공하는 한 지속적으로 작동해야 한다. 앞서 배운 것처럼 이는 이론적으로는 영원할지도 모른다.

스트림 처리 시스템은 프로그래밍과 운영 기술을 적용하여 제한된 컴퓨팅 리소스로 무한한 데이터 스트림 처리를 가능하게 한다.

1.2 스트림 처리에서 시간의 개념

데이터는 두 가지 형태로 발생할 수 있다.

● 유휴 데이터: 파일 형식,데이터베이스 내용 또는 기타 레코드 종류
● 사용 중인 데이터: 차량의 센서 또는 GPS 신호 측정과 같이 연속적으로 생성되는 신호 시퀀스

앞서 스트림 처리 프로그램은 입력 크기가 잠재적으로 무한하다고 가정하는 프로그램이라 논의한 바 있다. 보다 구체적으로 스트림 처리 프로그램은 입력 내용을 시간이 지남에 따라 관찰되는 무한 길이의 신호 시퀀스라고 가정한다.

시간의 흐름 관점에서 볼 때 유휴 데이터는 과거의 데이터다. 의심의 여지없이 모든 경계 데이터셋은 파일에 저장되어 있든 데이터베이스에 포함되어 있든 초기에는 스토리지에 시간이 흐르면서 수집된 데이터 스트림이다. 사용자 데이터베이스, 지난 분기의 모든 주문, 도시 택시 여행의 GPS 좌표 등은 모두 저장소에 수집된 개별 이벤트로 시작되었다.

사용 중인 데이터에 대한 추론을 시도하는 것은 더 어렵다. 데이터가 원래 생성되는 순간과 처리할 수 있는 시점 사이에는 시간 간격이 존재한다. 그 시간 간격은 같은 데이터센터 내에서 생성되고 처리되는 웹 로그 이벤트와 같이 매우 짧거나 차량이 터널을 빠져나온 후 무선 연결을 다시 설정할 때만 전송되는 차량의 GPS 데이터처럼 훨씬 길 수도 있다.

이벤트가 생성된 시간과 이벤트가 스트림 처리 시스템에 의해 처리되는 다른 타임라인이 있다는 것을 알 수 있다. 이러한 타임라인은 매우 중요하기 때문에 다음과 같은 특정 이름을 지정한다.

이벤트 시간

이벤트가 생성되었을 때의 시간. 시간 정보는 이벤트를 생성하는 장치의 로컬 시간에 의해 제공된다.

이벤트를 서로 관련시키거나 순서를 정하거나 집계해야 할 때 이러한 타임라인 간의 차별화는 매우 중요해진다.

1.3 불확실성의 요인

타임라인에서 유휴 데이터는 과거와 관련이 있으며 사용 중인 데이터는 현재로 볼 수 있다. 그렇다면 미래는 어떨까? 이 논의의 가장 미묘한 측면 중 하나는 시스템이 이벤트를 수신하는 처리량에 대한 가정이 없다는 것이다.

일반적으로 스트리밍 시스템은 일정한 간격으로, 한 번에 또는 특정 리듬에 따라 입력을 생성할 필요가 없다. 즉, 컴퓨팅에는 일반적으로 비용이 들기 때문에 입력 요소의 갑작스런 도착과 처리에 필요한 컴퓨팅 리소스를 일치시키는 최대 로드를 예측하는 것은 쉽지 않다.

입력 요소의 갑작스런 유입에 필요한 컴퓨팅 용량을 확보하면 시스템은 예상대로 결과를 생성하지만 별안간 터져 나오는 입력 데이터의 유입을 계획하지 않은 경우 일부 스트리밍 시스템에서 지연, 리소스 제약, 장애 등이 발생할 수 있다.

불확실성 처리는 스트림 처리의 중요한 측면이다.

요약하면 스트림 처리는 시간이 지남에 따라 전달된 이벤트로 관찰되는 무한 데이터(비경계 데이터) 스트림에서 정보를 추출할 수 있게 해준다. 그럼에도 불구하고 데이터를 수신하고 처리할 때 이벤트 시간의 부가적인 복잡성과 무한 입력으로 인해 발생하는 불확실성을 처리해야 한다.

왜 우리는 부가적인 문제를 해결해야 할까? 다음 절에서는 스트림 처리에 의해 더해진 가치와 데이터 스트림에 대한 더 빠르고 실행 가능한 통찰력과 비즈니스 가치를 제공할 수 있는 방법을 설명하는 여러 가지 사례를 살펴볼 것이다.

2. 스트림 처리 예제

스트림 처리의 사용은 새로운 실시간의 혁신적인 데이터 애플리케이션을 상상할 수 있는 능력만큼이나 중요하다. 다음 사례들은 저자가 어떤 방식으로든 참여한 작업이며, 광범위한 스트림 처리 애플리케이션을 설명하기 위해 사용하는 간단한 예제다.

장치 모니터링

한 소규모 스타트업에서 최대 1,000만 대의 장치에서 데이터를 수집, 처리 및 저장할 수 있는 클라우드 기반 사물인터넷(IoT) 장치 모니터를 출시했다. 인메모리 저장소를 사용한 실시간 대시보드 업데이트에서 고유한 카운트 및 최대/최소 측정과 같은 연속적인 데이터 집계에 이르기까지 애플리케이션의 여러 부분에 전원을 공급하기 위해 다중 스트림 프로세서가 배포되었다.

고장 탐지

한 대규모 하드웨어 제조업체는 복잡한 스트림 처리 파이프라인을 적용하여 장비 측정 항목을 받는다. 시계열 분석을 사용하면 잠재적인 오류가 감지되고 이를 수정하기 위한 조치가 장비에 자동적으로 다시 전송된다.

청구 시스템의 현대화

자리를 확실히 잡은 한 건실한 보험사에서는 회사의 청구 시스템을 스트리밍 파이프라인으로 옮겼다. 기존 메인 프레임 인프라로부터 발생하여 일괄 추출된 것들은 이 청구 시스템을 통해 스트리밍되어 보험 에이전트의 새로운 실시간 흐름을 같은 로직으로 처리하면서 기존 청구 프로세스를 충족시킨다.

차량 관리

한 차량 관리 회사는 관리 차량의 위치, 모터 파라미터 및 연료량과 같은 실시간 데이터를 보고할 수 있는 장치를 설치하여 지리적 경계와 같은 규칙을 시행하고 제한 속도에 대한 운전자 행동을 분석할 수 있게 하였다.

미디어 추천

한 전국 미디어 매체는 뉴스 리포트와 같은 새로운 영상 자료를 추천 시스템에 수집하기 위해 스트리밍 파이프라인을 구축하여 영상 자료가 회사의 미디어 저장소에 수집되는 즉시 사용자의 개인화 추천에 사용할 수 있도록 했다. 회사의 이전 시스템은 동일한 작업을 수행하기 위해 몇 시간을 소요했을 것이다.

빠른 대출

대출 서비스를 제공하는 한 은행은 여러 데이터 스트림을 스트리밍 애플리케이션으로 결합 함으로써 대출 승인에 걸리는 시간을 몇 시간에서 몇 초로 줄일 수 있었다.

이러한 활용 사례들의 공통점은 데이터를 수신한 후 짧은 시간 내에 처리하고 실행 가능한 통찰력을 창출하기 위한 비즈니스의 필요성이다. 이때 말하는 시간은 활용 사례와 관련 있다. 비록 대출 승인의 경우 몇 분 정도 걸리더라도 매우 빠른 전환이지만 디바이스 고장을 감지하고 지정된 서비스 레벨 임곗값 내에서 수정 조치를 발생시키려면 밀리초 단위의 응답이 필요할 수 있다.

어떤 경우에도 가능한 한 최신의 데이터를 소비할 때가 더 좋다고 주장할 수 있다.

스트림 처리가 무엇인지 이해했고 오늘날 어떻게 사용되는지 몇 가지 사례를 살펴봤기 때문에 이제 구현을 뒷받침하는 개념을 자세히 살펴보도록 하자.

3. 데이터 처리의 확장

스트림 처리에서 분산 컴퓨팅의 의미를 논의하기 전에 확장성 있고 안정적인 데이터 처리를 위한 토대를 마련한 컴퓨팅 모델인 맵리듀스를 빠르게 살펴보자.

3.1 맵리듀스

분산 시스템 프로그래밍의 역사는 2003년 2월에 주목할 만한 사건을 겪게 된다. 제프 딘Jeff Dean과 산제이 제마왓Sanjay Gemawhat은 구글의 크롤링 및 색인 시스템을 다시 작성하는 몇 차례의 반복 작업을 거친 후 공통 인터페이스를 통해 노출될 수 있는 일부 작업에 주목했다. 이로 인해 구글의 대규모 클러스터 분산 처리 시스템인 맵리듀스MapReduce가 개발되었다.

“초기에 맵리듀스를 개발하지 않은 이유 중 하나는 더 작은 규모로 작동할 때 계산에 적은 수의 기계가 사용되어 견고성이 그다지 중요하지 않았기 때문입니다. 일부 계산을 주기적으로 체크 포인트하고 기계가 다운된 경우 체크 포인트로부터 전체 계산을 다시 시작하는 것이 좋습니다. 그러나 특정 규모에 도달하면 항상 다시 시작하고 앞으로 진행하지 않기 때문에 이 방식은 상당히 불안정합니다.”

_2013년 8월 제프 딘이 브래드포드 F. 리옹에게 보낸 이메일에서

맵리듀스는 프로그래밍 API이자 구성 요소 집합으로서 분산 시스템에 대한 프로그래밍을 모든 이전 작업보다 상대적으로 쉽게 만들었다.

맵리듀스의 핵심은 다음 두 함수에 있다.

맵Map

맵 연산은 컬렉션의 모든 요소에 적용될 함수를 인수로 받는다. 컬렉션의 요소는 분산 파일시스템을 통해 분산된 방식으로 익스큐터 머신executor machine당 하나의 청크로 읽혀진다. 그런 다음 로컬 청크에 상주하는 컬렉션의 모든 요소가 그들에게 적용된 함수를 보고 익스큐터executor(실행자)가 있는 경우 해당 애플리케이션의 결과를 내보낸다.

리듀스Reduce

리듀스 연산에는 두 가지 인수가 사용된다. 하나는 중립 요소로서 빈 컬렉션이 넘겨지면 리듀스 연산이 리턴하는 것이고, 다른 하나는 집계의 현잿값인 컬렉션의 새 요소를 가져와서 새로운 집계로 묶는 집계 연산이다.

이 두 가지 고차함수의 조합은 데이터셋에서 수행하려는 모든 연산을 표현할 수 있을 만큼 강력하다.

3.2 교훈: 확장성 및 내결함성

프로그래머의 관점에서 맵리듀스의 주요 장점은 다음과 같다.

● 간단한 API를 가지고 있다.
● 매우 높은 표현력을 가진다.
● 프로그래머로부터 라이브러리 디자이너까지 프로그램을 배포하는 데 어려움이 크게 줄어든다. 특히 복원력이 모델에 내장되어 있다.

이러한 특성들이 모델을 매력적으로 만듦에도 불구하고 맵리듀스의 주된 성공은 성장을 유지하는 능력이다. 데이터 크기가 증가하고 비즈니스 요구 사항이 증가함에 따라 더 많은 정보 추출 작업이 이루어지면서 맵리듀스 모델은 다음 두 가지 중요한 속성을 발휘한다.

확장성

데이터셋이 증가함에 따라 안정적인 처리 성능을 유지하기 위해 시스템 클러스터에 더 많은 리소스를 추가할 수 있다.

결함 허용

시스템은 부분적인 장애를 버텨내고 복구할 수 있다. 모든 데이터가 복제된다. 데이터 전송 익스큐터가 손상되면 손상된 익스큐터에서 실행 중인 작업을 다시 시작하는 것으로도 충분하다. 마스터가 해당 작업을 추적하기 때문에 일정 변경 이외의 특정 문제는 발생하지 않는다.

이러한 두 가지 특성이 결합되면 시스템은 기본적으로 신뢰할 수 없는 환경에서도 워크로드를 지속적으로 유지할 수 있으며, 이는 스트림 처리에도 필요한 속성이다.

4. 분산 스트림 처리

맵리듀스 모델을 사용한 스트림 처리와 일반적인 배치 처리를 사용한 스트림 처리의 차이점은 배치 처리에서는 스트림을 사용하여 전체 데이터셋에 액세스할 수 있지만 언제나 데이터셋의 일부만 볼 수 있다는 것이다.

이러한 상황은 분산 시스템에서 악화된다. 즉, 일련의 익스큐터 사이의 처리 부하를 분산시키기 위해 입력 스트림을 파티션으로 분할한다. 각 익스큐터는 전체 스트림의 일부만 볼 수 있다.

분산 스트림 처리 프레임워크의 과제는 사용자에게 이러한 복잡성을 숨기고 스트림 전체를 추론할 수 있는 추상화를 제공하는 것이다.

4.1 분산 시스템에서 상태 기반 스트림 처리

대통령 선거에서 득표수를 세고 있다고 가정해보자. 고전적인 배치 방식은 모든 투표가 진행될 때까지 기다렸다가 그 뒤에 집계하는 것이다. 비록 이 접근법이 올바른 최종 결과를 도출하지만 선거 과정이 끝날 때까지 (중간) 결과가 알려지지 않기 때문에 하루 종일 지루한 뉴스만 전달될 것이다.

더 흥미로운 시나리오는 각 투표가 진행될 때 후보별로 득표수를 세는 경우다. 현재 참여자수를 부분적으로 집계하여 투표 추세뿐만 아니라 현재 순위도 볼 수 있다. 이를 통해 결과를 예측해볼 수 있다.

이 시나리오를 달성하려면 스트림 프로세서가 지금까지의 내부적인 투표 등록을 보관해야 한다. 일관된 계산을 보장하기 위해 이 레지스터는 어떤 부분적인 오류에서도 복구되어야 한다. 기술적인 실패를 이유로 시민들에게 다시 투표를 요청할 수는 없다.

또한 궁극적인 오류 복구는 최종 결과에 영향을 줄 수 없다. 우리는 잘못 복구된 시스템의 부작용으로 잘못된 당선자를 선언하게 되는 위험을 감수할 수는 없다.

이 시나리오는 분산 환경에서 실행되는 상태 기반 스트림 처리의 문제점을 보여준다. 상태 기반 처리는 시스템에 부담을 가중시키게 된다.

● 시간이 지나도 상태가 보존되도록 보장해야 한다.
● 부분적인 시스템 장애 발생 시에도 데이터 일관성의 보장이 필요하다.

이 책 전체에서 볼 수 있듯이 이러한 문제를 해결하는 것은 스트림 처리의 중요한 측면이다.

스트림 처리의 인기와 이 분야의 도전적인 측면에 대한 더 나은 인식을 갖게 되었으므로 이제 아파치 스파크를 소개할 차례가 된 것 같다. 통합 데이터 분석 엔진으로서 스파크는 일괄 처리 및 스트리밍 처리를 위한 데이터 처리 기능을 제공하며, 다음 절에서 볼 수 있듯이 데이터 집약 적 애플리케이션의 요구를 충족시키는 데 탁월한 선택이다.

5. 아파치 스파크 소개

아파치 스파크는 대규모 데이터 처리를 위한 빠르고 안정적이며 내결함성fault tolerance이 있는 분산 컴퓨팅 프레임워크다.

5.1 첫 번째 물결: 기능적 API

초기 스파크의 혁신은 획기적인 메모리 사용과 표현력이 풍부한 기능적인 API에 의해 이루어졌다. 스파크 메모리 모델은 RAM을 사용하여 데이터가 처리될 때 캐시하므로 배치성 작업 부하를 처리하기 위한 구글 맵리듀스의 오픈 소스 구현체인 하둡 맵리듀스보다 처리 속도가 최대 100배 빠르다.

핵심 추상화인 탄력적 분산 데이터셋Resilient Distributed Dataset(RDD)은 클러스터에서 분산 컴퓨팅의 복잡성을 추상화하는 풍부한 기능적 프로그래밍 모델을 제공한다. 또한 맵리듀스 개요에서 논의한 맵과 리듀스 단계보다 더 표현적인 프로그래밍 모델을 제공하는 변환과 액션이라는 개념을 소개했다. 이 모델에서 맵map, 플랫맵flatmap, 조인join 및 필터filter와 같은 많은 사용 가능한 변환은 하나의 내부 표현에서 다른 표현으로 데이터의 지연 변환을 표현하는 반면 액션이라는 열악한 작업은 분산 시스템에서 계산을 구체화하여 결과를 생성한다.

5.2 두 번째 물결: SQL

스파크 프로젝트의 역사에서 두 번째 전환점은 스파크 SQL 및 데이터프레임(그리고 이후에는 강력한 형식의 데이터프레임인 데이터셋)의 도입이었다. 높은 수준의 관점에서 스파크 SQL은 스키마가 있는 모든 데이터셋에 SQL 지원을 추가했다. SQL 데이터베이스를 쿼리할 때와 같은 방식으로 쉼표로 구분된 값comma-separated values(CSV), 파케이 또는 JSON 데이터셋을 쿼리할 수 있다.

이러한 진화는 사용자의 채택 임곗값을 낮췄다. 고급 분산 데이터 분석은 더 이상 소프트웨어 엔지니어들의 독점 영역이 아니며 이제는 데이터 과학자, 비즈니스 분석가, SQL에 익숙한 다른 전문가도 접근할 수 있게 되었다. 성능 관점에서 SparkSQL은 쿼리 최적화 프로그램과 물리적 실행 엔진을 스파크로 가져옴으로써 적은 리소스를 사용하는 동안 더 빠르게 실행될 수 있게 만들었다.

5.3 통합 엔진

현재 스파크는 데이터 분석에 대한 폴리그롯polyglot 접근과 호환되는 배치와 스트리밍 기능을 제공하는 통합 분석 엔진으로 스칼라, 자바, 파이썬 및 R 언어 API를 제공한다.

이 책에서는 아파치 스파크의 스트리밍 기능에 관심을 기울일 것이지만 배치 기능도 동등하게 향상되었으며 스트리밍 애플리케이션에 매우 보완적이다. 스파크의 통합 프로그래밍 모델은 개발자가 배치 및 스트리밍 워크로드를 모두 해결하기 위해 단 하나의 새로운 패러다임을 배우면 된다는 것을 의미한다.

NOTE_ 이 책에서는 아파치 스파크와 스파크를 서로 바꿔 사용할 수도 있다. 프로젝트 또는 프로젝트의 오픈 소스 측면을 강조하고 싶을 때는 아파치 스파크를 사용하고, 일반적으로 기술을 참조하는 경우에는 스파크를 사용할 것이다.

5.4 스파크 컴포넌트

[그림 1-1]은 어떻게 스파크가 핵심 엔진, 그 엔진 위에 빌드된 일련의 추상화셋(수평 레이어로 표현) 그리고 이러한 추상화를 사용하여 특정 영역을 처리하는 라이브러리(수직 상자로 표현)로 구성되는지 보여준다. 그림에서 이 책의 범위 안에 있는 것은 강조했고 다루지 않는 것은 흐리게 표시했다. 아파치 스파크의 다른 영역을 자세히 알아보려면 빌 챔버스와 마테이 자하리아의 『스파크 완벽 가이드』(한빛미디어, 2018)와 홀든 카로와 레이첼 워렌의 『하이 퍼포먼스 스파크』(제이펍, 2018)를 권장한다.

스파크의 추상화셋으로 다음과 같은 것들이 존재한다.

스파크 코어

스파크 핵심 실행 엔진과 스파크 링고의 익스큐터로 불리는 컴퓨팅 리소스 클러스터에 연산 을 배포하는 데 사용하는 하위 수준의 기능적 API 셋이 포함되어 있다. 클러스터 추상화를 통해 워크로드를 얀YARN, 메소스Mesos 및 쿠버네티스Kubernetes에 제출하고 자체 독립형 클러스터 모드를 사용할 수 있으며 스파크는 머신 클러스터에서 전용 서비스로 실행된다. 데이터 소스 추상화를 통해 파일, 블록 저장소, 데이터베이스 및 이벤트 브로커와 같은 다양한 데이터 공급자를 통합할 수 있다.

스파크 SQL

스파크의 상위 레벨 데이터셋 및 데이터프레임 API를 구현하고 임의의 데이터 소스 위에 SQL 지원을 추가한다. 또한 카탈리스트Catalyst 쿼리 엔진과 텅스텐Tungsten 프로젝트의 코드 생성 및 메모리 관리를 통해 얻게 되는 일련의 성능 향상을 도입한다.

이러한 추상화 위에 구축된 라이브러리는 머신러닝을 위한 엠엘립MLLib, 그래프 분석을 위한 그래프프레임GraphFrame 및 이 책의 초점이 되는 스트림 처리를 위한 두 가지 API인 스파크 스트리밍 및 구조적 스트리밍과 같은 대규모 데이터 분석의 여러 영역을 처리한다.

5.5 스파크 스트리밍

스파크 스트리밍은 핵심 스파크 엔진의 분산 처리 기능 위에 구축된 최초의 스트림 처리 프레임워크다. 2013년 2월 스파크 0.7.0 릴리스에서 알파 릴리스로 소개되었고, 오늘날 대규모 API를 처리하기 위해 업계에서 널리 채택한 성숙한 API가 되었다.

스파크 스트리밍은 개념은 간단하지만 ‘스파크의 분산 컴퓨팅 기능을 적용하여 연속적인 데이터 스트림을 스파크가 작동할 수 있는 개별 데이터 컬렉션으로 변환하여 스트림 처리에 적용하라’는 강력한 전제를 기반으로 구축되었다. 스트림 처리에 대한 이러한 접근 방식을 마이크로배치 모델microbatch model이라고 하며, 대부분의 다른 스트림 처리 구현에서 지배적인 요소별 모델element-at-time과 대조된다.

스파크 스트리밍은 스파크 코어와 동일한 기능적 프로그래밍 패러다임을 사용하지만 새로운 추상화된 DStreamDiscretized Stream(이산 스트림)을 도입하여 프로그래밍 모델을 스트림의 기본 데이터에서 작동하도록 한다.

5.6 구조적 스트리밍

구조적 스트리밍Structured Streaming은 스파크 SQL 추상화 위에 구축된 스트림 프로세서다. 스트리밍 기능으로 데이터셋 및 데이터프레임 API를 확장한다. 따라서 스키마 지향 변환 모델을 채택하여 이름의 구조화된 부분을 제공하고 스파크 SQL에 구현되어 있는 모든 최적화를 상속한다.

구조적 스트리밍은 2016년 7월 스파크 2.0과 함께 실험용 API로 도입되었다. 1년 후 스파크 2.2가 프로덕션 배포에 적합해짐에 따라 일반 가용성에 도달했다. 비교적 새로운 개발인 구조적 스트리밍은 여전히 새로운 버전의 스파크로 빠르게 진화하고 있다.

구조적 스트리밍은 선언적 모델을 사용하여 스트림 또는 스트림셋에서 데이터를 수집한다. API를 최대한 활용하려면 스트림의 데이터에 대한 스키마 지정이 필요하다. 데이터셋 및 데이터프레임 API에서 제공하는 일반 변환 모델을 지원할 뿐만 아니라 이벤트 시간, 스트리밍 조인 및 기본 런타임과의 분리와 같은 스트림별 기능을 소개한다. 이 기능은 다른 실행 모델로 런타임을 구현할 수 있는 기회를 제공한다. 기본 구현은 고전적인 마이크로배치 방식을 사용하는 반면, 최신 연속 처리 백엔드는 거의 실시간 연속 실행 모드를 실험적으로 지원한다.

구조적 스트리밍은 스트림 처리를 동일한 수준의 배치 지향 애플리케이션으로 가져오는 통합 된 모델을 제공하여 스트림 처리에 대한 많은 추론 부담을 제거한다.