기술 요약: JEDI – 선언적 및 명령형 쿼리의 Java 평가

문제 제기

Java 8 에서 도입된 Java Stream API 는 컬렉션과 무한 데이터 소스를 처리하기 위한 선언적 문법을 제공하며, 전통적인 명령형 루프 기반 코드에 비해 개발자 생산성, 코드 가독성 및 유지보수성을 향상시키는 것을 목표로 합니다. 고수준 추상화를 통해 병렬 계산을 단순화하지만, 기존 문헌에 따르면 Stream 기반 구현은 동등한 명령형 코드에 비해 성능 저하를 겪는 경우가 많습니다.

이 연구에서 식별된 중요한 간극은 Stream API 를 대상으로 한 전용 벤치마크 스위트의 부재입니다. 이러한 벤치마크가 없으면 다음 사항이 어렵습니다:

1. 연구자 및 라이브러리 개발자: Java 클래스 라이브러리 (JCL) 내 Stream API 구현을 최적화하는 것.
2. 애플리케이션 개발자: 다양한 스트림 연산 및 병렬화 전략의 성능 특성을 이해하여 효율적인 코드를 작성하는 것.

현재 벤치마크들은 Stream API 를 명시적으로 대상으로 하지 않거나, 복잡하고 실제적인 데이터 처리 워크로드를 반영하지 않는 단순한 합성 파이프라인에 의존합니다.

방법론

이 간극을 해결하기 위해 저자들은 JEDI(Java Evaluation of Declarative and Imperative Queries) 를 제시합니다. 이는 SQL 쿼리를 Java 소스 코드로 자동 변환하여 생성된 벤치마크 스위트입니다.

생성 과정

1. 소스 자료: 저자들은 다양한 데이터 처리 기능 (조인, 집계, 필터링, 정렬) 을 포괄하는 복잡한 쿼리로 구성된 널리 사용되는 데이터 분석 벤치마크인 TPC-H벤치마크를 활용합니다.
2. 코드 변환: 저자들은 SQL 쿼리를 여러 의미적으로 동등한 Java 구현으로 변환하는 기존 도구인 S2S(SQL to Stream) 를 확장했습니다.
   • 스키마 매핑: SQL 테이블은 메모리 내 객체 배열로 매핑됩니다.
   • 쿼리 번역:
     • SELECT 프로젝션 $\rightarrow$ map(...)
     • WHERE 술어 $\rightarrow$ filter(...)
     • ORDER BY $\rightarrow$ sorted(...)
     • LIMIT $\rightarrow$ limit(...)
     • GROUP BY 및 집계 $\rightarrow$ 생성된 컬렉터를 사용한 collect(...)
     • JOIN $\rightarrow$ 빌드 측에 해시맵을 구축하는 flatMap 또는 mapMulti 를 통해 구현됨.
3. 구현 변형: 단일 SQL 쿼리에 대해 JEDI 는 다양한 코딩 패턴과 실행 전략을 비교하기 위해 여러 변형을 생성합니다:
   • 순차 변형:
     • O1(필터 퓨전): 여러 술어를 단일 filter 호출로 결합하는 것과 여러 체인된 호출을 비교.
     • O2(조인 구현): 조인 연산에 mapMulti 를 사용하는 것과 flatMap 을 사용하는 것을 비교.
   • 병렬 변형 (O3):
     • P: 순서형 병렬 스트림 (parallel()).
     • PU: 비순서형 병렬 스트림 (parallel().unordered()).
     • CG: groupingByConcurrent 를 사용하는 비순서형 병렬 스트림 (락 기반 동기화를 통한 공유 상태).
     • CGCC: CG 에 스레드 안전 하류 컬렉터 (락 없는 원자 연산) 적용.
   • 명령형 베이스라인: 스트림 버전과 동일한 데이터 구조 및 연산 순서를 사용하는 루프 기반 구현으로 "Stream API 의 오버헤드"를 측정.

평가 설정

• 하드웨어: 두 가지 다른 아키텍처: Intel Xeon Gold(16 코어) 및 ARM Neoverse-N1(80 코어).
• JVM: Oracle JDK 24 및 GraalVM 24.
• 데이터셋: 순차 분석을 위한 TPC-H 스케일 팩터 1(1GB) 및 병렬 분석을 위한 10(10GB).
• 도구: 정상 상태 성능을 보장하기 위해 워머업 및 측정 반복을 포함한 Java Microbenchmark Harness(JMH).

주요 기여

1. JEDI 벤치마크 스위트: TPC-H 에서 파생된 오픈 소스 벤치마크 스위트 출시로, 의미적으로 동등한 스트림 및 명령형 구현을 자동 생성합니다.
2. 코드 생성기: 다양한 구현 전략 (순차 최적화 및 다양한 병렬 축소 패턴) 을 지원하는 S2S 의 확장 버전.
3. 성능 가이드라인: 경험적 데이터를 기반으로 Stream API 를 효율적으로 사용하기 위한 도출된 모범 사례 집합.
4. 오버헤드 분석: API 추상화의 성능 비용을 격리하기 위해 동일한 데이터 구조 및 연산 순서를 사용하여 스트림 기반 코드와 명령형 코드를 직접 비교.

결과 및 발견

RQ1: 순차 최적화 (필터 퓨전 및 조인 구현)

• 필터 퓨전 (O1): 여러 술어를 단일 filter 호출로 결합하면 성능이 향상되며, 특히 많은 수의 술어가 존재할 때 두드러집니다 (예: 7 개의 술어가 있는 마이크로 벤치마크에서 3.54 배 속도 향상).
• 조인 구현 (O2): 조인 연산에 flatMap 대신 mapMulti 를 사용하면 상당한 개선이 이루어집니다 (Intel JDK 에서 기하 평균 속도 향상 1.38 배).
• 결론: 개발자는 가능한 경우 O1 및 O2 를 모두 적용해야 합니다.

RQ2: 병렬화 전략

• 보편적인 승자 부재: 단일 병렬 전략이 모든 시나리오를 지배하지는 않습니다. 성능은 특히 집계된 그룹의 수와 집계 특성에 따라 데이터 특성에 크게 의존합니다.
• 스칼라 대 그룹화 집계:
  • 스칼라 집계(그룹화 없음) 또는 소수의 그룹의 경우, 공유 상태 전략 (CG, CGCC) 보다 순서형 (P) 또는 비순서형 (PU) 병렬 스트림이 더 낮은 경쟁으로 인해 성능이 우수합니다.
  • 많은 수의 그룹을 가진 그룹화 집계의 경우, CG( groupingByConcurrent 사용) 가 일반적으로 가장 좋은 전략입니다. 그룹 수가 증가함에 따라 락 경쟁이 감소하여 락 기반 동기화가 효율적이 됩니다.
• 락 없는 대 락 기반: CGCC(락 없는) 는 CG(락 기반) 보다 일관되게 성능이 뛰어나지 않으며 구현 복잡성을 도입합니다. 그러나 CG 가 높은 경쟁으로 고통받는 매우 작은 그룹 수의 경우 CGCC 가 더 견고합니다.
• Distinct 연산: 일반적으로 distinct 에는 비순서형 스트림 (PU) 이 권장되지만, 연구에 따르면 소수의 고유 요소를 가진 스트림의 경우 비순서형 스트림에서 공유 ConcurrentHashMap 을 관리하는 오버헤드로 인해 순서형 병렬 스트림 (P) 이 최대 2 배 더 빠를 수 있습니다.

RQ3: 스트림 대 명령형 성능

• 명령형 우위: 명령형 루프 기반 코드는 일관되게 스트림 기반 코드보다 성능이 우수합니다.
• 규모: 다양한 JVM 및 아키텍처에서 명령형 코드가 최상의 순차 스트림 구현 대비 기하 평균 속도 향상은 1.28 배에서 1.41 배 사이입니다.
• 맥락: 이는 이전 발견을 확인하지만, 저자들은 이 격차가 일부 이전 연구보다 작다고 지적하며 시간이 지남에 따라 Stream API 구현이 개선되었음을 시사합니다. 그러나 성능이 중요한 코드에서는 명령형 코드가 여전히 훨씬 빠릅니다.

RQ4: 코드 복잡성

• 가독성: 성능 격차에도 불구하고 스트림 기반 코드는 복잡성 지수가 현저히 낮습니다.
• 지표: 베이스라인 스트림 코드의 인지적 복잡성은 명령형 코드보다 2.43 배 낮습니다. 최적화 (O1+O2) 가 적용된 경우에도 스트림 코드는 명령형 코드보다 1.62 배 덜 복잡합니다.
• 트레이드오프: 스트림 코드를 최적화하는 것 (예: 필터 퓨전) 은 복잡성 지수를 증가시키지만 명령형 동등물보다 낮은 수준에 머무릅니다.

중요성 및 주장

이 논문은 JEDI 를 Java 커뮤니티와 JVM 구현자 모두에게 필수적인 도구로 위치시킵니다:

• 개발자를 위해: 워크로드 특성에 기반하여 mapMulti, 대규모 그룹의 경우 groupingByConcurrent 와 같은 특정 패턴을 제안함으로써 Stream API 의 성능 오버헤드를 최소화하기 위한 데이터 기반 가이드라인을 제공합니다.
• 라이브러리 구현자를 위해: 벤치마크 스위트와 식별된 "오버헤드"는 명령형 코드와의 성능 격차를 해소하기 위해 Stream API 구현을 최적화하기 위한 기준선을 제공합니다.
• 연구자를 위해: 향후 최적화, 리팩토링 도구 또는 병렬화 전략을 평가하기 위한 재현 가능하고 복잡한 워크로드 (TPC-H 파생) 를 제공합니다.

저자들은 JEDI 가 현재 배열 기반 데이터 소스와 특정 SQL-to-Stream 번역 패턴에 초점을 맞추고 있다는 점을 겸손하게 인정하며, 향후 작업에서 생성기를 확장하여 더 많은 Stream API 메서드를 다루고 데이터 소스 (예: List, Set) 를 다양화할 계획이라고 밝혔습니다.