2017.04.11

구글 빅쿼리, 하둡 SQL 최대 약점 '동시 실행' 대안 될까

Thor Olavsrud | CIO
빅데이터에서 BI(Business Intelligence) 작업을 처리하는 과정에서 다수의 동시 쿼리(Query) 기능이 중요한 기업이라면 구글 빅쿼리(Google BigQuery)를 테스트해 보는 것이 좋은 대안이다.



빅데이터내 BI를 지원하는 스타트업 '앳스케일(AtScale)'이 지난 6일 공개한 새로운 벤치마크 결과를 보면 빅쿼리의 최대 강점은 동시 실행인 것으로 나타났다. 소규모 데이터 세트에서의 동시 쿼리에서 성능 저하가 없었고 25명 이상의 동시 BI 사용자를 설정한 쿼리에서도 마찬가지였다.

앳스케일의 제품관리 부사장 조시 클레어에 따르면, 그동안 하둡 SQL(SQL-on-Hadoop)의 아킬레스건은 단연 '동시 실행'이었다. 그는 "그러나 빅쿼리는 달랐다. 성능 뿐만 아니라 사용자 경험도 훌륭했다. 구글이 수 년동안 소비자용 제품에 크게 집중했다는 점을 고려하면 놀랄 일이 아닐 수도 있지만 기대 이상이었다. 실제 작업에서는 우리의 로컬 네트워크에서 클라우드로 데이터를 로딩하는 데 가장 많은 시간이 걸렸다. 일단 데이터가 있으면 테이블 작성이 정말 쉬웠다”라고 말했다.

구체적인 벤치마크 과정은 지난 해 BI 작업 부하에 대한 하둡 SQL 엔진 벤치마크 테스트와 같은 모델을 사용했다. 이 테스트는 IT 전문가가 자신의 BI 활용 사례에 맞춰 가장 좋은 하둡 SQL 기술을 선택할 수 있도록 돕기 위한 것이다. 구글 빅쿼리 벤치마크도 같은 목적으로 진행됐다.

CR(Constellation Research)의 부사장겸 수석 애널리스트인 헨쉔은 “앳스케일 벤치마크는 기업 리더가 빅데이터에 BI를 활용하는 데 필요한 유용한 비교를 제공한다. 데이터가 더 복잡하고 다양해지면서 이런 벤치마크 통계가 기업이 주요 빅데이터 쿼리 선택사항을 파악하고 BI 인프라 지원에 필수적인 더 나은 결정을 내리는 데 도움이 된다"라고 말했다.

앳스케일 테스트팀은 널리 사용하는 TPCH 데이터에 기초해 일반적인 BI 지향 데이터 레이아웃을 더 정확하게 표현하기 위해 수정된 SSB(Star Schema Benchmark) 데이터 세트를 사용했다. 이 데이터 세트를 통해 대형 테이블에서 쿼리를 테스트할 수 있었다. 라인오더(Lineorder) 테이블에는 약 60억 줄이 포함돼 있으며 대기업 고객 테이블에는 10억 줄 이상이 포함돼 있다.

앳스케일은 구글 빅쿼리 벤치마크를 위해 지난 해 하둡 SQL 엔진과 BI 작업 부하 충족 적합성을 평가하기 위해 사용했던 3가지 핵심 요건을 검토했다.

- 빅데이터에서 수행하다. 하둡 SQL 엔진은 오류를 생성하지 않고 수 십억 또는 수 조 줄의 데이터를 일관되게 분석할 수 있으면서 명령 응답 시간이 수십 분의 또는 수백 분의 1초여야 한다.
- 소규모 데이터에서 빠르다. 이 엔진은 알려진 쿼리 패턴에 대해 상호적인 성능을 제공해야 하며 하둡 SQL 엔진이 (수천 또는 수백만 줄의 명령에서) 소규모 데이터 세트에 대해 수초 만에 결과를 반환해야 한다.
- 많은 사용자에게 안정적이다. 기업 BI 사용자 기반은 수백 또는 수천 명의 데이터 노동자로 구성돼 있다. 기반이 되는 하둡 SQL 엔진은 높은 동시 분석 작업 부하에서 반드시 신뢰할 수 있는 성능을 제공해야 한다.

지난해 벤치마크에서는 하둡 SQL 엔진인 아파치 임팔라(Apache Impala) 2.3, 아파치 스파크(Apache Spark) 1.6, 아파치 하이브(Apache Hive) 1.2가 모두 저마다의 장단점이 있었기 때문에 구체적인 BI 활용 사례에 따라 적합성이 갈렸다. 예를 들어, 하이브는 가장 느린 엔진으로 상호형 쿼리에는 적합하지 않았지만 현재까지 가장 안정적인 엔진이며 복수의 쿼리 유형에서 일관성이 가장 뛰어나다. 임팔라와 스파크는 더 작은 규모의 데이터 세트에 적합했다.


클레어가 밝힌 것처럼 빅쿼리의 가장 큰 장점은 동시 실행지원이다. 또한 사용에 앞서 튜닝 또는 시스템 구성을 크게 신경쓰지 않아도 됐다. 그는 "빅쿼리는 튜닝이 크게 필요 없으며 툴링도 거의 불가능하다. 반면 하이브, 임팔라, 스파크 SQL 등은 각 엔진의 파라미터를 제대로 설정하기까지 수일에서 수주가 걸릴 수 있다"라고 말했다.

앳스케일은 빅쿼리 관리 콘솔, 쿼리 툴, 문서화 덕분에 사용이 쉽고 신속하며 적응이 가능하다는 점도 높이 평가했다. 또한 데이터를 구글 클라우드로 이동하고 빅쿼리로 로딩하는 과정이 쉽고 문서화가 잘 돼 있었다. 단, 클레어는 이 과정이 구내 데이터보다는 클라우드 태생의 데이터에서 분명 더 빠르다고 밝혔다.

클레어에 따르면 빅쿼리는 성능 측면에서 임팔라나 스파크 SQL에 못미쳤지만 비슷한 수준이었다. 그는 "어떤 솔루션을 사용할 것인지 결정하려면 성능을 높이기 위해 필요한 노력과 용인 가능한 성능을 얻기 위해 걸리는 시간을 모두 고려해야 한다"라고 말했다. 단, 빅쿼리가 다른 기술보다 크게 뒤지는 부분은 조인(Join)이었다. 클레어는 "대규모 조인을 제대로 처리하지 못했다. (구글이) 모든 데이터가 하나의 테이블에 위치하는 집합적인 데이터 구조를 활발하게 홍보하는 것도 이 때문이다"라고 말했다.

최근의 벤치마크 결과를 보면 빅데이터 시장의 성숙도와 구글 같은 플랫폼 업체가 기업이 추가할 수 있는 실행 가능한 솔루션이 됐음을 알 수 있다.

앳스케일의 CTO 겸 공동설립자 맷 베어드는 "이번 벤치마크 결과는 빅데이터 시장의 빠른 발전 속도를 나타낸다. 기업은 이미 하둡 사용 여부, 빅쿼리 사용 여부, 구글 하둡, 클라우드 하둡, 구글의 서버리스 모델 사이의 차이점 등 상당한 복잡한 문제에 직면해 이를 따라잡기 벅찬 상황이다. 우리가 앳스케일을 설립한 것도 이런 어려움을 함께 해결해보자는 취지였다"라고 말했다. ciokr@idg.co.kr



2017.04.11

구글 빅쿼리, 하둡 SQL 최대 약점 '동시 실행' 대안 될까

Thor Olavsrud | CIO
빅데이터에서 BI(Business Intelligence) 작업을 처리하는 과정에서 다수의 동시 쿼리(Query) 기능이 중요한 기업이라면 구글 빅쿼리(Google BigQuery)를 테스트해 보는 것이 좋은 대안이다.



빅데이터내 BI를 지원하는 스타트업 '앳스케일(AtScale)'이 지난 6일 공개한 새로운 벤치마크 결과를 보면 빅쿼리의 최대 강점은 동시 실행인 것으로 나타났다. 소규모 데이터 세트에서의 동시 쿼리에서 성능 저하가 없었고 25명 이상의 동시 BI 사용자를 설정한 쿼리에서도 마찬가지였다.

앳스케일의 제품관리 부사장 조시 클레어에 따르면, 그동안 하둡 SQL(SQL-on-Hadoop)의 아킬레스건은 단연 '동시 실행'이었다. 그는 "그러나 빅쿼리는 달랐다. 성능 뿐만 아니라 사용자 경험도 훌륭했다. 구글이 수 년동안 소비자용 제품에 크게 집중했다는 점을 고려하면 놀랄 일이 아닐 수도 있지만 기대 이상이었다. 실제 작업에서는 우리의 로컬 네트워크에서 클라우드로 데이터를 로딩하는 데 가장 많은 시간이 걸렸다. 일단 데이터가 있으면 테이블 작성이 정말 쉬웠다”라고 말했다.

구체적인 벤치마크 과정은 지난 해 BI 작업 부하에 대한 하둡 SQL 엔진 벤치마크 테스트와 같은 모델을 사용했다. 이 테스트는 IT 전문가가 자신의 BI 활용 사례에 맞춰 가장 좋은 하둡 SQL 기술을 선택할 수 있도록 돕기 위한 것이다. 구글 빅쿼리 벤치마크도 같은 목적으로 진행됐다.

CR(Constellation Research)의 부사장겸 수석 애널리스트인 헨쉔은 “앳스케일 벤치마크는 기업 리더가 빅데이터에 BI를 활용하는 데 필요한 유용한 비교를 제공한다. 데이터가 더 복잡하고 다양해지면서 이런 벤치마크 통계가 기업이 주요 빅데이터 쿼리 선택사항을 파악하고 BI 인프라 지원에 필수적인 더 나은 결정을 내리는 데 도움이 된다"라고 말했다.

앳스케일 테스트팀은 널리 사용하는 TPCH 데이터에 기초해 일반적인 BI 지향 데이터 레이아웃을 더 정확하게 표현하기 위해 수정된 SSB(Star Schema Benchmark) 데이터 세트를 사용했다. 이 데이터 세트를 통해 대형 테이블에서 쿼리를 테스트할 수 있었다. 라인오더(Lineorder) 테이블에는 약 60억 줄이 포함돼 있으며 대기업 고객 테이블에는 10억 줄 이상이 포함돼 있다.

앳스케일은 구글 빅쿼리 벤치마크를 위해 지난 해 하둡 SQL 엔진과 BI 작업 부하 충족 적합성을 평가하기 위해 사용했던 3가지 핵심 요건을 검토했다.

- 빅데이터에서 수행하다. 하둡 SQL 엔진은 오류를 생성하지 않고 수 십억 또는 수 조 줄의 데이터를 일관되게 분석할 수 있으면서 명령 응답 시간이 수십 분의 또는 수백 분의 1초여야 한다.
- 소규모 데이터에서 빠르다. 이 엔진은 알려진 쿼리 패턴에 대해 상호적인 성능을 제공해야 하며 하둡 SQL 엔진이 (수천 또는 수백만 줄의 명령에서) 소규모 데이터 세트에 대해 수초 만에 결과를 반환해야 한다.
- 많은 사용자에게 안정적이다. 기업 BI 사용자 기반은 수백 또는 수천 명의 데이터 노동자로 구성돼 있다. 기반이 되는 하둡 SQL 엔진은 높은 동시 분석 작업 부하에서 반드시 신뢰할 수 있는 성능을 제공해야 한다.

지난해 벤치마크에서는 하둡 SQL 엔진인 아파치 임팔라(Apache Impala) 2.3, 아파치 스파크(Apache Spark) 1.6, 아파치 하이브(Apache Hive) 1.2가 모두 저마다의 장단점이 있었기 때문에 구체적인 BI 활용 사례에 따라 적합성이 갈렸다. 예를 들어, 하이브는 가장 느린 엔진으로 상호형 쿼리에는 적합하지 않았지만 현재까지 가장 안정적인 엔진이며 복수의 쿼리 유형에서 일관성이 가장 뛰어나다. 임팔라와 스파크는 더 작은 규모의 데이터 세트에 적합했다.


클레어가 밝힌 것처럼 빅쿼리의 가장 큰 장점은 동시 실행지원이다. 또한 사용에 앞서 튜닝 또는 시스템 구성을 크게 신경쓰지 않아도 됐다. 그는 "빅쿼리는 튜닝이 크게 필요 없으며 툴링도 거의 불가능하다. 반면 하이브, 임팔라, 스파크 SQL 등은 각 엔진의 파라미터를 제대로 설정하기까지 수일에서 수주가 걸릴 수 있다"라고 말했다.

앳스케일은 빅쿼리 관리 콘솔, 쿼리 툴, 문서화 덕분에 사용이 쉽고 신속하며 적응이 가능하다는 점도 높이 평가했다. 또한 데이터를 구글 클라우드로 이동하고 빅쿼리로 로딩하는 과정이 쉽고 문서화가 잘 돼 있었다. 단, 클레어는 이 과정이 구내 데이터보다는 클라우드 태생의 데이터에서 분명 더 빠르다고 밝혔다.

클레어에 따르면 빅쿼리는 성능 측면에서 임팔라나 스파크 SQL에 못미쳤지만 비슷한 수준이었다. 그는 "어떤 솔루션을 사용할 것인지 결정하려면 성능을 높이기 위해 필요한 노력과 용인 가능한 성능을 얻기 위해 걸리는 시간을 모두 고려해야 한다"라고 말했다. 단, 빅쿼리가 다른 기술보다 크게 뒤지는 부분은 조인(Join)이었다. 클레어는 "대규모 조인을 제대로 처리하지 못했다. (구글이) 모든 데이터가 하나의 테이블에 위치하는 집합적인 데이터 구조를 활발하게 홍보하는 것도 이 때문이다"라고 말했다.

최근의 벤치마크 결과를 보면 빅데이터 시장의 성숙도와 구글 같은 플랫폼 업체가 기업이 추가할 수 있는 실행 가능한 솔루션이 됐음을 알 수 있다.

앳스케일의 CTO 겸 공동설립자 맷 베어드는 "이번 벤치마크 결과는 빅데이터 시장의 빠른 발전 속도를 나타낸다. 기업은 이미 하둡 사용 여부, 빅쿼리 사용 여부, 구글 하둡, 클라우드 하둡, 구글의 서버리스 모델 사이의 차이점 등 상당한 복잡한 문제에 직면해 이를 따라잡기 벅찬 상황이다. 우리가 앳스케일을 설립한 것도 이런 어려움을 함께 해결해보자는 취지였다"라고 말했다. ciokr@idg.co.kr

X