Momenteel experimenteren veel ondernemingen, waaronder veel Cloudera-klanten, met machine learning (ML) en creëren ze modellen om een breed scala aan uitdagingen aan te pakken. Terwijl tegenwoordig veel modellen worden gebruikt voor dashboards en interne BI-doeleinden, is een kleine en snelgroeiende groep bedrijfsleiders begonnen het potentieel van ML voor bedrijfsautomatisering, -optimalisatie en productinnovatie te realiseren. In deze blogpost gaan we dieper in op het laatste, met name hoe bedrijfstakken hun datawetenschappers heroriënteren om samen te werken met applicatie-ingenieurs en andere belanghebbenden om realtime zakelijke problemen op te lossen. Deze use-cases variëren per branche en bedrijfskritiek en groeien in breedte en diepte naarmate bedrijven leren hoeveel er kan worden gedaan met de gegevens die ze hebben.
Voorbeelden van deze gebruiksscenario's zijn:
- Cerner, een leider in de gezondheidszorg, gebruikt sensorgegevens van patiënten om sepsis te identificeren met behulp van machine learning-modellen en stelt artsen proactief op de hoogte zodat ze binnen de 6 uur dat deze ziekte een diagnose kan stellen en deze kunnen behandelen, is behandelbaar
- Financiële diensten bedrijven gebruiken machine learning om frauduleuze transacties in realtime te detecteren en gebruiken realtime feedback van klanten om versterkend leren te doen
- Spoorwegmaatschappijen langeafstandsgoederentreinen door speciale stations laten rijden waar ze duizenden foto's met hoge resolutie maken en machine learning toepassen om defecte onderdelen te identificeren. Vervolgens plannen ze de trein om samen met onderdelen en technici bij een reparatiefaciliteit aan te komen - waardoor de stop lijkt op een pitstop in formule 1
- Hulpprogramma's gebruiken slimme-metergegevens om potentiële problemen in het elektriciteitsdistributienet te identificeren en proactief onderhoud te plannen
- Mediabedrijven gebruiken machine learning om relevante inhoud in realtime te identificeren en aan te bieden op basis van wat u bekijkt
- Bedrijven op het gebied van advertentietechnologie en e-commerce gebruiken deze mogelijkheden het langst om de relevantie van hun aanbiedingen voor verschillende doelgroepen te garanderen
Zodra een probleem is geïdentificeerd en een beslissing is genomen om in een bedrijfsoplossing te investeren, zullen datawetenschappers de gegevens bestuderen met behulp van verschillende ML-tools om de algoritmen te maken en met software-engineers werken om applicaties te bouwen die deze algoritmen kunnen benutten.
Afhankelijk van hun behoeften kunnen de gegevens zich in hun datawarehouse of in hun operationele databases bevinden. Veel van Cloudera's klanten zullen Spark &SparkMLlib binnen Cloudera Machine Learning (CML) gebruiken om hun algoritmen te trainen. Het gebruik van CML maakt naadloze workflows mogelijk voor het operationaliseren van modellen in een enkel, veilig en beheerd platform dat is gebouwd voor snellere ML-workflows. Voor meer informatie over onze benadering van het ontwikkelen van productieworkflows in CML, sluit u aan bij dit webinar.
Trainingsalgoritmen kunnen worden gedaan in de operationele database
Een van de belangrijkste redenen om een datawarehouse te gebruiken voor het trainen van algoritmen is om te voorkomen dat een bestaande operationele database wordt belast en daardoor de SLA's van de operationele werkbelasting worden beïnvloed. In het geval van Cloudera's Operational Database (OpDB) kunnen gebruikers echter quota en limieten instellen voor de hoeveelheid bronnen en de belasting die gebruikers van machine learning op het systeem kunnen uitoefenen. Dit beschermt operationele workloads terwijl datawetenschappers realtime gegevens kunnen gebruiken zonder de kosten van het maken van een tweede kopie.
Bij het gebruik van Cloudera's OpDB gebruiken klanten Spark vaak om gegevens in de operationele database op te vragen, waardoor het niet nodig is om gegevens te offloaden voordat ze worden onderzocht en gebruikt voor training met het oog op machine learning.
ML-algoritmen moeten voldoen aan de vereisten voor beschikbaarheid, veerkracht en reactievermogen op applicatieniveau
De ontwikkeling en training van het op ML gebaseerde algoritme wordt meestal gedaan in combinatie met het ontwikkelen van de applicatie (ervan uitgaande dat het feit dat dit mogelijk is al is vastgesteld). Typische applicatievereisten voor een onderliggende database zijn vaak:
- Responstijd van minder dan 1 ms
- Continue beschikbaarheid bij hardwarestoringen (of hoge beschikbaarheid, maar hoge beschikbaarheid heeft minder de voorkeur)
- Uitbreiding mogelijk
- Hoge gelijktijdigheid (1.000 aanvragen/seconde)
Bij het inzetten van machine learning als onderdeel van een applicatie, moet worden voldaan aan de applicatie-eisen op het gebied van beschikbaarheid, veerkracht en reactievermogen. Daarnaast worden er verschillende aanvullende machine learning-specifieke eisen gesteld aan de applicatie:
- Mogelijkheid om beslissingen te controleren
- Mogelijkheid tot versies van modellen / algoritmen
- Mogelijkheid om gegevensvergroting te ondersteunen voor continu leren (afhankelijk van het gebruikte algoritme)
De operationele database van Cloudera kan aan beide vereisten voldoen
Om aan deze vereisten te voldoen, zullen klanten doorgaans de output van het machine learning-model afvlakken in een tabel - in wezen pre-berekenen van alle outputs voor de gehele invoerruimte. Dit creëert extra vereisten voor de onderliggende database:
- Mogelijkheid om een tabel te maken van honderden gigabytes of terabytes (afhankelijk van de grootte en het aantal invoerparameters)
- Eenvoud van beheer (dwing beheerders niet om sharding te beheren, enz.)
Vanuit het operationele databaseperspectief van Cloudera kan een machine learning-model gemakkelijk worden weergegeven als een tabel (en dit is de benadering die veel klanten hebben gekozen):
- De primaire sleutel bestaat uit de set invoer die nodig is om de uitvoer te identificeren (ongeacht het aantal vereiste invoer)
- Kolom:Aanbeveling voor machine learning-modellen (de uitvoer)
- Kolom:Modelversie
Een auditmogelijkheid ziet er ook uit als een tabel:
- De primaire sleutel bestaat uit de set invoer die nodig is om de uitvoer te identificeren (ongeacht het aantal vereiste invoer)
- Kolom:aan wie heeft u deze uitvoer geleverd (bijv. klant-ID)
- Kolom:welke uitvoer is weergegeven
- Kolom:welke modelversie is gebruikt
- Kolom:welk alternatief antwoord zou beter zijn geweest (vergroting)
Augmentatie kan handmatig of programmatisch worden gedaan (dwz wanneer een creditcardmaatschappij u e-mailt met het verzoek om een transactie te verifiëren - ze doen aan gegevensvergroting). Deze audittabel die is aangevuld, kan worden gebruikt om het leren ter plaatse in de database te versterken of in een datawarehouse te laden.
Omdat de gegevens zich in de database bevinden, kunnen modelupdates worden uitgevoerd zonder enige uitvaltijd van de applicatie.
Vanuit een schaalperspectief is de operationele database van Cloudera gebouwd op Apache HBase en Apache Phoenix - van beide is bewezen dat ze probleemloos tabellen kunnen verwerken die honderden terabytes groot zijn.
Bekijk de operationele database van Cloudera binnen het Cloudera Data Platform op Public Cloud om uw volgende op ML gebaseerde app te bouwen.