윤남매 아빠's 스토리

안녕하세요!지난 6편에서는 복잡한 스트리밍 로직을 우아한 SQL 문법으로 풀어내는 마법, 그리고 시계열 조인(Temporal Table Join)에 대해 알아보았습니다. 이제 여러분은 흐르는 데이터의 통계를 내고 집계하는 작업의 달인이 되셨습니다.하지만, 비즈니스 현장에서는 단순한 '통계' 이상의 능력을 요구할 때가 많습니다. "최근 1시간 총매출"을 구하는 건 SQL이나 Window API로 충분하지만, 다음과 같은 시나리오는 어떨까요?"어떤 유저가 ①비밀번호를 3회 연속 틀린 후, ②5분 이내에 성공적으로 로그인해서, ③평소와 다른 IP로 100만 원 이상을 결제하면 즉시 계정을 동결해라!"이것은 데이터의 합계나 평균을 구하는 문제가 아닙니다. 시간의 흐름에 따라 발생하는 이벤트들 사이의 '인과관계'..

안녕하세요!지난 5편까지 우리는 시간(Time), 상태(State), 윈도우(Window), 그리고 장애 복구(Checkpoint)까지 Flink의 핵심 내부 엔진을 모두 분해하고 조립해 보았습니다. 진정한 하드코어 데이터 엔지니어링의 세계였죠.그런데 지금까지 배운 내용들을 Java나 Scala 코드로 직접 구현하려면 코드가 꽤 길고 복잡해집니다. "스트리밍 데이터도 그냥 RDB 다루듯이 SELECT, JOIN, GROUP BY 같은 표준 SQL로 처리할 순 없을까?"당연히 있습니다! Flink는 복잡한 하위 레벨 API(DataStream API)를 몰라도, 누구나 쉽게 실시간 파이프라인을 구축할 수 있도록 강력한 Table API & Flink SQL을 제공합니다. 오늘은 스트림을 테이블처럼 다루는 ..

안녕하세요!지난 2편에서는 지연되는 데이터를 우아하게 처리하기 위해 Flink가 사용하는 워터마크(Watermark)와 시간의 마법에 대해 알아보았습니다. 이제 데이터가 제때 도착하든 늦게 도착하든, 정확한 타이밍에 계산을 마감할 수 있게 되었습니다.그런데 여기서 근본적인 질문이 하나 생깁니다. "스트리밍은 데이터가 끊임없이 흘러가는 파이프라면서요? 그럼 방금 지나간 데이터는 어디에 기억해 두나요?""최근 10분간 유저 A가 장바구니에 담은 상품 목록", "어제부터 지금까지 발생한 총매출액". 이런 계산을 하려면 과거의 데이터를 '기억'해야 합니다. 무한한 데이터 스트림 속에서 시스템의 메모리가 터지지 않게 안전하게 기억을 관리하는 기술!오늘은 Flink를 단순한 파이프가 아닌 강력한 애플리케이션(Sta..

안녕하세요! 지난 1편에서는 Flink가 어떻게 Spark의 한계를 넘어 '밀리초 단위의 찐(True) 스트리밍'을 구현하는지 알아보았습니다. 데이터가 컨베이어 벨트를 타듯 들어오는 즉시 처리되는 그 짜릿한 속도감, 기억하시죠?하지만 실시간 데이터 처리의 세계에 발을 들이는 순간, 우리는 아주 골치 아픈 철학적 문제에 직면하게 됩니다. 바로 '시간(Time)'입니다.모바일 게임 유저가 지하철에서 몬스터를 잡았는데 인터넷이 끊겼습니다. 이 데이터가 다음 날 아침 서버에 도착했다면, 이 몬스터 사냥은 어제 일어난 일일까요, 오늘 일어난 일일까요?오늘은 완벽한 실시간 처리를 위해 반드시 정복해야 하는 Flink의 핵심 개념, 시간의 3가지 정의와 지연 데이터를 우아하게 제어하는 마법사 '워터마크(Waterma..

안녕하세요!데이터 엔지니어링의 끝판왕, '초실시간(Real-time) 스트리밍'의 세계로 오신 것을 환영합니다! Spark Streaming이 훌륭한 도구이긴 하지만, 태생적으로 데이터를 잘게 쪼개어 처리하는 '마이크로 배치(Micro-batch)' 방식이기에 수 초의 지연(Latency)이 발생합니다.하지만 금융권의 이상 거래 탐지(FDS), 초당 수백만 건이 발생하는 클릭 로그 분석, 실시간 추천 시스템에서는 밀리초(ms) 단위의 반응 속도가 필요합니다. 이때 혜성처럼 등장해 업계 표준으로 자리 잡은 진정한 스트리밍 엔진, Apache Flink의 모든 것을 바닥부터 최상위 운영 노하우까지 낱낱이 파헤쳐 보겠습니다.📋 Apache Flink 연재 시리즈 리포트제1편. [서론] 왜 Flink인가? M..

안녕하세요! 여러분의 AI 기술 가이드, 팬돌프입니다.지난 1편에서는 텍스트를 숫자로 바꾸는 임베딩(Embedding)에 대해 배웠습니다. "의미가 비슷하면 벡터 공간에서 거리가 가깝다"는 것이 핵심이었죠.그런데 여기서 현실적인 문제에 부딪힙니다. 여러분이 만든 서비스가 대박이 나서 데이터가 1억 개가 되었다고 상상해 봅시다. 사용자가 질문을 던질 때마다 1억 개의 데이터와 일일이 거리를 계산해서 가장 가까운 놈을 찾으려면 얼마나 걸릴까요?아마 답변 하나를 듣는 데 10초, 아니 1분이 걸릴지도 모릅니다. 사용자는 다 떠나겠죠.오늘은 정확도를 아주 조금 포기하는 대신, 속도를 수백 배 빠르게 만드는 벡터 데이터베이스의 심장, ANN(근사 최근접 이웃)과 HNSW 알고리즘의 비밀을 파헤쳐 봅니다.1. 완벽..

안녕하세요! 여러분의 데이터 아키텍처 길잡이, 팬돌프입니다.지난 2편에서는 Iceberg가 데이터를 파일 단위가 아닌 계층형 메타데이터로 관리한다는 사실을 배웠습니다. 이 구조가 주는 장점은 단순히 '검색 속도'만이 아닙니다.데이터 엔지니어들이라면 한 번쯤 겪어봤을 악몽이 있죠. "기획팀 요청으로 컬럼 이름을 바꿔야 하는데, 데이터가 100TB네요... 이걸 언제 다 다시 쓰지?"기존 Hive 환경에서는 단순한 컬럼명 변경조차 엄청난 비용이 드는 대공사였습니다. 하지만 Apache Iceberg 환경에서는 이 작업이 단 1초 만에 끝납니다. 데이터 파일을 단 1바이트도 건드리지 않고 말이죠.오늘은 Iceberg가 자랑하는 가장 강력한 기능 중 하나인 스키마 진화(Schema Evolution)와 파티션 ..

안녕하세요! 여러분의 데이터 아키텍처 가이드, 팬돌프입니다.지난 시간까지 우리는 Kafka로 데이터를 실시간으로 나르고, Spark로 대용량 데이터를 가공하는 법을 마스터했습니다. 이제 엔지니어링 파이프라인의 마지막 종착지, 바로 '저장(Storage)'에 대해 이야기할 차례입니다."그냥 S3에 Parquet 파일로 쌓아두면 되는 거 아니에요?"라고 물으실 수 있습니다. 하지만 데이터가 페타바이트급으로 커지고, 여러 부서에서 동시에 이 데이터를 읽고 쓰기 시작하면 심각한 문제들이 터지기 시작합니다.오늘은 왜 우리가 기존의 방식(Hive)을 버리고 'Apache Iceberg'라는 새로운 기술을 도입해야 하는지, 그리고 이것이 어떻게 데이터 레이크하우스(Data Lakehouse) 시대를 열었는지 아주 상..

안녕하세요! 여러분의 데이터 아키텍처 가이드, 팬돌프입니다.카프카로 데이터를 나르고, 스파크로 데이터를 가공했다면, 이제 그 데이터를 '어디에, 어떻게 저장할 것인가'가 남았습니다.기존의 하둡(Hive) 방식은 수정(Update)과 삭제(Delete)가 너무 어렵고, 스키마를 바꾸려면 테이블을 엎어야 하는 고통이 있었죠. 이 모든 문제를 해결하고 "S3 같은 객체 스토리지 위에서도 마치 RDB처럼 트랜잭션(ACID)을 보장하는" 혁명적인 기술, Apache Iceberg 시리즈를 준비했습니다.단순한 소개를 넘어 내부 메타데이터 구조까지 깊게 파고드는 전문가용 커리큘럼입니다.📋 Apache Iceberg 연재 시리즈 리포트제1편. [서론] 왜 Iceberg인가? Hive 테이블 포맷의 한계와 레이크하우스..

안녕하세요! 여러분의 영원한 데이터 엔지니어링 파트너, 팬돌프입니다.드디어 대장정의 마지막 순간이 왔습니다. 지난 1편부터 7편까지 우리는 스파크의 기본 개념부터 DataFrame, SQL 분석, 그리고 심화 튜닝 기술까지 숨 가쁘게 달려왔습니다. 이제 여러분은 이미 대용량 배치(Batch) 데이터를 처리하는 데 있어서는 준전문가 수준에 도달하셨습니다.하지만 현대의 데이터 환경은 멈춰 있지 않습니다. 데이터는 24시간 쉴 새 없이 흐릅니다. "어제 데이터 말고, 지금 당장 들어오는 매출 데이터를 보고 싶어!" 이런 요구사항에 대응하기 위해, 마지막 퍼즐 조각인 실시간 스트리밍(Streaming)을 맞춰보겠습니다.우리가 초반에 다뤘던 '카프카(Kafka)'와 오늘 배울 '스파크(Spark)'가 만나면 어떤..

안녕하세요! 여러분의 데이터 셰프, 팬돌프입니다.지난 4편에서는 지저분한 데이터를 깨끗하게 다듬는 '데이터 랭글링' 기술을 익혔습니다. 재료 손질이 끝났다면 이제 본격적으로 불을 지피고 맛있는 요리를 만들어낼 차례입니다.데이터 엔지니어링의 꽃은 결국 데이터 속에 숨겨진 통찰(Insight)을 찾아내는 것입니다. "어떤 상품이 가장 많이 팔렸지?", "부서별 평균 연봉은 얼마지?" 같은 질문에 답하는 과정이죠.오늘 소개할 Spark SQL과 집계 함수는 여러분에게 엑셀의 피벗 테이블, 혹은 그 이상의 강력한 분석 능력을 선사할 것입니다. 자, 시작해 볼까요?1. "나는 SQL이 더 편한데..." : Spark SQL의 마법많은 개발자와 데이터 분석가들에게 SQL은 모국어와 같습니다. PySpark의 함수(..

안녕하세요! 여러분의 데이터 요리사, 팬돌프입니다.지난 3편에서는 외부의 데이터를 가져와 DataFrame이라는 그릇에 예쁘게 담는 법을 배웠습니다. 하지만 현실의 데이터는 절대 깨끗하지 않죠. 필요 없는 컬럼이 잔뜩 있거나, 이상한 값이 섞여 있거나, 구멍(Null)이 숭숭 뚫려 있기 마련입니다.오늘은 이 원석 같은 데이터를 우리가 원하는 보석으로 다듬는 과정, 즉 데이터 랭글링(Data Wrangling)의 핵심 기술을 전수해 드립니다. 스파크 프로그래밍의 90%는 오늘 배우는 함수들로 이루어진다고 해도 과언이 아닙니다.준비되셨나요? 칼질을 시작해 봅시다!1. 스파크의 두 가지 움직임: 변환(Transformation)과 행동(Action)본격적인 코딩에 앞서, 스파크의 독특한 동작 방식을 다시 한번..

안녕하세요! 여러분의 데이터 엔지니어링 가이드, 팬돌프입니다.지난 시간, 우리는 도커(Docker)를 이용해 내 컴퓨터 안에 멋진 스파크 클러스터를 구축했습니다. 이제 엔진은 힘차게 돌아가고 있습니다. 그렇다면 이제 무엇을 태워야 할까요? 바로 데이터입니다.스파크를 처음 공부하시는 분들이 가장 많이 헷갈려 하는 것이 바로 RDD와 DataFrame의 차이입니다. "옛날 책에는 RDD를 쓰라던데, 요즘은 DataFrame을 쓰라네요?"결론부터 말씀드리면, "특수한 경우가 아니라면 RDD는 잊으셔도 좋습니다." 오늘 3편에서는 왜 우리가 DataFrame을 써야 하는지, 그리고 엑셀처럼 직관적이고 강력하게 데이터를 로딩하는 방법을 알아보겠습니다.1. RDD vs DataFrame: 스마트폰과 피처폰의 차이스..

안녕하세요! 여러분의 데이터 엔지니어링 멘토, 팬돌프입니다.지난 1편에서는 스파크가 왜 빅데이터 처리의 '게임 체인저'가 되었는지 이론적인 배경을 살펴보았습니다. "100배 빠르다"는 말에 가슴이 뛰셨나요?하지만 막상 스파크를 공부하려고 내 컴퓨터에 설치를 시도하다 보면, 그 설렘이 좌절로 바뀌는 경우가 많습니다. Java 버전을 맞추고, 환경 변수를 설정하고, 하둡 바이너리를 다운로드하는 과정이 '지옥의 문'처럼 느껴지기 때문이죠.그래서 오늘은 가장 깔끔하고, 가장 세련된 방법으로 단 5분 만에 내 로컬 PC에 완벽한 Spark 클러스터 환경을 구축하는 방법을 알려드리겠습니다. 바로 도커(Docker)를 이용해서 말이죠!1. 왜 Docker로 설치해야 하나요?과거에는 스파크를 공부하려면 리눅스 서버가 ..

안녕하세요! 여러분의 데이터 엔지니어링 여정을 함께하는 든든한 파트너, 팬돌프입니다.지난 시간까지 카프카(Kafka)를 통해 데이터를 실시간으로 수집하고 이동시키는 '데이터의 고속도로'를 건설했습니다. 데이터가 잘 흐르고 있다면, 이제 그 방대한 데이터를 씹고, 뜯고, 맛보고, 즐길 차례입니다.오늘부터 시작되는 [Apache Spark 완전 정복] 시리즈를 통해, 여러분은 현존하는 가장 강력한 분산 처리 엔진을 여러분의 무기로 만들게 될 것입니다. 그 첫 번째 시간, 스파크가 도대체 무엇이며 왜 전 세계 엔지니어들이 열광하는지 그 탄생 배경과 핵심 철학부터 차근차근 알아보겠습니다.1. 하둡(Hadoop)의 시대와 디스크 I/O의 병목빅데이터라는 단어가 세상에 처음 등장했을 때, 그 중심에는 하둡(Hado..