Amazon EMR på Amazon EKS gir et distribusjonsalternativ for Amazon EMR som lar deg kjøre analysearbeidsbelastninger på Amazon Elastic Kubernetes-tjeneste (Amazon EKS). Dette er et attraktivt alternativ fordi det lar deg kjøre applikasjoner på en felles pool av ressurser uten å måtte sørge for infrastruktur. I tillegg kan du bruke Amazon EMR Studio å bygge analysekode som kjører på Amazon EKS-klynger. EMR Studio er et nettbasert, integrert utviklingsmiljø (IDE) som bruker fullt administrerte Jupyter-notatbøker som kan kobles til en hvilken som helst EMR-klynge, inkludert EMR på EKS. Det bruker AWS enkelt pålogging (SSO) eller en kompatibel identitetsleverandør (IdP) for å logge direkte på EMR Studio via en sikker URL ved hjelp av bedriftslegitimasjon.
Å distribuere EMR Studio for å koble til EMR på EKS krever integrering av flere AWS-tjenester:
I tillegg må du installere følgende EMR på EKS-komponenter:
Dette innlegget hjelper deg med å bygge alle nødvendige komponenter og sy dem sammen ved å kjøre et enkelt skript. Vi beskriver også arkitekturen til dette oppsettet og hvordan komponentene fungerer sammen.
Arkitekturoversikt
Med EMR på EKS kan du kjøre Spark-applikasjoner sammen med andre typer applikasjoner på samme Amazon EKS-klynge, noe som forbedrer ressursallokering og forenkler infrastrukturadministrasjon. For mer informasjon om hvordan Amazon EMR opererer i en Amazon EKS-klynge, se Nytt – Amazon EMR på Amazon Elastic Kubernetes Service (EKS). EMR Studio tilbyr en nettbasert IDE som gjør det enkelt å utvikle, visualisere og feilsøke applikasjoner som kjører i EMR. For mer informasjon, se Amazon EMR Studio (forhåndsvisning): En ny bærbar PC-første IDE-opplevelse med Amazon EMR.
Spark-kjerner er planlagte pods i et navneområde i en Amazon EKS-klynge. EMR Studio bruker Jupyter Enterprise Gateway (JEG) for å lansere Spark-kjerner på Amazon EKS. Et administrert endepunkt av typen JEG er klargjort som en Kubernetes-distribusjon i den virtuelle EMR-klyngens tilknyttede navneområde og eksponert som en Kubernetes-tjeneste. Hver virtuelle EMR-klynge tilordnes til et Kubernetes-navneområde registrert med Amazon EKS-klyngen; virtuelle klynger administrerer ikke fysisk databehandling eller lagring, men peker på Kubernetes-navneområdet der arbeidsbelastningen er planlagt. Hver virtuell klynge kan ha flere administrerte endepunkter, hver med sine egne konfigurerte kjerner for forskjellige brukstilfeller og behov. JEG-administrerte endepunkter gir HTTPS-endepunkter, betjent av en Application Load Balancer (ALB), som kun kan nås fra EMR Studio og selvvertsbaserte bærbare datamaskiner som er opprettet i et privat undernett av Amazon EKS VPC.
Følgende diagram illustrerer løsningsarkitekturen.
Det administrerte endepunktet opprettes i den virtuelle klyngens Amazon EKS-navneområde (i dette tilfellet, sparkns
) og HTTPS-endepunktene betjenes fra private undernett. Kjernepodene kjører med jobbutførings-IAM-rollen definert i det administrerte endepunktet. Under opprettelse av administrert endepunkt bruker EMR på EKS AWS Load Balancer Controller i kube-system
navneområde for å lage en ALB med en målgruppe som kobles til det JEG-administrerte endepunktet i den virtuelle klyngens Kubernetes-navneområde.
Du kan konfigurere hvert administrert endepunkts kjerne annerledes. For eksempel for å tillate bruk av en Spark-kjerne AWS Lim som deres katalog, kan du bruke følgende konfigurasjons-JSON-fil i —configuration-overrides
flagg når du oppretter et administrert endepunkt:
Det administrerte endepunktet er en Kubernetes-distribusjon frontet av en tjeneste innenfor det konfigurerte navneområdet (i dette tilfellet, sparkns
). Når vi sporer endepunktinformasjonen, kan vi se hvordan Jupyter Enterprise Gateway-distribusjonen kobles til ALB og målgruppen:
For å se på hvordan dette henger sammen, vurder to EMR Studio-økter. ALB utsetter port 18888 for EMR Studio-øktene. JEG-tjenesten tilordner den eksterne porten 18888 på ALB til dynamikken NodePort
på JEG-tjenesten (i dette tilfellet 30091). JEG-tjenesten videresender trafikken til TargetPort
9547, som dirigerer trafikken til riktig Spark-sjåførkapsel. Hver notisbok-økt har sin egen kjerne, som har sine egne respektive Spark-driver- og executor-pods, som følgende diagram illustrerer.
Koble EMR Studio til en virtuell klynge og administrert endepunkt
Hver gang en bruker knytter en virtuell klynge og et administrert endepunkt til Studio-arbeidsområdet sitt og starter en Spark-økt, planlegges Spark-drivere og Spark-utøvere. Det kan du se når du løper kubectl
for å sjekke hvilke pods som ble lansert:
Hver bærbare Spark-kjernesesjon distribuerer en driver-pod og executor-pods som fortsetter å kjøre til kjernesesjonen er stengt.
Koden i notatbokcellene kjører i eksekveringsputene som ble distribuert i Amazon EKS-klyngen.
Sett opp EMR på EKS og EMR Studio
Det kreves flere trinn og deler for å sette opp både EMR på EKS og EMR Studio. Aktivering av AWS SSO er en forutsetning. Du kan bruke de to medfølgende lanseringsskriptene i denne delen eller distribuere den manuelt ved å bruke trinnene som er gitt senere i dette innlegget.
Vi gir to lanseringsskript i dette innlegget. Det ene er et bash-skript som bruker AWS skyformasjon, eksctl og AWS kommandolinjegrensesnitt (AWS CLI)-kommandoer for å gi en ende-til-ende-distribusjon av en komplett løsning. Den andre bruker AWS skyutviklingssett (AWS CDK) for å gjøre det.
Følgende diagram viser arkitekturen og komponentene vi distribuerer.
Forutsetninger
Sørg for å fullføre følgende forutsetninger:
For informasjon om støttede IdP-er, se Aktiver AWS Single Sign-On for Amazon EMR Studio.
Bash-skript
Skriptet er tilgjengelig på GitHub.
Forutsetninger
Skriptet krever at du bruker AWS Cloud9. Følg instruksjonene i Amazon EKS-verksted. Sørg for å følge disse instruksjonene nøye:
Etter at du har distribuert AWS Cloud9-skrivebordet, fortsett til neste trinn.
Forberedelse
Bruk følgende kode for å klone GitHub-repoen og forberede AWS Cloud9-forutsetningene:
Distribuer stabelen
Før du kjører skriptet, oppgi følgende informasjon:
- AWS-konto-ID og region, hvis AWS Cloud9-skrivebordet ditt ikke er i samme konto-ID eller region som du vil distribuere EMR på EKS
- Navnet på Amazon enkel lagringstjeneste (Amazon S3) bøtte å lage
- AWS SSO-brukeren som skal knyttes til EMR Studio-økten
Etter at skriptet har distribuert stabelen, vises URL-en til det distribuerte EMR Studio:
AWS CDK-skript
AWS CDK-skriptene er tilgjengelige på GitHub. Du må sjekke ut main
gren. Stakkene distribuerer en Amazon EKS-klynge og EMR på EKS virtuelle klynge i en ny VPC med private undernett, og eventuelt en Amazon administrerte Apache Airflow (Amazon MWAA) miljø og EMR Studio.
Forutsetninger
Du trenger AWS CDK versjon 1.90.1 eller høyere. For mer informasjon, se Komme i gang med AWS CDK.
Vi bruker en prefiksliste for å begrense tilgangen til enkelte ressurser til nettverks-IP-områder som du godkjenner. Lage en prefiksliste hvis du ikke allerede har en.
Hvis du planlegger å bruke EMR Studio, trenger du AWS SSO konfigurert i kontoen din.
Forberedelse
Etter at du har klonet depotet og sjekket ut main
gren, opprett og aktiver et nytt virtuelt Python-miljø:
Installer nå Python-avhengighetene:
Til slutt, bootstrap AWS CDK:
Distribuer stablene
Syntetiser AWS CDK-stablene med følgende kode:
Denne kommandoen genererer fire stabler:
- emr-eks-cdk – Hovedstabelen
- mwaa-cdk – Legger til Amazon MWAA
- studio-cdk – Legger til EMR Studio-forutsetninger
- studio-cdk-live – Legger til EMR Studio
Følgende diagram illustrerer ressursene som er distribuert av AWS CDK-stakkene.
Start med å distribuere den første stabelen:
Hvis du vil bruke Apache Airflow som orkestrator, distribuer den stabelen:
Distribuer den første EMR Studio-stabelen:
Vent til det administrerte endepunktet blir aktivt. Du kan sjekke statusen ved å kjøre følgende kode:
Den virtuelle klynge-ID-en er tilgjengelig i AWS CDK-utdata fra emr-eks-cdk-stakken.
Når endepunktet er aktivt, distribuerer du den andre EMR Studio-stabelen:
Manuell utplassering
Hvis du foretrekker å distribuere EMR manuelt på EKS og EMR Studio, bruk trinnene i denne delen.
Sett opp en VPC
Hvis du bruker Amazon EKS v. 1.18, sett opp en VPC som også har private undernett og passende merket for eksterne lastbalansere. For tagging, se: Lastbalansering av applikasjoner på Amazon EKS og Opprett en EMR Studio-tjenesterolle.
Opprett en Amazon EKS-klynge
Start en Amazon EKS-klynge med minst én administrert nodegruppe. For instruksjoner, se Setter opp og Komme i gang med Amazon EKS.
Lag relevante IAM-policyer, roller, IdP og SSL/TLS-sertifikat
For å opprette IAM-policyer, roller, IdP og SSL/TLS-sertifikat, fullfør følgende trinn:
- Aktiver klyngetilgang for EMR på EKS.
- Opprett en IdP i IAM basert på EKS OIDC-leverandørens URL.
- Opprett et SSL/TLS-sertifikat og plasser det i AWS Certificate Manager.
- Opprett relevante IAM-policyer og roller:
- Jobbutførende rolle
- Oppdater tillitspolicyen for jobbutførelsesrollen
- Distribuer og lag IAM-policyen for AWS Load Balancer Controller
- EMR Studio tjenesterolle
- EMR Studio brukerrolle
- EMR Studio brukerregler knyttet til AWS SSO-brukere og -grupper
- Registrer Amazon EKS-klyngen med Amazon EMR for å lage den virtuelle EMR-klyngen
- Lag den passende sikkerhetsgrupper som skal knyttes til hvert EMR-studio som er opprettet:
- Sikkerhetsgruppe for arbeidsområde
- Motorsikkerhetsgruppe
- Merk sikkerhetsgruppene med passende tagger. For instruksjoner, se Opprett en EMR Studio-tjenesterolle.
Nødvendige installasjoner i Amazon EKS
Implementere AWS belastningsbalanserkontroller i Amazon EKS-klyngen hvis du ikke allerede har gjort det.
Lag EMR på EKS-relevante stykker og kartlegg brukeren til EMR Studio
Fullfør følgende trinn:
- Opprett minst én virtuell EMR-klynge knyttet til Amazon EKS-klyngen. For instruksjoner, se trinn 1 av Sett opp Amazon EMR på EKS for EMR Studio.
- Opprett minst ett administrert endepunkt. For instruksjoner, se trinn 2 av Sett opp Amazon EMR på EKS for EMR Studio.
- Opprett minst ett EMR-studio; knytte EMR Studio til de private subnettene som er konfigurert med Amazon EKS-klyngen. For instruksjoner, se Lag et EMR-studio.
- Når EMR Studio er tilgjengelig, tilordne en AWS SSO-bruker eller -gruppe til EMR Studio og bruke en passende IAM-policy for den brukeren.
Bruk EMR Studio
For å begynne å bruke EMR Studio, fullfør følgende trinn:
- Finn URL-en til EMR Studio av studioene i en region:
- Logg på med den oppførte URL-en med AWS SSO-brukernavnet du brukte tidligere.
Etter autentisering blir brukeren rutet til EMR Studio-dashbordet.
- Velg Opprett arbeidsområde.
- Til Navn på arbeidsområde, skriv inn et navn.
- Til Subnet, velg undernettet som tilsvarer et av undernettene knyttet til den administrerte nodegruppen.
- Til S3 beliggenhet, skriv inn en S3-bøtte der du kan lagre innholdet på den bærbare datamaskinen.
- Etter at du har opprettet arbeidsområdet, velg en som er i
Ready
status.
- I sidefeltet velger du EMR-klyngeikonet.
- Under Klyngetype¸ velg EMR-klynge på EKS.
- Velg den tilgjengelige virtuelle klyngen og tilgjengelig administrert endepunkt.
- Velg Fest.
Etter at den er festet, viser EMR Studio kjernene som er tilgjengelige i bærbare og Konsoll seksjon.
- Velg PySpark (Kubernetes) for å starte en bærbar kjerne og starte en Spark-økt.
Fordi endepunktkonfigurasjonen her bruker AWS Glue for sin metalager, kan du liste opp databasene og tabellene som er koblet til AWS Glue Data Catalog. Du kan bruke følgende eksempelskript for å teste oppsettet. Endre skriptet etter behov for den aktuelle databasen og tabellen du har i datakatalogen din:
Rydd opp
For å unngå å pådra seg fremtidige kostnader, slett ressursene som er lansert her ved å kjøre remove_setup.sh:
konklusjonen
EMR på EKS lar deg kjøre applikasjoner på en felles pool av ressurser inne i en Amazon EKS-klynge uten å måtte klargjøre infrastruktur. EMR Studio er en fullstendig administrert Jupyter-notatbok og verktøy som sørger for kjerner som kjører på EMR-klynger, inkludert virtuelle klynger på Amazon EKS. I dette innlegget beskrev vi arkitekturen for hvordan EMR Studio kobler til EMR på EKS og ga skript for å automatisk distribuere alle komponentene for å koble de to tjenestene.
Hvis du har spørsmål eller forslag, vennligst legg igjen en kommentar.
Om forfatterne
Randy DeFauw er en hovedløsningsarkitekt hos Amazon Web Services. Han jobber med AWS-kundene for å gi veiledning og teknisk assistanse i databaseprosjekter, og hjelpe dem med å forbedre verdien av løsningene deres når de bruker AWS.
Matthew Tan er Senior Analytics Solutions Architect hos Amazon Web Services og gir veiledning til kunder som utvikler løsninger med AWS Analytics-tjenester på deres analysearbeidsmengder.
- '
- "
- 100
- 7
- 9
- adgang
- Logg inn
- aktiv
- Alle
- allokering
- Amazon
- Amazon Web Services
- analytics
- Apache
- Søknad
- søknader
- arkitektur
- Autentisering
- AWS
- swing
- bygge
- saker
- sertifikat
- avgifter
- Sjekk ut
- klassifisering
- Cloud
- kode
- Felles
- Beregn
- innhold
- fortsette
- controller
- Opprette
- Credentials
- Kunder
- dashbord
- dato
- Database
- databaser
- utvikle
- Utvikling
- sjåfør
- Endpoint
- Enterprise
- Miljø
- gjennomføring
- erfaring
- fabrikk
- Først
- følge
- fronted
- framtid
- gå
- GitHub
- Gruppe
- Hadoop
- her.
- Hive
- Hvordan
- HTTPS
- IAM
- ICON
- Identitet
- Inkludert
- informasjon
- Infrastruktur
- IP
- IT
- Jobb
- Jupyter Notebook
- Kubernetes
- lansere
- lanseringer
- linje
- Liste
- laste
- ledelse
- kart
- Kart
- nettverk
- notatbøker
- Alternativ
- Annen
- fysisk
- pods
- Politikk
- politikk
- basseng
- Forhåndsvisning
- Principal
- privat
- prosjekter
- Python
- Krav
- ressurs
- Ressurser
- Kjør
- rennende
- sikkerhet
- Tjenester
- sett
- Enkelt
- So
- Solutions
- SQL
- Begynn
- startet
- Tilstand
- status
- lagring
- oppbevare
- Støttes
- Target
- Teknisk
- test
- tid
- trafikk
- Stol
- Brukere
- verdi
- virtuelle
- web
- webtjenester
- innenfor
- ord
- Arbeid
- virker