Cloud Data Fusion은 기본적으로 자동 확장을 컴퓨팅 프로필로 사용했습니다.
워크로드에 가장 적절한 클러스터 작업자(노드) 수를 예측하는 것은 어려우며 전체 파이프라인에 단일 클러스터 크기를 사용하는 것이 적합하지 않은 경우가 많습니다.
Dataproc 자동 확장은 클러스터 리소스 관리를 자동화하는 메커니즘을 제공하고 클러스터 작업자 VM 자동 확장을 사용 설정합니다. 자세한 내용은 자동 확장을 참조하세요.
프로필 목록을 볼 수 있는 Compute 구성 페이지에는 프로필에서 확장할 수 있는 최대 v CPU(예: Up to 84)가 있는 총 코어 열이 있습니다.
Dataproc Compute 프로필을 사용하려는 경우 파이프라인 크기에 따라 클러스터 크기를 관리할 수 있습니다.
마스터 노드
마스터 노드는 클러스터에서 실행 중인 파이프라인 또는 추가 애플리케이션 수에 비례하는 리소스를 사용합니다. 임시 클러스터에서 파이프라인을 실행하는 경우 마스터 노드에 2개의 CPU와 8GB 메모리를 사용합니다. 영구 클러스터를 사용 중인 경우 워크플로를 계속 진행하기 위해 더 큰 마스터 노드가 필요할 수 있습니다. 더 큰 마스터 노드가 필요한지 확인하려면 해당 노드에서 메모리 및 CPU 사용을 모니터링하면 됩니다. 최소 2개의 CPU와 8GB 메모리로 작업자 노드 크기를 조정하는 것이 좋습니다. 더 큰 메모리를 사용하도록 파이프라인을 구성한 경우 더 큰 작업자를 사용해야 합니다.
실행 시간을 최소화하려면 클러스터에 최대한 많은 병렬 처리가 가능하도록 충분한 노드가 있는지 확인합니다.
작업자
다음 섹션에서는 워커 노드 크기 조정의 여러 측면을 설명합니다.
CPU 및 메모리
최소 2개의 CPU와 8GB 메모리를 사용하여 워커 노드 크기를 조정하는 것이 좋습니다. 더 큰 메모리를 사용하도록 파이프라인을 구성한 경우 더 큰 작업자를 사용합니다. 예를 들어 CPU가 4개이고 15GB의 워커 노드가 있으면 각 작업자는 YARN 컨테이너를 실행하는 데 사용할 수 있는 4개의 CPU와 12GB를 갖게 됩니다. 파이프라인이 1개의 CPU, 8GB 실행자를 실행하도록 구성되어 있는 경우 YARN은 워커 노드당 두 개 이상의 컨테이너를 실행할 수 없습니다. 각 워커 노드에는 아무것도 실행하는 데 사용할 수 없으므로 낭비되는 3개의 CPU와 4GB가 추가로 있습니다. 클러스터에서 리소스 사용률을 극대화하려면 YARN 메모리와 CPU가 Spark 실행자당 필요한 양의 정확한 배수가 되어야 합니다. YARN에서 yarn.nodemanager.resource.memory-mb 속성을 확인하여 각 작업자가 YARN에 예약한 메모리 양을 확인할 수 있습니다.
Dataproc을 사용하는 경우 YARN 컨테이너에 사용 가능한 메모리는 VM 메모리의 약 75%입니다. 최소 YARN 컨테이너 크기도 작업자 VM의 크기에 따라 조정됩니다. 몇 가지 일반적인 작업자 크기 및 해당 YARN 설정은 다음 표에 나와 있습니다.
작업자 CPU
작업자 메모리(GB)
YARN 노드 메모리(GB)
YARN 최소 할당 메모리(MB)
1
4
3
256
2
8
6
512
4
16
12
1024
8
32
24
1024
16
64
51
1024
Spark는 파이프라인에 설정된 실행자 메모리보다 더 많은 메모리를 요청하고 YARN은 요청된 양을 올림합니다. 예를 들어, 실행자 메모리를 2,048MB로 설정하고 spark.yarn.executor.memoryOverhead에 대한 값을 지정하지 않았다고 가정하면 384MB의 기본값이 사용됩니다. 즉, Spark는 각 실행자에 대해 2,048MB + 384MB를 요청하고 YARN은 YARN 최소 할당의 정확한 배수로 올림합니다. 8GB 워커 노드에서 실행하는 경우 YARN 최소 할당이 512MB이므로 2.5GB로 올림됩니다. 즉, 각 작업자는 두 개의 컨테이너를 실행하여 사용 가능한 모든 CPU를 사용하지만 1GB의 YARN 메모리(6GB - 2.5GB - 2.5GB)는 사용하지 않습니다. 즉, 워커 노드의 크기를 실제로 조금 더 작게 할 수 있거나 실행자에 약간 더 많은 메모리를 제공할 수 있습니다.
16GB 워커 노드에서 실행하는 경우 YARN 최소 할당이 1,024MB이므로 2,048MB + 1,024MB는 3GB로 올림됩니다.
즉, 각 워커 노드는 모든 CPU와 YARN 메모리를 사용하면서 4개의 컨테이너를 실행할 수 있습니다.
맥락을 파악할 수 있도록 다음 표에서는 일반적인 실행자 크기를 기준으로 권장되는 작업자 크기를 보여줍니다.
실행자 CPU
실행자 메모리(MB)
작업자 CPU
작업자 메모리( GB)
1
2048
4
15
1
3072
4
21
1
4096
4
26
2
8192
4
26
예를 들어 26GB 워커 노드는 YARN 컨테이너를 실행하는 데 사용할 수 있는 20GB 메모리로 변환됩니다. 실행자 메모리를 4GB로 설정하면 오버헤드로 1GB가 추가됩니다. 즉, 각 실행자에 5GB YARN 컨테이너가 있습니다. 이는 작업자가 남은 추가 리소스 없이 4개의 컨테이너를 실행할 수 있다는 것을 의미합니다.
작업자의 크기를 곱할 수도 있습니다. 예를 들어 실행자 메모리가 4,096GB로 설정되어 있는 경우 8개의 CPU와 52GB 메모리를 가진 작업자도 잘 작동합니다. Compute Engine VM은 코어 수에 따라 VM이 가질 수 있는 메모리 양을 제한합니다. 예를 들어 코어가 4개인 VM에는 최소 7.25GB 메모리 및 최대 26GB 메모리가 있어야 합니다. 이는 1개의 CPU와 8GB 메모리를 사용하도록 설정된 실행자가 VM에서 2개의 CPU와 26GB 메모리를 사용한다는 것을 의미합니다. 대신 실행자가 2개의 CPU와 8GB 메모리를 사용하도록 구성되면 모든 CPU가 사용됩니다.
디스크
디스크는 전체가 아닌 일부 파이프라인에서 중요합니다. 파이프라인에 셔플이 포함되지 않은 경우 디스크는 Spark에서 메모리가 부족하여 데이터를 디스크로 보내야 할 때만 사용됩니다. 이러한 파이프라인 유형의 경우 디스크 크기 및 유형은 일반적으로 성능에 큰 영향을 미치지 않습니다. 파이프라인에서 많은 데이터를 셔플하는 경우 디스크 성능이 차이를 가져옵니다. Dataproc을 사용하는 경우 디스크 성능은 디스크 크기에 따라 확장되므로 최소 1TB의 디스크 크기를 사용하는 것이 좋습니다. 디스크 성능에 대한 자세한 내용은 성능 요구사항을 충족하도록 디스크 구성을 참조하세요.
작업자 수
실행 시간을 최소화하려면 클러스터가 가능한 한 병렬로 실행할 수 있을 만큼 충분히 큰지 확인해야 합니다. 예를 들어 파이프라인 소스가 100개의 분할을 사용하여 데이터를 읽는 경우 클러스터가 한 번에 100개의 실행자를 실행할 수 있을 만큼 충분히 큰지 확인해야 합니다.
클러스터 크기가 작은지 알 수 있는 가장 쉬운 방법은 시간 경과에 따라 YARN 보류 메모리를 살펴보는 것입니다. Dataproc을 사용하는 경우 클러스터 세부정보 페이지에서 그래프를 찾을 수 있습니다
보류 메모리가 장시간 높은 경우 작업자 수를 늘려 클러스터에 그만큼의 추가 용량을 추가할 수 있습니다. 이전 예시에서는 클러스터를 약 28GB 늘려 최대 수준의 동시 로드를 달성해야 합니다.
향상된 유연성 모드(EFM)
EFM을 사용하면 데이터를 셔플할 때 기본 워커 노드만 관련되도록 지정할 수 있습니다. 보조 작업자는 더 이상 중간 셔플 데이터를 담당하지 않으므로 클러스터에서 제거될 때 Spark 작업은 지연되거나 오류가 발생하지 않습니다. 기본 작업자는 축소되지 않으므로 클러스터가 축소되고 안정성과 효율성이 향상됩니다. 정적 클러스터에서 셔플이 있는 파이프라인을 실행하는 경우 EFM을 사용하는 것이 좋습니다.
[[["이해하기 쉬움","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\u003eCloud Data Fusion utilizes Autoscale as the default compute profile, but Dataproc Autoscaling offers automated cluster resource management for dynamic worker VM scaling.\u003c/p\u003e\n"],["\u003cp\u003eMaster nodes require resources based on the number of pipelines or applications running, with a recommendation of at least 2 CPUs and 8 GB of memory for ephemeral clusters, and possibly larger nodes for persistent clusters.\u003c/p\u003e\n"],["\u003cp\u003eWorker nodes should ideally be sized with at least 2 CPUs and 8 GB of memory, adjusting for pipelines that need more memory, and worker node resource utilization can be optimized by ensuring YARN memory and CPU requirements align with Spark executor needs.\u003c/p\u003e\n"],["\u003cp\u003eTo minimize pipeline execution time, ensure the cluster has enough nodes to process as much as possible in parallel, for instance, if a pipeline uses 100 data splits, then the cluster needs to run 100 executors simultaneously.\u003c/p\u003e\n"],["\u003cp\u003eEnhanced Flexibility Mode (EFM) is recommended for pipelines with shuffles on static clusters, as it involves only primary worker nodes in data shuffling, leading to more stable and efficient cluster scaling.\u003c/p\u003e\n"]]],[],null,["# Cluster sizing\n\nCloud Data Fusion by default used Autoscale as the compute profile.\nEstimating the best number of cluster workers (nodes) for a workload is\ndifficult, and a single cluster size for an entire pipeline is often not ideal.\nThe Dataproc Autoscaling provides a mechanism for automating\ncluster resource management and enables cluster worker VM autoscaling. For more\ninformation, see [Autoscaling](/dataproc/docs/concepts/configuring-clusters/autoscaling)\n\nOn the **Compute config** page, where you can see a list of profiles, there is a\n**Total cores** column, which has the maximum v CPUs that the profile can\nscale up to, such as `Up to 84`.\n\nIf you want to use the Dataproc Compute profile , you can manage\ncluster sizes based on the pipeline size.\n\nMaster node\n-----------\n\nMaster nodes use resources proportional to the number of pipelines or additional\napplications that are running on the cluster. If you're running pipelines on\nephemeral clusters, use 2 CPUs and 8 GB of memory for the master\nnodes. If you're using persistent clusters, you might need larger master nodes\nto keep up with the workflow. To understand if you need larger master nodes, you\ncan monitor memory and CPU usage on the node. We recommend sizing your\nworker nodes with at least 2 CPUs and 8 GB of memory. If you've\nconfigured your pipelines to use larger amounts of memory, then you must use\nlarger workers.\n\nTo minimize execution time, ensure that your cluster has enough nodes to allow\nfor as much parallel processing as possible.\n\nWorkers\n-------\n\nThe following sections describe aspects of sizing worker nodes.\n\n### CPU and Memory\n\nWe recommend sizing your worker nodes with at least 2 CPU and 8 GB\nmemory. If you configured your pipelines to use larger amounts of memory, use\nlarger workers. For example, with a 4 CPU 15 GB worker node, each\nworker will have 4 CPU and 12 GB available to run YARN containers. If\nyour pipeline is configured to run 1 CPU, 8 GB executors, YARN is\nunable to run more than one container per worker node. Each worker node would\nhave an extra 3 CPU and 4 GB that's wasted because it can't be used to\nrun anything. To maximize resource utilization on your cluster, you will want\nthe YARN memory and CPUs to be an exact multiple of the amount needed per\nSpark executor. You can check how much memory each worker has reserved for YARN\nby checking the `yarn.nodemanager.resource.memory-mb` property in YARN.\n\nIf you're using Dataproc, the memory available for YARN\ncontainers will be roughly 75% of the VM memory. The minimum YARN container size\nis also adjusted depending on the size of the worker VMs. Some common worker\nsizes and their corresponding YARN settings are given in the following table.\n\nKeep in mind that Spark requests for more memory than the executor memory\nset for the pipeline, and that YARN rounds that requested amount up. For\nexample, suppose you have set your executor memory to 2048 MB, and have not\ngiven a value for `spark.yarn.executor.memoryOverhead`, which means the default\nof 384 MB is used. That means Spark requests 2048 MB + 384 MB\nfor each executor, which YARN rounds up to an exact multiple of the YARN\nminimum allocation. When running on a 8 GB worker node, because the YARN\nminimum allocation is 512 MB, it gets rounded up to 2.5 GB. This\nmeans each worker can run two containers, using up all\navailable CPUs, but leaving 1 GB of YARN memory (6 GB -\n2.5 GB - 2.5 GB) unused. This means the worker node can actually be\nsized a little smaller, or the executors can be given a little bit more memory.\nWhen running on a 16 GB worker node, 2048 MB + 1024 MB is\nrounded up to 3 GB because the YARN minimum allocation is 1024 MB.\nThis means each worker node is able to run four containers, with all CPUs\nand YARN memory in use.\n\nTo help give context, the following table shows recommended worker sizes given\nsome common executor sizes.\n\nFor example, a 26 GB worker node translates to 20 GB of memory usable\nfor running YARN containers. With executor memory set to 4 GB, 1 GB is\nadded as overhead, which means 5 GB YARN containers for each executor. This\nmeans the worker can run four containers without any extra resources leftover.\nYou can also multiply the size of the workers. For example, if executor memory\nis set to 4096 GB, a worker with 8 CPUs and 52 GB memory would\nalso work well. Compute Engine VMs restrict how much memory the VM can have based\non the number of cores. For example, a VM with 4 cores must have at least\n7.25 GB of memory and at most 26 GB of memory. This means an executor\nset to use 1 CPU and 8 GB of memory uses 2 CPUs and 26 GB\nof memory on the VM. If executors are instead configured to use 2 CPUs and\n8 GB of memory, all of the CPUs are utilized.\n\n### Disk\n\nDisk is important for some pipelines but not all of them. If your pipeline does\nnot contain any shuffles, disk will only be used when Spark runs out of memory\nand needs to spill data to disk. For these types of pipelines, disk size and\ntype are generally not going to make a big impact on your performance. If your\npipeline is shuffling a lot of data, disk performance will make a difference. If\nyou are using Dataproc, it is recommended that you use disk sizes\nof at least 1tb, as disk performance scales up with disk size. For information\nabout disk performance, see [Configure disks to meet performance\nrequirements](/compute/docs/disks/performance).\n\n### Number of workers\n\nIn order to minimize execution time, you will want to ensure that your cluster\nis large enough that it can run as much as it can in parallel. For example, if\nyour pipeline source reads data using 100 splits, you will want to make sure the\ncluster is large enough to run 100 executors at once.\n\nThe easiest way to tell if your cluster is undersized is by looking at the YARN\npending memory over time. If you are using Dataproc, a graph can\nbe found on the cluster detail page.\n\nIf pending memory is high for long periods\nof time, you can increase the number of workers to add that much extra capacity\nto your cluster. In the preceding example, the cluster should be increased by\naround 28 GB to ensure that the maximum level of parallelism is achieved.\n\n#### Enhanced Flexibility Mode (EFM)\n\nEFM lets you specify that only primary worker nodes be involved when shuffling\ndata. Since secondary workers are no longer responsible for intermediate shuffle\ndata, when they are removed from a cluster, Spark jobs don't run into delays or\nerrors. Since primary workers are never scaled down, the cluster scales down\nwith more stability and efficiency. If you're running pipelines with shuffles on\na static cluster, it is recommended that you use EFM.\n\nFor more information on EFM, see [Dataproc enhanced flexibility mode](/dataproc/docs/concepts/configuring-clusters/flex)."]]
