실행 효율성의 최적화는 항상 Flink가 추구하는 목표였습니다. 대부분의 작업, 특히 배치 작업에서 네트워크를 통해 작업간에 데이터를 전송하는 비용 (데이터 셔플이라고 함)은 상대적으로 높습니다. 정상적인 상황에서 네트워크를 통한 데이터 조각은 직렬화, 디스크 읽기 및 쓰기, 소켓 읽기 및 쓰기, 역 직렬화를 거쳐야 업스트림 작업에서 다운 스트림으로 전송 될 수 있습니다. 메모리에는 몇 개의 CPU 만 필요하며 주기적으로 8 바이트 포인터를 전송하는 것으로 충분합니다.
Flink의 초기 버전에서 운영자 체인 메커니즘은 동일한 동시 인접 단일 입력 운영자를 동일한 작업에 통합하여 단일 입력 운영자 간의 불필요한 네트워크 전송을 제거하는 데 사용되었습니다. 그러나 조인과 같은 다중 입력 연산자간에 추가적인 데이터 셔플 문제가 있으며, 가장 많은 양의 셔플 데이터를 가진 소스 노드와 다중 입력 연산자 간의 데이터 전송은 연산자 체인 메커니즘을 사용하여 최적화 될 수 없습니다.
Flink 1.12에서는 현재 연산자 체인으로 다룰 수없는 시나리오에 대해 다중 입력 연산자 및 소스 체인 최적화를 도입했습니다. 이 최적화는 Flink 작업에서 대부분의 중복 셔플을 제거하고 작업의 실행 효율성을 더욱 향상시킵니다. 이 기사에서는 SQL 작업을 예로 들어 위의 최적화를 소개하고 TPC-DS 테스트 세트에서 Flink 1.12의 결과를 보여줍니다.
최적화 사례 분석 : 주문량 통계
중복 셔플을 제거하는 방법을 자세히 소개하기 위해 TPC-DS q96을 예로 들어 보겠습니다.이 SQL은 다중 조인을 통해 특정 조건을 충족하는 주문을 필터링하고 계산하기위한 것입니다.
select count(*)
from store_sales
,household_demographics
,time_dim, store
where ss_sold_time_sk = time_dim.t_time_sk
and ss_hdemo_sk = household_demographics.hd_demo_sk
and ss_store_sk = s_store_sk
and time_dim.t_hour = 8
and time_dim.t_minute >= 30
and household_demographics.hd_dep_count = 5
and store.s_store_name = 'ese'
그림 1- 초기 실행 계획
중복 셔플은 어떻게 발생합니까?
일부 연산자에는 입력 데이터 배포에 대한 요구 사항이 있기 때문에 (예 : 해시 조인 연산자에는 동일한 동시성에서 데이터 조인 키의 동일한 해시 값이 필요함) 연산자간에 전달할 때 데이터를 재 배열하고 정렬해야 할 수 있습니다. 맵 축소의 셔플 프로세스와 유사하게 Flink 셔플은 업스트림 작업에서 생성 된 중간 결과를 정렬하여 요청시 이러한 중간 결과가 필요한 다운 스트림 작업으로 보냅니다. 그러나 경우에 따라 업스트림 출력 데이터가 이미 데이터 배포 요구 사항을 충족합니다 (예 : 동일한 조인 키를 사용하는 여러 연속 해시 조인 연산자). 이때 더 이상 데이터를 구성 할 필요가 없으며 결과 셔플이 생성됩니다. 실행 계획에서 순방향 셔플로 표시되는 중복 셔플이됩니다.
그림 1의 해시 조인 연산자는 브로드 캐스트 해시 조인이라는 특수 연산자입니다. 예를 들어 store_sales 조인 time_dim을 예로 들어 보겠습니다. time_dim 테이블의 데이터 양이 매우 적기 때문에 현재 브로드 캐스트 셔플은 테이블의 전체 데이터를 각 동시 해시 조인으로 전송하여 모든 동시 사용자가 모든 데이터를 수락합니다. 조인에 영향을주지 않고 store_sales 테이블 해시 조인의 실행 효율성을 향상시키면서 결과의 정확성. 이때 조인 연산자에게 store_sales 테이블의 네트워크 전송도 중복 셔플이됩니다. 마찬가지로 여러 조인 간의 셔플은 필요하지 않습니다.
그림 2- 중복 셔플 (빨간색 상자로 표시됨)
해시 조인 및 브로드 캐스트 해시 조인 외에도 동일한 그룹 키 및 조인 키를 사용한 해시 집계 + 해시 조인, 그룹 키에 대한 포함 관계가있는 다중 해시 집계 등과 같이 중복 셔플을 생성하는 많은 시나리오가 있습니다. 여기서는 확장되지 않습니다.
Operator Chaining으로 해결할 수 있습니까?
Flink 최적화 프로세스에 대해 어느 정도 이해하고있는 독자는 불필요한 순방향 셔플을 제거하기 위해 Flink가 초기 단계에서 연산자 연결 메커니즘을 도입했음을 알 수 있습니다. 이 메커니즘은 동일한 동시 인접 단일 입력 연산자를 동일한 작업에 통합하고 동일한 스레드에서 함께 작업을 수행합니다. 연산자 체인 메커니즘은 그림 1에서 이미 효과가 있습니다. 그렇지 않으면 브로드 캐스트 셔플의 세 소스 노드 이름에서 "->"로 구분 된 연산자가 여러 다른 작업으로 분할되어 중복 데이터 셔플이 발생합니다. 그림 3은 연산자 체인의 실행 계획을 보여줍니다.
그림 3- 연산자 체인이 닫힌 후 실행 계획
네트워크와 파일을 통한 TM 간의 데이터 전송을 줄이고 운영자 링크를 작업에 병합하는 것은 매우 효과적인 최적화입니다. 스레드 간 전환을 줄이고 메시지의 직렬화 및 역 직렬화를 줄이며 데이터 양을 줄일 수 있습니다. 대기 시간을 줄이면서 전체 처리량을 교환하고 향상시킵니다. 그러나 연산자 체인은 연산자 통합에 대해 매우 엄격한 제한이 있으며, 그중 하나는 "다운 스트림 연산자의 차수가 1"이며, 이는 다운 스트림 연산자가 하나의 입력 만 가질 수 있음을 의미합니다. 여기에는 다중 입력 연산자 (예 : 조인)가 제외됩니다.
다중 입력 연산자의 솔루션 : 다중 입력 연산자
연산자 체인의 최적화 아이디어를 모방 할 수 있다면 새로운 최적화 메커니즘을 도입하고 다음 조건을 충족하십시오.
- 이 메커니즘은 다중 입력 연산자를 결합 할 수 있습니다.
- 이 메커니즘은 여러 입력을 지원합니다 (결합되는 연산자에 대한 입력 제공).
순방향 셔플과 연결된 다중 입력 연산자를 실행을 위해 하나의 작업에 넣어 불필요한 셔플을 제거 할 수 있습니다. Flink 커뮤니티는 오래 전 연산자 체인의 단점에 주목 해 왔으며 Flink 1.11에서는 스트리밍 API 계층의 MultipleInputTransformation과 해당 MultipleInputStreamTask가 도입되었습니다. 이러한 API는 위의 조건 2를 충족하고 Flink 1.12는이 다중 입력 연산자를 기반으로 SQL 계층에서 조건 1을 충족하는 새로운 연산자를 구현합니다. FLIP 문서 [1]을 참조 할 수 있습니다.
다중 입력 연산자는 테이블 계층의 플러그 가능한 최적화입니다. 테이블 계층 최적화의 마지막 단계에 있으며 생성 된 실행 계획을 탐색하고 교환에 의해 차단되지 않은 인접 연산자를 다중 입력 연산자로 통합합니다. 그림 4는 원래 SQL 최적화 단계에 대한 최적화 수정을 보여줍니다.
그림 4- 여러 입력 연산자를 추가 한 후의 최적화 단계
독자에게 질문이있을 수 있습니다. 기존 연산자 체인을 수정하고 새로 시작하지 않는 이유는 무엇입니까? 실제로 연산자 연결을 완료하는 것 외에도 여러 입력 연산자는 각 입력의 우선 순위를 정렬해야합니다. 일부 다중 입력 연산자 (예 : 해시 조인 및 중첩 루프 조인)는 입력에 엄격한 순서 제한이 있기 때문이며 입력 우선 순위가 제대로 정렬되지 않으면 교착 상태가 발생할 수 있습니다. 연산자 입력 우선 순위의 정보는 테이블 계층의 연산자에서만 설명되므로보다 자연스러운 방법은 테이블 계층에 최적화 메커니즘을 도입하는 것입니다.
다중 입력 연산자는 여러 연산자를 관리하는 연산자 체인과 다르며 그 자체가 큰 연산자이고 내부 작업은 외부 세계의 블랙 박스입니다. 다중 입력 연산자의 내부 구조는 연산자 이름에 완전히 반영됩니다. 독자는 연산자가 포함 된 작업을 실행할 때 어떤 토폴로지에서 어떤 연산자가 다중 입력 연산자로 결합되는지 연산자 이름에서 볼 수 있습니다.
그림 5는 다중 입력에 의해 최적화 된 연산자의 토폴로지 다이어그램과 다중 입력 연산자의 관점 다이어그램을 보여줍니다. 그림의 세 해시 조인 연산자 사이의 중복 셔플이 제거 된 후에는 하나의 작업에서 실행할 수 있지만 연산자 체인은이 다중 입력 상황을 처리 할 수 없습니다. 다중 입력 연산자 실행에 넣으면 다중 입력 연산자가 관리합니다. 각 연산자의 입력 시퀀스와 연산자 간의 호출 관계.
그림 5- 다중 입력 최적화 후 연산자 토폴로지
다중 입력 연산자의 구성 및 운영은 더 복잡하며,이 세부 사항에 관심이있는 독자는 설계 문서 [2]를 참조 할 수 있습니다.
소스를 놓칠 수 없음 : 소스 체인
다중 입력 연산자 최적화 후 그림 1 ~ 그림 6의 실행 계획을 최적화하고, 그림 3은 연산자 체이닝에 의한 최적화 후 그림 6의 실행 그래프가된다.
그림 6- 다중 입력 연산자에 의해 최적화 된 실행 계획
그림 6의 store_sales 테이블에서 생성 된 순방향 셔플 (빨간색 상자에 표시됨)은 여전히 최적화의 여지가 있음을 나타냅니다. 서문에서 언급했듯이 대부분의 작업에서 소스에서 직접 생성 된 데이터는 조인과 같은 연산자에 의해 필터링 및 처리되지 않으며 셔플의 데이터 양이 가장 큽니다. 10T 데이터에서 TPC-DS q96을 예로 들어 더 이상 최적화가 수행되지 않으면 store_sales 소스 테이블이 포함 된 작업이 1.03T의 데이터를 네트워크로 전송하고 조인 스크리닝 후 데이터 볼륨이 16.5로 빠르게 감소합니다. 지. 소스 테이블의 순방향 셔플을 생략 할 수 있다면 작업의 전반적인 실행 효율성이 크게 향상 될 수 있습니다.
불행히도 다중 입력 연산자는 소스가 입력이 없다는 점에서 다른 연산자와 다르기 때문에 소스 셔플 시나리오를 다룰 수 없습니다. 이러한 이유로 Flink 1.12는 셔플에 의해 차단되지 않은 소스를 운영자 체인에 병합하여 소스와 다운 스트림 운영자 사이의 순방향 셔플을 제거하는 소스 체인 기능을 운영자 체인에 추가합니다.
현재는 FLIP-27 소스와 다중 입력 연산자 만 소스 체인 기능을 사용할 수 있지만이 기사에서는 최적화 시나리오를 해결하기에 충분합니다.
여러 입력 연산자와 소스 체인을 결합한 후 그림 7은이 기사에서 최적화 사례의 최종 실행 계획을 보여줍니다.
그림 7- 최적화 된 실행 계획
TPC-DS 테스트 결과
다중 입력 연산자 및 소스 체인은 대부분의 작업, 특히 배치 작업에 상당한 최적화 효과를 제공합니다. Flink 1.12의 전체 성능을 테스트하기 위해 TPC-DS 테스트 세트를 사용했습니다. Flink 1.10에서 발표 한 총 12267 초에 비해 Flink 1.12의 총 시간은 8708 초로 실행 시간이 거의 30 % 단축되었습니다!
그림 8-TPC-DS 테스트 세트 총 시간 비교
그림 9- TPC-DS의 일부 테스트 포인트에 대한 시간 비교
향후 계획
TPC-DS의 테스트 결과를 통해 소스 체인 + 다중 입력이 성능을 크게 향상시킬 수 있음을 알 수 있습니다. 현재 전체 프레임 워크가 완성되었으며 일반적으로 사용되는 배치 연산자는 중복 교환을 제거하는 파생 논리를 지원하고 있으며 향후 더 많은 배치 연산자와 더 정제 된 파생 알고리즘을 지원할 것입니다.
스트리밍 작업의 데이터 셔플은 일괄 작업처럼 디스크에 데이터를 쓸 필요가 없지만 네트워크 전송으로 인한 메모리 전송으로 인한 성능 향상도 매우 인상적입니다. 따라서 소스 체인 + 다중 입력을 지원하는 스트리밍 작업은 다음과 같습니다. 또한 매우 자극적입니다. 최적화가 예상됩니다. 동시에 스트림 작업에 대한이 최적화를 지원하려면 많은 작업이 필요합니다. 예를 들어 스트림 운영자에 대한 중복 교환을 제거하기위한 파생 로직은 아직 지원되지 않으며 일부 운영자는 재구성해야합니다. 입력 데이터는 바이너리 등입니다. 이것이 Flink 1.12가 스트리밍 작업에서이 최적화에 대한 이유를 아직 도입하지 않은 이유입니다. 후속 버전에서는 이러한 작업을 점진적으로 완료 할 것이며 더 많은 커뮤니티 팀이 우리와 함께 가능한 한 빨리 더 많은 최적화를 구현하기를 바랍니다.
저자 ｜ He Xiaoling, Weng Caizhi
이 기사는 Alibaba Cloud의 원본 콘텐츠이며 허가없이 복제 할 수 없습니다.