Big data draait voor een groot deel om geavanceerde analytische toepassingen op extreme schaal. Datawetenschappers zijn, behalve specialist op gebied van omgaan met data, ook de voornaamste applicatieontwikkelaars van de toekomst. Vaak zijn de statistische modellen die zij bouwen productie-activa die mee moeten kunnen schalen met het volume, de snelheid en de variëteit van aanverwante workloads.
Het probleem is dat de meeste datawetenschappers geen developers zijn, maar wiskundigen. In hun omgang met data, hebben ze van nature minder oog voor de prestaties in een productieomgeving naar aanleiding van de analytische modellen die ze bouwen en verfijnen. Als de algoritmes die zij bouwen niet schalen met zware workloads, dan zijn de modellen pas bruikbaar voor productie als ze aangepast kunnen worden door IT-experts.
De toenemende kloof tussen wensen en mogelijkheden
Op dit gebied kunnen DevOps een belangrijke rol spelen. Devops is een softwareontwikkelingsmethode waarbij de nadruk ligt op samenwerking en integratie tussen developers en operations professionals. Veel datawetenschappers hebben hier nog niet naar gekeken, maar dat zouden ze wel moeten doen. De steeds sterkere focus op resultaat met advanced analytics leidt tot zwaardere belasting in productieomgevingen. Als de behoeften groeien, groeit de kloof tussen datawetenschap (die prestaties beschouwt als bijzaak) en IT-beheerders (voor wie alles rond performance draait).
Een recent artikel over toegepaste voorspellende modellering uit dezelfde zorg. Volgens auteur Steve Miller is bijvoorbeeld statistisch leren (statistical learning) zeer rekenintensief en op dit moment alleen toepasbaar voor modellen die gericht zijn op kleine datasets, omdat het werken met grote datasets onbetaalbaar is.
Het is altijd goed om een resource-vretend algoritme bijtijds op te merken en niet zomaar in een productieomgeving te integreren. Mocht dit toch gebeuren, dan zijn er twee oplossingen. Ofwel je bedrijf zal moeten investeren in CPU-kracht, geheugen, storage en networking om het beest te blijven kunnen voeden of je datawetenschappers moeten in staat zijn het model te herbouwen zodat het zuiniger met beschikbare resources omgaat.
Tooling sluit niet aan bij de werkelijkheid
In een ideale wereld zou de calculatie van computergerelateerde kosten automatisch plaatsvinden binnen het werkproces van de datawetenschapper. Met andere woorden: Analytische tools, bibliotheken en sandboxing platforms zouden deze meetgegevens als een decision-support functionaliteit moeten aanbieden zodat datawetenschapper de uiteindelijke prestatiekarakteristieken kunnen meewegen in de modellen die ze bouwen.
Vanuit DevOps standpunt bezien, zou de ideale toolset voor datawetenschappers hun modellen moeten beoordelen op de volgende punten van impact op latency:
- Data-latency: Als het model wordt gebruikt voor dataverzameling, integratie en cleaning, vertraagt het model dan datatransmissie van bronnen naar uiteindelijke consumerende applicaties?
- Executie-latency: Als het model wordt uigevoerd binnen een in-database analyticsplatform, hoe snel kan het dan resultaat produceren? Als het wordt ingezet op een platform waarop meerdere workloads draaien, heeft de executie van het model dan impact op de andere workloads die op het platform draaien?
- Modellering-latency: Als het model wordt gebouwd met behulp van bestaande statistische en analytische datatools, duurt het dan langer voordat het kan worden ontwikkeld, ingevuld, getest, verbeterd en deployed?
Ervan uitgaande dat er meeste alternatieve modellen mogelijk zijn om tot hetzelfde resultaat te komen, zou de ideale tool ook prestatie voor- en nadelen meewegen, zodat de datawetenschapper een developer-verantwoorde keuze kan maken.
Ik hoop dat dit gaat gebeuren, want het zal echt blijken dat 's werelds meest vernufte analytische toepassingen nutteloos blijken als ze niet binnen redelijke termijn kunnen worden uitgevoerd op big data platforms.
-
-
Er zijn nog geen reacties.Reageer
Preview