SQL 사용 없이 데이터 웨어하우스
Source: Dev.to
현재 대부분의 데이터 웨어하우스는 데이터를 처리하기 위해 SQL을 사용합니다. 수십 년에 걸친 개발을 거치면서 SQL은 데이터베이스 세계의 표준 언어가 되었고 방대한 사용자 기반을 확보했기 때문에, 데이터 웨어하우스가 SQL을 지원하는 것은 당연합니다. 그러나 현대 빅데이터 환경에서는 비즈니스 복잡성이 계속 증가하고 있으며, 계산이 주요 작업인 데이터‑웨어하우스 시나리오에서 SQL의 능력이 점점 부족해 보입니다. 전형적인 사례로 일부 데이터 웨어하우스가 Python과 같은 비‑SQL 언어를 통합하기 시작한다는 점을 들 수 있습니다. 업계가 SQL의 역량에 의문을 품고 있다는 점이 명확합니다.
이 글에서는 비‑SQL 기반 데이터 웨어하우스 esProc을 소개합니다. esProc은 쿼리 언어로 SQL이 아닌 SPL을 사용하므로, 새로운 유형의 데이터 웨어하우스로 볼 수 있습니다.
왜 esProc은 SQL을 사용하지 않을까?
절차적·순차적 계산 부족
SQL은 절차적 계산을 지원하는 데 한계가 있습니다. CTE 구문을 사용하더라도 복잡한 계산을 SQL로 기술하는 것은 번거롭고 종종 깊게 중첩된 쿼리를 필요로 합니다. 또한 SQL은 데이터셋을 무순서(unordered)로 취급하기 때문에, 순차적인 계산을 수행하기 어렵거나 불가능합니다.
예를 들어 전자상거래 기업의 퍼널 분석(각 단계별 사용자 이탈 계산: 페이지 조회 → 장바구니 추가 → 주문 → 결제)과 같은 전형적인 데이터 분석 작업은 단계별·순차적 계산을 지원하는 언어(예: Python 또는 SPL)로 구현하는 것이 훨씬 쉽습니다.
관계형 데이터베이스의 폐쇄성
관계형 데이터베이스는 주로 트랜잭션 처리(TP)를 위해 설계되었습니다. 엄격한 제약을 강제합니다: 기준을 만족하는 데이터만 로드할 수 있고, 데이터베이스 내부에 있는 데이터만 처리할 수 있습니다. 이러한 “폐쇄성”은 TP에는 유리하지만 분석 처리(AP)에는 단점이 됩니다.
- 다중 소스 계산 – 여러 데이터베이스의 데이터를 자유롭게 결합할 수 없어 웨어하우스 활용 사례가 제한됩니다.
- ETL 오버헤드 – 현대 애플리케이션은 파일, 스트림, NoSQL 스토어 등 다양한 데이터 소스를 수집합니다. 데이터베이스가 저장소 외부의 데이터를 계산할 수 없기 때문에 먼저 데이터를 가져와야 하며, 이는 ETL 단계를 추가하고 개발자 작업량을 늘리며 실시간 신선도를 잃게 합니다.
- 시간‑대‑공간 트레이드오프 – 중간 결과 테이블을 중복 저장하면 쿼리 성능이 향상될 수 있지만, SQL은 데이터를 테이블에 강제합니다. 수천 개의 중간 테이블을 유지하면 메타데이터가 팽창하고 운영·유지보수 비용이 증가하며 용량·확장성 문제가 발생합니다.
성능 제한
SQL 성능은 데이터베이스 옵티마이저에 크게 좌우됩니다. 단순한 쿼리에서는 옵티마이저가 효율적인 실행 계획을 선택할 수 있지만, 계산이 어느 정도 복잡해지면 옵티마이저가 문자 그대로 실행으로 전환되어 급격한 성능 저하가 발생합니다. 퍼널 분석 예시는 실용적으로 사용하기에 너무 느리게 실행되는 경우가 많으며, 배치 작업은 몇 시간씩 걸릴 수 있습니다.
SQL 기반 웨어하우스에 Python을 추가할 때의 문제점
Python과 같은 서드파티 언어를 도입하면 기술 스택이 복잡해집니다:
- 개발·운영 비용 증가 – 서로 다른 패러다임을 가진 여러 언어를 관리하면 복잡성이 상승합니다.
- 빅데이터 지원 제한 – Python은 메모리 용량을 초과하는 데이터를 처리하기 위한 기본 메커니즘(예: 커서)을 제공하지 않아 대규모 계산이 번거롭습니다.
- 비효율적인 병렬 처리 – Python의 전역 인터프리터 락(GIL) 때문에 진정한 다중 스레드 CPU 병렬 처리가 불가능하며, 병렬 실행이 오히려 직렬보다 느릴 수 있습니다.
- I/O 오버헤드 – Python은 폐쇄형 데이터베이스에서 데이터를 읽어야 하므로 추가 I/O 비용이 발생하고 성능이 더욱 저하됩니다.
- 스토리지 개입 불가 – 고성능 알고리즘(예: 순차 병합)에는 데이터 레이아웃에 대한 직접 제어가 필요하지만, 데이터가 폐쇄형 관계형 저장소에 있으면 이를 구현할 수 없습니다.
결론
SQL 기반 데이터 웨어하우스는 다음 세 가지 핵심 문제를 안고 있습니다:
- 절차적·순차적 계산 기능 부족
- 유연한 데이터 통합을 방해하고 ETL/ELT 부담을 증가시키는 폐쇄성
- 중간 정도 복잡도의 분석 워크로드에서 성능 저하
Python을 추가한다고 해서 이러한 문제들이 해결되는 것은 아니며, 오히려 복잡성과 성능 제약을 추가합니다. esProc은 SQL을 포기하고 SPL을 채택함으로써 이러한 과제를 해결하고, 현대 데이터‑웨어하우스 분석에 보다 유연하고 개방적이며 고성능인 환경을 제공합니다.