Share
Naarmate meer bedrijven het belang van data science en geavanceerde analyses voor hun winstmarge ontdekken, is een botsing van culturen begonnen. Hoe kunnen deze snelgroeiende velden deel gaan uitmaken van het ecosysteem van een bedrijf, vooral voor gevestigde bedrijven die al meer dan tien jaar bestaan?
Gegevenswetenschappers en IT-professionals hebben sterk uiteenlopende behoeften op het gebied van infrastructuur. Hier zal ik enkele van die vereisten uiteenzetten en bespreken hoe ik verder kan gaan - en samen evolueren.
Bij het opstarten van data science-programma's binnen bedrijven, komen de grootste problemen vaak niet voort uit de technologie zelf, maar uit eenvoudige miscommunicatie. Interdepartementale misvattingen kunnen resulteren in veel wrok-vasthouden tussen beginnende data science-teams en IT-afdelingen.
Om dit te bestrijden, zullen we beide perspectieven onderzoeken en rekening houden met elk van hun behoeften. We zullen beginnen met te definiëren wat een IT-professional nodig heeft om een succesvolle workflow te behouden, en dan zullen we kijken naar wat een data-wetenschapper nodig heeft voor maximale efficiëntie. Ten slotte zullen we de gemeenschappelijke basis vinden: hoe het te gebruiken om een gezonde infrastructuur te implementeren om beide te laten floreren.
Laten we beginnen met het bekijken van een typische gegevensinfrastructuur voor IT en softwareontwikkeling.
Wat gegevens betreft, zijn er drie essentiële vereisten waaraan elke IT-afdeling zich zal moeten houden:
Vanwege dit maakt een groot deel van de IT gebruik van op tabellen gebaseerde schema's en gebruikt vaak SQL (Structured Query Language) of een van zijn varianten.
Deze opstelling betekent dat er een groot aantal tabellen voor elk doel is. Elk van deze tabellen is gescheiden van elkaar, met externe sleutels die ze verbinden. Vanwege deze opstelling kunnen query's snel, efficiënt en met beveiliging worden uitgevoerd. Dit is belangrijk voor softwareontwikkeling, waarbij gegevens intact en betrouwbaar moeten blijven.
Met deze structuur is de vereiste hardware vaak minimaal in vergelijking met de behoeften van de gegevenswetenschap. De opgeslagen gegevens zijn goed gedefinieerd en evolueren met een voorspelbaar tempo. Weinig van de gegevens worden herhaald en het queryproces verlaagt de hoeveelheid benodigde verwerkingsbronnen.
Laten we eens kijken hoe gegevenswetenschap verschilt.
Aan de andere kant heeft data science verschillende behoeften. Dataskundigen hebben bewegingsvrijheid met hun gegevens en flexibiliteit nodig om hun gegevens snel aan te passen. Ze moeten gegevens op niet-standaard manieren kunnen verplaatsen en grote hoeveelheden tegelijk verwerken.
Deze behoeften zijn moeilijk te implementeren met behulp van zeer gestructureerde databases. Data science vereist een andere infrastructuur, in plaats daarvan op ongestructureerde data en tafelloze schema's.
Wanneer we naar ongestructureerde gegevens verwijzen, hebben we het over gegevens zonder intrinsieke definitie. Het is vaag totdat het door een gegevenswetenschapper is gegeven. Voor de meeste ontwikkelingen moet elk veld van een gedefinieerd type zijn, zoals een geheel getal of een tekenreeks. Voor data science gaat het echter om het ondersteunen van datapunten die slecht zijn gedefinieerd.
Tafelloze schema's voegen meer veelzijdigheid toe aan deze quasi-chaotische opstelling, waardoor alle informatie op één plek kan leven. Het is vooral handig voor gegevenswetenschappers die regelmatig gegevens moeten samenvoegen op creatieve en ongestructureerde manieren. Populaire keuzes omvatten NoSQL-varianten of structuren die verschillende dimensies toestaan, zoals OLAP-kubussen.
Als gevolg hiervan is de hardware die nodig is voor data science vaak aanzienlijker. Het moet alle gebruikte gegevens bevatten, evenals deelverzamelingen van die gegevens (hoewel dit vaak wordt verspreid over meerdere structuren of diensten). De hardware kan ook aanzienlijke verwerkingsbronnen vereisen, aangezien grote hoeveelheden gegevens worden verplaatst en geaggregeerd.
Met deze twee sets van behoeften in gedachten, kunnen we nu zien hoe miscommunicatie kan optreden. Laten we deze perspectieven nemen en gebruiken om te bepalen welke veranderingen we zoeken en hoe. Welke problemen moeten worden opgelost bij het brengen van data science in een traditionele IT-omgeving?
In een traditionele IT-omgeving volgen de databases van een bepaald bedrijf waarschijnlijk een rigide structuur, met tabellen die zijn opgedeeld om aan specifieke behoeften te voldoen, een geschikt schema om elk gegeven te definiëren en externe sleutels om alles samen te binden. Dit zorgt voor een efficiënt systeem voor het opvragen van gegevens. De verkennende aard van sommige methoden van data science kan dit tot het uiterste opdringen.
Wanneer een gemeenschappelijke taak het samenvoegen van een tiental of meer tabellen vereist, worden de voordelen van op tafel gebaseerde structuren minder duidelijk. Een populaire methode om dit aan te pakken is om een secundaire NoSQL of meerdimensionale database te implementeren. Deze secundaire database maakt gebruik van reguliere ETL's (Extract, Transform, Load) om de informatie vers te houden. Dit voegt de kosten van extra hardware- of cloudservicegebruik toe, maar minimaliseert eventuele andere nadelen.
Houd er rekening mee dat in sommige gevallen het toevoegen van een aparte database voor data science goedkoper kan zijn dan het gebruik van dezelfde database (vooral als ingewikkelde licentiekwesties een rol gaan spelen).
Dit specifieke probleem heeft betrekking op twee genoemde mismatches:
In traditionele IT is de grootte van uw database goed gedefinieerd, waarbij deze dezelfde grootte behoudt of groeit in een bescheiden tempo. Bij gebruik van een database voor data science kan die groei exponentieel zijn. Het is gebruikelijk om elke dag (of meer) gigabytes aan gegevens toe te voegen. Met de enorme omvang van dit soort gegevens moet een bedrijf een plan opnemen om de interne architectuur te schalen of een geschikte cloudoplossing gebruiken.
Wat betreft ongestructureerde gegevens, het kan veel resources in beslag nemen op het gebied van opslag en verwerkingskracht, afhankelijk van uw specifieke gebruik. Daarom is het vaak inefficiënt om alles in een database te bewaren die voor andere doeleinden kan worden gebruikt. De oplossing is vergelijkbaar met schalen in het algemeen. We hebben een plan nodig om onze interne architectuur aan te passen om aan deze behoeften te voldoen, of we zullen een geschikte cloudoplossing moeten vinden.
Het laatste grote verschil dat we zullen bespreken is het gebruik van middelen. Voor IT is het gebruik van resources doorgaans efficiënt, goed gedefinieerd en consistent. Als een database een eCommerce-site van stroom voorziet, zijn er bekende beperkingen. Een IT-professional weet ongeveer hoeveel gebruikers er over een bepaalde periode zullen zijn, dus kunnen zij hun hardwarelevering plannen op basis van hoeveel informatie nodig is voor elke gebruiker.
Met de traditionele IT-infrastructuur zullen er geen problemen zijn als een project maar een paar honderd rijen van een handvol tabellen gebruikt. Maar een project dat elke rij van twee dozijn tafels vereist, kan al snel een probleem worden. In de gegevenswetenschap veranderen de behoeften op het gebied van verwerking en opslag van project tot project en dat soort onvoorspelbaarheid kan moeilijk zijn om te ondersteunen.
In traditionele IT kunnen bronnen worden gedeeld met andere partijen, bijvoorbeeld een live-productiesite of een intern ontwikkelteam. Het risico is hier dat het draaien van een grootschalig data science project mogelijk die andere gebruikers voor een bepaalde periode kan afsluiten. Een ander risico is dat de servers met een database mogelijk niet de enorme hoeveelheid verwerking aankunnen die nodig is. Het oproepen van 200.000 rijen uit 15 tabellen en vragen om aggregatie van gegevens bovenaan, wordt een probleem. Deze omvang van query's kan zeer belastend zijn op een server die normaal ongeveer duizend gelijktijdige gebruikers aankan.
De ideale oplossing komt neer op cloudverwerking. Dit behandelt twee belangrijke factoren. De eerste is dat het queryprestaties uit de buurt van belangrijke databases maakt. De tweede is dat het schaalmogelijkheden biedt die bij elk project passen.
Nu we het over de behoeften hebben gehad, laten we ze samenvatten. Een afdeling IT en data science heeft het volgende nodig voor succes op de lange termijn:
Laten we alles opsplitsen in specificaties, zodat we een voor beide partijen voordelige oplossing kunnen samenstellen. Nu zullen we kijken hoe we de specifieke resources kunnen definiëren die nodig zijn voor een organisatie:
Van IT-zijde zijn er drie hoofddefinities nodig om de nodige infrastructuur te creëren. Dit zijn:
Hier is hoe je elk kunt bepalen.
Het begint allemaal met de benodigde initiële gegevensgrootte en de geschatte doorlopende gegevenstoevoegingen.
Neem voor uw eerste gegevensbehoeften de gedefinieerde grootte van uw huidige database. Trek nu de kolommen of tabellen af die u niet nodig heeft in uw data science-projecten. Neem dit nummer en voeg de gegevensgrootte toe van alle nieuwe bronnen die u zult introduceren. Nieuwe bronnen kunnen Google Analytics-gegevens of informatie van uw Point of Sale-systeem bevatten. Dit totaal zal de gegevensopslag zijn die we van te voren willen bereiken.
Hoewel de initiële opslagbehoeften van tevoren nuttig zijn, moet u rekening houden met de huidige gegevensbehoeften, omdat u waarschijnlijk in de loop van de tijd meer informatie aan de database zult toevoegen. Om deze informatie te vinden, kunt u uw dagelijks toegevoegde gegevens uit uw momenteel beschikbare gegevens berekenen. Bekijk de hoeveelheid informatie die in de afgelopen 30 dagen aan uw database is toegevoegd en deel die vervolgens met 30 in. Herhaal vervolgens voor elke informatiebron die u gaat gebruiken en voeg deze bij elkaar.
Hoewel dit niet precies is, is er een oude ontwikkelingsmantra die je zou moeten verdubbelen, en die gaan we hier gebruiken. Waarom? We willen rekening houden met onvoorspelbare wijzigingen die van invloed kunnen zijn op uw gegevensopslagbehoeften, zoals bedrijfsgroei, behoeften per project of alleen algemene gebieden.
Met dat nummer dat nu is gedefinieerd, vermenigvuldigt u het met 365. Dit is nu uw geprojecteerde gegevensgroei voor een jaar, die, wanneer toegevoegd aan uw startbedrag, bepaalt hoeveel opslagruimte u moet kijken naar het verkrijgen van.
In tegenstelling tot de behoefte aan gegevensopslag, zijn de verwerkingsbehoeften veel moeilijker om precies te berekenen. Het belangrijkste doel hier is om te beslissen of u het zware werk op queries of op een lokale machine (of cloudinstantie) wilt plaatsen. Houd er hier rekening mee dat wanneer ik het heb over een lokale computer, ik niet alleen de computer bedoel die u normaal gebruikt, u hebt waarschijnlijk een soort van geoptimaliseerd werkstation nodig voor de meer intensieve berekeningen..
Om deze keuze te maken, helpt het om na te denken over het grootste data science-project dat je misschien het komende jaar zou uitvoeren. Kan uw gegevensoplossing een zoekopdracht van die omvang afhandelen zonder ontoegankelijk te worden voor alle andere belanghebbenden? Als het kan, dan ben je goed om te gaan zonder extra hulpmiddelen nodig. Als dat niet het geval is, moet u van plan zijn om een werkstation van de juiste grootte te krijgen of cloudinstanties te schalen.
Nadat u hebt besloten waar u uw gegevens wilt opslaan en verwerken, is de volgende beslissing hoe. Als u een ETL-proces maakt, blijft uw gegevenswetenschapdatabase overzichtelijk en bijgewerkt en wordt voorkomen dat deze onnodige bronnen van elders gebruikt.
Dit is wat u zou moeten hebben in uw ETL-documentatie:
Met alle gegevenspunten in de hand, is het tijd om een oplossing te kiezen. Dit deel zal wat onderzoek vergen en zal sterk afhankelijk zijn van uw specifieke behoeften, omdat zij aan de oppervlakte over veel overeenkomsten beschikken..
Drie van de grootste cloudoplossingen: Amazon Web Services (AWS), Google Cloud Platform (GCP) en Microsoft Azure bieden enkele van de beste prijzen en functies. Alle drie hebben relatief vergelijkbare kosten, hoewel AWS het moeilijker is om de kosten te berekenen voor (vanwege zijn a la carte Prijsstructuur).
Naast prijs bieden ze ook schaalbare gegevensopslag en de mogelijkheid verwerkingsinstanties toe te voegen, hoewel elk zijn instanties een andere naam noemt. Wanneer u onderzoekt welke te gebruiken voor uw eigen infrastructuur, houdt u rekening met welke typen projecten u het meest zult gebruiken, omdat dat de waarde van ieders prijsstelling en functieset kan verschuiven.
Veel bedrijven kiezen echter eenvoudigweg welke lijn uitgelijnd is met hun bestaande technologiestack.
U kunt ook uw eigen infrastructuur intern inrichten, hoewel dit aanzienlijk ingewikkelder is en niet voor bangeriken.
Met al je eenden op een rij, kun je de implementatie starten! Om u daarbij te helpen, volgen hier een aantal zuurverdiende tips om uw project eenvoudiger te maken - van pitch tot uitvoering.
Wanneer je je ETL-proces voor het eerst samenstelt, test dan niet alles in één keer! Dit kan uw middelen ernstig belasten en uw cloudkosten drastisch verhogen als er een fout is of als u het proces verschillende keren moet proberen.
In plaats daarvan is het een goed idee om uw proces eerst uit te voeren met alleen de eerste 100 rijen van uw oorsprongstabellen. Voer vervolgens de volledige overdracht uit als u weet dat deze werkt.
Hetzelfde geldt voor elke grote query die u uitvoert op een cloudinstantie. Een fout maken die miljoenen gegevens verzamelt, is veel moeilijker dan een systeem dat er maar een paar inhaalt, vooral als je per GB betaalt.
De meeste cloud-operators bieden dit als een functie, dus u hoeft zich hier geen zorgen over te maken. Uw team moet nog steeds bespreken of zij hun eigen regelmatige back-up van de gegevens willen maken, of dat het effectiever is om de gegevens te reconstrueren als de noodzaak zich voordoet.
Wanneer u klantgegevens naar de cloud verplaatst, moet u ervoor zorgen dat alle betrokkenen op de hoogte zijn van het beleid voor gegevensbeheer van uw bedrijf om problemen onderweg te voorkomen. Dit kan u ook helpen om wat geld te besparen op de hoeveelheid gegevens die in de cloud wordt opgeslagen.
Wanneer u uw ETL uitvoert vanuit een op tabellen gebaseerde database naar een ongestructureerde database, moet u voorzichtig zijn met het benoemen van procedures. Als namen alleen maar groothandel zijn, hebt u waarschijnlijk veel velden uit verschillende tabellen met dezelfde naam. Een eenvoudige manier om dit in eerste instantie te overwinnen, is door uw nieuwe dimensies een naam te geven in de ongestructureerde database Oldtablename _ columnname en hernoem ze vanaf daar.
Nu kunt u de basis van uw analyse- en datalinkinfrastructuur plannen. Met veel van de belangrijkste vragen en antwoorden gedefinieerd, zou het implementatieproces en het krijgen van management buy-in veel vlotter moeten verlopen.
Heeft u moeite om antwoorden te vinden voor uw eigen bedrijf? Heb ik iets belangrijks weggelaten? Laat het me weten in de comments!
Accentsconagua