제퍼넷 로고

Spark Operator 및 spark-submit을 사용한 EKS 작업 제출에 Amazon EMR 소개 | 아마존 웹 서비스

시간

EKS의 Amazon EMR 조직이 Amazon Elastic Kubernetes Service(Amazon EKS)에서 오픈 소스 빅 데이터 프레임워크를 실행할 수 있도록 하는 Amazon EMR용 배포 옵션을 제공합니다. EKS의 EMR을 사용하면 Spark 애플리케이션이 Apache Spark용 Amazon EMR 런타임에서 실행됩니다. Amazon EMR에서 제공하는 이 성능 최적화 런타임은 Spark 작업을 빠르고 비용 효율적으로 실행합니다. EMR 런타임은 다음을 제공합니다. 최대 5.37배 향상된 성능 및 76.8% 비용 절감, Amazon EKS에서 오픈 소스 Apache Spark를 사용하는 것과 비교할 때.

EKS에서 Amazon EMR의 성공을 기반으로 고객은 다음을 사용하여 작업을 실행하고 관리해 왔습니다. emr 컨테이너 API, 생성 EMR 가상 클러스터, AWS 명령줄 인터페이스(AWS CLI)를 통해 EKS 클러스터에 작업을 제출하거나 아파치 에어 플로우 스케줄러. 그러나 Spark 애플리케이션을 실행하는 다른 고객은 스파크 오퍼레이터 또는 네이티브 스파크 제출 Amazon EKS에서 Apache Spark 작업을 정의하고 실행할 수 있지만 최적화된 EMR 런타임에서 Spark를 실행하여 얻을 수 있는 성능 이점은 활용하지 않습니다. 이러한 요구에 부응하여 EMR 6.10부터 Spark Operator 또는 spark-submit. 이는 EKS에서 Spark 워크로드를 실행하는 모든 사람이 EMR의 최적화된 런타임을 활용할 수 있음을 의미합니다.

이 게시물에서는 Spark Operator 및 Spark 작업을 모두 사용하여 Spark 작업을 설정하고 실행하는 과정을 안내합니다. spark-submit, EMR 런타임 기능과 통합되었습니다. 두 가지 방법으로 인프라를 설정하고 작업을 제출하는 데 도움이 되는 단계별 지침을 제공합니다. 또한 다음을 사용할 수 있습니다. EKS 청사진 데이터 Terraform 템플릿을 사용하여 전체 인프라를 배포합니다.

인프라 개요

이 게시물에서는 다음을 사용하여 포괄적인 솔루션을 배포하는 프로세스를 안내합니다. eksctl, 투구 및 AWS CLI. 배포에는 다음 리소스가 포함됩니다.

  • 다음으로 설정된 VPC, EKS 클러스터 및 관리형 노드 그룹 eksctl 수단
  • 필수 Amazon EKS 관리형 추가 기능(예: VPC CNI, CoreDNS 및 KubeProxy는 eksctl 수단
  • Cluster Autoscaler 및 Spark Operator 추가 기능, Helm을 사용하여 설정
  • Spark 작업 실행 AWS 자격 증명 및 액세스 관리 (IAM) 역할, 다음에 대한 IAM 정책 아마존 단순 스토리지 서비스 (Amazon S3) 버킷 액세스, 서비스 계정 및 역할 기반 액세스 제어, AWS CLI를 사용하여 설정 및 eksctl

사전 조건

머신에 다음 필수 구성 요소가 설치되어 있는지 확인하십시오.

AWS 자격 증명 설정

다음 단계로 진행하고 eksctl 명령을 실행하기 전에 로컬 AWS 자격 증명 프로필을 설정해야 합니다. 지침은 다음을 참조하십시오. 구성 및 자격 증명 파일 설정.

VPC, EKS 클러스터 및 관리형 추가 기능 배포

다음 구성은 us-west-1 기본 지역으로. 다른 리전에서 실행하려면 regionavailabilityZones 그에 따라 필드. 또한 게시물 전체의 후속 단계에서 동일한 지역이 사용되는지 확인하십시오.

AWS 자격 증명이 설정된 터미널에 다음 코드 조각을 입력합니다. 를 업데이트하십시오. publicAccessCIDRs 아래 명령을 실행하기 전에 IP를 입력하십시오. 이름이 지정된 파일이 생성됩니다. eks-cluster.yaml:

cat <<EOF >eks-cluster.yaml
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata: name: emr-spark-operator region: us-west-1 # replace with your region version: "1.25"
vpc: clusterEndpoints: publicAccess: true privateAccess: true publicAccessCIDRs: ["YOUR-IP/32"]
availabilityZones: ["us-west-1a","us-west-1b"] # replace with your region
iam: withOIDC: true serviceAccounts: - metadata: name: cluster-autoscaler namespace: kube-system wellKnownPolicies: autoScaler: true roleName: eksctl-cluster-autoscaler-role
managedNodeGroups: - name: m5x instanceType: m5.xlarge availabilityZones: ["us-west-1a"] volumeSize: 100 volumeType: gp3 minSize: 2 desiredCapacity: 2 maxSize: 10 tags: k8s.io/cluster-autoscaler/enabled: "true" k8s.io/cluster-autoscaler/eks-nvme: "owned" addons: - name: vpc-cni version: latest - name: coredns version: latest - name: kube-proxy version: latest
cloudWatch: clusterLogging: enableTypes: ["*"]
EOF

다음 명령을 사용하여 EKS 클러스터를 생성합니다. eksctl create cluster -f eks-cluster.yaml

클러스터 자동 크기 조정기 배포

Cluster Autoscaler는 현재 리소스 수요에 따라 Kubernetes 클러스터의 크기를 자동으로 조정하고 리소스 사용률과 비용을 최적화하는 데 중요합니다. 만들기 autoscaler-helm-values.yaml 파일을 만들고 Helm을 사용하여 Cluster Autoscaler를 설치합니다.

cat <<EOF >autoscaler-helm-values.yaml
---
autoDiscovery: clusterName: emr-spark-operator tags: - k8s.io/cluster-autoscaler/enabled - k8s.io/cluster-autoscaler/{{ .Values.autoDiscovery.clusterName }}
awsRegion: us-west-1 # Make sure the region same as the EKS Cluster
rbac: serviceAccount: create: false name: cluster-autoscaler
EOF

helm repo add autoscaler https://kubernetes.github.io/autoscaler
helm install nodescaler autoscaler/cluster-autoscaler --namespace kube-system --values autoscaler-helm-values.yaml --debug

당신은 또한 설정할 수 있습니다 카펜터 EKS 클러스터의 애플리케이션을 처리하기 위해 올바른 컴퓨팅 리소스를 자동으로 실행하는 클러스터 오토스케일러로 사용됩니다. 당신은 이것을 따를 수 있습니다 블로그 Karpenter를 설정하고 구성하는 방법에 대해 설명합니다.

Spark 연산자 배포

스파크 오퍼레이터 Kubernetes에서 실행되는 Spark 애플리케이션을 관리하고 모니터링하도록 특별히 설계된 오픈 소스 Kubernetes 운영자입니다. Spark 애플리케이션을 정의, 구성 및 실행하고 Kubernetes API를 통해 작업 수명 주기를 관리하는 Kubernetes 사용자 지정 리소스를 제공하여 Spark 작업 배포 및 관리 프로세스를 간소화합니다. 일부 고객은 다른 Kubernetes 리소스와 마찬가지로 Spark 애플리케이션을 관리할 수 있기 때문에 Spark Operator를 사용하여 Spark 작업을 관리하는 것을 선호합니다.

현재 고객은 오픈 소스 Spark 이미지를 구축하고 사용하고 있습니다. S3a 커미터 Spark Operator를 통한 작업 제출의 일부로 또는 spark-submit. 그러나 새로운 작업 제출 옵션을 사용하면 이제 EMRFS와 함께 EMR 런타임의 이점을 누릴 수 있습니다. Amazon EMR 6.10부터 EMR 런타임의 각 향후 버전에 대해 EMR 런타임을 사용하기 위해 Spark Operator 및 해당 Helm 차트를 릴리스할 예정입니다.

이 섹션에서는 다음에서 Spark Operator Helm 차트를 배포하는 방법을 보여줍니다. Amazon Elastic Container Registry (Amazon ECR) EMR 런타임 이미지를 사용하여 작업을 리포지토리하고 제출하여 EMR 런타임에서 제공하는 성능 향상의 이점을 누릴 수 있습니다.

Amazon ECR에서 Helm과 함께 Spark Operator 설치

Spark Operator Helm 차트는 ECR 리포지토리에 저장됩니다. Spark Operator를 설치하려면 먼저 ECR 리포지토리로 Helm 클라이언트를 인증해야 합니다. 차트는 다음 경로에 저장됩니다. ECR_URI/spark-operator.

Helm 클라이언트를 인증하고 Spark Operator를 설치합니다.

aws ecr get-login-password --region us-west-1 | helm registry login --username AWS --password-stdin 608033475327.dkr.ecr.us-west-1.amazonaws.com

해당 리전에 대한 AWS 계정 ID를 얻어 EKS 지원 리전에서 다른 EMR에 인증할 수 있습니다. 자세한 내용은 다음을 참조하십시오. 기본 이미지 URI를 선택하는 방법.

스파크 오퍼레이터 설치

이제 다음 명령을 사용하여 Spark Operator를 설치할 수 있습니다.

helm install spark-operator-demo oci://608033475327.dkr.ecr.us-west-1.amazonaws.com/spark-operator --set emrContainers.awsRegion=us-west-1 --version 1.1.26-amzn-0 --set serviceAccounts.spark.create=false --namespace spark-operator --create-namespace

연산자가 올바르게 설치되었는지 확인하려면 다음 명령을 실행하십시오.

helm list --namespace spark-operator -o yaml

Spark 작업 실행 역할 및 서비스 계정 설정

이 단계에서는 Spark Operator에서 사용할 Spark 작업 실행 IAM 역할과 서비스 계정을 생성하고 spark-submit 작업 제출 예시.

먼저 다음에서 사용할 IAM 정책을 생성합니다. 서비스 계정의 IAM 역할 (IRSA). 이 정책을 사용하면 드라이버 및 실행기 포드가 정책에 지정된 AWS 서비스에 액세스할 수 있습니다. 다음 단계를 완료하십시오.

  1. 전제 조건으로 S3 버킷(aws s3api create-bucket --bucket <ENTER-S3-BUCKET> --create-bucket-configuration LocationConstraint=us-west-1 --region us-west-1) 또는 기존 S3 버킷을 사용합니다. 바꾸다 버킷 이름이 있는 다음 코드에서.
  2. S3 버킷에 대한 읽기 및 쓰기 액세스를 허용하는 정책 파일을 생성합니다.
    cat >job-execution-policy.json <<EOL
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket", "s3:PutObject", "s3:DeleteObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": [ "arn:aws:s3:::<ENTER-S3-BUCKET>", "arn:aws:s3:::<ENTER-S3-BUCKET>/*", "arn:aws:s3:::aws-data-lake-workshop/*", "arn:aws:s3:::nyc-tlc", "arn:aws:s3:::nyc-tlc/*" ] } ]
    }
    EOL

  3. 다음 명령을 사용하여 IAM 정책을 생성합니다.
    aws iam create-policy --policy-name emr-job-execution-policy --policy-document file://job-execution-policy.json

  4. 다음으로 이름이 지정된 서비스 계정을 만듭니다. emr-job-execution-sa-role IAM 역할도 마찬가지입니다. 다음과 같은 eksctl 명령은 실행기와 드라이버에서 사용하도록 정의된 네임스페이스 및 서비스 계정으로 범위가 지정된 서비스 계정을 만듭니다. 꼭 교체하세요 명령을 실행하기 전에 계정 ID로:
    eksctl create iamserviceaccount --cluster=emr-spark-operator --region us-west-1 --name=emr-job-execution-sa --attach-policy-arn=arn:aws:iam::<ENTER_YOUR_ACCOUNT_ID>:policy/emr-job-execution-policy --role-name=emr-job-execution-irsa --namespace=data-team-a --approve

  5. 3단계에서 생성한 실행 역할만 4단계에서 생성한 S3 버킷에서 읽고 쓸 수 있도록 S1 버킷 정책을 생성합니다. 명령을 실행하기 전에 계정 ID로:
    cat > bucketpolicy.json<<EOL
    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:ListBucket", "s3:PutObject", "s3:DeleteObject", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Principal": { "AWS": "arn:aws:iam::<ENTER_YOUR_ACCOUNT_ID>:role/emr-job-execution-irsa" }, "Resource": [ "arn:aws:s3:::<ENTER-S3-BUCKET>", "arn:aws:s3:::<ENTER-S3-BUCKET>/*" ] } ]
    }
    EOL aws s3api put-bucket-policy --bucket ENTER-S3-BUCKET-NAME --policy file://bucketpolicy.json

  6. Spark 작업 실행에 사용되는 서비스 계정에 필요한 Kubernetes 역할 및 역할 바인딩을 만듭니다.
    cat <<EOF >emr-job-execution-rbac.yaml
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata: name: emr-job-execution-sa-role namespace: data-team-a
    rules: - apiGroups: ["", "batch","extensions"] resources: ["configmaps","serviceaccounts","events","pods","pods/exec","pods/log","pods/portforward","secrets","services","persistentvolumeclaims"] verbs: ["create","delete","get","list","patch","update","watch"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata: name: emr-job-execution-sa-rb namespace: data-team-a
    roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: emr-job-execution-sa-role
    subjects: - kind: ServiceAccount name: emr-job-execution-sa namespace: data-team-a
    EOF

  7. 다음 명령을 사용하여 Kubernetes 역할 및 역할 바인딩 정의를 적용합니다.
kubectl apply -f emr-job-execution-rbac.yaml

지금까지 Spark 작업 실행 역할을 포함한 인프라 설정을 완료했습니다. 다음 단계에서는 Spark Operator와 Spark Operator를 모두 사용하여 샘플 Spark 작업을 실행합니다. spark-submit EMR 런타임으로.

EMR 런타임으로 Spark Operator 작업 구성

이 섹션에서는 S3 버킷에 저장된 퍼블릭 데이터 세트에서 데이터를 읽고 처리하고 결과를 자체 S3 버킷에 쓰는 샘플 Spark 작업을 제시합니다. 교체하여 다음 구성에서 S3 버킷을 업데이트해야 합니다. 자신의 S3 버킷에 대한 URI가 참조된 2 단계 의 "Spark 작업 실행 역할 및 서비스 계정 설정" 섹션에 있어야 합니다.. 또한, 우리가 사용하고 있음에 유의하십시오. data-team-a 네임스페이스로 emr-job-execution-sa 이전 단계에서 만든 서비스 계정으로. 이는 전용 네임스페이스에서 Spark 작업 포드를 실행하는 데 필요하며 서비스 계정에 연결된 IAM 역할은 데이터 읽기 및 쓰기를 위해 S3 버킷에 액세스하는 데 사용됩니다.

가장 중요한 것은 image 현재 다음으로 설정된 EMR 최적화 런타임 도커 이미지가 포함된 필드 emr-6.10.0. Amazon EMR 팀에서 릴리스할 때 최신 버전으로 변경할 수 있습니다. 또한 작업을 구성할 때 다음을 포함해야 합니다. sparkConfhadoopConf 다음 매니페스트에 정의된 대로 설정합니다. 이러한 구성을 통해 EMR 런타임 성능의 이점을 얻을 수 있습니다. AWS 접착제 Data Catalog 통합 및 EMRFS 최적화 커넥터.

  1. 파일 생성(emr-spark-operator-example.yaml) 다음 단계의 일부로 작업을 제출할 수 있도록 S3 버킷 위치를 로컬로 업데이트합니다.
    cat <<EOF >emr-spark-operator-example.yaml
    ---
    apiVersion: "sparkoperator.k8s.io/v1beta2"
    kind: SparkApplication
    metadata: name: taxi-example namespace: data-team-a
    spec: type: Scala mode: cluster # EMR optimized runtime image image: "483788554619.dkr.ecr.eu-west-1.amazonaws.com/spark/emr-6.10.0:latest" imagePullPolicy: Always mainClass: ValueZones mainApplicationFile: s3://aws-data-lake-workshop/spark-eks/spark-eks-assembly-3.3.0.jar arguments: - s3://nyc-tlc/csv_backup - "2017" - s3://nyc-tlc/misc/taxi _zone_lookup.csv - s3://<ENTER_S3_BUCKET>/emr-eks-results - emr_eks_demo hadoopConf: # EMRFS filesystem config fs.s3.customAWSCredentialsProvider: com.amazonaws.auth.WebIdentityTokenCredentialsProvider fs.s3.impl: com.amazon.ws.emr.hadoop.fs.EmrFileSystem fs.AbstractFileSystem.s3.impl: org.apache.hadoop.fs.s3.EMRFSDelegate fs.s3.buffer.dir: /mnt/s3 fs.s3.getObject.initialSocketTimeoutMilliseconds: "2000" mapreduce.fileoutputcommitter.algorithm.version.emr_internal_use_only.EmrFileSystem: "2" mapreduce.fileoutputcommitter.cleanup-failures.ignored.emr_internal_use_only.EmrFileSystem: "true" sparkConf: spark.eventLog.enabled: "true" spark.eventLog.dir: "s3://<ENTER_S3_BUCKET>/" spark.kubernetes.driver.pod.name: driver-nyc-taxi-etl # Required for EMR Runtime and Glue Catalogue spark.driver.extraClassPath: /usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/* spark.driver.extraLibraryPath: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native spark.executor.extraClassPath: /usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/* spark.executor.extraLibraryPath: /usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native # EMRFS commiter spark.sql.parquet.output.committer.class: com.amazon.emr.committer.EmrOptimizedSparkSqlParquetOutputCommitter spark.sql.parquet.fs.optimized.committer.optimization-enabled: "true" spark.sql.emr.internal.extensions: com.amazonaws.emr.spark.EmrSparkSessionExtensions spark.executor.defaultJavaOptions: -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseParallelGC -XX:InitiatingHeapOccupancyPercent=70 -XX:OnOutOfMemoryError='kill -9 %p' spark.driver.defaultJavaOptions: -XX:OnOutOfMemoryError='kill -9 %p' -XX:+UseParallelGC -XX:InitiatingHeapOccupancyPercent=70 sparkVersion: "3.3.1" restartPolicy: type: Never driver: cores: 1 memory: "4g" serviceAccount: emr-job-execution-sa executor: cores: 1 instances: 4 memory: "4g" serviceAccount: emr-job-execution-sa
    EOF

  2. 다음 명령을 실행하여 EKS 클러스터에 작업을 제출합니다.
    kubectl apply -f emr-spark-operator-example.yaml

    작업을 완료하는 데 4~5분이 걸릴 수 있으며 드라이버 포드 로그에서 성공 메시지를 확인할 수 있습니다.

  3. 다음 명령을 실행하여 작업을 확인합니다.
kubectl get pods -n data-team-a

Spark UI에 대한 액세스 활성화

Spark UI는 작업 진행 상황을 추적하고, 자세한 작업 및 단계 정보를 보고, 리소스 사용률을 분석하여 병목 현상을 식별하고 코드를 최적화할 수 있기 때문에 데이터 엔지니어에게 중요한 도구입니다. Kubernetes에서 실행되는 Spark 작업의 경우 Spark UI는 드라이버 포드에서 호스팅되며 해당 액세스는 Kubernetes의 내부 네트워크로 제한됩니다. 액세스하려면 트래픽을 포드로 전달해야 합니다. kubectl. 다음 단계는 설정 방법을 안내합니다.

다음 명령을 실행하여 트래픽을 드라이버 포드로 전달합니다.

kubectl port-forward <driver-pod-name> 4040:4040

다음과 유사한 텍스트가 표시되어야 합니다.

Forwarding from 127.0.0.1:4040 -> 4040
Forwarding from [::1]:4040 → 4040

제출 시 드라이버 포드 이름을 지정하지 않은 경우 SparkApplication, 다음 명령으로 가져올 수 있습니다.

kubectl get pods -l spark-role=driver,spark-app-name=<your-spark-app-name> -o jsonpath='{.items[0].metadata.name}'

브라우저를 열고 입력 http://localhost:4040 주소 표시 줄에서. Spark UI에 연결할 수 있어야 합니다.

스파크 UI 스크린샷

스파크 히스토리 서버

실행 후 작업을 탐색하려면 Spark 기록 서버를 통해 볼 수 있습니다. 선행 SparkApplication 정의에는 이벤트 로그가 활성화되어 있으며 다음 경로를 사용하여 S3 버킷에 이벤트를 저장합니다. s3://YOUR-S3-BUCKET/. Spark History Server 설정 및 로그 탐색에 대한 지침은 다음을 참조하십시오. Spark 기록 서버 시작 및 Docker를 사용하여 Spark UI 보기.

스파크 제출

스파크 제출 클러스터 또는 로컬에서 Apache Spark 애플리케이션을 실행하기 위한 명령줄 인터페이스입니다. 애플리케이션을 Spark 클러스터에 제출할 수 있습니다. 이 도구를 사용하면 애플리케이션 속성, 리소스 할당 및 사용자 지정 라이브러리를 간단하게 구성할 수 있어 Spark 작업의 배포 및 관리가 간소화됩니다.

Amazon EMR 6.10부터 spark-submit 작업 제출 방법으로 지원됩니다. 이 방법은 현재 제출 메커니즘으로 클러스터 모드만 지원합니다. 다음을 사용하여 작업을 제출하려면 spark-submit 메서드에서 이전에 설정한 서비스 계정의 IAM 역할을 재사용합니다. 또한 Spark Operator 메서드에 사용되는 S3 버킷을 사용합니다. 이 섹션의 단계에서는 다음을 사용하여 작업을 구성하고 제출하는 방법을 안내합니다. spark-submit EMR 런타임 개선의 이점을 누릴 수 있습니다.

  1. 작업을 제출하려면 Amazon EMR에서 사용 가능한 버전과 일치하는 Spark 버전을 사용해야 합니다. Amazon EMR 6.10의 경우 다음을 수행해야 합니다. 스파크 3.3 버전 다운로드.
  2. 당신은 또한 당신이 가지고 있는지 확인해야합니다 자바 환경에 설치됩니다.
  3. 파일의 압축을 풀고 Spark 디렉터리의 루트로 이동합니다.
  4. 다음 코드에서 EKS 끝점 뿐만 아니라 S3 버킷 그런 다음 스크립트를 실행합니다.
./bin/spark-submit --class ValueZones --master k8s://EKS-ENDPOINT --conf spark.kubernetes.namespace=data-team-a --conf spark.kubernetes.container.image=608033475327.dkr.ecr.us-west-1.amazonaws.com/spark/emr-6.10.0:latest --conf spark.kubernetes.authenticate.driver.serviceAccountName=emr-job-execution-sa --conf spark.kubernetes.authenticate.executor.serviceAccountName=emr-job-execution-sa --conf spark.driver.extraClassPath="/usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/*" --conf spark.driver.extraLibraryPath="/usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native" --conf spark.executor.extraClassPath="/usr/lib/hadoop-lzo/lib/*:/usr/lib/hadoop/hadoop-aws.jar:/usr/share/aws/aws-java-sdk/*:/usr/share/aws/emr/emrfs/conf:/usr/share/aws/emr/emrfs/lib/*:/usr/share/aws/emr/emrfs/auxlib/*:/usr/share/aws/emr/security/conf:/usr/share/aws/emr/security/lib/*:/usr/share/aws/hmclient/lib/aws-glue-datacatalog-spark-client.jar:/usr/share/java/Hive-JSON-Serde/hive-openx-serde.jar:/usr/share/aws/sagemaker-spark-sdk/lib/sagemaker-spark-sdk.jar:/home/hadoop/extrajars/*" --conf spark.executor.extraLibraryPath="/usr/lib/hadoop/lib/native:/usr/lib/hadoop-lzo/lib/native:/docker/usr/lib/hadoop/lib/native:/docker/usr/lib/hadoop-lzo/lib/native" --conf spark.hadoop.fs.s3.customAWSCredentialsProvider=com.amazonaws.auth.WebIdentityTokenCredentialsProvider --conf spark.hadoop.fs.s3.impl=com.amazon.ws.emr.hadoop.fs.EmrFileSystem --conf spark.hadoop.fs.AbstractFileSystem.s3.impl=org.apache.hadoop.fs.s3.EMRFSDelegate --conf spark.hadoop.fs.s3.buffer.dir=/mnt/s3 --conf spark.hadoop.fs.s3n.impl=com.amazon.ws.emr.hadoop.fs.EmrFileSystem --deploy-mode cluster s3://aws-data-lake-workshop/spark-eks/spark-eks-assembly-3.3.0.jar s3://nyc-tlc/csv_backup 2017 s3://nyc-tlc/misc/taxi_zone_lookup.csv s3://S3_BUCKET/emr-eks-results emr_eks_demo

이 작업은 하나의 코어와 7G 메모리의 두 실행기로 완료하는 데 약 1분이 걸립니다.

커스텀 쿠버네티스 스케줄러 사용

많은 양의 작업을 동시에 실행하는 고객은 Kubernetes가 제공하는 표준 예약 및 리소스 사용률 관리로는 해결할 수 없는 컴퓨팅 용량에 대한 공정한 액세스 제공과 관련된 문제에 직면할 수 있습니다. 또한 Amazon Elastic Compute Cloud(Amazon EC2)의 Amazon EMR에서 마이그레이션하고 YARN 대기열로 일정을 관리하는 고객은 이를 Kubernetes 일정 기능으로 바꿀 수 없습니다.

이 문제를 극복하기 위해 다음과 같은 사용자 지정 스케줄러를 사용할 수 있습니다. 아파치 유니콘 or 화산.Spark Operator는 기본적으로 이러한 스케줄러를 지원하며 이를 통해 우선 순위, 리소스 요구 사항 및 공정성 정책과 같은 요소를 기반으로 Spark 애플리케이션을 예약할 수 있으며 Spark Operator는 애플리케이션 배포 및 관리를 간소화합니다. 갱 스케줄링으로 Yunikorn을 설정하고 Spark Operator를 통해 제출된 Spark 애플리케이션에서 사용하려면 다음을 참조하십시오. YuniKorn을 사용한 스파크 오퍼레이터.

정리

AWS 계정에 원치 않는 요금이 부과되지 않도록 하려면 이 배포 중에 생성된 모든 AWS 리소스를 삭제하십시오.

eksctl delete cluster -f eks-cluster.yaml

결론

이번 포스팅에서는 Spark Operator의 EMR 런타임 기능을 소개하고 spark-submit, EKS 클러스터에서 이 기능을 사용할 때의 이점을 살펴보았습니다. 최적화된 EMR 런타임을 사용하면 비용을 최적화하면서 Spark 애플리케이션의 성능을 크게 향상시킬 수 있습니다. 우리는 다음을 사용하여 클러스터 배포를 시연했습니다. eksctl 도구, , 다음을 사용할 수도 있습니다. EKS 청사진에 대한 데이터 EKS의 EMR에 사용할 수 있는 프로덕션 준비 EKS를 배포하고 EKS API 작업 제출 방법의 EMR 외에도 이러한 새로운 배포 방법을 활용할 수 있습니다. 최적화된 EMR 런타임에서 애플리케이션을 실행하면 Spark 애플리케이션 워크플로를 더욱 향상시키고 데이터 처리 파이프라인에서 혁신을 주도할 수 있습니다.


저자에 관하여

로피 무히브 Amazon Web Services의 공공 부문 팀에서 일하는 수석 솔루션 설계자입니다. 그는 EMEA 전역의 공공 부문 고객이 아이디어를 실현하고 새로운 서비스를 구축하며 시민을 위해 혁신하도록 돕습니다. 여가 시간에 Lotfi는 사이클링과 달리기를 즐깁니다.

바라 본투 전담 기술 전문가이자 Data on EKS의 전 세계 기술 리더로서 전략적 계정에서 다양한 조직에 이르는 AWS 고객을 전문적으로 지원합니다. 그는 오픈 소스 기술, 데이터 분석, AI/ML 및 Kubernetes에 열정을 갖고 있으며 개발, DevOps 및 아키텍처에 대한 광범위한 배경 지식을 자랑합니다. Vara의 주요 초점은 Kubernetes 플랫폼에서 확장성이 뛰어난 데이터 및 AI/ML 솔루션을 구축하여 고객이 데이터 중심 추구를 위해 최첨단 기술의 잠재력을 최대한 활용할 수 있도록 돕는 것입니다.

spot_img

최신 인텔리전스

spot_img