새벽을 밝히는 붉은 달
Trino와 Presto 톺아보기 본문
1. 들어가며
presto는 이전부터 많이 들었던 서비스이자 자주 사용하는 AWS Athena가 presto기반 문법을 사용하고 있기 때문에 익숙했다. Trino는 최근에 많이 언급되는 것을 보았는데, 어디선가 presto가 trino로 바뀌었다~ 정도로 들어서 둘이 이름이 같구나 정도로 이해하고 있었는데 datahub ingestion guide 읽어보니까 presto랑 trino랑 다르게 취급을 하고 있어서 혼란이 왔다. 그래서 이번에 둘에 대해서 알아보기로 했다.
2. 결론부터 이야기하면, 둘이 다른게 맞다
나 같은 사람이 많았나보다. starbust에서 Trino와 Presto의 차이가 무엇인지에 대해 설명을 해둔 글(The Difference Between PrestoSQL, PrestoDB, and Trino)이 있는 것을 보니 말이다.
3. Presto 톺아보기
전 PrestoDB -> 현 Presto
3-1. Distributed SQL query engine, Presto
Presto는 모든 크기의 데이터에 대해 빠른 분석 쿼리를 위해 설계된 오픈 소스 분산 SQL 쿼리 엔진이다.
HDFS, Amazon S3, Cassandra, MongoDB, Hbase와 같은 비관계형 데이터베이스와 MySQL, PostgreSQL, Amazon Redshift, Microsoft SQL Server, Teradata와 같은 관계형 데이터베이스를 둘 다 지원한다.
Presto는 데이터를 별도의 분석 시스템으로 옮길 필요 없이 저장된 곳에서 쿼리가 가능하다. 쿼리 실행은 순수 메모리 기반 아키텍처에서 병렬적으로 실행이 되며 대부분의 결과가 몇 초 안에 반환된다.
3-2. Presto의 탄생
이전에 PrestoDB라고 불렸던 Presto는 Fackbook에서 Martin Traverso, David Phillips, Dain Sundstromm Eric Hwang이 만들었다. 처음에는 300 PB 규모의 Hive Data Warehouse에서의 slow query를 해결하기 위해서 만들어졌다고 한다.
Presto를 만들기 전에는 Facebook에서 Apache Hive를 사용했는데, Hive가 Hadoop ecosystem에서 복잡한 Java MapReduce 잡을 SQL처럼 처리할 수 있게 해준다는 이점이 있지만 interactive query에서 performance를 향상시키기 위한 optimize가 불가능하다는 단점이 있었다.
Presto가 만들어진 후, interactive query system은 petabyte 규모에서 빠르게 동작할 수 있게 되었다. 2013년에 Facebook은 Apache Software License 하에 Presto를 오픈 소스로 공개했으며, 현재는 Hadoop에서 interactive query를 하기 위한 선택지들 중 인기있는 선택지가 되었다.
3-3. Presto는 어떻게 동작하는가?
Presto는 하둡에서 실행되는 분산 시스템으로 클래식한 MPP 데이터베이스 관리 시스템과 비슷한 아키텍처를 사용하고 있다.
아래 사진과 같이 여러 worker 노드와 동기화되어 동작하는 하나의 coordinator 노드가 있다.
사용자는 custom query와 execution engine을 사용하여 worker 노드들에게 분산 쿼리 계획을 parse하고, plan하고, schedule하는 coordinate 노드에 SQL 쿼리를 제출한다.
쿼리가 컴파일된 후에 Presto는 worker 노드 전체에 걸쳐서 요청을 여러 stages로 처리한다. 모든 processing은 인메모리로, 불필요한 I/O 오버헤드를 피하기 위해서 stage들 간 네트워크를 통해 파이프라인된다. Worker 노드를 더 추가하는 것은 더 많은 병렬 처리(parallelism) 그리고 더 빠른 processing을 가능하게 한다.
Presto는 어떤 데이터 소스든 확장이 가능하도록 스토리지 추상화를 사용해 pluggable connectors를 쉽게 구축할 수 있도록 설계되었다. 그래서 Presto는 여러 비관계형 데이터베이스와 관계형 데이터베이스와 connect할 수 있는 다양한 connector가 있다.
복잡한 쿼리, aggregations, joins, left/right outer joins, subqueries, window functions, distinct counts, approximate percentiles를 포함하는 표준 ANSI SQL semantic을 지원하도록 디자인되었다.
조금 더 다양한 내용에 대해서 알고 싶다면 Presto의 concept을 설명하고 있는 공식 문서를 읽어보는 것을 추천한다.
4. Trino 톺아보기
이전의 PrestoSQL -> Trino
4-1. 같은 개발자들이 만든 Distributed SQL query engine, Trino
Trino도 하나 이상의 heterogeneous한 데이터 소스에 분산되어 있는 대규모 데이터에 쿼리할 수 있도록 설계된 분산 SQL 쿼리 엔진이다. Trino는 Hive나 Pig와 같은 MapReduce 작업의 파이프라인을 사용해 HDFS를 쿼리하는 도구의 대안으로 설계되었지만, HDFS 뿐만 아니라 Presto처럼 비관계형 데이터베이스와 관계형 데이터베이스와 같은 다양한 종류의 데이터 소스에서 동작할 수 있다.
Presto의 경우 Facebook이나 Uber와 같은 hyper-scale의 인터넷 회사들을 위해 구축되었으나 Trino는 훨씬 더 다양한 고객과 사용 사례를 위해 구축되었다. Trino는 cloud adoption의 다양한 stage에 있는, 모든 데이터에 빠르게 접근하고 싶어하는 다양한 기업들에 Presto의 가치를 제공한다.
3-2. Trino의 탄생
Presto를 만들면서 하나의 협상불가능한 조건이 바로 Presto를 오픈소스 프로젝트여야 한다는 것이었다. Presto를 만들었던 Martin, Dain, David는 오픈소스가 자신들의 DNA에 있다고 믿었다. 모두 과거에 다양한 정도로 오픈 소스 프로젝트를 사용하고 참여했으며, 오픈 커뮤니티와 개발자들이 함께 시간의 시험을 견딜 수 있는 성공적인 소프트웨어를 구축하는 힘이 있다는 것을 알고 있었기 때문이다.
그러나 2018년, Facebook 경영진들은 프로젝트와 프로젝트의 미래에 대해서 좀 더 타이트한 통제를 하고자했고, 결국 Presto에 관한 아무런 경험이 없는 Facebook 개발자에게 프로젝트에 대한 권한을 부여하는 것으로 결정되었다. 더군다나 Facebook은 Presto 커뮤니티를 참여시키지 않고 법정 판결로 이러한 결정을 내렸다. Martin, Dain, David는 이러한 결정이 건강하고 오픈된 커뮤니티와 양립할 수 없다고 생각을 했고, 그들이 가지고 있던 원칙처럼 Presto가 개방적이고 독립적인 커뮤니티를 가진 성공적인 프로젝트가 되기 위해 Facebook을 떠나는 선택을 내리게 되었다고 한다.
결국 Martin, Dain, David는 Presto Open Source Community를 구축하기 위해 2018년에 Facebook을 떠났고, PrestoSQL이라는 새로운 이름의 프로젝트로 커뮤니티를 빠르게 통합하고, 커뮤니티를 확장하고 강화했다. 아래 사진에서 보면 알 수 있듯이, PrestoSQL은 커뮤니티를 활성화한 결과 훨씬 더 많은 새로운 사용자와 개발자가 참여하여 Presto와 PrestoSQL 사이의 커밋수가 점점 차이가 나는 것을 볼 수 있다.
3-3. 왜 이름을 변경했을까?
2020년 12월에 PrestoSQL은 Trino로 리브랜딩했다. 왜 리브랜딩을 했을까?
Facebook은 Linux Foundation을 이용해서 경쟁적인 커뮤니티를 만들기로 결정했고, 이에 대한 첫 번째 조치로 Presto라는 이름을 상표출원했다. 그리고 2019년 9월 Facebook은 Linux Foundation에 Presto Foundation을 설립하고 그 즉시 이 새로운 상표를 시행하기 위해서 노력하기 시작했다.
PrestoSQL은 Facebook과 Linux Foundation의 커뮤니티에 부정적인 영향을 끼치지 않는 조건에 합의하기 위해 노력했지만 그렇게 할 수 없었고, 따라서 그들은 PrestoSQL의 이름을 변경할 수밖에 없었다.
3-4. Trino는 어떻게 동작하는가?
Presto 개발자들이 Trino를 개발했기 때문에, Coordinator와 Worker로 이루어져 있는 등 전반적인 구조는 동일하다. 애초에 Trino의 concept을 설명하고 있는 공식 문서도 Resource Manager와 Cluster 부분을 빼고 거의 똑같다. Presto에서는 간략하게 설명했으므로 여기에서는 조금 더 자세히 설명한다. (Presto도 거의 똑같이 동작하는 것으로 보인다)
유저는 JDBC driver나 Trino CLI 등으로 Coordinator와 연결되어 있다. Coordinator는 data source에 access 하는 worker들과 커뮤니케이션한다.
Coordinator는 입력된 쿼리를 핸들링하고 쿼리를 실행하도록 worker 를 관리하는 역할을 하는 Trino Server이다. Worker는 task를 실행하고 data를 처리하는 책임이 있는 Trino server다.
Coordinator는 SQL 구문을 받아서 parse하고, 쿼리를 planning하고, worker 노드를 관리한다. 즉 Trino Installation의 brain에 해당하는 부분이자 client와 연결을 담당하는 문이기도 하다. 모든 Trino installation에는 하나 이상의 worker와 한 개의 coordinator가 있어야 하는데, 만약 개발 또는 테스트 등의 목적으로 사용한다면 단일 인스턴스가 두 개의 역할을 모두 수행하도록 구성할 수 있다.
SQL 구문을 받으면 Coordinator는 앞서 말했던 것처럼 쿼리를 parsing하고, analyzing하고, planning하고 worker 노드들에게 쿼리 실행을 스케줄링한다. 받았던 SQL 구문은 worker들의 클러스터에서 실행되는 일련의 connected task들로 변환된다. Worker들이 데이터를 처리할 때, 결과는 Coordinator에 의해서 검색되고 output butffer 상에서 client에게 노출된다. 한번 client가 output buffer를 읽으면 coordinator는 client를 대신해서 worker들에게 더 많은 데이터를 요청한다. 그러면 worker들은 데이터를 얻기 위해서 데이터 소스들과 상호작용을 하게 되고, 그 결과 query 실행이 완료될 때까지 데이터는 client로부터 지속적으로 요청되고 worker 노드가 데이터 소스로부터 데이터를 제공한다.
Clients, coordinator, worker들 간의 통신과 데이터 전송은 REST API에 기반한 HTTP/HTTPS 통신을 사용한다.
4. 결론
1. Presto와 Trino는 결국 같은 개발자들이 개발한 것이다.
2. Facebook의 정책에 의해서 Presto 개발자들이 회사를 나와서 Trino 프로젝트를 만들었다.
3. Facebook의 상표 등록으로 인해 PrestoDB가 이름이 Presto로 바뀌고, PrestoSQL의 이름이 Trino로 바뀌었다.
Reference
https://www.starburst.io/learn/open-source-presto/prestosql-and-prestodb/
https://aws.amazon.com/ko/big-data/what-is-presto/
https://trino.io/blog/2020/12/27/announcing-trino.html
https://www.oreilly.com/library/view/trino-the-definitive/9781098107703/ch04.html
'Data Engineering' 카테고리의 다른 글
| [Hadoop] YARN capacity-scheduler 사용 기록 (0) | 2023.09.09 |
|---|---|
| [Airflow] on_failure_callback에서 Xcom 사용하기 (1) | 2023.02.05 |
| [NLP] FastText 의 pretrained-model에 text-classification을 위한 추가학습하기 (0) | 2021.09.26 |
| [밑바닥부터 시작하는 딥러닝] 퍼셉트론 (0) | 2021.04.10 |
