파이프라인에서 높은 초기화 시간 해결

파이프라인은 흐름을 최신 상태로 유지하기 위해 많은 흐름이 있는 많은 데이터 세트를 포함할 수 있습니다. 파이프라인은 업데이트 및 클러스터를 자동으로 관리하여 효율적으로 업데이트합니다. 그러나 많은 수의 흐름을 관리하는 데 약간의 오버헤드가 있으며, 이로 인해 처리 중에 예상보다 큰 초기화 또는 관리 오버헤드가 발생할 수 있습니다.

5분 동안의 초기화 시간과 같이 트리거된 파이프라인이 초기화되기를 기다리는 지연이 발생하는 경우 데이터 세트가 동일한 원본 데이터를 사용하는 경우에도 처리를 여러 파이프라인으로 분할하는 것이 좋습니다.

파이프라인 분할을 고려해야 하는 경우

성능상의 이유로 파이프라인 분할이 유리할 수 있는 몇 가지 경우가 있습니다.

• INITIALIZING 단계 및 SETTING_UP_TABLES 단계가 원하는 것보다 오래 걸리며 전체 파이프라인 시간에 영향을 줍니다. 5분 이상인 경우 파이프라인을 분할하여 개선되는 경우가 많습니다.
• 클러스터를 관리하는 드라이버는 단일 파이프라인 내에서 많은(30-40개 이상) 스트리밍 테이블을 실행할 때 병목 상태가 될 수 있습니다. 드라이버가 응답하지 않는 경우 스트리밍 쿼리에 대한 기간이 늘어나 업데이트의 총 시간에 영향을 줍니다.
• 여러 스트리밍 테이블 흐름이 있는 트리거된 파이프라인이 병렬로 병렬 처리 가능한 모든 스트림 업데이트를 수행하지 못할 수 있습니다.

성능 문제에 대한 세부 정보

이 섹션에서는 단일 파이프라인에 많은 테이블과 흐름이 있기 때문에 발생할 수 있는 몇 가지 성능 문제에 대해 설명합니다.

INITIALIZING 및 SETTING UP TABLES 단계의 병목 현상

실행의 초기 단계는 파이프라인의 복잡성에 따라 성능 병목 상태일 수 있습니다.

초기화 단계

이 단계에서는 종속성 그래프를 빌드하고 테이블 업데이트 순서를 결정하는 계획을 포함하여 논리 계획을 만듭니다.

SETTING_UP_TABLES 단계

이 단계에서는 이전 단계에서 만든 계획에 따라 다음 프로세스가 수행됩니다.

• 파이프라인에 정의된 모든 테이블에 대한 스키마 유효성 검사 및 확인
• 종속성 그래프를 빌드하고 테이블 실행 순서를 결정합니다.
• 각 데이터 세트가 파이프라인에서 활성화되어 있는지 또는 이전 업데이트 이후 새 데이터 세트인지 확인합니다.
• 첫 번째 업데이트에서 스트리밍 테이블을 만들고 구체화된 뷰의 경우 모든 파이프라인 업데이트 중에 필요한 임시 뷰 또는 백업 테이블을 만듭니다.

INITIALIZING 및 테이블 설정이 더 오래 걸릴 수 있는 이유

여러 데이터 세트에 대한 많은 흐름이 있는 대규모 파이프라인은 여러 가지 이유로 더 오래 걸릴 수 있습니다.

• 흐름이 많고 종속성이 복잡한 파이프라인의 경우 작업 볼륨으로 인해 이러한 단계가 더 오래 걸릴 수 있습니다.
• 변환을 비롯한 Auto CDC 복잡한 변환은 정의된 변환에 따라 테이블을 구체화하는 데 필요한 작업으로 인해 성능 병목 현상이 발생할 수 있습니다.
• 또한 해당 흐름이 업데이트의 일부가 아니더라도 많은 수의 흐름으로 인해 속도가 느려질 수 있는 시나리오도 있습니다. 예를 들어 700개가 넘는 흐름이 있는 파이프라인을 고려합니다. 그 중 50개 미만이 구성을 기반으로 각 트리거에 대해 업데이트됩니다. 이 예제에서 각 실행은 모든 700개 테이블에 대한 단계 중 일부를 통과하고, 데이터 프레임을 가져와서 실행할 테이블을 선택해야 합니다.

드라이버의 병목 현상

드라이버는 실행 내에서 업데이트를 관리합니다. 각 흐름을 처리해야 하는 클러스터의 인스턴스를 결정하려면 모든 테이블에 대해 몇 가지 논리를 실행해야 합니다. 단일 파이프라인 내에서 여러(30-40개 이상) 스트리밍 테이블을 실행하는 경우 클러스터 전체에서 작업을 처리할 때 드라이버가 CPU 리소스에 병목 상태가 될 수 있습니다.

드라이버에 메모리 문제가 발생할 수도 있습니다. 이는 병렬 흐름 수가 30개 이상일 때 더 자주 발생할 수 있습니다. 드라이버 메모리 문제를 일으킬 수 있는 특정 수의 흐름 또는 데이터 세트는 없지만 병렬로 실행되는 작업의 복잡성에 따라 달라집니다.

스트리밍 흐름은 병렬로 실행될 수 있지만, 이를 위해서는 드라이버가 모든 스트림에 메모리 및 CPU를 동시에 사용해야 합니다. 트리거된 파이프라인에서 드라이버는 메모리 및 CPU 제약 조건을 방지하기 위해 한 번에 병렬로 스트림의 하위 집합을 처리할 수 있습니다.

이러한 모든 경우에서 각각에 최적의 흐름 집합이 있도록 파이프라인을 분할하면 초기화 및 처리 시간이 빨라질 수 있습니다.

파이프라인 분할 시의 절충점

모든 흐름이 동일한 파이프라인 내에 있는 경우 Lakeflow Spark 선언적 파이프라인은 종속성을 관리합니다. 여러 파이프라인이 있는 경우 파이프라인 간의 종속성을 관리해야 합니다.

• 종속성 여러 업스트림 파이프라인(하나 대신)에 의존하는 다운스트림 파이프라인이 있을 수 있습니다. 예를 들어, pipeline_A, pipeline_B, pipeline_C 세 개의 파이프라인이 있고, pipeline_C가 pipeline_A와 pipeline_B 모두에 의존한다면, pipeline_C는 pipeline_A과 pipeline_B가 각각의 업데이트를 완료한 후에만 업데이트되어야 합니다. 이 문제를 해결하는 한 가지 방법은 종속성이 올바르게 모델링된 작업 에서 각 파이프라인을 작업으로 만들어 종속성을 오케스트레이션하는 것이므로 pipeline_C 둘 다 pipeline_Apipeline_B 완료된 후에만 업데이트됩니다.

• 동시성 파이프라인 내의 서로 다른 흐름은 완료하는 데 매우 다른 시간이 걸릴 수 있습니다. 예를 들어 flow_A은(는) 15초 만에 업데이트되는 반면, flow_B은(는) 완료하는 데 몇 분이 걸릴 수 있습니다. 파이프라인을 분할하기 전에 쿼리 시간을 확인하고 짧은 쿼리를 함께 그룹화하는 것이 유용할 수 있습니다.

파이프라인 분할 계획

시작하기 전에 파이프라인 분할을 시각화할 수 있습니다. 다음은 25개 테이블을 처리하는 원본 파이프라인의 그래프입니다. 단일 루트 데이터 원본은 각각 2개의 뷰가 있는 8개의 세그먼트로 분할됩니다.

파이프라인을 분할한 후 두 개의 파이프라인이 있습니다. 하나는 단일 루트 데이터 원본을 처리하고 4개 세그먼트 및 연결된 뷰를 처리합니다. 두 번째 파이프라인은 다른 4개 세그먼트와 연결된 뷰를 처리합니다. 두 번째 파이프라인은 첫 번째 파이프라인을 사용하여 루트 데이터 원본을 업데이트합니다.

전체 새로 고침 없이 파이프라인 분할

파이프라인 분할을 계획한 후 필요한 새 파이프라인을 만들고 파이프라인 간에 테이블을 이동하여 파이프라인 부하를 분산합니다. 전체 새로 고침을 유발하지 않고 테이블을 이동할 수 있습니다.

자세한 내용은 파이프라인 간에 테이블 이동을 참조하세요.

이 방법에는 몇 가지 제한 사항이 있습니다.

• 파이프라인은 Unity 카탈로그에 있어야 합니다.
• 원본 및 대상 파이프라인은 동일한 작업 영역 내에 있어야 합니다. 작업 영역 간 이동은 지원되지 않습니다.
• 이동 전에 대상 파이프라인을 만들고 한 번 실행해야 합니다(실패하더라도).
• 기본 게시 모드를 사용하는 파이프라인에서 레거시 게시 모드를 사용하는 파이프라인으로 테이블을 이동할 수 없습니다. 자세한 내용은 LIVE 스키마(레거시)를 참조하세요.