빅데이터 분석 Trino(구 Presto)로 해결하자.

빅데이터 분석 플랫폼의 종류

현재 SQL ON Hadoop 인메모리 병렬분산처리 플랫폼들의 춘추전국 시대입니다.

가장 대표적인 플랫폼으로 Spark가 있고 cloudera에서 구현한 impala,

Facebook에서 개발한 Presto 등 여러 쿼리 엔진으로 사용할 수 있는 오픈소스들이 난무하고 있습니다.

이중에서 Trino(구 Presto)라는 빅데이터용 쿼리엔진을 소개하고자 합니다.

 

 

Trino?

Trino는 Facebook에서 만든 Presto를 리브렌딩한 쿼리 엔진입니다.

SQL On Hadoop 의 한 종류로  짧은 지연 시간의 임시 데이터 분석에 최적화된 오픈 소스 분산 SQL 쿼리 엔진입니다. Presto는 복잡한 쿼리, 집계, 조인, 윈도우 함수 등 ANSI SQL 표준을 지원합니다. Presto는 하둡 분산 파일 시스템(HDFS)과 Amazon S3를 비롯한 여러 데이터 소스의 데이터를 처리할 수 있습니다.

지금까지 Facebook에서 빅데이터 처리 엔진에 대해 전세계적으로 기여해온 점에 대해 감사의 마을을 전합니다.

 

Facebook은 2009년 기점으로 Hive를 아파치 재단에 기부하였고 2012년 Presto Project를 Facebook에서 시작하였습니다.

개인적으로 추정하면 MapReduce기반의 Hive로 데이터 처리 시 데이터 분석 시간이 오래 걸리는 것이 발목을 잡았을 것입니다.

이후 메모리 기반의 데이터 분석을 시도하였고 가능성을 타진 후 Presto 쿼리 엔진을 구현한 것으로 파악됩니다.

2010년 정도 시기에 CPU와 메모리 기술이 많이 발전한 시기였고 어느정도 비용 대비 운영비용이 현격히 줄어들어 활용 가능한 시기와 맞물린 점이 인메모리 기반 빅데이터 분석 쿼리 엔진의 탄생 시점에 불을 지핀것으로 생각됩니다.

 

현재 Facebook은 Presto 쿼리엔진을 통해 페타바이트급 데이터를 처리하여 자사 고객 분석에 큰 역할을 하고 있습니다.

데이터 분석 업체들이 계속해서 고도화하고 있는 Presto 쿼리엔진을 활용하여 좀더 빠른 분석으로 데이터에 대한 인사이트를 키우는게 좋지 않을까 합니다. 아래는 넷플릭스에서 성능 테스트를 통해 Presto와 Hive의 Performance를 비교한 차트입니다. 

 

위 비교차트를 보면 기존 MapReduce 엔진을 통한 쿼리 처리를 하는 Hive와 인메모리기반의 분산병렬 쿼리 엔진 Trino(구 Preto)의 처리 속도가 많이 차이나는 것을 볼 수 있습니다. 성능 차이가 비교적 좋아도 내구성이나 안정성에 대해서 고민해볼 필요가 있습니다.

수백 기가바이트의 데이터를 쿼리할 경우 MapReduce 프레임워크에서는 HDFS 시스템에 중간데이터를 저장 후 데이터를 안정적으로 분석하지만 인메모리 기반의 쿼리 엔진은 메모리에 데이터를 올려놓고 처리하기 때문에 인메모리 기반 쿼리엔진이 기동 중인 클러스터의 메모리에 제약이 많습니다. 이런 약점을 어떻게 극복하느냐에서 안정성을 확보할 수 있습니다.

 

Trino의 특징

Trino(구 Presto) 를 활용한 빅데이터 분석 시스템을 구축 활용할 경우 위에서 제시한 메모리 문제점과 속도면에서 큰 혜택을 볼 수 있습니다. 특히 메모리 초과 용량의 데이터를 처리할 때 Trino(구 Presto) 에서는 OS에서 제공하는 스와핑 같은 기능을 제공합니다. Trino(구 Presto) 쿼리 엔진 세팅 중에 "Spill To Disk" 라는 설정부분이 있는데 이 설정을 통해 스와핑 기능을 설정할 수 있습니다.  

 

Spill To Disk는 쿼리 샐행 후 중간 작업 결과를 디스크로 오프로딩하는 기능입니다.

이 메커니즘의 목표는 쿼리당 또는 노드당 제한을 초과하는 메모리 양을 디스크로 임시저장하여 현재 메모리 용량에 최적화하여 필요한 쿼리를 실행할 수 있도록 하는 것입니다. OS 에서의 스와핑 기능과 유사합니다.당연히 하드디스크의 종류별로 속도의 차이가 존재합니다. 되도록이면 SSD 또는 NVME SSD로 구성하면 속도에서도 어느정도 장점을 발휘할 것입니다. 

 

기존적인 Trino 클러스터 설치 방법은 https://trino.io/docs/current/installation/deployment.html 문서를 통해 진행할 수 있습니다. 이 문서에서는 대략적인 Trino의 소개 내용으로 다음에 블로그를 통해 구성 설치를 소개하도록 하겠습니다.

 

 

Spill To Disk의 설정은 다음의 Spilling Properties 를 설정하여 기능을 활성화 합니다.

Property	Type	Description
spill-enabled	boolean	Spill To Disk 기능 On Off  Default Value : false
spiller-spill-path	string	중간 작업결과 유출 경로 (예: /home/trino/spill)

 

2013년 Presto를 처음 설치하고 HDFS에 저장된 Hive데이터를 쿼리한 적이 있었는데 초기 버전이라 OutOfMemory 에러가 많이 발생되었었습니다. 하지만 이제 위의 Spill To Disk 기능을 통해 Trino (구 Presto) 쿼리 엔진을 통해 수 페타바이트도 처리 가능하도록 구성할 수 있는 점이 다른 Impala보다 더 큰 데이터를 처리가 가능합니다.

 

Trino(구 Presto) 엔진의 또다른 장점으로 많은 데이터소스를 하나의 쿼리로 조인이 가능하며 다른 데이터소스로 인서트 처리가 가능하다는 점입니다. 이는 ETL툴을 별도로 사용하지 않고 Trino쿼리 엔진을 통해 하둡기반의 Hive와 Mysql, Postgresql, Oracle, MSSQL 등의 RDBMS와의 데이터 연계처리가 가능합니다. 별도의 ETL 툴을 활용하거나 프로그램을 구현하지 않을 수 있기 때문에 작업 단계를 획기적으로 줄일 수 있습니다.

 

마지막으로 Trino(구 Presto)의 가장 큰 특징으로 설치 제약이 없다는 부분입니다. Hive나 Impala는 하둡 클러스터가 설치된 클러스터에서만 설치가 가능합니다. 이에 반해 Trino(구 Presto)는 단순 JAVA가 실행될 수 있는 노드만 있으면 설치 후 실행이 가능합니다. 이 말은 하둡 클러스터와 별도로 여러개의 Trino(구 Presto) 클러스터를 구성하여 쿼리엔진을 여러 개로 쪼갤 수 있다는 것입니다. 대부분 데이터베이스(RDBMS)은 설치된 서버를 통해 쿼리를 실행하는게 일반적인 패턴입니다. 이는 데이터베이스 서버를 구축하고 여러 분석 팀들이 모두 같은 데이터베이스에 접속하여 수많은 쿼리를 실행하고 결과를 받는다는 것입니다. 만약 데이터베이스가 A서버에 설치되어 있고 B서버는 쿼리 엔진만 설치되어 있다고 볼때 B서버로 접속하여 쿼리를 실행할 경우 B서버는 쿼리를 분석 스케쥴링하고 A서버의 데이터를 가져다 B서버 내에서 해당 쿼리의 결과를 조작하는 작업이 가능하다면 개발1팀은 B서버로 쿼리를 실행요청을 할 것입니다. 이에 더해 개발2팀, 개발3팀이 B서버로 접속하여 쿼리 실행을 요청할 경우 한 서버로 여러 쿼리 요청이 진행될 것입니다. 이럴 경우 B서버에는 여러 요청들로 인해 병복 현상이 발생합니다. 이럴 경우 C서버에 B서버와 같은 쿼리 엔진을 설치한 후 개발2팀에 배분하고 D서버에도 같은 쿼리 엔진을 설치한 후 개발3팀에 배분하면 각각의 B, C, D 서버에서 각팀에서 요청한 쿼리를 실행할 경우 병복현상이 거의 없이 처리될 수 있습니다. 그 결과 쿼리 결과를 추출하는 데 필요한 처리 시간이 병목없이 빠른 처리가 가능합니다. 하지만 아직 RDBMS에서는 이런 처리를 위해서 어마어마한 라이센스 비용이 발생되기 때문에 일반적인 업체에서는 활용할 엄두가 나지 않습니다. 

 

이에 비해 오픈소스 Trino(구 Presto)에서는 위와 같이 개발1, 2, 3팀에게 별도의 쿼리 처리 서버를 구성하고 하둡 클러스터에 쿼리를 요청할 수 있게 시스템 아키텍처를 구성할 수 있습니다.

                                                                        <N개의 Trino 클러스터 활용 구성안>

모 반도체 대기업에서는 하둡 클러스터와 별도로 Trino클러스터를 100대의 Worker노드로 구성하여 여러 팀들이 동시 접속하여 데이터를 분석하고 있습니다. 하지만 100개의 팀들이 하나의 Trino클러스터로 접속하여 데이터 분석 중에 클러스터 부하가 심한 상태가 자주 발생되고 있습니다. 이에 위와 같이 각 팀들에게 적은 갯수의 Trino클러스터를 별도로 구성하여 데이터 분석을 집중하도록 구성하면 보다 쾌적한 작업 환경이 될 것입니다.

 

추가적으로 여러 Trino클러스터를 구성하여 데이터 분석 처리를 진행할 경우. 해당 Region에서 네트워크 병목현상이 발생할 소지가 있습니다. 이를 위해 Trino(구 Presto) 클러스터 및 하이브 클러스터 구성 시 네트워크 BandWidth는 기본 10G급 이상의 구성이 필요합니다. 일반적인 AWS 클러스터 및 Azure, Kakao, Naver에서 제공하는 클러스터 내부에서는 40G 이상의 속도를 보장하는 백본 스위치 네트워크가 구성되어 있어 원하는 만큼의 클러스터들을 구성하여 충분한 속도가 보장되는 시스템을 구성할 수 있습니다. 

 

 

마무리

마무리하며 현재 고속의 네트워크 상에서 소비자 또는 IOT 기기들에서 생성되는 모든 데이터들이 분석 대상이 되었습니다. 이에 어떤 데이터 분석 엔진을 통해 수많은 데이터에서 의미있는 데이터를 빨리 분석하느냐가 기업의 역량으로 평가받고 있습니다.

2010년 후부터 하둡이 세상에서 명성을 떨치고 있는 중에 하둡 위에 하둡을 더 빛을 낼 수 있는 시스템들이 대거 나온 후 기업들의 데이터 분석 역량은 무어의 법칙처럼 계속 발전하고 있는 상황입니다. 이런 상황에서 Trino 클러스터를 다양한 방식으로 조합하여 보다 쾌적한 성능의 데이터 분석이 가능하다고 봅니다.