왜 빅데이터 플랫폼이 SQL로 돌아오는가?

Source: Dev.to

배경

구조화된 데이터는 빅데이터 분석의 기본이다

빅데이터 플랫폼은 빅데이터 저장 및 분석에 대한 수요를 해결하는 데 초점을 맞춘다. 저장해야 할 방대한 데이터 중에는 비즈니스 활동에서 발생하는 구조화된 데이터 외에도 오디오, 비디오 등과 같은 비구조화된 데이터가 엄청나게 많으며, 이는 플랫폼 전체 데이터의 80 % 이상을 차지할 수 있다. 데이터를 저장하는 것은 빅데이터 플랫폼 목표의 한 부분일 뿐이며, 더 중요한 부분은 데이터를 분석하고 활용해 비즈니스 가치를 창출하는 것이다.

빅데이터 분석은 두 종류의 데이터를 다룬다: 구조화된 데이터와 비구조화된 데이터.

• 구조화된 데이터는 일상적인 비즈니스 운영 과정에서 생성되며 기업의 핵심 부분을 차지한다. 빅데이터 플랫폼이 등장하기 전에는 구조화된 데이터가 기업 정보 기반의 대부분—혹은 전부—를 차지했다. 비즈니스가 확장됨에 따라 데이터가 축적되고 기존 RDB 기반 처리 시스템에 부담을 주었다. 빅데이터 플랫폼은 이러한 도전에 대응하여 구조화된 데이터 분석 문제에 대한 솔루션을 제공했다.
• 비구조화된 데이터(로그, 이미지, 오디오, 비디오 등)는 종종 관련된 구조화된 속성을 추출하기 위해 처리된다—예를 들어 비디오의 경우 제작자, 날짜, 카테고리, 길이, 로그의 경우 사용자 IP, 접근 시간, 키워드 등. 따라서 비구조화된 데이터 분석은 주로 파생된 구조화된 데이터에 초점을 맞춘다.

그 결과, 구조화된 데이터 분석이 여전히 빅데이터 플랫폼에서 비즈니스 분석을 주도한다. 구조화된 데이터를 처리하기 위한 성숙한 기술—주로 SQL 기반의 관계형 모델 RDBMS—가 널리 사용된다.

SQL이 구조화된 데이터 처리 분야를 장악하다

빅데이터 분석에서 SQL 구문으로의 회귀는 명확한 트렌드다. Hadoop에서는 초기 PIG Latin이 사라지고 Hive가 남았으며, Spark에서는 SparkSQL이 Scala 기반 API보다 훨씬 널리 사용된다. 새로운 빅데이터 컴퓨팅 시스템도 계산에 SQL을 선호한다. 고대 언어가 다양한 도전자와의 수년간 경쟁 끝에 그 위치를 재확인하고 있다.

이 재부흥을 이끄는 두 가지 이유가 있다:

1. 더 나은 선택지가 아직 존재하지 않는다
   관계형 데이터베이스가 오랫동안 인기를 끌어온 덕분에 SQL은 개발자에게 “오래된 친구”가 되었다. SQL은 일반적인 쿼리에는 간단하지만 복잡한 절차적 혹은 순서 기반 계산에는 덜 편리하다. 대안 기술도 마찬가지로 복잡한 UDF나 맞춤 코드를 요구해 번거롭다. 두 가지 불편함에 직면했을 때, 많은 이가 익숙한 것을 선택한다.

2. SQL은 빅데이터 벤더들의 지지를 받고 있다
   벤더들은 높은 성능을 추구하고, SQL은 이해하고 평가하기 쉬운 잘 알려진 벤치마크(예: TPC‑H)를 제공한다. 이는 벤더들이 SQL 최적화에 집중하도록 만든다.

SQL 호환 플랫폼은 마이그레이션 친화적이다

SQL 호환 플랫폼의 장점은 명확하다:

• SQL은 널리 알려져 있어 교육 비용을 절감한다.
• 수많은 프론트‑엔드 도구가 이미 SQL을 지원하므로 통합이 간단하다.
• 기존 SQL 기반 데이터베이스와의 호환성은 마이그레이션을 용이하게 하고 비용을 낮춘다.

하지만 이러한 이점은 SQL의 단점을 감수해야 한다는 대가를 동반한다.

문제점

낮은 성능

SQL을 사용할 때 가장 큰 문제는 빅데이터 컴퓨팅에 요구되는 높은 성능을 달성하는 데 가장 효율적인 수단이 아니라는 점이다.

• SQL은 특정 고성능 계산을 위한 데이터 타입과 정의가 부족해 실행 엔진의 엔지니어링 최적화에 크게 의존한다.
• 수십 년간의 경험을 통해 상용 데이터베이스에는 풍부한 최적화 기법이 축적되었지만, 많은 빅데이터 시나리오는 여전히 최적화가 어렵다.
• SQL은 절차적 계산을 표현하거나 최적 실행 경로를 지정하는 데 적합하지 않다. 고성능 알고리즘에 필수적인 최적 경로를 구현하려면 많은 특수 수정자가 필요하고, 절차적 구문이 더 직관적일 수 있다.

역사적으로 SQL은 제한된 하드웨어를 염두에 두고 설계되었다. 이러한 설계 제약은 대용량 메모리, 대규모 병렬성, 클러스터 메커니즘 등 현대 하드웨어 기능을 충분히 활용하기 어렵게 만든다. 성능과 관련된 제한 사례는 다음과 같다:

• JOIN 연산 – 전통적인 SQL JOIN은 키 값을 기준으로 레코드를 매칭하며, 종종 해시 계산을 사용한다. 대용량 메모리 환경에서는 주소 기반 매칭이 훨씬 빠를 수 있다.
• 정렬되지 않은 테이블 – 단일 테이블 연산은 파티셔닝을 통해 병렬화할 수 있지만, 여러 테이블에 걸친 동적 분할(예: 다중 테이블 JOIN)은 어려워 정적 세분화가 필요하고 이는 유연한 스레드 할당을 방해한다.
• 클러스터 컴퓨팅 – SQL은 차원 테이블과 사실 테이블을 구분하지 않으며, JOIN을 필터링된 카테시안 곱으로 정의한다. 대형 테이블 JOIN은 비용이 큰 해시 셔플을 유발해 네트워크 대역폭을 소모하고 클러스터 확장의 이점을 감소시킨다.

예시

10억 건 레코드가 있는 테이블에서 상위 10개 행을 조회하려면:

SELECT TOP 10 x, y
FROM T
ORDER BY x DESC;

ORDER BY 절은 전체 테이블 정렬을 강제하므로 이 규모에서는 매우 느리다. 전체 정렬을 피하는 알고리즘을 설계할 수 있지만, SQL은 이를 직접 표현할 수 없으며 데이터베이스 옵티마이저가 효율적인 계획을 찾아야 한다.