경량 빅데이터 처리 기술

Source: Dev.to

전통적인 빅데이터 아키텍처의 단점

• 복잡한 운영·관리(O&M) – 클러스터가 클수록 운영 노력이 증가합니다. 현재의 빅데이터 기술은 하드웨어 자원을 충분히 활용하지 못해 과도한 규모의 클러스터가 필요하고, 유지보수 비용이 상승합니다.
• 폐쇄형 시스템 – 데이터를 처리하려면 먼저 데이터베이스에 적재해야 합니다. 이는 ETL 단계를 강제하게 되어 지연 시간이 늘어나고, 특히 데이터가 다수의 소스에서 유입될 때 실시간 처리 능력이 저하됩니다.
• 강한 결합 – 여러 애플리케이션이 동일한 테이블과 연산 로직을 공유하면 의존성이 강해집니다. 하나의 애플리케이션 변경이 다른 애플리케이션에 영향을 미쳐 확장·유지보수가 어려워지고, 용량 압박이 가중됩니다.

프론트엔드 연산 레이어

중앙 데이터센터에 부하가 걸릴 경우 연산의 일부를 애플리케이션 측으로 옮길 수 있습니다. 프론트엔드 연산 레이어는 각각 특정 유형의 애플리케이션에 전용된 여러 데이터 마트로 구성될 수 있습니다. 이 접근 방식은

• 데이터센터와 연산 부하를 공유합니다.
• 각 데이터 마트가 단일 목적을 수행하므로 애플리케이션 간 결합도를 낮춥니다.

다만, 이 레이어는 가볍고 운영이 쉬우며 비교적 작은 데이터 양을 처리할 수 있는 기술로 구축되어야 합니다.

전통적인 데이터베이스가 적합하지 않은 이유

1. 무거운 배포 – 대부분의 데이터베이스는 별도의 물리적 자원을 필요로 하여 전체 프레임워크의 복잡도와 비용이 증가합니다.
2. 데이터 범위 딜레마
   • 너무 작음: 데이터 마트가 애플리케이션 쿼리를 만족시키지 못합니다.
   • 너무 큼: 사실상 데이터센터가 되어 가벼운 레이어라는 목적을 상실합니다.
3. SQL 한계
   • 모든 데이터를 데이터베이스에 적재해야 하므로 비효율적입니다.
   • 복잡한 계산(예: 다단계 전자상거래 퍼널)을 수행하려면 Python이나 Java와 같은 외부 언어에 의존해야 합니다.
   • 수천 줄에 달하는 중첩된 SQL 스크립트는 작성·읽기·유지가 어렵습니다.

이러한 문제는 전통적인 데이터베이스뿐 아니라 SQL 인터페이스를 제공하는 많은 빅데이터 플랫폼에도 적용됩니다.

경량 처리 엔진에 대한 요구사항

• 데이터베이스 독립성 – 전체 RDBMS 배포가 필요 없습니다.
• 통합·임베디드 가능 – 애플리케이션에 패키징하여 사용할 수 있습니다.
• 단순하고 편리함 – 운영 부담이 최소화됩니다.
• 오픈·확장성 – 다수의 데이터 소스를 처리할 수 있어야 합니다.
• 데이터 범위 효율 처리 – 전체 데이터센터가 되지 않으면서 선택적 데이터 로딩을 지원합니다.

esProc SPL: 오픈소스 솔루션

esProc은 빅데이터를 위해 설계된 구조화 데이터 연산 엔진으로 다음과 같은 특성을 가집니다.

1. 경량 배포 – 독립 실행이 가능하거나 애플리케이션에 직접 임베드할 수 있어 시스템 복잡도가 감소합니다.
2. 높은 개방성 – 혼합 소스 연산을 지원해 다양한 출처의 데이터를 함께 처리할 수 있습니다.
3. 고성능 단일 노드 처리 – 단일 노드에서 하드웨어 활용도를 극대화하여 다수의 머신이 필요한 클러스터 수준 성능을 구현합니다.
4. 데이터 라우팅 – 필요에 따라 작업을 로컬에서 실행하거나 데이터센터에 위임할 수 있습니다.
5. 민첩한 SPL 문법 – Structured Process Language (SPL)는 간결하고 복잡한 계산에 적합해 중첩된 SQL의 장황함을 피합니다.

요컨대, esProc은 배포부터 실행까지 전 과정을 경량화한 솔루션을 제공합니다.

esProc의 기술 프레임워크

통합

• 임베드 모드 – esProc을 애플리케이션에 통합해 비즈니스 로직과 함께 계산을 수행함으로써 프레임워크 변경 및 운영·관리 부담을 최소화합니다.
• 독립 서비스 모드 – 추가 연산 능력이 필요할 경우 esProc을 독립 서비스로 배포합니다. 로드 밸런싱·장애 복구를 지원하는 분산 배포가 가능해 전통적인 빅데이터 클러스터의 오버헤드 없이 클러스터와 유사한 기능을 제공합니다.