För närvarande experimenterar många företag, inklusive många Cloudera-kunder, med maskininlärning (ML) och skapar modeller för att ta sig an ett brett spektrum av utmaningar. Medan många modeller idag används för instrumentpaneler och interna BI-ändamål, har en liten och snabbt växande grupp företagsledare börjat inse potentialen hos ML för affärsautomatisering, optimering och produktinnovation. I det här blogginlägget kommer vi att dyka in i det senare – specifikt hur branscher omorienterar sina datavetare för att arbeta med applikationsingenjörer och andra intressenter för att lösa affärsproblem i realtid. Dessa användningsfall varierar mellan bransch och affärskritik och växer i bredd och djup när företag lär sig hur mycket som kan göras med den data de har.
Exempel på dessa användningsfall inkluderar:
- Cerner, en vårdledare, använder sensordata från patienter för att identifiera sepsis med hjälp av maskininlärningsmodeller och meddelar proaktivt läkare så att de kan diagnostisera och behandla ytterligare inom de 6 timmar som denna sjukdom är behandlingsbar
- Finansiella tjänster företag använder maskininlärning för att upptäcka bedrägliga transaktioner i realtid och använder realtidsfeedback från kunder för att göra förstärkningsinlärning
- Järnvägsföretag har långdistansgodståg att gå genom speciella stationer där de tar tusentals högupplösta bilder och tillämpar maskininlärning för att identifiera felaktiga delar. De schemalägger sedan att tåget ska anlända till en reparationsanläggning tillsammans med delar och tekniker – vilket gör stoppet liknande ett formel 1-stopp
- Verktyg använder smarta mätardata för att identifiera potentiella problem i eldistributionsnätet och proaktivt schemalägga underhåll
- Medieföretag använder maskininlärning för att identifiera och tillhandahålla relevant innehåll i realtid baserat på vad du tittar på
- Annonsteknik- och e-handelsföretag har använt dessa funktioner längst för att säkerställa relevansen av deras erbjudanden för olika målgrupper
När ett problem har identifierats och ett beslut har fattats om att investera i en affärslösning, kommer datavetare att studera data med hjälp av olika ML-verktyg för att skapa algoritmerna och arbeta med mjukvaruingenjörer för att bygga applikationer som kan utnyttja dessa algoritmer.
Beroende på deras behov kan uppgifterna finnas i deras datalager eller i deras operativa databaser. Många av Clouderas kunder kommer att använda Spark &SparkMLlib inuti Cloudera Machine Learning (CML) för att träna sina algoritmer. Att använda CML möjliggör sömlösa arbetsflöden för operationalisering av modeller i en enda, säker och styrd plattform byggd för snabbare ML-arbetsflöden. För att lära dig mer om vårt tillvägagångssätt för att utveckla produktionsarbetsflöden i CML gå med det här webbinariet.
Träningsalgoritmer kan göras i den operativa databasen
En av de främsta anledningarna till att använda ett datalager för att träna algoritmer är att undvika att lägga till belastning på en befintlig operativ databas och därigenom påverka SLA:er för den operativa arbetsbelastningen. Men i fallet med Clouderas operationella databas (OpDB) kan användare ställa in kvoter och gränser för mängden resurser och den belastning som maskininlärningsanvändare kan lägga på systemet. Detta skyddar operativa arbetsbelastningar samtidigt som datavetare kan använda realtidsdata utan att det kostar att skapa en andra kopia.
När kunderna använder Clouderas OpDB använder kunder ofta Spark för att söka efter data i den operativa databasen, vilket eliminerar behovet av att ladda ner data innan de utforskar den och använder den för utbildning för maskininlärningsändamål.
ML-algoritmer måste uppfylla kraven på tillgänglighet, motståndskraft och lyhördhet på applikationsnivå
Utvecklingen och träningen av den ML-baserade algoritmen görs vanligtvis i samband med utvecklingen av applikationen (förutsatt att det faktum att detta är genomförbart redan har fastställts). Typiska applikationskrav för en underliggande databas inkluderar ofta:
- Sub 1ms svarstid
- Kontinuerlig tillgänglighet inför maskinvaruavbrott (eller hög tillgänglighet men hög tillgänglighet är mindre att föredra)
- Förmåga att skala ut
- Hög samtidighet (1 000-tals förfrågningar/sekund)
När man implementerar maskininlärning som en del av en applikation måste applikationskrav på tillgänglighet, resiliens och lyhördhet uppfyllas. Dessutom ställs flera ytterligare maskininlärningsspecifika krav på applikationen:
- Förmåga att granska beslut
- Möjlighet att versionera modeller/algoritmer
- Förmåga att stödja dataökning för kontinuerlig inlärning (beroende på algoritmen som används)
Clouderas operationella databas kan uppfylla båda kraven
För att möta dessa krav kommer kunderna vanligtvis att platta ut utdata från maskininlärningsmodellen till en tabell – i huvudsak förberäknar alla utdata för hela inmatningsutrymmet. Detta skapar ytterligare krav för den underliggande databasen:
- Möjlighet att skapa en tabell som är i hundratals gigabyte eller terabyte (beroende på storlek och antal indataparametrar)
- Enkel hantering (tvinga inte administratörer att hantera sönderdelning, etc.)
Ur Clouderas operativa databasperspektiv är en maskininlärningsmodell lätt att representera som en tabell (och detta är det tillvägagångssätt som många kunder har använt) :
- Den primära nyckeln består av den uppsättning ingångar som krävs för att identifiera utdata (oavsett antalet ingångar som krävs)
- Kolumn:Rekommendation för maskininlärningsmodell (utdata)
- Kolumn:Modellversion
En revisionsfunktion ser också ut som en tabell:
- Den primära nyckeln består av den uppsättning ingångar som krävs för att identifiera utdata (oavsett antalet ingångar som krävs)
- Kolumn:vem skickade du denna utdata till (t.ex. kund-ID)
- Kolumn:vilken utdata som serverades
- Kolumn:vilken modellversion användes
- Kolumn:vilket alternativt svar skulle ha varit bättre (augmentation)
Förstärkning kan göras manuellt eller programmatiskt (dvs. när ett kreditkortsföretag skickar ett e-postmeddelande till dig och ber dig att verifiera en transaktion - de gör dataökning). Denna granskningstabell som är utökad kan användas för förstärkningsinlärning på plats i databasen eller laddas av till ett datalager.
Eftersom data finns i databasen, kan modelluppdateringar göras utan applikationsstopp.
Ur ett skalningsperspektiv är Clouderas operativa databas byggd på Apache HBase och Apache Phoenix – som båda har visat sig hantera tabeller som är hundratals terabyte stora utan problem.
Kolla in Clouderas operativa databas inom Cloudera Data Platform på Public Cloud för att bygga din nästa ML-baserade app.