파이프라인을 사용하면 드라이버와 각 실행자에 제공할 CPU와 메모리를 지정할 수 있습니다. Cloud Data Fusion Studio 파이프라인 구성에서 리소스를 구성할 수 있습니다. 자세한 내용은 파이프라인 구성 관리를 참조하세요.
이 페이지에서는 사용 사례에 맞게 구성할 드라이버 및 실행자 리소스의 양에 대한 가이드라인을 제공합니다.
드라이버
드라이버에서 많은 작업을 수행하지 않으므로 기본적으로 대부분의 파이프라인을 실행하는 데 CPU 1개와 메모리 2GB로 충분합니다. 많은 스테이지 또는 대규모 스키마가 포함된 파이프라인의 메모리를 늘려야 할 수 있습니다. JOIN의 병렬 처리에서 언급한 바와 같이 파이프라인에서 인메모리 조인을 실행하는 경우 인메모리 데이터 세트도 드라이버의 메모리에 맞아야 합니다.
실행자
CPU 및 메모리 리소스에 대한 다음 가이드라인을 고려하세요.
CPU
실행자에 할당된 CPU 수에 따라 실행자에서 동시에 실행할 수 있는 태스크 수가 결정됩니다. 데이터의 각 파티션을 처리하려면 태스크 하나가 필요합니다. 대부분의 경우 CPU 수를 1로 설정하고 메모리 조정에 집중하는 것이 가장 간단합니다.
메모리
대부분의 파이프라인의 경우 파이프라인을 실행하는 데 실행자 메모리 4GB로 충분합니다. 심하게 왜곡된 멀티 테라바이트 조인은 실행자 메모리 4GB로 완료되었습니다. 메모리 양을 늘려 실행 속도를 향상시킬 수 있지만 이렇게 하려면 데이터와 파이프라인 모두 잘 이해해야 합니다.
Spark는 메모리를 여러 섹션으로 나눕니다. 섹션 하나는 Spark 내부 사용을 위해 예약되고 다른 섹션은 실행과 스토리지를 위해 예약됩니다.
기본적으로 스토리지 및 실행 섹션은 총 메모리의 약 60%를 차지합니다. Spark의 spark.memory.fraction configuration 속성(기본값: 0.6)은 이 비율을 제어합니다. 이 양은 대부분의 워크로드를 잘 수행하며 일반적으로 조정할 필요는 없습니다.
스토리지 및 실행 섹션은 추가적으로 스토리지와 실행을 위한 별도의 공간으로 나뉩니다. 기본적으로 이러한 공간의 크기는 같지만 spark.memory.storageFraction(기본값: 0.5)을 설정하여 공간을 조정하여 스토리지용으로 예약되는 공간의 비율을 제어할 수 있습니다.
저장공간에는 캐시된 데이터가 저장됩니다. 실행 공간에는 셔플, 조인, 정렬, 집계 데이터가 저장됩니다. 실행 섹션에 여유 공간이 있으면 Spark에서 여유 공간 일부를 데이터 저장에 사용할 수 있습니다. 그러나 실행 데이터는 어떠한 저장공간도 사용하지 않습니다.
파이프라인이 데이터를 캐시하지 않는다는 것을 알고 있으면 스토리지 비율을 줄여 실행 요구사항을 위한 공간을 더 확보할 수 있습니다.
고려사항: YARN 컨테이너 메모리
실행자 메모리 설정은 실행자에게 할당되는 힙 메모리 양을 제어합니다. Spark는 기본값이 384m인 spark.executor.memoryOverhead 설정에 의해 제어되는 오프힙 메모리에 메모리 양을 추가합니다. 즉, YARN이 각 실행자에 대해 예약하는 메모리 양이 파이프라인 리소스 구성에서 설정한 숫자보다 큽니다. 예를 들어 실행자 메모리를 2,048m으로 설정하면 Spark는 이 수치에 384m을 더하고 YARN에 2,432m 컨테이너를 요청합니다. 또한 YARN은 요청 수를 yarn.scheduler.increment-allocation-mb의 배수로 올림하며 기본값은 yarn.scheduler.minimum-allocation-mb 값입니다. 512로 설정하면 YARN은 2432m을 2560m으로 올림합니다. 값을 1,024로 설정하면 YARN은 2,432m을 3,072m으로 올림합니다. 클러스터의 각 워커 노드 크기를 결정할 때 이 점을 염두에 두어야 합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(UTC)"],[[["\u003cp\u003ePipelines allow users to specify CPU and memory allocation for both the driver and each executor, configurable within the Cloud Data Fusion Studio pipeline settings.\u003c/p\u003e\n"],["\u003cp\u003eFor most pipelines, the default driver configuration of 1 CPU and 2 GB of memory is sufficient, but memory may need to be increased for pipelines with many stages or large schemas, particularly those performing in-memory joins.\u003c/p\u003e\n"],["\u003cp\u003eWhile setting the number of CPUs per executor to one is usually adequate, users should focus primarily on adjusting memory, with 4 GB of executor memory being enough for most pipelines, even complex ones.\u003c/p\u003e\n"],["\u003cp\u003eSpark divides executor memory into sections for its internal usage, execution, and storage, with the execution and storage space being adjustable via Spark's \u003ccode\u003espark.memory.fraction\u003c/code\u003e and \u003ccode\u003espark.memory.storageFraction\u003c/code\u003e properties, respectively.\u003c/p\u003e\n"],["\u003cp\u003eThe total memory YARN reserves for each executor exceeds the configured executor memory due to the \u003ccode\u003espark.executor.memoryOverhead\u003c/code\u003e setting, and this YARN request is rounded up to a multiple of \u003ccode\u003eyarn.scheduler.increment-allocation-mb\u003c/code\u003e, which should be considered when sizing worker nodes.\u003c/p\u003e\n"]]],[],null,["# Resource management\n\nPipelines let you specify the CPUs and memory to give to the driver and each\nexecutor. You can configure resources in the Cloud Data Fusion Studio pipeline\nconfigurations. For more information, see [Manage pipeline configurations](/data-fusion/docs/concepts/manage-pipeline-configurations).\n\nThis page provides the guidelines on how much driver and executor resources to\nconfigure for your use case.\n\nDriver\n------\n\nSince the driver doesn't do much work, the default of 1 CPU and 2 GB\nmemory is enough to run most pipelines. You might need to increase the memory\nfor pipelines that contain many stages or large schemas. As mentioned in\n[Parallel processing of JOINs](/data-fusion/docs/concepts/parallel-processing-join-operations), if the pipeline is performing in-memory\njoins, the in-memory datasets also need to fit in the driver's memory.\n\nExecutor\n--------\n\nConsider the following guidelines on CPU and memory resources.\n\n### CPU\n\nThe number of CPUs assigned to an executor determines the number of tasks the\nexecutor can run in parallel. Each partition of data requires one task to\nprocess. In most cases, it's simplest to set the number of CPUs to one, and\ninstead focus on adjusting memory.\n\n### Memory\n\nFor most pipelines, 4 GB of executor memory is enough to successfully run\nthe pipeline. Heavily skewed, multi-terabyte joins have been completed with\n4 GB of executor memory. It's possible to improve execution speed by\nincreasing the amount of memory, but this requires a strong understanding of\nboth your data and your pipeline.\n\nSpark divides memory into several sections. A section is reserved for Spark\ninternal usage, and another is for execution and storage.\n\nBy default, the storage and execution section is roughly 60% of the total\nmemory. Spark's `spark.memory.fraction configuration` property (defaults to 0.6)\ncontrols this percentage. This amount performs well for most workloads and\nnormally doesn't need to be adjusted.\n\nThe storage and execution section is further divided into separate spaces for\nstorage and execution. By default, those spaces are the same size, but you can\nadjust them by setting `spark.memory.storageFraction` (defaults to 0.5) to\ncontrol what percentage of the space is reserved for storage.\n\nThe storage space stores cached data. The execution space stores shuffle, join,\nsort, and aggregation data. If there's extra space in the execution section,\nSpark can use some of it for storage data. However, execution data will never\nuse any of the storage space.\n\nIf you know your pipeline isn't caching any data, you can reduce the storage\nfraction to leave more room for execution requirements.\n\n#### Point to consider: YARN container memory\n\nThe executor memory setting controls the amount of heap memory given to the\nexecutors. Spark adds an additional amount of memory for off-heap memory, which\nis controlled by the `spark.executor.memoryOverhead` setting, which defaults to\n384m. That means that the amount of memory YARN reserves for each executor is\nhigher than the number set in the pipeline resources configuration. For example,\nif you set executor memory to 2048m, Spark adds 384m to that number and requests\nYARN for a 2432m container. On top of that, YARN rounds the request number up to\na multiple of `yarn.scheduler.increment-allocation-mb`, which defaults to the\nvalue of `yarn.scheduler.minimum-allocation-mb`. If it is set to 512, YARN\nrounds the 2432m up to 2560m. If the value is set to 1024, YARN rounds up the\n2432m to 3072m. This point is useful to keep in mind when determining the size\nof each worker node in your cluster."]]
