I øjeblikket eksperimenterer mange virksomheder, herunder mange Cloudera-kunder, med maskinlæring (ML) og skaber modeller til at tackle en bred vifte af udfordringer. Mens mange modeller i dag bruges til dashboards og interne BI-formål, er en lille og hurtigt voksende gruppe af virksomhedsledere begyndt at realisere potentialet i ML til forretningsautomatisering, optimering og produktinnovation. I dette blogindlæg vil vi dykke ned i sidstnævnte – specifikt, hvordan brancher omorienterer deres dataforskere til at arbejde med applikationsingeniører og andre interessenter for at løse forretningsproblemer i realtid. Disse use cases varierer på tværs af branche- og forretningskritikalitet og vokser i bredde og dybde, efterhånden som virksomheder lærer, hvor meget der kan gøres med de data, de har.
Eksempler på disse use cases omfatter:
- Cerner, en leder i sundhedssektoren, bruger sensordata fra patienter til at identificere sepsis ved hjælp af maskinlæringsmodeller og underretter proaktivt læger, så de kan diagnosticere og behandle yderligere inden for de 6 timer, at denne sygdom kan behandles
- Finansielle tjenester virksomheder bruger maskinlæring til at opdage svigagtige transaktioner i realtid og bruger feedback i realtid fra kunder til at lave forstærkende læring
- Jernbaneselskaber få langdistancegodstog til at gå gennem særlige stationer, hvor de tager tusindvis af billeder i høj opløsning og anvender maskinlæring til at identificere defekte dele. De planlægger derefter, at toget ankommer til et reparationsanlæg sammen med reservedele og teknikere - hvilket gør stoppet beslægtet med et formel 1-pitstop
- Hjælpeprogrammer bruger smart-meter-data til at identificere potentielle problemer i det elektriske distributionsnet og proaktivt planlægge vedligeholdelse
- Medievirksomheder bruger maskinlæring til at identificere og levere relevant indhold i realtid baseret på det, du ser
- Annonceteknologi og e-handelsvirksomheder har brugt disse muligheder længst for at sikre relevansen af deres tilbud til forskellige målgrupper
Når et problem er identificeret, og der er truffet en beslutning om at investere i en forretningsløsning, vil dataforskere studere dataene ved hjælp af forskellige ML-værktøjer til at skabe algoritmerne og arbejde med softwareingeniører for at bygge applikationer, der kan udnytte disse algoritmer.
Afhængigt af deres behov kan dataene ligge i deres datavarehus eller i deres operationelle databaser. Mange af Clouderas kunder vil bruge Spark &SparkMLlib inde i Cloudera Machine Learning (CML) til at træne deres algoritmer. Brug af CML muliggør problemfri arbejdsgange til operationalisering af modeller i en enkelt, sikker og styret platform bygget til hurtigere ML-arbejdsgange. For at lære mere om vores tilgang til udvikling af produktionsarbejdsgange i CML tilmeld dig dette webinar.
Træningsalgoritmer kan udføres i den operationelle database
En af de primære grunde til at bruge et datavarehus til træning af algoritmer er at undgå at tilføje belastning til en eksisterende operationel database og derved påvirke SLA'er for den operationelle arbejdsbyrde. Men i tilfældet med Clouderas Operational Database (OpDB) kan brugere indstille kvoter og grænser for mængden af ressourcer og den belastning, som maskinlæringsbrugere kan lægge på systemet. Dette beskytter operationelle arbejdsbelastninger, samtidig med at dataforskere kan bruge realtidsdata uden at pådrage sig omkostningerne ved at oprette en anden kopi.
Når kunderne bruger Clouderas OpDB, bruger kunder ofte Spark til at forespørge data i den operationelle database, hvilket eliminerer behovet for at aflæse data, før de udforsker dem og bruger dem til træning med henblik på maskinlæring.
ML-algoritmer skal opfylde kravene til tilgængelighed, robusthed og reaktionsevne på applikationsniveau
Udvikling og træning af den ML-baserede algoritme sker typisk i forbindelse med udvikling af applikationen (forudsat at det faktum, at dette kan lade sig gøre, allerede er fastslået). Typiske applikationskrav til en underliggende database inkluderer ofte:
- Sub 1 ms responstid
- Kontinuerlig tilgængelighed i tilfælde af hardwareudfald (eller høj tilgængelighed, men høj tilgængelighed er mindre foretrukket)
- Evne til at skalere ud
- Høj samtidighed (1.000-vis af anmodninger pr. sekund)
Når du implementerer maskinlæring som en del af en applikation, skal applikationskravene til tilgængelighed, robusthed og lydhørhed opfyldes. Derudover stilles der flere yderligere maskinlæringsspecifikke krav til applikationen:
- Evne til at revidere beslutninger
- Mulighed for at versionere modeller/algoritmer
- Evne til at understøtte dataforøgelse til kontinuerlig læring (afhængigt af den algoritme, der er implementeret)
Clouderas operationelle database kan opfylde begge sæt krav
For at imødekomme disse krav vil kunder typisk fladte outputtet fra maskinlæringsmodellen ud til en tabel - i det væsentlige forudberegne alle output for hele inputrummet. Dette skaber yderligere krav til den underliggende database:
- Mulighed for at oprette en tabel, der er i hundredvis af gigabyte eller terabyte (afhængigt af størrelsen og antallet af inputparametre)
- Simpel administration (tving ikke administratorer til at administrere sharding osv.)
Fra Clouderas operationelle databaseperspektiv er en maskinlæringsmodel let repræsenteret som en tabel (og dette er den tilgang, mange kunder har valgt):
- Den primære nøgle er sammensat af det sæt af input, der kræves for at identificere output (uanset antallet af nødvendige input)
- Kolonne:Maskinlæringsmodelanbefaling (outputtet)
- Kolonne:Modelversion
En revisionsfunktion ligner også en tabel:
- Den primære nøgle er sammensat af det sæt af input, der kræves for at identificere output (uanset antallet af nødvendige input)
- Kolonne:hvem sendte du dette output til (f.eks. kunde-id)
- Kolonne:hvilket output blev serveret
- Kolonne:hvilken modelversion blev brugt
- Kolonne:hvilket alternativt svar ville have været bedre (augmentation)
Augmentation kan udføres manuelt eller programmatisk (dvs. når et kreditkortselskab sender dig en e-mail og beder dig om at bekræfte en transaktion - de udfører dataforøgelse). Denne revisionstabel, der er udvidet, kan bruges til forstærkende læring på plads i databasen eller overføres til et datavarehus.
Da dataene er i databasen, kan modelopdateringer udføres uden enhver nedetid for programmet.
Fra et skaleringsperspektiv er Clouderas operationelle database bygget på Apache HBase og Apache Phoenix - som begge har vist sig at håndtere tabeller, der er hundredvis af terabyte store uden problemer.
Tjek Clouderas operationelle database i Cloudera Data Platform på Public Cloud for at bygge din næste ML-baserede app.