Shutterstock
For et årti siden identificerede Ion Stoica og hans kolleger på UC Berkeleys computerskole vejspærringen til at udføre avanceret analyse. Udfordringen på det tidspunkt var, hvad vi så kaldte Big Data. Billig opbevaring og beregning kunne udnyttes med tilladelse til Hadoop-projektet, men jobene havde tendens til at tage timer eller dage. Stoica og kolleger arbejdede på en løsning, der udnyttede hukommelse, og resultatet var Apache Spark-projektet. Oprettet på UC Berkeleys AMPLab, er det blevet de facto-standarden for storbatch-databehandling, for ikke at nævne teknologien, der fødte et firma, der i øjeblikket værdsættes til 28 milliarder dollars.
Hurtigt frem til nutiden, og Stoica og hans kolleger har identificeret beregning som den nye flaskehals, da maskinindlæringens omfavnelse har gjort arbejdsbyrdebehandling mere kompleks. De forbruger selvfølgelig stadig masser af data.
Ironisk nok er afbrydelsen ikke fra mangel på ressourcer. Alle ingredienser til at køre AI-modeller i produktion er nu på plads, og hvis de køres ordentligt, kan det være ret omkostningseffektivt. For eksempel er serverløse tjenester i skyen blevet populære, men de har typisk været begrænset til at betjene enkle apps bygget af funktioner, hvor det store krav var autoskalering. Opbevaring er blevet ret billig, og udviklere står over for en rigdom af processorinstanser, der kan matches til problemet, fra GPU'er til specialiserede ASIC'er. Der er masser af rammer, såsom TensorFlow, der hjælper udviklere med at strukturere orkestrering af computing. Og der er Kubernetes, der kan automatisere orkestrering.
Men punktum. I dag kræver det end-to-end-tjenester, der automatiserer implementeringen af ML-modeller, kendskab til Kubernetes og/eller en kompleks værktøjskæde til håndtering af autoskalering. Og i modsætning til de relativt enkle apps, der er bygget fra funktioner, involverer maskinindlæring og dyb læring typisk komplekse iterative flertrinsprogrammer, der ud fra et beregningssynspunkt bruger ressourcer som klassisk HPC (højtydende computing).
Løsningen er udviklet af AMPLabs efterfølger RISELab og er Ray, et open source-projekt, der er vært på GitHub. Stoica skabte sammen med kollegalaborator Robert Nishihara og professor i Berkeley Michael I. Jordan projektet, og de har medstifter virksomheden Anyscale til at kommercialisere det. Med en finansiering på 60 millioner dollars understøttes den af nogle af de samme venturepartnere, der står bag Databricks. Med få ord vil Ray gøre det muligt for udviklere og dataforskere at starte serverløs beregning til deres egne ML-modeller og apps uden at kræve kendskab til den underliggende VVS. I dag starter Ray-samfundet det andet Ray Summit med de sædvanlige tidlige adopterede mistænkte, der viser, hvordan dataforskere og udviklere på bærbare computere har trukket dette af.
Kort sagt, Ray leverer en API til opbygning af distribuerede applikationer. Det gør det muligt for enhver udvikler, der arbejder på en bærbar computer, at implementere en model i et serverfrit miljø, hvor implementering og autoskalering automatiseres under dækkene. Det leverer en serverløs oplevelse uden at kræve, at udvikleren tilmelder sig en bestemt cloud-serverløs service eller ved noget om opsætning og kørsel af en sådan infrastruktur.
En Ray-klynge består af en hovedknude og et sæt medarbejdernoder, der kan arbejde på enhver infrastruktur, lokalt eller i en offentlig sky. Dens muligheder inkluderer en autoskaler, der introspekterer afventende opgaver og derefter aktiverer det mindste antal noder for at køre dem og overvåger udførelsen for at øge flere noder eller lukke dem. Der kræves dog en vis samling, da udvikleren skal registrere sig for at beregne forekomststyper.
Ray kan starte og stoppe virtuelle computere i den valgte sky; ray docs giver information om, hvordan man gør dette i hver af de store skyer og Kubernetes.
Man ville blive tilgivet for at få en fornemmelse af, at Ray er déjà vu igen. Stoica, der var medvirkende til at fremme Sparks fremkomst, påtager sig en lignende rolle med Ray. Begge stammer fra UC Berkeley, og som open source-projekter går begge samfundsruten. Ligesom Spark pralede af en portefølje med snesevis af open source-biblioteker, der er bidraget af samfundet, vil det samme være tilfældet med Ray. Den største forskel er målgruppen: Mens Spark og Databricks var rettet mod dataforskere og dataingeniører, vil Ray primært være rettet mod udviklere, der søger genveje for at få komplekse maskinlæringsmodeller i produktion.
Ray logo
Ray
Kafka logo
Apache Kafka
Og om det logo. Yup, det ligner meget Kafka, ikke? Men lad dig ikke narre. Input til eller output fra at køre en model på en Ray-klynge kan involvere en Kafka-strøm, men det er så tæt som forbindelsen mellem de to bliver.
Ligesom Spark blev udviklet i Scala og oprindeligt optimeret til det, blev Ray designet til Python og dets økosystem af biblioteker som en førsteklasses borger, men havde en API, der er tilstrækkelig åben til at blive påberåbt fra andre sprog. Men oprindeligt vil nogle sprog og modeller være mere lige end andre. Ethvert bibliotek fra ethvert sprog kan kalde beregning via Rays API. Stadig kan biblioteker optimeres med specialiserede udførelsesrutiner for at udnytte Rays serverløse orkestrering mere effektivt, hvor Horovod er plakatbarnet.
Ligesom Databricks blev dannet for at levere en kommerciel platform-as-a-service til optimeret Spark, følger Anyscale i samme fodspor. Stoica, der fortsat er administrerende formand for Databricks, gentager sin rolle med den nye opstart, og som tidligere nævnt lancerer han med nogle af de samme venture-backers. Anyscales tjeneste er i øjeblikket i beta.
Vi kan forestille os, at Anyscale ville tilføje nogle klokker og fløjter, såsom forudbefolkningsegenskaber for populære node-typer (f.eks. Amazon EC2 C6g) og en rigere administrationskonsol ud over det grundlæggende dashboard med open source community-udgaven. Og mens Anyscale betegner sin API som “universel”, hvilket betyder at den kan tilgås fra programmer skrevet på ethvert sprog, skal du ikke blive overrasket, hvis virksomheden (som Databricks før den) udvikler optimeringer.
Big Data
Hvor er IBMs hybrid cloud launchpad? Syv måder at gøre realtidsteknologi til virkelighed for din organisation Maskinindlæring på kanten: TinyML bliver stor Hvad er næste for Cloudera? McDonald's ønsker at 'demokratisere' maskinindlæring for alle brugere på tværs af sine operationer
Relaterede emner:
Cloud Digital Transformation Robotics Internet of Things Innovation Enterprise Software 