DEVOCEAN

2020년 Databricks는 C++ 기반 SQL 실행 엔진 Photon을 공개했습니다.

(https://www.databricks.com/kr/blog/2020/06/24/introducing-photon-engine.html)

먼저 Databricks는 왜 C++ 기반 실행 엔진을 만들었고, 왜 C++이어야만 하는지 간단히 설명합니다.

Spark SQL을 사용하기 위해 사용자가 입력한 쿼리는 다음의 단계를 거쳐 Code Gen이 되어 byte code로 변환되고, 각 executor에서 실행됩니다.

[그림 1] Spark Catalyst Optimizer

JVM으로 실행하는 Spark Executor는 아무리 잘 포장해도 Java가 C++/Rust 등에 비해 부족한 약점을 보완하기 어렵습니다.

가장 대표적인 부분 몇 가지만 나열하면 다음과 같습니다.

1. 메모리 제어의 유연성 부족으로 인한 최대 성능 제약

2. 네이티브 SIMD 지원 부족으로 최신 장비의 성능 극대화 방안 부족

3. SIMD를 위한 표준 라이브러리 부족과 JNI를 통해서만 호출할 수 있는 SIMD 사용 복잡성

4. SIMD 명령을 실행하기 위한 자동 벡터화(비록 최신 SDK에서 Vector API 등을 지원하지만 JVM을 통한 실행으로 성능과 확장성 제약) 불가능

주요 약점들이 대규모 병렬 서비스 개발에는 치명적인 제약으로 다가올 수 있습니다.

JIT 컴파일러 기반의 Vector화된 코드는 C++ 컴파일러가 제공하는 수준의 정교한 최적화가 어렵기 때문에

여전히 고성능 서비스 개발에서 JVM 기반 언어는 C++과 Rust와의 경쟁이 어렵습니다.

Spark SQL을 실행하는 구조에서 어떤 부분을 고성능 모듈로 바꾸면 좋을지 생각해볼 수 있습니다.

Spark Catalyst Optimizer에서 완성된 code gen 바이트 코드를 Spark Executor에 전달하는 과정까지는 C++, Java무엇으로 개발하든 성능 차이가 안 나는 영역입니다.

빅데이터에 대한 병렬처리의 장점을 극대화할 수 있는 구간이 아니기 때문이죠.

SQL을 Parsing하고 실행계획을 만드는건 단일 노드에서도 얼마든지 빠르게 처리할 수 있고, 이는 java application이 C++ 보다 경쟁 우위에 있을 수 있는 분명한 영역입니다.

하지만 완성된 code gen이 실행되는 병렬 컴퓨팅 영역은 C++이 압도적인 성능 우위를 얻어낼 수 있는 구간입니다.

그래서 Spark Executor에서 실행을 담당하는 엔진을 C++로 새롭게 개발한 서비스가 Databricks Photon Engine입니다.

[그림2] Databricks Photon 엔진 구조

Photon 엔진은 위에서 언급한 JVM 기반 Spark Executor가 가진 단점을 모두 해결해줍니다.

• C++로 작성된 MPP 기반의 병렬 처리 구조

• Native SIMD 명령어 처리를 통한 대규모 데이터 세트의 처리 속도 향상

• 최신 HW 최적화를 지원하여 CPU와 메모리 활용도 획기적인 증가

• 벡터화된 쿼리 처리와 메모리 사용으로 쿼리 성능 압도적인 개선

• CBO 기반 쿼리 실행 비용 최적화와 물리 실행 계획 최적화

• HW 가속의 확장성으로 특정 연산을 더욱 빠르게 튜닝

• 기존 Spark API와의 호환성 부여로 기존 Spark SQL의 수정없이 그대로 사용

Spark 환경의 성능적인 약점을 모두 해결하면서 기존 사용자들의 Spark SQL을 그대로 사용할 수 있게 해준 획기적인 개발이었습니다.

Photon 엔진으로 인해 Databricks의 플랫폼은 Apache Spark와는 확실한 차별점을 부여할 수 있었고, 강력한 무기가 되었습니다.

보통 선구자가 이렇게 좋은 기술을 개발하면 그 동네에 있는 누군가는 비슷하거나 더 좋은 기술을 만드는게 IT 바닥의 흐름 같습니다.

Databricks와 같은 동네에 살고 있는 IT업계의 큰 형님 중 한 명인 Meta는 Data Platform 관련 기술에 진심인 회사 중 하나입니다.

요즘은 G.AI가 모든 이슈를 가리고 있지만 Meta는 빅데이터 처리와 관련된 다양한 open source를 개발하고 공유하는 큰 열정을 보여주고 있습니다.

요즘은 llama를 주로 얘기하지만 React, PyTorch, Presto(현 PrestoDB), GraphQL 등 훌륭한 open source 포트폴리오를 가지고 있고 지속적인 지원을 하고 있습니다.

Meta도 유례없는 큰 데이터를 처리하는 회사이고, 핵심 분석 플랫폼의 고성능화에도 많은 투자를 하고 있습니다.

Meta의 핵심 쿼리 엔진인 Presto는 Java로 구현되어 있습니다.

Java는 사용하기 편하고, 웹기반 서비스 개발에도 좋지만, 결국 위에서 언급한 JVM 기반 Spark의 약점을 그대로 가지고 있습니다.

Presto나 Trino는 C++ 기반 MPP엔진에 비교했을 때 동시성, CPU 사용률, 병렬처리 등 Spark와 유사한 단점을 보유하고 있습니다.

Meta는 이를 해결하기 위해 전체 아키텍처 관점에서 해결책을 사용했었습니다.

여러 개의 Presto 클러스터를 구축하고, 가장 앞단에 Gateway를 배치하여 다양한 라우팅 전략을 부여하여 안정적인 빅데이터 서비스를 만들고자 했습니다.

(https://developers.facebook.com/blog/post/2023/04/11/running-presto-at-meta-scale/)

[그림 3] Gateway를 활용한 Presto 클러스터의 Scale 관리

Scale Out 구조가 좋아도 하나의 노드에서 처리하는 최대 성능이 모여서 전체 클러스터 성능을 결정하기 때문에

Meta도 Presto의 분산 처리 영역을 C++ 기반의 엔진으로 바꾸는 Open Source를 개발합니다.

(https://engineering.fb.com/2023/03/09/open-source/velox-open-source-execution-engine/)

[그림4] Velox 실행 엔진

Velox는 C++기반 실행 엔진이기 때문에 C++이 가진 경쟁우위 요소를 그대로 상속받습니다.

Presto의 실행 엔진 영역을 C++ 기반 고성능으로 개선, 벡터 처리 모델을 사용하여 SIMD 극대화와 메모리 최적화,

이로인한 데이터 접근 시간 단축, 컴파일된 표현식 사용으로 런타임 오버헤드 감소를 달성할 수 있습니다.

Databricks Photon이라는 선례가 있기 때문에 Velox 개발자들은 Photon 대비 더 나은 경쟁력을 가질 수 있는 설계를 합니다.

더욱더 광범위한 벡터화된 처리와 SIMD 명령어 활용과 최적화, 다양한 데이터 형식을 유연하게 지원하여 Spark나 Presto 전용 실행 엔진이 아닌 다양한 서비스에 적용할 수 있는 확장성을 가집니다.

이는 플러그인 아키텍처를 적용한 구조에서도 극명하게 들어납니다. 그리고 Open Source 생태계와의 통합으로 더 많은 프로젝트에서의 활용이 가능합니다.

Velox를 사용하여 Presto용 실행엔진을 플러그인 형식으로 확장했습니다.

(https://github.com/prestodb/presto/tree/master/presto-native-execution)

PrestoDB와 C++ 실행엔진의 조합은 Apache Impala와 거의 동일한 구조를 가지게 됩니다.

외부 인터페이스 영역은 Java이고 내부 실행 엔진은 C++로 구성하여 두 언어의 장점을 최대한 활용하는 전략입니다.

어째든 Meta는 Velox를 PrestoDB에 플러깅하면서 성능과 안정성 두 마리 토끼를 모두 잡은것으로 보입니다.

그림3에 있는 Gateway를 활용해 일반 PrestoDB와 PrestoDB with Velox 클러스터로 라우팅을 유연하게 조정할 수 있기 때문에 서비스 적용이나 호환성 문제도 안정적으로 관리할 수 있습니다.

마지막으로 Photon에 해당하는 Spark용 C++ 실행 엔진을 Velox로 적용할 수 있습니다.

Gluten 프로젝트라고 불리우고 있고, apache의 incubator 프로젝트입니다.

(https://github.com/apache/incubator-gluten)

Gluten 자체는 실행 엔진이 아닙니다. 다만, 플러그인 형식으로 다양한 벡엔드 엔진을 붙일 수 있습니다.

여기에 Velox 실행 엔진을 연동하여 Spark SQL을 Photon과 동일한 형태의 구조로 만들어줍니다.

[그림5] Gluten Plugin 구조

[그림6] Spark와 Gluten Plugin

Gluten은 Server, Worker, Executor, Frontend, metadata 연동 등의 모듈로 나뉘어 있고, Velox 실행 엔진을 통해 C++ 기반의 병렬 성능을 확보합니다.

이번 글에서는 Velox에 대해 간단히 설명했고, 다음 글에는 실제 테스트 결과를 공유하겠습니다.