Data science kan op allerlei plaatsen in de organisatie waarde toevoegen. Losstaande analyses kunnen uitgevoerd worden om bijvoorbeeld meer inzicht te krijgen in bedrijfsprocessen of risico’s beter in kaart te brengen. Steeds vaker is er ook de wens om de data-science-technieken toe te passen in apps, op websites of andere productie-applicaties.
Data scientists zijn echter geen software engineers en de gebouwde modellen zijn vaak niet direct inzetbaar in de applicaties omdat ze niet performant genoeg zijn, het heel veel resources vraagt om deze te draaien, of niet fault-tolerant zijn. Toch willen niet het volledige werk van de data scientist overdoen wanneer we het model in productie zetten. Daarom onderstaand een aantal technieken waarmee het mogelijk is voorspellende modellen in productie te brengen.
Batch Caching
Voorspellingen hoeven niet altijd on-the-fly te gebeuren, maar kunnen veelal op voorhand of op gezette intervallen gedaan worden. Denk bijvoorbeeld aan een recommendation engine, mijn voorkeur aan films zal niet elke minuut wijzigen, dus deze kunnen ook 1x per dag of 1x per week berekend worden.
Voor dergelijke use-cases kunnen we een batch cache techniek inzetten. Dat houdt in dat we op bepaalde intervallen alle mogelijke voorspellingen doen en deze opslaan in een datastore. Het ophalen van de voorspelling is voor de app dus niets meer dan een lookup.
De batch berekeningen kunnen gedaan worden op tijdstippen dat er weinig load staat op de it-infrastructuur (bijvoorbeeld ’s nachts of in het weekend). Batch computing frameworks als Spark kunnen helpen om op grote schaal veel voorspellingen te maken. Voor het opslaan van de voorspellingen kan een low-latency datastore gebruikt worden zoals Redis of Cassandra.
Voordelen
- Bij het ophalen van een voorspelling hoeft geen berekening meer gemaakt te worden, maar enkel een database lookup. Deze techniek heeft dus een heel lage latency per request en is dus ideaal voor integratie met een website of app waarbij performance belangrijk is.
- Veel flexibiliteit in de keuze van het model.
- Zeer resillient. Het batch process kan heel grondig en goed getest worden. Bovendien gebeurt dit offline, dus indien er problemen optreden tijdens runtime kunnen die worden aangepakt zonder dat eindgebruikers hier problemen door ondervinden.
Nadelen
- Alleen inzetbaar als op voorhand alle features bekend zijn.
- Omdat er op bepaalde intervallen voorspeld wordt, kunnen de trends uit de tussenliggende periode niet worden meegenomen in de voorspelling.
- Niet mogelijk om real-time informatie mee te nemen als feature, zoals clickstreamdata.
Modelparameters opslaan
Soms is het niet mogelijk om alle voorspellingen op voorhand te doen. Denk bijvoorbeeld aan cases waarbij real-time of snel veranderende data als feature wordt gebruikt. Bijvoorbeeld sessie-gegevens om de meest relevante banner op de website te voorspellen. Ook bij use-cases waarbij de te voorspellen mogelijkheden zo groot zijn dat dit problemen oplevert met de database.
In dergelijke gevallen kan worden gekozen om niet alle voorspellingen te cachen, maar enkel de modelparameters op te slaan in een datastore. De modelparameters opnieuw trainen kan hierbij alsnog offline gebeuren. In tegenstelling tot de batch cache techniek is het moeilijker om nieuwe modellen te introduceren. In de batch cache techniek heeft dit geen invloed op de applicatie, aangezien de uitkomst er nog steeds hetzelfde zal uitzien wanneer alleen een lookup gebeurt. Bij het opslaan van de modelparameters zal er nu ook aan de applicatiekant een stuk logica moeten zijn waar de voorspelling aan de hand van de opgeslagen parameters gebeurt. Bij een ander model zal dit deel van de applicatie dus aangepast moeten worden.
Voordelen
- Meer flexibiliteit in het gebruik van features, real-time data kan mee worden genomen in de voorspellen.
- Kleine database footprint.
- Bij een laag volume aan requests hoeft er minder gerekend te worden.
Nadelen
- Applicatie moet de “predict”-logica bevatten. Daardoor extra moeilijkheid indien een nieuw model geïntroduceerd wordt.
- Minder goede performance t.o.v. de batch-cache-techniek, aangezien hier per request een berekening zal plaatsvinden.
Micro-service prediction API’s
Bij de vorige techniek zagen we dat de applicatie logica moet bevatten om de parameters te interpreteren. Dit willen we vaak niet, denk aan de principes van “clean architecture”, “separation of concerns” en dergelijke. Dit kunnen we oplossen door het model te wrappen in een micro service api. In dat geval bouwen we een kleine API rond het getrainde model en exposen we een beperkt aantal endpoints. Bijvoorbeeld alleen een “/predict” met de features om een voorspelling te maken.
Op deze manier is de overige applicatielogica volledig gescheiden van de logica die hoort bij het voorspellend model. Een dergelijke API kan ook bijna volledig door data scientists ontwikkeld worden met beperkte hulp van software engineers. Deze service kan uitgerold worden als stateless api en is daardoor dus ook optimaal schaalbaar.
Voordelen
- Beter schaalbaar dan modelparameters opslaan. Enkel de micro-service hoeft namelijk geschaald te worden, niet de volledige applicatie.
- Flexibiliteit in het gebruik van features, real-time data kan mee worden genomen in de voorspellen.
- Volledig gescheiden logica tussen prediction API en de rest van de applicatie.
- Modelparameters opnieuw trainen is moeilijker dan bij de andere technieken, aangezien het model gewrapped is in de micro service zal een nieuwe deployment plaats moeten vinden.
- Heel makkelijk A-B testen van verschillende modellen.
Nadelen
- Latency zal hoger zijn dan bij de batch cache techniek.
- Nieuwe losstaande service die moet gemonitored worden.
- Voorspellingen gebeuren online dus er moet goede errorhandling zijn indien iets fout gaat. Hiervoor kunnen bijvoorbeeld circuit breakers worden ingezet.
Conclusie
We kunnen uit het bovenstaande overzicht concluderen dat afhankelijk van het probleem er verschillende manieren zijn om data science modellen in productie te brengen, waarbij veel afhangt van de gestelde requirements. Daarbij geldt wel dat bovenstaande opsomming bij lange na niet uitputtend is en slechts geldt als voorbeeld.
Meet-up “Data science in productie”
Op dinsdag 28 maart organiseert BigData Republic de meet-up “Data science in productie” waarbij we hier verder op ingaan en laten zien hoe de micro-service architectuur in de praktijk werkt. Interesse? Aanmelden kan via https://www.meetup.com/Creating-Data-Science-Architecture-best-practice-workshops/events/237241122/.
