R/Python platform zakelijk

[bits]

Ik werk voor een bedrijf die marktdata wil importeren uit verschillende databronnen en hierop verschillende apparaten wil gaan aansturen. Deze apparaten moeten elke minuut een nieuw signaal krijgen. Hiervoor zijn we opzoek naar een platform waarin we onze eigen Python en R scripts kunnen draaien en beheren. Verschillende algoritmes zullen dan worden gecombineerd tot uiteindelijk één stuursignaal ontstaat. Deze puzzel bestaat uiteindelijk uit de volgende delen:

• Het importeren en opslaan van externe databronnen in een (SQL) database
• Het toepassen van verschillende machine learning technieken om te komen tot een stuursignaal per apparaat
• Het verzenden van dit stuursignaal naar de uiteindelijke apparaten, inclusief stabiel houden van de verbinding, monitoring e.d.

Van deze puzzel ben ik opzoek naar het tweede onderdeel. Het derde onderdeel draait goed en het eerste onderdeel draait wel maar vertoont nog aanzienlijke performance issues.

Requirements die we hebben opgesteld zijn:

• Ondersteuning voor Python 2.x, Python 3.x en R scripts
• Parallel kunnen draaien van verschillende scripts met verschillende starttijden zodat bijvoorbeeld een neuraal netwerk kan worden getraind (een proces van uren) terwijl nog steeds elke minuut een stuursignaal wordt geproduceerd
• Opslaan en laden van o.a. .JSON en .H5 bestanden voor gebruik in de algoritmes. Een van onze algoritmes gebruikt deze bestanden.
• Moeiteloos importeren van datasets van 50MB. We zullen niet gauw datasets van >1GB nodig hebben.
• Mogelijkheid om (minimaal) een testomgeving en productieomgeving te bouwen zodat we een nieuw algoritme direct kunnen simuleren
• Mogelijkheid om script X te draaien nadat script A tot Q klaar zijn met draaien
• Mogelijkheid om scripts elkaar aan te laten roepen
• Mogelijkheid om scripts op gezette tijden (bijv. elke minuut of elke week) te laten draaien
• _{Nice-to-have: een user interface waarmee een simulatie kan worden gedaan voor verschillende parameters op de meest recente algoritmes}
• _{Nice-to-have: een user interface waarmee resultaten met minder dan 5 seconden vertraging visueel worden weergegeven}
• Geen requirement is een 'data science made easy' platform. We hebben uitstekende data scientists in dienst die vaak gebruikmaken van obscure R en Python packages/libraries. Een 'data science made easy'-platform beperkt hun alleen maar.

Wat we zoeken lijkt ons niet bijzonder moeilijk te maken en ik kan me niet voorstellen dat er geen ondernemingen te vinden zijn die zoiets hebben, het lijkt mij dan ook dat er voldoende oplossingen zijn maar dat we ze gewoon niet kunnen vinden.

Er is al gekeken naar Microsoft Azure ML (traag, beperkt) en we zijn nu aan het kijken naar Apache Spark. Mogelijk zijn er verschillende tools te combineren in Azure die hetzelfde resultaat opleveren? Alternatief zou zijn om alles zelf te bouwen in Python maar daar ligt niet onze expertise. Mijn vraag is daarom of er een platform bestaat wat voldoet aan bovenstaande requirements? Twijfel vooral niet om iets te roepen, mogelijk brengt dit iemand op het juiste spoor.

[P_de_B]

Met verschillende onderdelen binnen Azure kun je dit zeker doen. Voor machine learning technieken is Azure ML dan wel een voorname kandidaat, kun je iets meer vertellen over de beperkingen en traagheid die je hebt ervaren? Heb je het bijvoorbeeld met een betaald account getest? Dat scheelt nogal in performance. Qua beperkingen eigenlijk dezelfde vraag. Je kunt je eigen python en r scripts en packages toevoegen. Het kan natuurlijk zeker dat er beperkingen zijn, maar kun je daar iets meer over vertellen? Naast AzureML kun je ook gebruik maken van R in SQL Server 2016.

Ondersteuning voor Python 2.x, Python 3.x en R scripts

Check

Parallel kunnen draaien van verschillende scripts met verschillende starttijden zodat bijvoorbeeld een neuraal netwerk kan worden getraind (een proces van uren) terwijl nog steeds elke minuut een stuursignaal wordt geproduceerd

Check, als je een AzureML model gedeployed hebt naar productie kun je hem als webservice aanroepen om het model te evalueren. Een nieuwe versie kan ondertussen getrained worden.

Opslaan en laden van o.a. .JSON en .H5 bestanden voor gebruik in de algoritmes. Een van onze algoritmes gebruikt deze bestanden.

Check, verschillende mogelijkheden. Je kunt ze in BLOB-storage plaatsen of in een database (SQL, DocumentDB of andere db)

Moeiteloos importeren van datasets van 50MB. We zullen niet gauw datasets van >1GB nodig hebben.

Check

Mogelijkheid om (minimaal) een testomgeving en productieomgeving te bouwen zodat we een nieuw algoritme direct kunnen simuleren

Check

Mogelijkheid om script X te draaien nadat script A tot Q klaar zijn met draaien

Check, maar hier moet je zelf wel werk voor doen. Kijk daarvoor eens naar Datafactories, dat is de tool die gebruik kan worden om je hele flow van data te orchestreren en om data van (on premise) bronnen te uploaden, transformeren, opslaan etc. Dit zou ook een oplossing kunnen zijn voor punt 1 van je oplossing. Kijk ook eens naar Logic Apps om workflows te maken.

Mogelijkheid om scripts elkaar aan te laten roepen

Check, maar kan zijn dat je hier zelf ook wel werk voor moet doen. Wij gebruiken hier een service bus structuur voor. Een bericht in een queue of topic zorgt ervoor dat een achtergrondproces een volgende stap aanroept. Ook Datafactory of Logic Apps kan hier een rol in spelen

Mogelijkheid om scripts op gezette tijden (bijv. elke minuut of elke week) te laten draaien

Check

Nice-to-have: een user interface waarmee een simulatie kan worden gedaan voor verschillende parameters op de meest recente algoritmes

Twijfel, je kunt in AzuremL studio simulaties doen, je kunt in PowerBi verschillende scenario's visualiseren, maar je zult er wel werk voor moeten doen.

Nice-to-have: een user interface waarmee resultaten met minder dan 5 seconden vertraging visueel worden weergegeven

Check, we gebruiken hier Stream Analytics met PowerBi voor.

Geen requirement is een 'data science made easy' platform. We hebben uitstekende data scientists in dienst die vaak gebruikmaken van obscure R en Python packages/libraries. Een 'data science made easy'-platform beperkt hun alleen maar.

AzureML neemt je natuurlijk werk uit handen, maar de hele stack biedt een groot aantal mogelijkheden om custom werk te doen.

Je zou eens kunnen kijken naar een aantal Cortana Analytics solution templates waarbij een groot aantal technieken binnen de Azure stack gecombineerd worden tot een complete oplossing, of deze. Je ziet dan ook wel dat het geen complete out-of-the-box oplossing is, je zult onderdelen (waaronder ook Apache Spark tot de mogelijkheden behoort) tot een werkende oplossing moeten maken.

Laatste opmerking, voor het verzenden van stuursignalen, monitoring van de verbinding, security etc kun je ook naar de Azure IoT propositie kijken.

Er zijn natuurlijk ook andere oplossingen, bijvoorbeeld Cloudera. Dat is een wat meer out-of-the-box oplossing.

[raptorix]

Die Azure Machine learning is zeer aan te raden.

[zneek]

Er leiden meerdere wegen naar Rome. Ik zou niet zomaar een (infrastructuur/hosting) platform kiezen, maar eerst goed je uitdaging helder krijgen, een gedegen ontwerp neerzetten en daar je platform bij kiezen. Spark is een logische keuze voor je processing, zowel batch (trainen modellen) als realtime/streaming. Apache Flink zou een alternatief kunnen zijn.

Wij starten met dit soort cases meestal vanuit de gedachte van een Lambda Architectuur. Dit is een redelijke fit met de meeste van dit soort cases en biedt voldoende ruimte om later nuances en focus te verschuiven binnen je architectuur. De basisbouwstenen voor ons zijn meestal Hadoop (MapR!), Spark en in veel gevallen ElasticSearch (briljant!).

Data analyse, het onwikkelen van algoritmes en bouwen van modellen gebeurt meestal door ons Datascience & AI team met behulp van RapidMiner om vervolgens uitgewerkt en verfijnd te worden in Python. Onze engineering tak pakt het dan over en implementeert het binnen de lambda architectuur in Spark (op basis van Python en Scala).

Qua infra kunnen je met de genoemde bouwstenen alle kanten op, wij draaien dit soort architecturen op zowel eigen hardware bij klanten, bij NL hostingproviders, Amazon, Azure en Google. De standaard oplossingen die partijen bieden, zoals de AWS, Azure of Google standaard omgevingen zijn een mooie opstap, maar die voldoen voor veel klanten niet op lange termijn. Qua security, controle, flexibiliteit en kosten (!! Azure, AWS, Google zijn NIET goedkoper dan NL ISPs) moeten veel klanten meer dan die standaarden bieden.

[bits]

Dank voor de adviezen tot zover! Ik ga even kijken of dit in het straatje past, ik zie al dat het uiteindelijk uit zal draaien op een combinatie van oplossingen en dat er niet zomaar één of-the-shelf oplossing is.

P_de_B schreef op donderdag 25 augustus 2016 @ 10:06:
Met verschillende onderdelen binnen Azure kun je dit zeker doen. Voor machine learning technieken is Azure ML dan wel een voorname kandidaat, kun je iets meer vertellen over de beperkingen en traagheid die je hebt ervaren? Heb je het bijvoorbeeld met een betaald account getest? Dat scheelt nogal in performance. Qua beperkingen eigenlijk dezelfde vraag. Je kunt je eigen python en r scripts en packages toevoegen. Het kan natuurlijk zeker dat er beperkingen zijn, maar kun je daar iets meer over vertellen?

Wij hebben Azure ML op dit moment laten schieten om 2 redenen:

1. De communicatie naar het platform dat het stuursignaal doorzend naar de verschillende apparaten (het derde puzzelstukje) zou niet snel genoeg werken. We kunnen met ML wel een webservice opzetten maar Azure biedt geen request-response variant aan waardoor we Azure ML geen resultaten kunnen laten doorpushen. Dit zou op te lossen zijn door resultaten batch-based te laten processen maar dan krijg je ofwel veel traffic (door elke seconde te processen) ofwel vertraging (door elke minuut te processen). Voor ons is elke seconde vertraging al een aanzienlijke schadepost
2. We hadden een standard subscription (de betaalde variant dus) en waren ontevreden over de performance. Sowieso was het trainen van de modellen veel te langzaam maar ook als een webservice deployed was en het model getrained liet ML een wisselende performance zien waarin het soms te langzaam was.

Een extra requirement die ik overigens nog niet heb kunnen testen (Azure ML is eerst door iemand anders getest die het nog niet langs mij had gehaald) is of ook Python modules waarvan code deels in C#/C++ is geschreven gebruikt kan worden. Deze zal ik even toevoegen aan de opening post.

[P_de_B]

bits schreef op donderdag 25 augustus 2016 @ 11:31:
Dank voor de adviezen tot zover! Ik ga even kijken of dit in het straatje past, ik zie al dat het uiteindelijk uit zal draaien op een combinatie van oplossingen en dat er niet zomaar één of-the-shelf oplossing is.


[...]


Wij hebben Azure ML op dit moment laten schieten om 2 redenen:
[list=1]
• De communicatie naar het platform dat het stuursignaal doorzend naar de verschillende apparaten (het derde puzzelstukje) zou niet snel genoeg werken. We kunnen met ML wel een webservice opzetten maar Azure biedt geen request-response variant aan waardoor we Azure ML geen resultaten kunnen laten doorpushen. Dit zou op te lossen zijn door resultaten batch-based te laten processen maar dan krijg je ofwel veel traffic (door elke seconde te processen) ofwel vertraging (door elke minuut te processen). Voor ons is elke seconde vertraging al een aanzienlijke schadepost

Je kunt toch de RRS gebruiken?

quote: https://azure.microsoft.c...ing-consume-web-services/

Request-Response Service (RRS)
A Request-Response Service (RRS) is a low-latency, highly scalable web service used to provide an interface to the stateless models that have been created and deployed from an Azure Machine Learning Studio experiment. It enables scenarios where the consuming application expects a response in real-time.

RRS accepts a single row, or multiple rows, of input parameters and can generate a single row, or multiple rows, as output. The output row(s) can contain multiple columns.

Je kunt dit zelfs op real time data via stream analytics laten uitvoeren.

• We hadden een standard subscription (de betaalde variant dus) en waren ontevreden over de performance. Sowieso was het trainen van de modellen veel te langzaam maar ook als een webservice deployed was en het model getrained liet ML een wisselende performance zien waarin het soms te langzaam was.

Heb je contact gehad met het team? Ze zijn erg geïnteresseerd in en behulpzaam richting bedrijven die hier serieus mee aan de slag gaan. Je kunt hele goede ondersteuning krijgen.

[bits]

P_de_B schreef op donderdag 25 augustus 2016 @ 12:07:
[...]


Je kunt toch de RRS gebruiken?


[...]


Je kunt dit zelfs op real time data via stream analytics laten uitvoeren.


[...]


Heb je contact gehad met het team? Ze zijn erg geïnteresseerd in en behulpzaam richting bedrijven die hier serieus mee aan de slag gaan. Je kunt hele goede ondersteuning krijgen.

We hebben zeker contact gehad met het team van Microsoft. Ze waren inderdaad erg behulpzaam en schakelden direct enkele experts bij maar vonden de use case toch ook erg lastig en uiteindelijk zijn we niet tot de juiste oplossing gekomen. Ik ga even aan de slag met de zaken die jij aandraagt om te kijken of dat toch de oplossing is!

[MrBlond]

Ik kan je knime aanraden. Is volledig open source en kan eigenlijk alle aspecten die jij benoemd. Je kan verbinden met databases, er je eigen python en r scripts inhangen en verbinding maken met api's etc. Zitten ook veel machine learning libraries en heeft heeft een erg intuïtief werkende Gui. Wij hebben de server variant draaien om bepaalde analyses beschikbaar te maken voor iedereen.

[Morrar]

Knime gebruiken wij ook wel voor exploratie en kleinschalige analyses, maar i.c.m. schedulen van jobs zou ik het niet echt aanraden (al kan t wel). Daarnaast vind ik de performance van Knime ook niet fantastisch.

Zou zelf ook naar een Spark setup gaan kijken en dan jobs starten op de driver via bijvoorbeeld cron. Meerdere scripts achter elkaar aanroepen kun je afhandelen door een caller script te maken dat de taken 1 voor 1 uitvoert. Voordeel van Spark is natuurlijk ook dat het horizontaal schaalt als je meer capaciteit nodig hebt.

Voor ontvangen van events zou ik naar bijvoorbeeld Kafka kijken, dat is een mooie message bus. Op die manier kun je event processing ook loshalen van je analysestack en redundantie inbouwen.

[ Voor 7% gewijzigd door Morrar op 30-09-2016 10:35 ]

[bits]

Een korte update van mijn kant: we hebben uiteindelijk gekozen voor een zelfbouwoplossing m.b.v. Python in een virtual machine op Azure voor de speed layer en zullen voor de batch layer een HDInsight-cluster starten wanneer nodig met daarop Apache Spark. Visualisatie gebeurt nu domweg door een JSON file naar een mapje te schrijven en met behulp van een beetje HTML en Plotly kan alles worden gevisualiseerd terwijl het ook nog eens onze kritische processen (algoritme) veilig afschermt.

Het is niet de meest chique oplossing maar leek ons voor nu de beste oplossing omdat:

- We al dusdanig veel werk in Python moeten doen (ophalen data, algoritme ontwikkeling) dat het bouwen van een framework waarin e.e.a. (stabiel) kan draaien op dit moment waarschijnlijk een eenvoudigere en sneller exercitie is dan het verkennen en opzetten van alternatieve technologieën
- Onze requirements nog eenvoudig aan te voldoen zijn m.b.v. custom build waardoor het integreren van alle software op een Spark (of vergelijkbare) omgeving waarschijnlijk overkill is
- Dit ons helpt onze requirements verder te verfijnen. We beschouwen het eindproduct als een minimum viable product en gaan dan kijken of en hoe we deze verder kunnen verbeteren.
- Er binnen onze organisatie (nog) geen kennis is van Spark/Knime/Kafka/etc waardoor we bij het opzetten hiervan continu tegen barrières zouden oplopen waarvoor we (dure) hulp van buitenaf nodig zouden hebben of veel uren van onszelf. Zoals gezegd gaan we dan liever eerst verder 'scopen' zodat we dan veel effectiever hulp van buitenaf kunnen inschakelen. Het laatste wat we willen is het klassieke 'we hebben nu een heel duur systeem wat totaal iets anders doet dan wat we eigenlijk wilden'

Technologisch gezien hebben we dus nog geen chique oplossing maar praktisch gezien zijn we wel vooruit. Waarvoor overigens dank, want alles wat tot nu toe genoemd is heeft ons wel geholpen met het verder inzoomen op het probleem en de oplossing, met name het benoemen van de lambda architectuur (was onbekend) was een eye-opener.

Wordt vervolgd.

[P_de_B]

Sla je dan je data op blob storage? Die kun je via HDFS eenvoudig via een on demand HDIsight cluster gebruiken. Dat is een relatief goedkope oplossing.

[zneek]

bits schreef op dinsdag 04 oktober 2016 @ 10:54:
Een korte update van mijn kant: we hebben uiteindelijk gekozen voor een zelfbouwoplossing m.b.v. Python in een virtual machine op Azure voor de speed layer en zullen voor de batch layer een HDInsight-cluster starten wanneer nodig met daarop Apache Spark. Visualisatie gebeurt nu domweg door een JSON file naar een mapje te schrijven en met behulp van een beetje HTML en Plotly kan alles worden gevisualiseerd terwijl het ook nog eens onze kritische processen (algoritme) veilig afschermt.

Het is niet de meest chique oplossing maar leek ons voor nu de beste oplossing omdat:

- We al dusdanig veel werk in Python moeten doen (ophalen data, algoritme ontwikkeling) dat het bouwen van een framework waarin e.e.a. (stabiel) kan draaien op dit moment waarschijnlijk een eenvoudigere en sneller exercitie is dan het verkennen en opzetten van alternatieve technologieën
- Onze requirements nog eenvoudig aan te voldoen zijn m.b.v. custom build waardoor het integreren van alle software op een Spark (of vergelijkbare) omgeving waarschijnlijk overkill is
- Dit ons helpt onze requirements verder te verfijnen. We beschouwen het eindproduct als een minimum viable product en gaan dan kijken of en hoe we deze verder kunnen verbeteren.
- Er binnen onze organisatie (nog) geen kennis is van Spark/Knime/Kafka/etc waardoor we bij het opzetten hiervan continu tegen barrières zouden oplopen waarvoor we (dure) hulp van buitenaf nodig zouden hebben of veel uren van onszelf. Zoals gezegd gaan we dan liever eerst verder 'scopen' zodat we dan veel effectiever hulp van buitenaf kunnen inschakelen. Het laatste wat we willen is het klassieke 'we hebben nu een heel duur systeem wat totaal iets anders doet dan wat we eigenlijk wilden'

Technologisch gezien hebben we dus nog geen chique oplossing maar praktisch gezien zijn we wel vooruit. Waarvoor overigens dank, want alles wat tot nu toe genoemd is heeft ons wel geholpen met het verder inzoomen op het probleem en de oplossing, met name het benoemen van de lambda architectuur (was onbekend) was een eye-opener.

Wordt vervolgd.

Goed te lezen! En klinkt als een goede praktische oplossing!

[bits]

P_de_B schreef op dinsdag 04 oktober 2016 @ 11:16:
Sla je dan je data op blob storage? Die kun je via HDFS eenvoudig via een on demand HDIsight cluster gebruiken. Dat is een relatief goedkope oplossing.

Eenvoudig antwoord: ja.

Complexer antwoord: beetje. We hebben ook een interne SQL database bijgehouden door mijn collega's van de BI afdeling waarvan het uiteindelijke doel is voor het hele bedrijf een centrale database te bieden met alle marktprijzen, device informatie en andere zaken die relevant kunnen zijn voor analyses. Echter: om van die on-premises database data naar de Azure cloud te krijgen moet deze eerst via een Data Factory pipeline in een blob geplaatst worden. We gaan dus voor heel veel tussenstapjes blob gebruiken om redundantie te creëren en omdat dit performance-wise een goede oplossing is en omdat dit ons helpt een development-omgeving op te zetten. We gebruiken dus wel Blob storage, maar het is niet waar alles op leunt.