파일시스템 캐시

파일시스템 캐시 (File system cache)

Trino는 객체 스토리지와 원격 파일시스템의 파일에 직접 접근해요. 이 과정은 종종 대량의 데이터 전송을 수반해요. Trino는 오픈소스 Alluxio 라이브러리를 활용해 이러한 파일을 캐싱하는 것을 지원해요.

출처: 문서

본문

Trino는 객체 스토리지와 원격 파일시스템 스토리지의 파일에 직접 접근해요. 이는 종종 대량의 데이터 전송을 수반해요. 파일은 HDFS 또는 그 밖의 지원되는 객체 스토리지에서 여러 워커가 가져와 해당 워커에서 처리돼요. 파라미터가 다른 반복 쿼리나, 서로 다른 사용자의 다른 쿼리도 종종 같은 객체에 접근하고 따라서 같은 데이터를 전송해요.

Trino는 다음 커넥터를 사용하는 카탈로그에서 오픈소스 Alluxio 라이브러리의 도움으로 이러한 파일을 캐싱하는 것을 지원해요.

• Delta Lake 커넥터
• Hive 커넥터
• Iceberg 커넥터

분산 캐싱 (Distributed caching)

파일시스템 캐싱은 다른 어떤 쿼리 처리 메커니즘과 마찬가지로 Trino에서 분산되어 있어요. 쿼리 처리는 각기 다른 스테이지로 나뉘고, 각 단계의 태스크와 스플릿(split)은 클러스터의 서로 다른 노드가 처리해요. 최하위 수준의 스플릿은 특정 카탈로그의 커넥터 도움으로 데이터 소스에서 데이터를 가져와요. 파일시스템 캐싱의 경우, 이러한 스플릿은 객체 스토리지에서 파일을 가져오는 결과를 낳아요.

시간이 지나면서 서로 다른 노드들이 객체 스토리지의 데이터가 있는 스플릿을 처리하긴 하지만, 주어진 파일에 대해서는 고정된 노드 집합을 선호해요. 선호 노드가 너무 바쁘면 스플릿, 따라서 캐싱은 선호되지 않는 덜 바쁜 노드에서 일어나요. 파일시스템 캐싱은 가져온 파일의 복사본을 각 노드에 별도로 존재하는 로컬 캐시 스토리지에 보관해요. 시간이 지나면서 객체 스토리지의 같은 파일은 특정 태스크를 처리하는 데 그 데이터 파일이 필요한 어떤 노드에든 캐시돼요. 각 노드의 각 캐시는 TTL과 크기 구성에 따라 별도로 관리되며, 캐시된 파일은 캐시에서 축출(evict)돼요.

코디네이터의 etc/config.properties에 node-scheduler.cache-preferred-hosts-count 프로퍼티로 이러한 태스크를 처리하는 데 선호되는 호스트 수를 제한할 수 있어요. 쿼리 처리는 태스크의 병렬 처리를 위해 필요에 따라 다른 모든 노드도 계속 사용하므로, 잠재적으로 선호 호스트보다 더 많은 노드에 파일을 캐시할 수 있어요. 기본값 2 같은 낮은 설정은 같은 파일이 여러 노드에 캐시되는 빈도를 줄여 캐시의 전체 크기를 줄일 수 있어요. 클러스터 노드 수까지의 더 높은 설정은 기본적으로 더 많은 워커에 워크로드를 분산하고, 효과적인 캐시 크기를 희생하더라도 노드 실패에 대한 복원력을 높여요.

이점 (Benefits)

캐싱을 활성화하면 다음과 같은 중요한 이점이 있을 수 있어요.

스토리지 부하 감소 (Reduced load on storage)

가져와서 캐시된 모든 파일은 같은 워커의 이후 쿼리에서 스토리지로부터의 반복 가져오기를 피하게 해요. 그 결과 스토리지 시스템이 계속해서 파일을 제공하지 않아도 돼요.

예를 들어 쿼리가 스토리지에서 100MB의 파일에 접근한다면, 첫 번째 실행 때 100MB를 다운로드해 캐시해요. 이후의 어떤 쿼리도 이 파일을 사용해요. 사용자가 같은 파일에 접근하는 쿼리를 100개 더 실행하면, 스토리지 시스템은 그 데이터를 반복해서 제공할 필요가 없어요. 캐싱이 없으면 같은 파일을 계속 제공해야 해서 총 제공해야 할 파일 크기가 최대 10GB가 될 수 있어요.

쿼리 성능 향상 (Increased query performance)

캐싱은 반복적인 네트워크 전송을 피하고 대신 로컬 캐시에서 파일 복사본에 접근함으로써 상당한 성능상의 이점을 제공할 수 있어요. 스토리지에 직접 접근하는 성능이 로컬 캐시에 접근하는 것보다 낮을수록 성능 이득이 더 커요.

예를 들어 다른 네트워크, 다른 데이터 센터, 또는 다른 클라우드 제공자 리전의 스토리지에 접근하면 쿼리 성능이 느려요. 빠른 로컬 스토리지로 캐싱을 추가하면 큰 영향을 주고 쿼리를 훨씬 빠르게 만들어요.

반면 스토리지가 이미 I/O와 네트워크 접근에서 매우 높은 성능으로 운영되고 있고 로컬 캐시 스토리지가 비슷하거나 더 느린 속도라면, 성능 이점은 미미할 수 있어요.

쿼리 비용 절감 (Reduced query costs)

앞서 언급한 스토리지 부하 감소의 결과는 네트워크 트래픽과 스토리지 접근을 크게 줄이는 것이에요. 네트워크 트래픽과 접근은 종종 API 접근 형태로, 특히 퍼블릭 클라우드 제공자 시스템에서 호스팅될 때 상당한 비용 요인이 돼요.

구성 (Configuration)

카탈로그 프로퍼티 파일에서 다음 표의 프로퍼티를 사용해 특정 카탈로그의 캐싱을 활성화하고 구성해요.

모니터링 (Monitoring)

캐시는 org.alluxio 패키지 아래에 Alluxio JMX 클라이언트 메트릭을, 그리고 io.trino.filesystem.alluxio.AlluxioCacheStats 아래에 외부 읽기와 캐시 읽기 메트릭을 노출해요. 캐시 코드는 OpenTelemetry 트레이싱을 사용해요.

권장 사항 (Recommendations)

로컬 캐시 스토리지의 속도는 캐시 성능에 결정적이에요. 가장 흔하고 비용 효율적인 방법은 고성능 SSD 디스크 또는 이에 준하는 스토리지를 연결하는 거예요. 빠른 캐시 성능은 인메모리 캐시로 사용하는 RAM 디스크로도 달성할 수 있어요.

어떤 경우든 노드의 루트 파티션과 디스크 사용은 피하세요. 대신 각 노드에 캐시용으로 하나 이상의 전용 스토리지 장치를 연결해요. 스토리지는 각 노드에 로컬·전용이어야 하며 공유하면 안 돼요.

Trino의 배포 방법이 스토리지를 연결하고 캐싱용 디렉토리를 만드는 방법을 결정해요. 보통 SSD 드라이브 같은 빠른 스토리지 시스템을 연결하고, 구성된 경로에 마운트되도록 해야 해요.

더 알아보기 (Learn more)

파일시스템 캐시로 객체 스토리지 성능을 크게 높일 수 있어요. 이어서 객체 스토리지의 메타데이터를 관리하는 메타스토어(Metastores)를 살펴보면 좋아요.