Amazon EMR på Amazon EKS ger ett distributionsalternativ för Amazon EMR som låter dig köra analytiska arbetsbelastningar på Amazon Elastic Kubernetes-tjänst (Amazon EKS). Detta är ett attraktivt alternativ eftersom det låter dig köra applikationer på en gemensam resurspool utan att behöva tillhandahålla infrastruktur. Dessutom kan du använda Amazon EMR Studio att bygga analyskod som körs på Amazon EKS-kluster. EMR Studio är en webbaserad, integrerad utvecklingsmiljö (IDE) som använder fullt hanterade Jupyter-anteckningsböcker som kan kopplas till alla EMR-kluster, inklusive EMR på EKS. Det använder AWS-inloggning (SSO) eller en kompatibel identitetsleverantör (IdP) för att logga in direkt på EMR Studio via en säker URL med hjälp av företagsuppgifter.
Att distribuera EMR Studio för att koppla till EMR på EKS kräver att flera AWS-tjänster integreras:
Dessutom måste du installera följande EMR på EKS-komponenter:
Det här inlägget hjälper dig att bygga alla nödvändiga komponenter och sy ihop dem genom att köra ett enda skript. Vi beskriver också arkitekturen för denna installation och hur komponenterna fungerar tillsammans.
Arkitekturöversikt
Med EMR på EKS kan du köra Spark-applikationer tillsammans med andra typer av applikationer på samma Amazon EKS-kluster, vilket förbättrar resursallokeringen och förenklar infrastrukturhanteringen. För mer information om hur Amazon EMR fungerar i ett Amazon EKS-kluster, se Nytt – Amazon EMR på Amazon Elastic Kubernetes Service (EKS). EMR Studio tillhandahåller en webbaserad IDE som gör det enkelt att utveckla, visualisera och felsöka applikationer som körs i EMR. För mer information, se Amazon EMR Studio (Preview): En ny notebook-första IDE-upplevelse med Amazon EMR.
Spark-kärnor är schemalagda poddar i ett namnområde i ett Amazon EKS-kluster. EMR Studio använder Jupyter Enterprise Gateway (JEG) för att lansera Spark-kärnor på Amazon EKS. En hanterad slutpunkt av typen JEG tillhandahålls som en Kubernetes-distribution i det virtuella EMR-klustrets associerade namnområde och exponeras som en Kubernetes-tjänst. Varje virtuellt EMR-kluster mappas till ett Kubernetes-namnområde registrerat hos Amazon EKS-klustret; virtuella kluster hanterar inte fysisk beräkning eller lagring, utan pekar på Kubernetes-namnutrymmet där arbetsbelastningen är schemalagd. Varje virtuellt kluster kan ha flera hanterade slutpunkter, var och en med sina egna konfigurerade kärnor för olika användningsfall och behov. JEG-hanterade slutpunkter tillhandahåller HTTPS-slutpunkter, som betjänas av en Application Load Balancer (ALB), som endast kan nås från EMR Studio och egna bärbara datorer som skapas inom ett privat undernät av Amazon EKS VPC.
Följande diagram illustrerar lösningsarkitekturen.
Den hanterade slutpunkten skapas i det virtuella klustrets Amazon EKS-namnområde (i det här fallet, sparkns
) och HTTPS-ändpunkterna betjänas från privata undernät. Kärnpodarna körs med IAM-rollen för jobbutförande definierad i den hanterade slutpunkten. Under skapande av hanterade slutpunkter använder EMR på EKS AWS Load Balancer Controller i kube-system
namnområde för att skapa en ALB med en målgrupp som ansluter till den JEG-hanterade slutpunkten i det virtuella klustrets Kubernetes-namnområde.
Du kan konfigurera varje hanterad slutpunkts kärna på olika sätt. Till exempel för att tillåta en Spark-kärna att använda AWS-lim som deras katalog kan du använda följande JSON-konfigurationsfil i —configuration-overrides
flagga när du skapar en hanterad slutpunkt:
Den hanterade slutpunkten är en Kubernetes-distribution som frontas av en tjänst inom det konfigurerade namnområdet (i det här fallet, sparkns
). När vi spårar slutpunktsinformationen kan vi se hur Jupyter Enterprise Gateway-distributionen ansluter till ALB och målgruppen:
För att se hur detta hänger ihop, överväg två EMR Studio-sessioner. ALB exponerar port 18888 för EMR Studio-sessionerna. JEG-tjänsten mappar den externa porten 18888 på ALB till dynamiken NodePort
på JEG-tjänsten (i detta fall 30091). JEG-tjänsten vidarebefordrar trafiken till TargetPort
9547, som dirigerar trafiken till lämplig Spark-förarkapsel. Varje anteckningsbokssession har sin egen kärna, som har sin egen Spark-drivrutin och executor-pod, som följande diagram illustrerar.
Anslut EMR Studio till ett virtuellt kluster och hanterad slutpunkt
Varje gång en användare kopplar ett virtuellt kluster och en hanterad slutpunkt till sin Studio Workspace och startar en Spark-session, schemaläggs Spark-drivrutiner och Spark-exekutorer. Det kan man se när man springer kubectl
för att kontrollera vilka poddar som lanserades:
Varje Spark-kärnsession för notebook-datorn distribuerar en drivrutinspod och executor-pod som fortsätter att köras tills kärnsessionen stängs av.
Koden i anteckningsbokens celler körs i executor-podarna som distribuerades i Amazon EKS-klustret.
Ställ in EMR på EKS och EMR Studio
Flera steg och bitar krävs för att ställa in både EMR på EKS och EMR Studio. Att aktivera AWS SSO är en förutsättning. Du kan använda de två medföljande startskripten i det här avsnittet eller distribuera dem manuellt med hjälp av stegen som anges senare i det här inlägget.
Vi tillhandahåller två lanseringsskript i det här inlägget. Det ena är ett bash-skript som använder AWS molnformation, eksctl och AWS-kommandoradsgränssnitt (AWS CLI)-kommandon för att tillhandahålla en end-to-end-distribution av en komplett lösning. Den andra använder AWS Cloud Development Kit (AWS CDK) för att göra det.
Följande diagram visar arkitekturen och komponenterna som vi distribuerar.
Förutsättningar
Se till att uppfylla följande förutsättningar:
För information om de stödda IdP:er, se Aktivera AWS Single Sign-On för Amazon EMR Studio.
Bash-skript
Manuset finns tillgängligt på GitHub.
Förutsättningar
Skriptet kräver att du använder AWS Cloud9. Följ instruktionerna i Amazon EKS Workshop. Se till att följa dessa instruktioner noggrant:
När du har distribuerat AWS Cloud9-skrivbordet fortsätter du till nästa steg.
FÖRBEREDNING
Använd följande kod för att klona GitHub-repo och förbereda AWS Cloud9-förutsättningarna:
Distribuera stacken
Innan du kör skriptet, ange följande information:
- AWS-konto-ID och region, om ditt AWS Cloud9-skrivbord inte finns i samma konto-ID eller region där du vill distribuera EMR på EKS
- Namnet på Amazon enkel lagringstjänst (Amazon S3) hink att skapa
- AWS SSO-användaren som ska kopplas till EMR Studio-sessionen
Efter att skriptet har distribuerat stacken visas URL:en till den distribuerade EMR Studio:
AWS CDK-skript
AWS CDK-skripten är tillgängliga på GitHub. Du måste checka ut main
gren. Stackarna distribuerar ett Amazon EKS-kluster och EMR på EKS virtuella kluster i en ny VPC med privata subnät, och valfritt en Amazon hanterade Apache Airflow (Amazon MWAA) miljö och EMR Studio.
Förutsättningar
Du behöver AWS CDK version 1.90.1 eller senare. För mer information, se Komma igång med AWS CDK.
Vi använder en prefixlista för att begränsa åtkomsten till vissa resurser till nätverks-IP-intervall som du godkänner. Skapa en prefixlista om du inte redan har en.
Om du planerar att använda EMR Studio behöver du AWS SSO konfigurerat i ditt konto.
FÖRBEREDNING
När du har klonat förvaret och checkat ut main
förgrena sig, skapa och aktivera en ny virtuell Python-miljö:
Installera nu Python-beroendena:
Slutligen, bootstrap AWS CDK:
Distribuera staplarna
Syntetisera AWS CDK-stackarna med följande kod:
Detta kommando genererar fyra stackar:
- emr-eks-cdk – Huvudstacken
- mwaa-cdk – Lägger till Amazon MWAA
- studio-cdk – Lägger till EMR Studio-förutsättningar
- studio-cdk-live – Lägger till EMR Studio
Följande diagram illustrerar resurserna som distribueras av AWS CDK-stackarna.
Börja med att distribuera den första stacken:
Om du vill använda Apache Airflow som din orkestrator, distribuera den stacken:
Distribuera den första EMR Studio-stacken:
Vänta tills den hanterade slutpunkten blir aktiv. Du kan kontrollera statusen genom att köra följande kod:
Det virtuella kluster-ID:t är tillgängligt i AWS CDK-utgången från emr-eks-cdk-stacken.
När slutpunkten är aktiv, distribuera den andra EMR Studio-stacken:
Manuell distribution
Om du föredrar att manuellt distribuera EMR på EKS och EMR Studio, använd stegen i det här avsnittet.
Skapa en VPC
Om du använder Amazon EKS v. 1.18, ställ in en VPC som också har privata undernät och är lämpligt taggade för externa lastbalanserare. För taggning, se: Applikationsbelastningsbalansering på Amazon EKS och Skapa en EMR Studio-tjänstroll.
Skapa ett Amazon EKS-kluster
Starta ett Amazon EKS-kluster med minst en hanterad nodgrupp. För instruktioner, se Inställning och Komma igång med Amazon EKS.
Skapa relevanta IAM-policyer, roller, IdP och SSL/TLS-certifikat
För att skapa dina IAM-policyer, roller, IdP och SSL/TLS-certifikat, utför följande steg:
- Aktivera klusteråtkomst för EMR på EKS.
- Skapa en IdP i IAM baserat på EKS OIDC-leverantörens URL.
- Skapa ett SSL/TLS-certifikat och placera det i AWS certifikathanterare.
- Skapa relevanta IAM-policyer och roller:
- Arbetsutförande roll
- Uppdatera förtroendepolicyn för uppdragsutföranderollen
- Distribuera och skapa IAM-policyn för AWS Load Balancer Controller
- EMR Studio tjänsteroll
- EMR Studio användarroll
- EMR Studio användarpolicyer associerade med AWS SSO-användare och grupper
- Registrera Amazon EKS-klustret med Amazon EMR för att skapa det virtuella EMR-klustret
- Skapa lämpliga säkerhetsgrupper som ska kopplas till varje skapad EMR-studio:
- Arbetsplatssäkerhetsgrupp
- Motorsäkerhetsgrupp
- Tagga säkerhetsgrupperna med lämpliga taggar. För instruktioner, se Skapa en EMR Studio-tjänstroll.
Nödvändiga installationer i Amazon EKS
Distribuera AWS Load Balancer Controller i Amazon EKS-klustret om du inte redan har gjort det.
Skapa EMR på EKS-relevanta delar och mappa användaren till EMR Studio
Följ följande steg:
- Skapa minst ett virtuellt EMR-kluster associerat med Amazon EKS-klustret. För instruktioner, se steg 1 av Konfigurera Amazon EMR på EKS för EMR Studio.
- Skapa minst en hanterad slutpunkt. För instruktioner, se steg 2 av Konfigurera Amazon EMR på EKS för EMR Studio.
- Skapa minst en EMR Studio; associera EMR Studio med de privata undernäten som konfigurerats med Amazon EKS-klustret. För instruktioner, se Skapa en EMR-studio.
- När EMR Studio är tillgänglig, mappa en AWS SSO-användare eller grupp till EMR Studio och tillämpa en lämplig IAM-policy för den användaren.
Använd EMR Studio
För att börja använda EMR Studio, slutför följande steg:
- Hitta webbadressen till EMR Studio av studiorna i en region:
- Med den angivna URL:en loggar du in med AWS SSO-användarnamnet du använde tidigare.
Efter autentisering dirigeras användaren till EMR Studios instrumentpanel.
- Välja Skapa arbetsyta.
- För Arbetsytans namn, ange ett namn.
- För subnät, välj det undernät som motsvarar ett av undernäten som är associerade med den hanterade nodgruppen.
- För S3-plats, ange en S3-hink där du kan lagra anteckningsbokens innehåll.
- När du har skapat arbetsytan väljer du en som finns i
Ready
status.
- Välj ikonen EMR-kluster i sidofältet.
- Enligt Klustertyp¸ välja EMR-kluster på EKS.
- Välj det tillgängliga virtuella klustret och den tillgängliga hanterade slutpunkten.
- Välja Bifoga.
Efter att den har bifogats visar EMR Studio de kärnor som finns tillgängliga i Notebook och Konsol sektion.
- Välja PySpark (Kubernetes) för att starta en bärbar datorkärna och starta en Spark-session.
Eftersom slutpunktskonfigurationen här använder AWS Glue för sin metastore, kan du lista de databaser och tabeller som är anslutna till AWS Glue Data Catalog. Du kan använda följande exempelskript för att testa installationen. Ändra skriptet efter behov för lämplig databas och tabell som du har i din datakatalog:
Städa upp
För att undvika framtida avgifter, ta bort resurserna som startas här genom att köra remove_setup.sh:
Slutsats
EMR på EKS låter dig köra applikationer på en gemensam resurspool i ett Amazon EKS-kluster utan att behöva tillhandahålla infrastruktur. EMR Studio är en fullständigt hanterad Jupyter-anteckningsbok och ett verktyg som tillhandahåller kärnor som körs på EMR-kluster, inklusive virtuella kluster på Amazon EKS. I det här inlägget beskrev vi arkitekturen för hur EMR Studio ansluter med EMR på EKS och tillhandahöll skript för att automatiskt distribuera alla komponenter för att ansluta de två tjänsterna.
Om du har frågor eller förslag, vänligen lämna en kommentar.
Om författarna
Randy DeFauw är en Principal Solutions Architect på Amazon Web Services. Han arbetar med AWS-kunderna för att ge vägledning och teknisk assistans i databasprojekt och hjälpa dem att förbättra värdet av sina lösningar när de använder AWS.
Matthew Tan är Senior Analytics Solutions Architect på Amazon Web Services och ger vägledning till kunder som utvecklar lösningar med AWS Analytics-tjänster för deras analysarbete.
- '
- "
- 100
- 7
- 9
- tillgång
- Konto
- aktiv
- Alla
- fördelning
- amason
- Amazon Web Services
- analytics
- Apache
- Ansökan
- tillämpningar
- arkitektur
- Autentisering
- AWS
- gunga
- SLUTRESULTAT
- fall
- certifikat
- avgifter
- Till Kassan
- klassificering
- cloud
- koda
- Gemensam
- Compute
- innehåll
- fortsätta
- styrenhet
- Skapa
- referenser
- Kunder
- instrumentbräda
- datum
- Databas
- databaser
- utveckla
- Utveckling
- chaufför
- Slutpunkt
- Företag
- Miljö
- utförande
- erfarenhet
- fabrik
- Förnamn
- följer
- beklädd
- framtida
- gå
- GitHub
- Grupp
- Hadoop
- här.
- Bikupa
- Hur ser din drömresa ut
- HTTPS
- IAM
- IKON
- Identitet
- Inklusive
- informationen
- Infrastruktur
- IP
- IT
- Jobb
- Jupyter Notebook
- Kubernetes
- lansera
- lanserar
- linje
- Lista
- läsa in
- ledning
- karta
- kartor
- nät
- bärbara datorer
- Alternativet
- Övriga
- fysisk
- pods
- Strategier
- policy
- poolen
- Förhandsvisning
- Principal
- privat
- projekt
- Python
- Krav
- resurs
- Resurser
- Körning
- rinnande
- säkerhet
- Tjänster
- in
- Enkelt
- So
- Lösningar
- SQL
- starta
- igång
- Ange
- status
- förvaring
- lagra
- Som stöds
- Målet
- Teknisk
- testa
- tid
- trafik
- Litar
- användare
- värde
- Virtuell
- webb
- webbservice
- inom
- ord
- Arbete
- fungerar