Zephyrnet-logotyp

Generativ dataintelligens

Stora data

Introducerar Amazon EMR på EKS-jobbinlämning med Spark Operator och spark-submit | Amazon webbtjänster

Återutgiven av Platon
Återutgiven av Platon

Datum:

Visningar: 139

Amazon EMR på EKS tillhandahåller ett distributionsalternativ för Amazon EMR som tillåter organisationer att köra stordataramverk med öppen källkod på Amazon Elastic Kubernetes Service (Amazon EKS). Med EMR på EKS körs Spark-applikationer på Amazon EMR runtime för Apache Spark. Denna prestandaoptimerade körtid som erbjuds av Amazon EMR gör att dina Spark-jobb körs snabbt och kostnadseffektivt. EMR-körtiden ger upp till 5.37 gånger bättre prestanda och 76.8 % kostnadsbesparingar, jämfört med att använda Apache Spark med öppen källkod på Amazon EKS.

Byggande på framgången med Amazon EMR på EKS, har kunder drivit och hanterat jobb med hjälp av emr-behållare API, skapande EMR virtuella kluster, och skicka jobb till EKS-klustret, antingen via AWS Command Line Interface (AWS CLI) eller Apache luftflöde schemaläggare. Andra kunder som kör Spark-applikationer har dock valt Spark Operator eller infödd gnista-submit att definiera och köra Apache Spark-jobb på Amazon EKS, men utan att dra fördel av prestandavinsterna från att köra Spark på den optimerade EMR-körtiden. Som svar på detta behov, från och med EMR 6.10, har vi introducerat en ny funktion som låter dig använda den optimerade EMR-körtiden medan du skickar och hanterar Spark-jobb genom antingen Spark Operator eller spark-submit. Detta innebär att alla som kör Spark-arbetsbelastningar på EKS kan dra nytta av EMR:s optimerade körtid.

I det här inlägget går vi igenom processen att ställa in och köra Spark-jobb med både Spark Operator och spark-submit, integrerad med EMR runtime-funktionen. Vi tillhandahåller steg-för-steg-instruktioner för att hjälpa dig att sätta upp infrastrukturen och skicka in ett jobb med båda metoderna. Dessutom kan du använda Data om EKS-ritning att distribuera hela infrastrukturen med Terraform-mallar.

Infrastrukturöversikt

I det här inlägget går vi igenom processen med att implementera en omfattande lösning med hjälp av eksctl, Helm och AWS CLI. Vår implementering inkluderar följande resurser:

  • En VPC, EKS-kluster och en hanterad nodgrupp, inrättad med eksctl verktyg
  • Viktiga Amazon EKS-hanterade tillägg, såsom VPC CNI, CoreDNS och KubeProxy som konfigurerats med eksctl verktyg
  • Cluster Autoscaler och Spark Operator-tillägg, konfigurerade med hjälp av Helm
  • Ett Spark-jobbutförande AWS identitets- och åtkomsthantering (IAM) roll, IAM-policy för Amazon enkel lagringstjänst (Amazon S3) hinkåtkomst, servicekonto och rollbaserad åtkomstkontroll, konfigurerad med AWS CLI och eksctl

Förutsättningar

Kontrollera att följande förutsättningar är installerade på din maskin:

Ställ in AWS-uppgifter

Innan du går vidare till nästa steg och kör kommandot eksctl måste du konfigurera din lokala AWS-referensprofil. För instruktioner, se Inställningar för konfiguration och autentiseringsfil.

Distribuera VPC, EKS-klustret och hanterade tillägg

Följande konfiguration använder us-west-1 som standardregion. Om du vill köra i en annan region uppdaterar du region och availabilityZones fält i enlighet därmed. Kontrollera också att samma region används i de efterföljande stegen under hela inlägget.

Ange följande kodavsnitt i terminalen där dina AWS-uppgifter är inställda. Se till att uppdatera publicAccessCIDRs fält med din IP innan du kör kommandot nedan. Detta kommer att skapa en fil med namnet 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

Använd följande kommando för att skapa EKS-klustret: eksctl create cluster -f eks-cluster.yaml

Distribuera Cluster Autoscaler

Cluster Autoscaler är avgörande för att automatiskt justera storleken på ditt Kubernetes-kluster baserat på aktuella resursbehov, för att optimera resursutnyttjande och kostnad. Skapa en autoscaler-helm-values.yaml fil och installera Cluster Autoscaler med hjälp av Helm:

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

Du kan också ställa in Snickare som en kluster autoscaler för att automatiskt starta rätt beräkningsresurser för att hantera ditt EKS-klusters applikationer. Du kan följa detta blogg om hur man ställer in och konfigurerar Karpenter.

Distribuera Spark Operator

Spark Operator är en Kubernetes-operatör med öppen källkod speciellt utformad för att hantera och övervaka Spark-applikationer som körs på Kubernetes. Det effektiviserar processen för att distribuera och hantera Spark-jobb, genom att tillhandahålla en anpassad Kubernetes-resurs för att definiera, konfigurera och köra Spark-applikationer, samt hantera jobblivscykeln genom Kubernetes API. Vissa kunder föredrar att använda Spark Operator för att hantera Spark-jobb eftersom det gör det möjligt för dem att hantera Spark-applikationer precis som andra Kubernetes-resurser.

För närvarande bygger kunderna sina Spark-bilder med öppen källkod och använder dem S3a committers som en del av jobbinlämningar hos Spark Operator eller spark-submit. Men med det nya alternativet för inlämning av jobb kan du nu dra nytta av EMR-körtiden i samband med EMRFS. Från och med Amazon EMR 6.10 och för varje kommande version av EMR-runtime kommer vi att släppa Spark Operator och dess Helm-diagram för att använda EMR-runtime.

I det här avsnittet visar vi dig hur du distribuerar ett Spark Operator Helm-diagram från ett Amazon Elastic Container Registry (Amazon ECR) arkiv och skicka in jobb med hjälp av EMR-runtime-bilder, dra nytta av prestandaförbättringarna som tillhandahålls av EMR-runtime.

Installera Spark Operator med Helm från Amazon ECR

Spark Operator Helm-diagrammet lagras i ett ECR-förråd. För att installera Spark Operator måste du först autentisera din Helm-klient med ECR-förvaret. Diagrammen lagras under följande sökväg: ECR_URI/spark-operator.

Autentisera din Helm-klient och installera 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

Du kan autentisera till andra EMR på EKS-stödda regioner genom att skaffa AWS-konto-ID för motsvarande region. För mer information, se hur man väljer en basbilds-URI.

Installera Spark Operator

Du kan nu installera Spark Operator med följande kommando:

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

För att verifiera att operatören har installerats korrekt, kör följande kommando:

helm list --namespace spark-operator -o yaml

Konfigurera Spark-jobbexekveringsrollen och servicekontot

I det här steget skapar vi en Spark-jobbexekverings-IAM-roll och ett servicekonto, som kommer att användas i Spark Operator och spark-submit exempel på arbetsinlämning.

Först skapar vi en IAM-policy som kommer att användas av IAM-roller för tjänstekonton (IRSA). Denna policy gör det möjligt för drivrutinen och executor-podarna att komma åt de AWS-tjänster som anges i policyn. Slutför följande steg:

  1. Som en förutsättning, skapa antingen en S3-hink (aws s3api create-bucket --bucket <ENTER-S3-BUCKET> --create-bucket-configuration LocationConstraint=us-west-1 --region us-west-1) eller använd en befintlig S3-skopa. Byta ut i följande kod med hinkens namn.
  2. Skapa en policyfil som tillåter läs- och skrivåtkomst till en S3-bucket: 
    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. Skapa IAM-policyn med följande kommando: 
    aws iam create-policy --policy-name emr-job-execution-policy --policy-document file://job-execution-policy.json

  4. Skapa sedan tjänstekontot med namnet emr-job-execution-sa-role samt IAM-rollerna. Det följande eksctl kommandot skapar ett tjänstekonto avgränsat till namnutrymmet och tjänstekontot som definierats för att användas av executorn och drivrutinen. Se till att byta ut med ditt konto-ID innan du kör kommandot: 
    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. Skapa en S3-bucket-policy för att endast tillåta exekveringsrollen skapad i steg 4 att skriva och läsa från S3-bucket skapa i steg 1. Se till att ersätta med ditt konto-ID innan du kör kommandot: 
    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. Skapa en Kubernetes-roll- och rollbindning som krävs för tjänstekontot som används i Spark-jobbkörningen: 
    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. Tillämpa Kubernetes roll- och rollbindningsdefinition med följande kommando:
kubectl apply -f emr-job-execution-rbac.yaml

Hittills har vi slutfört installationen av infrastrukturen, inklusive rollerna för Spark-jobbet. I följande steg kör vi exempel på Spark-jobb med både Spark Operator och spark-submit med EMR-körtiden.

Konfigurera Spark Operator-jobbet med EMR-körtiden

I det här avsnittet presenterar vi ett exempel på Spark-jobb som läser data från offentliga datauppsättningar lagrade i S3-buckets, bearbetar dem och skriver resultaten till din egen S3-bucket. Se till att du uppdaterar S3-skopan i följande konfiguration genom att byta ut den med URI:n till din egen S3-hink hänvisad till steg 2 av "Konfigurera Spark-jobbexekveringsrollen och servicekontot" avsnitt. Observera också att vi använder data-team-a som ett namnutrymme och emr-job-execution-sa som ett tjänstekonto, som vi skapade i föregående steg. Dessa är nödvändiga för att köra Spark-jobbpodarna i det dedikerade namnutrymmet, och IAM-rollen kopplad till tjänstekontot används för att komma åt S3-bucket för att läsa och skriva data.

Viktigast av allt, lägg märke till image med den EMR-optimerade runtime Docker-bilden, som för närvarande är inställd på emr-6.10.0. Du kan ändra detta till en nyare version när det släpps av Amazon EMR-teamet. När du konfigurerar dina jobb, se till att du inkluderar sparkConf och hadoopConf inställningar enligt definitionen i följande manifest. Dessa konfigurationer gör att du kan dra nytta av EMR-körningsprestanda, AWS-lim Datakatalogintegrering och den EMRFS-optimerade kontakten.

  1. Skapa filen (emr-spark-operator-example.yaml) lokalt och uppdatera platsen för S3-skopan så att du kan skicka in jobbet som en del av nästa steg: 
    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. Kör följande kommando för att skicka jobbet till EKS-klustret: 
    kubectl apply -f emr-spark-operator-example.yaml

    Jobbet kan ta 4–5 minuter att slutföra och du kan verifiera att meddelandet lyckades i drivrutinspoddens loggar.

  3. Verifiera jobbet genom att köra följande kommando:
kubectl get pods -n data-team-a

Aktivera åtkomst till Spark UI

Spark UI är ett viktigt verktyg för dataingenjörer eftersom det låter dig spåra framstegen för uppgifter, se detaljerad jobb- och sceninformation och analysera resursutnyttjande för att identifiera flaskhalsar och optimera din kod. För Spark-jobb som körs på Kubernetes finns Spark-gränssnittet på drivrutinspodden och dess åtkomst är begränsad till Kubernetes interna nätverk. För att komma åt den måste vi vidarebefordra trafiken till podden med kubectl. Följande steg tar dig igenom hur du ställer in den.

Kör följande kommando för att vidarebefordra trafik till förarkapseln:

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

Du bör se text som liknar följande:

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

Om du inte angav förarens podnamn när du skickade in SparkApplication, kan du få det med följande kommando:

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

Öppna en webbläsare och gå in http://localhost:4040 i adressfältet. Du bör kunna ansluta till Spark UI.

spark-ui-skärmdump

Spark History Server

Om du vill utforska ditt jobb efter körningen kan du se det via Spark History Server. Det föregående SparkApplication definition har händelseloggen aktiverad och lagrar händelserna i en S3-bucket med följande sökväg: s3://YOUR-S3-BUCKET/. För instruktioner om hur du ställer in Spark History Server och utforskar loggarna, se Starta Spark-historikservern och visa Spark-gränssnittet med Docker.

gnista-submit

gnista-submit är ett kommandoradsgränssnitt för att köra Apache Spark-applikationer i ett kluster eller lokalt. Det låter dig skicka in ansökningar till Spark-kluster. Verktyget möjliggör enkel konfiguration av applikationsegenskaper, resursallokering och anpassade bibliotek, vilket effektiviserar distributionen och hanteringen av Spark-jobb.

Från och med Amazon EMR 6.10, spark-submit stöds som en arbetsinlämningsmetod. Denna metod stöder för närvarande bara klusterläge som inlämningsmekanism. För att skicka in jobb med hjälp av spark-submit metoden återanvänder vi IAM-rollen för tjänstekontot som vi skapade tidigare. Vi använder även S3-skopan som används för Spark Operator-metoden. Stegen i det här avsnittet tar dig igenom hur du konfigurerar och skickar jobb med spark-submit och dra nytta av EMR-körningsförbättringar.

  1. För att skicka in ett jobb måste du använda Spark-versionen som matchar den som finns tillgänglig i Amazon EMR. För Amazon EMR 6.10 måste du ladda ner Spark 3.3-versionen.
  2. Du måste också se till att du har java installerad i din miljö.
  3. Packa upp filen och navigera till roten av Spark-katalogen.
  4. I följande kod, byt ut EKS-ändpunkt samt S3 hink kör sedan skriptet:
./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

Jobbet tar cirka 7 minuter att slutföra med två exekutorer av en kärna och 1 G minne.

Använder anpassade kubernetes-schemaläggare

Kunder som kör en stor volym jobb samtidigt kan möta utmaningar relaterade till att tillhandahålla rättvis tillgång till beräkningskapacitet som de inte kan lösa med den standardiserade schemaläggningen och hanteringen av resursutnyttjande som Kubernetes erbjuder. Dessutom kommer kunder som migrerar från Amazon EMR på Amazon Elastic Compute Cloud (Amazon EC2) och hanterar sin schemaläggning med YARN-köer inte att kunna överföra dem till Kubernetes schemaläggningsfunktioner.

För att övervinna detta problem kan du använda anpassade schemaläggare som Apache Yunikorn or Volcano.Spark Operator stöder inbyggt dessa schemaläggare, och med dem kan du schemalägga Spark-applikationer baserat på faktorer som prioritet, resurskrav och rättvisa policyer, medan Spark Operator förenklar applikationsdistribution och hantering. För att ställa in Yunikorn med gängschemaläggning och använda det i Spark-ansökningar som skickas in via Spark Operator, se Spark Operator med YuniKorn.

Städa upp

För att undvika oönskade debiteringar på ditt AWS-konto, radera alla AWS-resurser som skapats under den här implementeringen:

eksctl delete cluster -f eks-cluster.yaml

Slutsats

I det här inlägget introducerade vi EMR runtime-funktionen för Spark Operator och spark-submit, och utforskade fördelarna med att använda den här funktionen på ett EKS-kluster. Med den optimerade EMR-körtiden kan du avsevärt förbättra prestandan för dina Spark-applikationer samtidigt som du optimerar kostnaderna. Vi demonstrerade distributionen av klustret med hjälp av eksctl verktyg, , du kan också använda Data om EKS-ritningar för att distribuera en produktionsklar EKS som du kan använda för EMR på EKS och utnyttja dessa nya distributionsmetoder utöver EMR på EKS API-jobbinlämningsmetoden. Genom att köra dina applikationer på den optimerade EMR-körtiden kan du ytterligare förbättra dina Spark-applikationsarbetsflöden och driva innovation i dina databearbetningspipelines.

Om författarna

Lotfi Mouhib är en Senior Solutions Architect som arbetar för den offentliga sektorns team med Amazon Web Services. Han hjälper offentliga kunder i hela EMEA att förverkliga sina idéer, bygga nya tjänster och förnya för medborgarna. På fritiden tycker Lotfi om att cykla och springa.

Vara Bonthu är en dedikerad teknikprofessionell och världsomspännande teknisk ledare för data om EKS, specialiserad på att hjälpa AWS-kunder allt från strategiska konton till olika organisationer. Han brinner för öppen källkodsteknologi, dataanalys, AI/ML och Kubernetes, och har en omfattande bakgrund inom utveckling, DevOps och arkitektur. Varas primära fokus ligger på att bygga mycket skalbara data- och AI/ML-lösningar på Kubernetes-plattformar, vilket hjälper kunder att utnyttja den fulla potentialen hos spjutspetsteknologi för sina datadrivna sysselsättningar.

plats_img

Senaste intelligens

plats_img

Copyright @ 2024 Plato Technologies Inc.

Chatta med oss

Hallå där! Hur kan jag hjälpa dig?