1) 초기 빅데이터 플랫폼
기존에는 원천 데이터, 파생 데이터, 서빙 데이터로 나누어져 있었다.
원천 데이터를 특정 프로세싱을 통해서 파생 데이터로 만들어서 운영하였다.
파생 데이터를 바탕으로 애플리케이션에서 사용할 수 있도록 서빙 데이터로 만들어서 적재하여 활용하였다.
위의 방식은 End-to-End로 각 서비스 애플리케이션으로부터 데이터를 배치로 모으고, 복잡한 데이터 파이프라인을 운영해야 했다.
데이터를 배치로 모으는 구조는 유연하지 못하였고 실시간으로 생성되는 데이터들에 대한 인사이트를 서비스 애플리케이션에 빠르게 전달하지 못하는 단점이 있었다.
원천 데이터로부터 파생된 데이터의 히스토리 또한 파악하기 어려워 데이터가 파편화되면서 데이터의 거버런스, 즉 표준과 정책을 지키기 어려웠다.
2) 람다(Lambda) 아키텍처
크게 3가지 레이어로 나뉜다. (배치 레이어, 서빙 레이어, 스피드 레이어)
배치 레이어: 배치 데이터를 모아서 특정 시간 그리고 타이밍마다 일괄 처리한다.
서빙 레이어: 배치 레이어와 스피드 레이어에서 만들어진 데이터를 데이터 사용자와 서비스 애플리케이션이 사용할 수 있도록 데이터가 저장된 공간
스피드 레이어: 서비스에서 생성되는 원천 데이터를 실시간으로 분석하는 용도로 사용함. 카프카가 이 위치에 있다고 보면 된다.
기본적으로 배치 데이터를 배치 레이어에서 활용하되 추가적으로 낮은 레이턴시로 데이터를 빠르게 분석하여서 애플리케이션 단위로 넘어갈 때는 스피드 레이어에 위치한 카프카를 활용하는 방법으로 데이터를 활용하였다.
기본적으로 여러 IT 기업에서도 이런 방식으로 많이 활용하곤 한다.
기본적으로 배치로 오는 1단위 혹은 시간 단위 데이터의 경우, 데이터 매니지먼트 도구(ex. Airflow)를 통해서 데이터를 각각 순차적으로 처리해야 될 경우도 있고,
혹은 빠르게 데이터를 처리할 경우 AWS에서는 Kinesis나 MSK나 카프카와 같은 스트리밍 데이터 도구를 사용해서 데이터를 처리할 수 있게 한다.
람다 아키텍처의 한계
데이터 처리 방식을 명확히 나눌 수 있었지만 레이어가 2개로 나뉘어서 생기는 단점이 있다.
- 데이터를 분석 처리하는데 필요한 로직이 2벌로 각각의 레이어에 따로 존재해야 한다.
- 배치 데이터와 실시간 데이터를 융합하여 처리할 시 유연하지 못한 파이프라인을 생성해야 한다.
기업에서 람다 아키텍처를 운영할 시, 배치 레이어에 적합한 코드 프레임워크를 활용하고
스피드 레이어는 스트림 파이프라인 아키텍처에 맞는 프레임워크를 선정해서 별개로 운영하는 것이 일반적이다.
