571. Spark 스트리밍 (Micro-batch) vs Flink (Native Stream)

⚠️ 이 문서는 카프카(Kafka)나 IoT 센서에서 1초에 수백만 건씩 끊임없이 쏟아지는 '실시간 데이터(Stream)'를 분석하는 빅데이터 분산 처리 엔진의 양대 산맥인 아파치 스파크(Spark)의 '마이크로 배치(Micro-batch)' 방식과, 아파치 플링크(Flink)의 '네이티브 스트림(Native Stream)' 처리 방식의 근본적인 아키텍처 차이점과 한계를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 끊임없이 흐르는 냇물(데이터)을 떠먹는 방식의 차이다. Spark는 1초마다 작은 바가지로 물을 퍼서 모아 마시는 방식(Micro-batch)이고, Flink는 흐르는 물길에 아예 파이프를 박아놓고 물이 지나가는 족족 0.01초 만에 바로 삼켜버리는 방식(Native Stream)이다.
  2. 가치: Spark는 기존의 거대한 엑셀 파일(Batch)을 분석하던 막강한 노하우와 머신러닝 생태계를 그대로 실시간 분석에 재활용할 수 있는 튼튼함이 무기다. 반면 Flink는 자율 주행차나 주식 초단타 매매처럼 "1초의 지연도 용납할 수 없는" 초저지연(Sub-millisecond) 실시간 분석의 끝판왕이다.
  3. 기술 체계: Spark Streaming은 시간을 쪼개어 가상의 '작은 덩어리(Batch)'를 만들어 처리하므로 태생적인 딜레마(지연시간)가 존재하지만, Flink는 이벤트가 발생하는 그 순간 하나하나를 독립적인 생명체(Event-at-a-time)로 보고 처리하는 진정한 스트리밍 엔진이다.

Ⅰ. 아파치 스파크 (Spark)의 꼼수: 마이크로 배치 (Micro-batch)

원래 덤프트럭(배치)이던 놈을 개조해서 오토바이(스트리밍)처럼 쓰려다 보니 꼼수가 필요했다.

  1. 배치(Batch)의 태생적 한계:
    • 스파크는 원래 하둡(Hadoop) 맵리듀스를 대체하기 위해 램(RAM) 위에서 거대한 데이터 덩어리(100GB 파일 등)를 한 방에 처리하는 '배치 처리(Batch Processing)'의 제왕으로 태어났다.
    • 그런데 시대가 바뀌어 "실시간 검색어 순위를 뽑아줘!"라는 요구가 빗발쳤다.
  2. 마이크로 배치의 발명 (가짜 스트리밍):
    • 스파크 설계자들은 똑똑한 꼼수를 냈다. "진짜 실시간은 너무 복잡하니까, 우리가 젤 잘하는 배치 처리를 '0.5초' 단위로 아주 짧게 무한 반복하게 만들면 사람이 보기엔 실시간처럼 보이지 않을까?"
    • 카프카에서 물이 흐르면 스파크는 0.5초 동안 물을 바가지에 모은다(Micro-batch). 그리고 그 작은 바가지를 기존의 거대한 배치 엔진에 휙 던져서 분석한다. 이걸 1초에 두 번씩 무한 반복한다.
  3. 한계점 (지연 시간, Latency):
    • 결국 아무리 바가지를 작게 쪼개도, '모으는 시간'과 '엔진에 태우는 준비 시간' 때문에 최소 수백 밀리초(0.5초~1초)의 딜레이가 반드시 발생한다. 주식 초단타 매매(HFT)에서는 이 0.5초 때문에 수백억 원이 날아갈 수 있어 스파크를 쓸 수 없다.

📢 섹션 요약 비유: 스파크 스트리밍은 무거운 덤프트럭(배치 엔진)입니다. 이 트럭으로 오토바이(실시간 배달) 흉내를 내기 위해, 1초마다 물건을 1개씩 싣고 10미터 앞을 무한 반복해서 왔다 갔다 하는 아주 성실한 꼼수를 부리는 것입니다. 튼튼하고 짐은 잘 나르지만, 구조적으로 오토바이의 날렵한 속도(초저지연)를 낼 수는 없습니다.

애초에 처음부터 흐르는 물을 마시기 위해 태어난 진골 스트리밍 엔진이다.

  1. Event-at-a-time (건별 즉시 처리):
    • 플링크는 바가지(배치)라는 개념 자체가 없다.
    • 센서에서 데이터가 1건 톡 떨어지는 순간(Event), 그 데이터 1건이 곧바로 플링크 파이프라인의 톱니바퀴를 타고 들어가 빛의 속도로 분석을 마치고 0.01초 만에 화면에 뿌려진다.
    • 이를 **'진정한 스트리밍(Native Streaming)'**이라고 부른다.
  2. 반대로 꼼수를 부리는 플링크:
    • 재밌게도 플링크는 반대로 거대한 파일(Batch) 처리를 요구받으면, "거대한 파일도 결국 끝이 정해져 있는 스트림(Bounded Stream) 데이터일 뿐이잖아?"라며 스트림 엔진으로 배치 파일을 돌려버리는 역발상을 시전한다.
  3. 정확한 시간의 통제 (Event Time vs Processing Time):
    • 플링크의 진가는 '지연 도착 데이터'를 다룰 때 나타난다.
    • 고객이 지하철에서 와이파이가 끊겨 결제 데이터가 10분 늦게 서버에 도착했다. 스파크는 바가지(시간) 단위로 끊어버리기 때문에 이 데이터를 10분 뒤의 통계에 잘못 섞어버린다.
    • 반면 플링크는 철저히 데이터 몸통에 찍힌 타임스탬프(Event Time)와 여유 시간(Watermark)을 보고, "아 넌 10분 전 데이터구나? 잠깐 멈춰봐, 10분 전 통계 다시 계산해 줄게"라며 완벽한 정합성을 보장한다.

📢 섹션 요약 비유: 플링크는 정수기에 입을 대고 나오는 물방울을 떨어지는 족족 바로바로 삼켜버리는 진짜 실시간 엔진입니다. 게다가 물방울에 번호표(Event Time)가 붙어 있어서, 물방울이 파이프에 막혀 늦게 도착해도 기가 막히게 원래 순서대로 줄을 세워 소화 불량(통계 오류)을 막아내는 경이로운 소화 기관을 가졌습니다.

Ⅲ. 승부의 결론: 언제 무엇을 써야 하는가?

생태계의 스파크냐, 극한의 속도를 쫓는 플링크냐.

  1. Spark의 절대적 우위 (머신러닝과 에코시스템):
    • 속도에서 플링크에 밀리지만, 전 세계 빅데이터 시장의 90%는 여전히 스파크를 쓴다.
    • 이유: 스파크는 이미 10년간 쌓아온 무적의 머신러닝 라이브러리(MLlib)와 SQL 생태계를 가지고 있다.
    • "로그 1억 건을 0.5초마다 모아서, 우리 회사 AI 모델에 던져서 추천 상품 뽑아줘" 같은 복잡한 AI 통합 파이프라인을 짤 때는 플링크가 스파크의 거대한 툴체인을 도저히 이길 수 없다.
  2. Flink의 압승 무대 (금융, 자율주행, 이상 탐지):
    • "서버에 해커가 들어왔는지 로그를 0.001초 만에 스캔해서 서버를 차단해라", "우버(Uber) 택시의 실시간 위치를 밀리초 단위로 지도에 찍어라"
    • AI 분석보다 **'즉각적인 반응(Reaction)'**과 **'시간 단위의 복잡한 윈도우(Window) 연산'**이 생명인 곳에서는 플링크가 스파크를 학살하며 새로운 왕좌를 차지하고 있다.

📢 섹션 요약 비유: 스파크는 무거운 갑옷을 입었지만, 손에 마법 지팡이(AI), 엑스칼리버(SQL), 회복 물약 등 세상의 모든 무기(생태계)를 다 들고 있는 든든한 만능 기사입니다. 플링크는 오직 가벼운 단검 하나만 들고 눈에 보이지도 않는 속도로 적의 목을 베어버리는 극강의 암살자입니다. 적진 한가운데서 다양한 마법(분석)을 써야 하면 스파크를, 0.1초의 지체도 없이 VIP를 보호(실시간 탐지)해야 한다면 플링크를 고용해야 합니다.