[Hadoop_기초]Udemy course - 섹션 10. Spark Streaming & Storm & Flink

86강. Spark Streaming 소개

수집되는 데이터를 일괄적으로 처리하기 보다는, 수집되는 순간 그때그때 처리하기 위한 기술이다. 

이전 강의에서 나온 kafka 클러스터의 processing 쪽의 기능을 한다고 보면 된다.

 

Spark Streaming을 사용하는 이유

웹 서버 로그에 감지된 사용자 활동 데이터를 가져온다면 항상 데이터가 들어올 것이고, 이러한 데이터를 일괄적으로 처리하기에는 확장성 등의 여러 한계가 발생한다. 따라서 이러한 경우에는 데이터가 수집되는 즉시 실시간으로 처리하면 된다.

 

Spark Streaming 작동방식

Flume이나 Kafka 혹은 어떤 서버 집단의 TCP 연결 소켓을 수신하는 데이터 수신기(receivers)를 가진다.

 

이렇게 수신된 데이터를 spark streaming이 작은 조각으로 나눈다.

특정 시간으로 증분 시간을 지정하면 위의 그림처럼 데이터를 시간 단위의 RDD 조각으로 나눈다.

각 RDD에는 짧은 기간동안 수신한 구분된 데이터 조각이 들어가 있다. 

그리고 이 데이터를 변형하고 처리하게 되는 것이다. 

 

Spark Stream은 엄밀히 말하면  "실시간"은 아니다. "마이크로 배치"이다.
데이터를 작은 RDD 조각으로 나누어 더 큰 구조의 일부분으로 함께 관리하는 개념이다.

기술적으로는 실시간으로 보기 힘들지만, 그 데이터를 초 단위로 나누기 때문에 실시간으로 봐도 무방하다. 

 

Spark Streaming의 모든 작업은 분산된다. 데이터를 수신하고 RDD조각들을 처리하는 모든 과정이 하둡 클러스터의 다양한 작업자 노드에 걸쳐 병렬로 처리된다는 것이다.

 

DStreams(Discretized Streams)

RDD 조각 위에, 구분된 스트림이라는 뜻의  DStream라는 개념이 있다.

• DStream 객체가 각 배치의 RDD를 만드는 작업을 하며 각 배치의 출력을 생산하기도 한다.
• DStream에 트랜스포머나 액션을 적용함으로써 각 배치를 수신하자마자 이 작업을  DStream에 실시하라고 지정할 수 있다.

이러한 작업적 특징이 Spart Stream 이 Spark와 다른 점이다.

작업을 DStream에 실시하고 새 배치 데이터를 수신할 때마다 적용한다. 그리고 중단하기 전까지 스크립트의 끝에서 다시 실행한다.

클러스터의 분산된 모든 데이터를 나타내는 RDD를 가져와 한 번에 처리하는 Spark의 일괄처리 방식과 다르다.

 

DStream에서는 RDD에서 하는 것처럼 변환, 매핑, 액션을 수행할 수 있지만 시간이 지나면서 새로운 정보 배치가 수신되면 

새롭게 수신된 정보도 끊임없이 적용해야한다. 

 

DStream에서 RDD에 접근할 수 있으므로 인해서, DStream에서 할수 없는 작업을 RDD에서 직접할 수도 있다.

mapping, flat, filter, key, reducing 등의 Spark RDD에서 사용하는 기능을 Spark Streaming의 Dstream에서도 사용할 수 있다.

 

stateful 데이터를 유지하여 마이크로 배치 정보를 들어오는 즉시 처리할 수 있으며 특정 배치 간격을 초과하여 오랫동안 상태를 유지할 수 있다. 

 

즉 세션데이터나 웹서버 로그 데이터를 집계하기 위한 마이크로 배치 기능을 제공해주며,  DStream과 함께 상태(state)를 일정시간동안 유지할 수 있는 것이다.

 

Windowing

Windowed Transformation

Spark Streaming이 일정 시간동안 상태를 유지할 수 있게 해주는 기술이다.

 

해당 기술은 짧은 배치 간격보다 더 긴시간동안 결과를 계산하게 한다. 

 

예를 들어, 다양한 웹서버에 걸친 전자 상거래 웹사이트에서 나오는 활동데이터를 한 시간동안 수집해서 가장 잘팔리는 상품을 분석한다고 할때, 배치 간격을 1초로 설정해 신속히 처리 되도록 하고 윈도를 한시간으로 유지한다.

그러면 한시간짜리 미닫이 창이 생긴것과 같다. 

지난 한시간동안의 모든 데이터를 가져와 모든 배치의 누계를 낼 수 있다.

 

이렇게 1시간짜리 윈도간격 안에 수신한 모든 데이터를 합한 정보를 Spark Streaming이 관리한다. 그리고 주기적으로 전체 윈도간격에 대한 집계를 할 수 있다.

 

배치간격은 얼마나 자주 데이터를 별개 RDD로 DStream에 가져오기를 정하는 것. 슬라이드 간격은 얼마나 자주 윈도변화를 계산하는가를 정하는 것. 이 슬라이드 간격에서 집계한 데이터를 묶는 기준이 윈도 간격이다. 

 

예를 들어 지난 한시간동안 가장 잘팔린 상품을 구하는 예시에서, 1시간동안의 인기 상품을 매 30분마다 찾는다면 배치간격은 1초, 슬라이드 간격은 30분, 윈도 간격은 1시간이다. 

 

위의 경우는 1초의 배치간격과, 2초의 슬라이드 간격(매 2초마다 결과를 계산), 3초의 윈도 간격(3초는 지난 세 배치를 가지고 결과를 계산)이다. 

여기서 마지막 박스(batch) - 그림상에서는 가장 처음에 있는 박스 - 는 슬라이드 간격에 도달했으나 시작한지 3초가 지나지 않아서 첫 2개의 배치만을 가지고 계산하게 된다. 

 

Spark Streaming에서는 SparkContext와 더불어 StreamingContext를 구성해야 한다. 

SparkContext를 기반으로  StreamingContext를 만든다. 이때 두번째 매개변수는 배치 간격이다. 

즉 'StreamingContext'를 만드는데 'sc'를 기반으로하며 1초의 '배치 간격'을 갖는다는 뜻이다.

 

'StreamingContext'를 구성하면 'reduceByKey'를 호출하고 윈도할 수 있다.

예를 들어, 'DStream' 컨텍스트에서 만들어온 'DStream'이 있다면 그 'DStream'에 윈도와 'reduceByKey'를 호출 할 수 있다.

여기 이 인수에 'lambda' 함수를 사용한다. 주어진 x, y 값이 있고 이 둘을 더한다. 그다음에 이 계산에서 항목을 제거하는 함수가 있다.

이 경우에는 'x'에서 'y'를 빼면 된다.

그다음 '윈도 간격' 300초, 5분을 지정하고 '슬라이드 간격'은 1초이다.

이 예시의 의미는 지난 5분 동안의 값을 평범하게 더하고 빼며 합계하고 매 1초마다 이 계산을 수행한다는 뜻이다.

 

Structured Streaming

Spark Streaming은 실제로 현재 과도기 단계이며 구조화 스트리밍이라는 새 패러다임을 향해 나아가고 있다.

이전 Spark강의에서 RDD를 직접사용하는 대신, Dataframe을 기반으로 한 Dataset API를 사용하는 쪽으로 나아가고 있다고 했다.

이와 비슷한 개념으로 구조화 스트리밍은  DStream대신 DataSet을 주 API로 사용한다. 

 

즉 개별적인 RDD아 DStream을 사용하는 대신 표 형식의 구조화 데이터를 가진 DataFrame를 갖는 것이다. 

이에 따라 테이블에 지속적으로 새 행이 추가된다. 

API의 관점에서 또 다른 DStream을 다루는 것과 동일하지만, 유일한 차이점은 데이터가 지속적으로 추가 된다는 점과 

그 Dataframe에 새로운 윈도 운영을 실행할 수 있다는 점이다.

 

Structured Streaming의 장점

스트리밍 버전의 코드가 비스트리밍 버전의 코드와 비슷하다.

따라서 코딩하는 방식이 크게 다르지 않아서 일괄 분석 스크립트에서 실시간 스트리밍 데이터 스크립트로 전환하기가 쉽지 않다.

Dataset을 사용할 때의 성능상 장점이 여기에서 드러난다. 

 

다른 Spark기능들도 DatasetAPI로 나아가고 있다. 예를 들어 MLLib도 DatasetAPI를 향해 나아간다. 

즉 항상 새 데이터를 수신하는 구조화 스트리밍 Dataset이 있다면 그것을 바로 머신러닝 라이브러리에 전달해 흥미로운 데이터 분석을 할 수 있게 된다.

 

따라서 데이터를 분석하고 마이닝하는 과정에서의 코드 작업이 점점 간결해질 수 있는 것이다.

 

87강. [실습]Flume으로 발행한 웹로그 분석하기

아직  구조화 스트리밍은 실험 단계이므로 Dstream으로 실습 진행

 

88~89강. [실습]Flume  발행 로그에서 실시간으로 오류 모니터링하기

 

90강. Apache Strom 소개

데이터 스트림을 처리하는 또 하나의 방법이다. 

 

Yarn위에서 작동할수도 있지만 독자적으로 개발되어 더 독립적이다. 

 

Spark Streaming과는 다르게 개별이벤트를 작업하고 마이크로 배치를 다루지는 않는다. 

이에 따라서 처리 과정에서 1초 미만의 지연만을 요구한다면 실질적으로  spark streaming을 사용하기가 힘들며 이런 경우 storm을 고려할 수 있다.

데이터를 받는 그대로 신속하게 처리한다. 

 

Strom의 기본 개념

Stream

실시간으로 시스템에 끊임없이 흘러들어오는 데이터의 개념이다.

스트림은 데이터 투플을 포함한다. 투플은 시스템에서 전달된 정보의 목록이다. 

예를 들어 세 개의 투플이 숫자 5, 7, 33과 세 개의 다른 문자열을 포함한다. 즉 투플은 그룹 지어진 데이터의 목록이다.

 

Storm에서 스트림은 스파웃(spout)으로부터 흘러나온다. 스파웃은 소스이며 Kafka, Twitter, 데이터베이스 연결, 혹은 TCP 포트 등이다.

스파웃을 직접 작성해 원하는 곳으로부터 데이터를 가져올 수 있다. 즉 스파웃은 추가적인 처리를 위해 데이터를 Storm으로 가져오는 곳이다. 

 

그리고 스파웃에서 나온 데이터를 가져다가 실제로 처리하는 곳은 볼트(bolt)다. Storm에서 볼트 클래스를 구성해 데이터가 들어오는 순간 변환하거나 집계하고 출력을 작성할 수도 있다.  볼트는 데이터 스트림을 끊임없이 처리하므로 데이터베이스에 작성할 최종 결과정보가 없다. 실시간 처리를 하면서 볼트가 처리하여 나오는 데이터의 결과가 계속 바뀌게 된다.

 

스파웃과 볼트는 서로 연결되어 토폴로지가 된다. 일종의 가방으로써 이 요소들을 원하는 대로 조립할 수 있다.

보통은 해당 구좍 간단하여서 스파웃에서 볼트로 가고 아마 또 다른 볼트로 가는 정도이다

이 요소들을 조금 더 정교하게 연결한다면 두 개의 스파웃을 가질 수도 있다. 어떤 볼트는 두 스파웃을 동시에 처리하고 어떤 볼트는 단 하나만을 처리하게 될 수도 있다. 그리고 어떤 볼트는 다른 볼트로 이어져 추가적인 작업을 할 수 있다.

 

Strom Architecture

더 복잡하게 아키텍쳐를 구성하고 싶다면 위의 방식으로 구조화가 가능하다.

이는 Spark의 방향성 비순환 그래프와 유사하다. 그러나 DAG는 자동으로 최적화 경로를 찾아주지만 Storm에서는 스스로 생각해내야 한다.

 

Nimbus

일종의 jobTracker이다. 작업들이 어디에서 어떻게 돌아가는지를 기록한다. 

기술적으로 이것은 단일실패지점이다. 그렇지만 다운되더라도 잃어버리는 것 없이 신속히 살려낼 수 있다.

최근에는 단일 실패 지점의 문제를 해결하기 위해 고가용성 버전의 storm에서 백업 nimbus서버를 가지고 필요에 따라 자동으로 전환한다.

 

Zookeeper

위의 nimbus서버의 작업은 주키퍼를 통하며 이 자체도 고가용성을 갖고 있다.

 

Supervisor

strom의 작업이 어디서 일어나는지 알고 있으며 실제로 작업자와 작업 프로세스를 실행하는 주체이다. 

 

Strom특징

Storm 어플리케이션은 보통 자바로 개발된다. 그러나 스트리밍을 통해 볼트를 그 어떤 스크립트나 언어와도 소통하도록 구성할 수 있으므로 자바 외의 모든 언어와도 호환될 수 있다.

 

Storm Core는 저수준 API이며 굉장히 간단하다. 작업을 분산하고 모든 것이 잘 실행되는지 확인하는 등의 복잡함을 단순화 시킨다.

이는  at-least-once 시멘틱을 제공한다.

strom core를 사용하면 복사본을 받을 확률도 있다. 

Trident를 사용하는 추세인데, 이는 고수준  API를 제공하고  Strom Core위에서 작동한다. 즉 추가적인 레이어이다. 단순한 API이며 토플로지를 구성할 수 있고 Exactly once 시멘틱을 제공한다.

 

이런 토플로지를 구성해서  storm에 제출하면 작업이 끝났을때 멈출것을 명시해야한다. 즉 스크립트가 끝났어도 이를 명시하지 않으면 끝난 것이 아니다. 

 

Spark Streaming과 비교

Spark가 제공하는 통합기능을 사용하고자 한다면 spark streaming을 사용하는 것이 좋다.

그러나 이벤트별로 처리되며 1초 미만의 처리 시간이 필요하다면 strom이 적절하다.

 

Spark Streaming의 시간별 데이터 윈도 집계처럼 Strom Core에서는 텀블링 윈도를 할 수 있다.

spark streaming의 슬라이드 윈도와 별개로 데이터가 들어옴에 따라 지난 5초동안 들어온 모든 이벤트를 원하는 경우, 새 데이터가 들어오면 5초 후에 다른 윈도를 갖는다. 그 윈도는 해당 5초의 다음 이벤트 시퀀스를 갖는 등으로 진행된다.

텀플링 윈도에서는 이벤트가 겹칠일이 없으나 슬라이드 윈도에서는 겹치도록 설계할 수 있다,

 

90강.[실습] Strom으로 단어 세기

91강. Flink 개요

Flink VS Strom VS Spark Streaming

Storm과 유사하게 이벤트별로 작업한다. 즉 spark streaming과 달리 마이크로 배치가 아닌 실시간 처리이다.

그리고 spark가 yarn이나 mesos위에서 작동하는 것 처럼 flink도 독립적인 클러스터에서 실행할 수 있다.

flink는 storm보다 처리량이 빠르다. 성능 또한 훨씬 좋다. 따라서 동일한 작업을 할 때도 하드웨어 요구 사항이 더 낮다.

flink는 trident나 spark처럼 고수준api를 제공하지만 그 와중에도 실시간 스트리밍을 할 수 있다. 

또한 scala를 지원하여 flink가 spark streaming과 유사하다고 볼 수 있다.

 

flink의 특징 중 대표적인 것은 spark처럼 스스로의 생태계를 가지고 있다는 것이다.

기계학습 라이브러리나 SQL쿼리 라이브러리 등을 사용할 수 있다.

 

Flink 장점

flink는 확장성이 크다는 장점을 가지고 있다. 이는 분산전략덕분인데, 대규모로 배치해서 사용한다면 천개의 노드까지 확장할 수 있다. 

 

강력한 내고장성을 가지고 있다. state snapshopt을 사용하여 실패가 발생하더라도 한번의 처리를 보장한다. 

이러한 특징한 금융거래를 다루는 경우에 중요하게 활용될 수 있다.

 

데이터를 받는 순간이 아닌 이벤트 시간을 기준으로 데이터를 처리할 수 있다.

이부분 또한 금융 거래에서 중요하다. 때때로 이상한 실패 모드를 가진 사용자들이 데이터를 전송하거나 주식을 거래할 때 몇시간 혹은 며칠의 딜레마가 발생할 수도 있기 때문이다. 

이러한 상황에서 뒤틀린 순서로 클러스터에 도달하더라도 다른 이벤트 사이에서 올바른 순서로 적용될 수 있다.

 

유연한 윈도 시스템을 가지고 있어서 시간에 따라 흘러들어오는 데이터를 윈도잉하고 분석할 수 있다.

 

Flink Architecture

Flink 자체는 런타임 엔진으로 spark처럼 독립적인 클러스터에 실행할 수 있고 하둡의 yarn위에서 실행할수도 있으며 AWS나 GCP 위에서 실행할 수도 있다.

 

스트리밍 데이터뿐 아니라 배치 데이터도 처리할 수 있다.

 

DataStream API는 CEP를 사용해서 이벤트를 처리하고 테이블 기반 프로세싱으로 들어오는 데이터에 SQL유사 관계형 쿼리를 할 수 있다. 

DataSet API는 배치 데이터를 다룬다. 

Gelly는 spark의 GraphX와 대응할 수 있으며,  Table는 SparkSQL로 대응할 수 있다.

 

91강.[실습] Flink로 단어세기