데이터이야기
DB 노하우, 데이터직무, 다양한 인터뷰를 만나보세요.
SQL on Hadoop
함윤식 (hys17445@naver.com) “SQL On Hadoop”이라는 다소 생소한 개념을 이해하기 위해서는 관련된 용어를 사전에 정리할 필요가 있다. 필자는 IT업계에서 많이 사용하는 “플랫폼”과 “에코”라고 하는 용어에 대해서 먼저 정리하고 이를 “SQL On Hadoop”의 개념과 연결시키고자 한다. “플랫폼’의 사전적 의미는 “역사” 또는 “기차역”의 의미이다. 우리에게 친숙한 서울역을 잠시 떠올려 보자. 서울역에는 수 많은 사람들이 모이지만 그 목적을 살펴 보면 기차를 중심으로 차를 타는 사람들과 차를 내리는 사람들로 나눌 수 있다. 경영학에서는 이런 매개시장을 ‘양면시장’이라고 칭하는데 플랫폼은 이와 같이 양면시장. 즉, Sell Side와 Buy Side라는 두 개의 시장을 매개하는 역할을 지칭하는 용어로 사용되고 있다. “플랫폼”은 이러한 공급자와 서비스이용자 2개의 시장을 매개하는 “양면시장”과 3개 이상의 시장을 매개하는 “다면시장”으로 구분할 수 있다. 가. 하둡의 문제점 가. SQL On Hadoop의 주요 기술 SQL On Hadoop도 다른 솔루션들과 마찬가지로 산업 니즈에 따라 몇 개 갈래로 나뉘어 개발되고 있으며 크게 두 가지 유형으로 나뉜다., 아직 시장이 넓지 않고(특히 국내에서) 지속적으로 개발 중이라 발전의 방향은 예측이 불가하지만 국내에서는 DW(Data Warehouse)형이 선호되는 추세이다. SQL on Hadoop
現 아이리포 기술사회, 정보관리기술사
1.SQL On Hadoop의 개념
다면시장의 대표적인 사례로는 “구글의 모바일 플랫폼”을 들 수 있다. 구글의 모바일 플랫폼은 앱을 개발하는 개발자와 앱을 사용하는 사용자와 광고주 등 크게 3개의 시장을 매개하는 다면시장 구조이다. 다음은 ‘에코’라는 하는 용어를 이해해야 한다. ‘서울역’으로 되돌아 가자. 기차를 타고 내리는 플랫폼 주변에는 필수적으로 여행객들을 위한 tool들이 존재한다. 음식점, 쉼터 등 편의시설과, 세계 주요국 언어로 된 안내표지판, 접근성을 높이기 위한 대중교통과의 연계도 제공한다. 이러한 플랫폼 이용을 편리하고 효율적으로 이용할 수 있도록 제공하는 환경을 통칭하여 ‘에코’라고 이해하면 쉽게 개념이 잡힐 것이다.
“Hadoop”은 플랫폼에 매칭되는 개념이다. 하둡은 빅데이터를 지원하는 대표적인 플랫폼으로서 빅데이터를 분산 저장하는 ‘HDFS’ 파일시스템과 빅데이터를 분산 처리/분석하는 ‘RapReduce’로 구성되어 있다. 즉 아파치의 하둡은 빅데이터의 저장 및 처리를 값싸고 빠르게 잘 지원해 주는 플랫폼이고, 이 플랫폼을 중심으로 개발자와 서비스공급자, 사용자들이 모인다. 그리고 “SQL On Hadoop”은 에코에 매칭되는 개념으로서 Hadoop의 MapReduce가 기존 개발자들이 사용하기에 익숙치 않고 다소 불편한 점들을 해소하기 위해 다루기 손쉬운 SQL문으로 하둡에서 빅데이터를 처리할 수 있도록 지원하는 솔루션이다. 이러한 SQL을 지원하는 하둡과 에코 시스템들의 집합을 “SQL On Hadoop”이라고 통칭한다. 즉, HDFS에 저장된 데이터를 SQL문으로 처리할 수 있게 한 솔루션으로 ‘탈 MapReduce 모델’을 지원하는 에코 시스템을 “SQL On Hadoop”이라고 정의할 수 있다.
2 .Hadoop의 문제점 및 SQL on Hadoop 아키텍처
하둡은 대용량 분석을 위한 플랫폼이므로 배치 프로세싱에 최적화되어 있고 설치와 사용이 어려워 관련 엔지니어 확보가 쉽지 않다. 그래서 이러한 하둡의 기능을 보완하기 위한 다양한 에코시스템들이 존재하며, 대표적인 것으로는 Flume, chuckwa, Scribe 등이 있다. 특히 하둡의 MapReduce는 데이터분석가 또는 기존 개발자에게 낯선 스크립트 형식이고 관계형 DB 처리를 위해 고안된 것이 아니기 때문에 데이터 처리 모델상 한계가 존재하여, 이를 보완해줄 에코시스템이 필요하다. 그러나, 대표적인 초기 “SQL On Hadoop”라 볼 수 있는 Pig나 Hive는 SQL을 MapReduce로 변환하여 실행하는 것이기 때문에 MapReduce가 제공하는 기능 이상의 확장이 불가능하고 대용량 배치작업을 위해 설계되었기 때문에 초기화 및 스케줄링 시간이 느려 성능보장에도 어려움이 존재하며 개발 노력이 많이 든다는 단점이 있다.
하지만 이후 개발되고 있는 “SQL On Hadoop”들은 보다 확장된 SQL문이나 함수 등으로 낮은 사용성을 극복하고 또한 각종 부가 기능을 제공하거나, 별도 처리 엔진을 두는 등 의 처리성능을 높였으며, BI와 같은 데이터 분석 솔루션들과도 연동이 용이하다.
나. SQL on Hadoop의 아키텍처
- SQL on Hadoop 아키텍처는 마스터 슬레이브 구조를 적용하였고 마스터에 문제 발생시에도 작업의 연속적인 수행을 위해 슬레이브에 각 질의작업 별 실행을 관리하는 쿼리마스터를 제공한다.
다. SQL on Hadoop 아키텍처의 구성요소
3. SQL On Hadoop 에 필요한 기술
작업량이 큰 하나의 연산을 다수의 장치에 나누어 처리하는 것이 매우 효과적이기는 하지만 주어진 시간 내 원하는 결과를 만들고 그 결과값의 정확성을 보장하기 위해서는 몇 가지 반드시 필요한 기술들이 있다. 먼저 분산처리의 핵심기능을 담당하는 쿼리마스터는 작업완료라는 임무를 완수하기 위해 소속된 클러스터의 내고장성(Fault Tolerance, 장애허용)을 보장해야 한다.
수 시간 이상 소요되는 한 개의 질의(Long time query, Master server)가 다수개의 개별질의(distributed query, Slave server)로 나누어 동시에 실행될 때는 각 질의 중간중간 생성되는 데이터 또는 중간결과들의 병합 또는 추가 연산이 필요하며, 서로서로 연관성이 있는 한 덩어리의 대용량 데이터가 개별 질의가 필요한 부분별로 조각 내어 사용하거나 또는 한 데이터에 동시에 여러 개의 질의가 접근하여 사용하므로 쿼리마스터는 개별 질의의 수행중간에 수 없이 개입해야 한다.
개별질의가 오류를 발생했다면, 해당 오류를 처리하고 전체 작업은 계속 진행시킬 수 있어야 하며, 전체 데이터 중 필요데이터를 구분하여 마스터서버에 할당 요청하고, 수행이 끝난 개별질의의 결과를 다음 질의의 입력값으로 처리하는 것도 쿼리 마스터의 몫이다. 클러스터의 효율을 높이기 위해 개별질의로 나눌 때 조인, 정렬, 병합 등 데이터 처리방법을 변환하기도 하고, 고정 로드밸런싱 보다는 동적 로드밸런싱을 적용하는데, 이는 초기에 스케줄링을 끝내고 슬레이브에 할당하는 것이 아니라, 한번에 한 개의 작업을 할당한 후 완료하면 다시 다음작업을 할당하는 것으로 쉬는 슬레이브 서버가 없도록 하는데 효과적이다. 여기까지 언급된 스킬들은 대부분 쿼리마스터의 역할이기 때문에 쿼리마스터가 열심히 위 작업들을 수행할수록 성능과는 반비례관계가 될 수 밖에 없다. 가용성은 마스터서버, 쿼리마스터 등의 fail over 설계와 슬레이브 서버를 쿼리마스터가 잘 관리함으로써 해결한다고 치고, 솔루션의 성패를 좌우하는 성능 부분을 좀 더 살펴보자.
나. SQL On Hadoop의 성능보장을 위한 고려사항
위에서 설명했듯이 Hadoop의 언어는 관계형 DB나 SQL문이 아니다. 온라인 비즈니스를 지원하기 위해 설계된 것도 아니기 때문에 대부분의 작업은 배치작업일 것이며, HDFS의 데이터를 대부분 Full Scan하여 질의를 처리할 것이다. Hadoop에서의 데이터 처리의 핵심은 어떤 데이터를 어디에 배치하고 인덱스를 어떻게 구성할 것이냐가 아니라, 어떤 형태로 저장하고 어떻게 가져다 쓸 것이냐가 된다. 데이터를 읽기만 한다면 ORC file을 사용하면 되지만, 그렇지 않다면 read/write 방식, 횟수, 한번에 작업하는 양 등 질의나 작업의 특성에 따라 적절한 파일 포멧을 선택하는 것이 중요하다.
전통적인 Text file 이나 seq file 외, 최근에는 컬럼 기반인 RCF file이나 Parquet 등 선택의 폭이 넓어졌다. 한번에 쓰거나 읽는 양이 많다면 압축기술을 적절히 가미하는 것도 도움이 될 수 있다. 이렇게 잘 저장된 데이터를 가져다 쓰는 주체는 결국 질의 들인데, 쿼리마스터가 개별질의 수행을 위해 새로 생성한 실행계획과 개별질의의 수행결과인 중간데이터의 처리방법이 여기에 큰 영향을 미친다. 이 역시 질의의 특징과 데이터의 형태에 따라 질의의 변형, 정렬 알고리즘, 중간 데이터 처리 시 메모리 사용여부 등을 결정해야 한다. 이 외의 부분은 질의 수행에 관여하는 새로운 아키텍처를 추가하여 개선해야 한다. Map-Reduce를 배제하고 별도 분석엔진을 추가하는 솔루션이 등장하는 것도 이 이유에서다.
4 .SQL On Hadoop 솔루션 분류 및 솔루션별 비교
가. DW(Data Warehouse)형
기업의 레거시와의 연동, 의사결정 지원, 통계, 연구 등을 수행하기 위해 복잡하고 규모가 큰 분석을 수행하거나 기존 정보계 시스템과 연동하기 위한 목적으로 활용되며, 긴 질의(Long Time Query)를 안정적으로 처리하는 기술과 DW솔루션 연동을 위한 기존데이터의 추출, 변환, 적재(ETL)작업이 가능하다. 국산제품인 Apache Tajo와 Hive가 개선된Stringer가 대표적이다.
나. Distributed Query Engine형
몇 시간 또는 몇 일 단위로 전략을 세워야 하는 마케팅분야나 데이터분석가의 두뇌와 상호작용하는 대화식 분석 등 비즈니스 지원분야에서는 짧은 질의가 사용되고 빠른 응답속도가 요구되므로 데이터 처리 시 In-Memory 기술을 적극 활용하거나, 편의성을 위한 사용자 함수와 확장된 SQL명령어가 필요하다. IMPALA(클라우데라)와 presto(Facebook)가 여기에 속한다. 아래는 대표적인 SQL on Hadoop솔루션들이다. 기존 시스템과 비즈니스 요구를 잘 고민하며 비교해보는데 도움이 됐으면 한다.