PE Notes · DB
빅데이터 도구 선정, Hadoop V3, 카파 아키텍처
처리 패턴·데이터 특성·확장·생태계·TCO 선정 원칙, Hadoop 3의 EC·다중 NameNode, 람다와 카파 비교를 정리합니다.
도구를 잘못 고르면 클러스터 비용과 운영 부채가 남습니다. Hadoop, Spark, Flink, Kafka는 같은 층이 아닙니다. 먼저 지연 허용과 데이터 모양을 적습니다.
선정 다섯 원칙
| 원칙 | 확인 |
|---|---|
| 처리 패턴 | 배치 / 스트림 / 혼합, 허용 지연 |
| 데이터 특성 | 정형 여부, 크기, 속도 |
| 확장성 | 수평 확장, 클러스터 비용 |
| 생태계 | 인력, 벤더, 커뮤니티 |
| TCO | 라이선스·운영, 매니지드 가능 여부 |
| 패턴 | 도구 예 |
|---|---|
| 대용량 배치 | MapReduce, Spark |
| 스트림 | Kafka + Flink |
| 둘 다 | Spark Structured Streaming |
| 대화형 SQL | Hive, Trino |
| 분산 학습 | Spark MLlib 등 |
Hadoop V3
Hadoop은 HDFS(저장) + 처리 엔진 + (자원)입니다. 1.x는 MapReduce와 단일 NameNode, 2.x는 YARN과 NameNode HA, 3.x는 저장 효율과 가용을 올립니다.
은 3중 복제(오버헤드 200%) 대신 데이터+패리티(예: 6+3, 오버헤드 약 50%)로 같은 내결함성을 노립니다. NameNode는 2대를 넘어 여러 대를 둘 수 있습니다. 스토리지 정책으로 핫은 SSD, 웜은 HDD, 콜드는 아카이브로 나눕니다. YARN은 컨테이너를 자원으로 받습니다.
람다와 카파
는 배치 레이어(정확, 느림)와 스피드 레이어(근사, 빠름)를 병렬로 두고 서빙에서 합칩니다. 로직이 두 벌이고 병합이 어렵습니다.
는 스트림 한 줄입니다. 로그에 원본을 남기고, 재처리는 처음부터 다시 재생합니다. 코드가 하나이고 지연은 초 단위에 가깝습니다.
| 축 | 람다 | 카파 |
|---|---|---|
| 레이어 | 배치+스피드+서빙 | 스트림+서빙 |
| 코드 | 두 벌 | 한 벌 |
| 재처리 | 배치 | 로그 재생 |
| 적합 | 배치가 필수 | 스트림으로 충분 |
실시간 대시보드와 작은 팀은 카파, 장기간 재집계가 업무 요건이면 람다를 남깁니다. 레이크하우스(Iceberg, Delta)가 둘 사이를 메우는 중입니다.
