Share
Etter hvert som flere bedrifter oppdager viktigheten av datavitenskap og avansert analyse for bunnlinjen, har et kultursamfunn begynt. Hvordan kan disse raskt voksende feltene bli en del av selskapets økosystem, spesielt for etablerte selskaper som har eksistert i ti år eller lenger?
Datavitenskapere og IT-fagfolk har svært forskjellige behov når det gjelder infrastruktur. Her legger jeg ut noen av disse kravene og diskuterer hvordan man beveger seg utover dem - og utvikler seg sammen.
Når man starter opp datavitenskapsprogrammer innen bedrifter, oppstår de største problemene ikke ofte fra selve teknologien, men fra enkel misforståelse. Interdepartementale misforståelser kan resultere i mye grudge-holding mellom fledgling datavitenskapsteam og IT avdelinger.
For å bekjempe dette, undersøker vi begge perspektiver og tar hensyn til hver enkelt av deres behov. Vi starter med å definere hva en IT-profesjonell krever for å opprettholde en vellykket arbeidsflyt, og så ser vi på hva en datavitenskapsmann trenger for maksimal effektivitet. Til slutt finner vi felles grunnlag: hvordan du bruker den til å implementere en sunn infrastruktur for både å blomstre.
La oss starte med å se på en typisk datainfrastruktur for IT og programvareutvikling.
Når det gjelder data, er det tre viktige forutsetninger som enhver IT-avdeling vil fokusere på:
På grunn av dette bruker mye av IT tabellbaserte skjemaer, og bruker ofte SQL (Structured Query Language) eller en av varianter.
Dette oppsettet betyr at det er et stort antall tabeller for alle formål. Hver av disse tabellene er skilt fra hverandre, med utenlandske nøkler som forbinder dem. På grunn av dette oppsettet kan spørringer utføres raskt, effektivt og med sikkerhet i tankene. Dette er viktig for programvareutvikling, hvor data må forbli intakt og pålitelig.
Med denne strukturen er den nødvendige maskinvaren ofte minimal i forhold til datavitenskapens behov. De lagrede dataene er veldefinerte, og det utvikles med et forutsigbart tempo. Lite av dataene gjentas, og spørringsprosessen reduserer mengden behandlingsressurser som kreves.
La oss se hvordan datavitenskap er forskjellig.
I den andre enden har datavitenskap et annet sett behov. Datavitenskapere trenger bevegelsesfrihet med data og fleksibilitet for å kunne endre data raskt. De må kunne flytte data på ikke-standardiserte måter og behandle store mengder av gangen.
Disse behovene er vanskelige å implementere ved hjelp av svært strukturerte databaser. Datavitenskap krever en annen infrastruktur, basert i stedet på ustrukturerte data og tabellfrie skemaer.
Når vi henviser til ustrukturerte data, snakker vi om data uten egen definisjon. Det er nebulous til gitt form av en datavitenskapsmann. For de fleste utviklingen må hvert felt være av en definert type, for eksempel et heltall eller en streng. For datavitenskap handler det imidlertid om å støtte datapunkter som er dårlig definert.
Tabell-mindre skjemaer gir mer allsidighet til dette kvasi-kaotiske oppsettet, slik at all informasjonen kan leve på ett sted. Det er spesielt nyttig for datavitenskapere som regelmessig trenger å slå sammen data på kreative og ustrukturerte måter. Populære valg inkluderer NoSQL-varianter eller strukturer som tillater flere dimensjoner, for eksempel OLAP-kuber.
Som et resultat er maskinvaren som kreves for datavitenskap, ofte større. Det må holde hele dataene i bruk, samt delsett av dataene (selv om dette ofte spres ut mellom flere strukturer eller tjenester). Maskinvaren kan også kreve betydelige prosessressurser, da store mengder data blir flyttet og aggregert.
Med disse to settene av behov i tankene, kan vi nå se hvordan feilkommunikasjon kan oppstå. La oss ta disse perspektiver og bruke dem til å definere hvilke endringer vi leter etter og hvordan. Hvilke problemer må løses når databehandling blir en tradisjonell IT-innstilling?
I en tradisjonell IT-innstilling, følger en gitt virksomhets databaser sannsynligvis en stiv struktur, med tabeller delt for å passe til spesifikke behov, et passende skjema for å definere hvert stykke data og utenlandske nøkler for å knytte det sammen. Dette gir et effektivt system med spørringsdata. Den utforskende naturen til noen datavitenskapsmetoder kan presse dette til sine grenser.
Når en felles oppgave måtte trenge å bli med et dusin eller flere tabeller, blir fordelene ved tabellbaserte strukturer mindre synlige. En populær metode for å håndtere dette er å implementere en sekundær NoSQL eller flerdimensjonal database. Denne sekundære databasen bruker vanlige ETLer (Extract, Transform, Load) for å holde informasjonen frisk. Dette legger til kostnaden for ekstra maskinvare- eller skybruksbruk, men minimerer eventuelle andre ulemper.
Husk at i enkelte tilfeller kan legge til en egen database for datavitenskap være rimeligere enn å bruke den samme databasen (spesielt når kompliserte lisensspørsmål kommer inn i spill).
Dette spesifikke problemet dekker to nevnte feilaktigheter:
I tradisjonell IT er størrelsen på databasen veldefinert, enten i samme størrelse eller voksende i et beskjedent tempo. Når en database for datavitenskap brukes, kan denne veksten være eksponentiell. Det er vanlig å legge til gigabyte med data hver dag (eller mer). Med den store størrelsen på denne typen data må en bedrift innlemme en plan for å skalere intern arkitektur eller bruke en passende skyløsning.
Når det gjelder ustrukturert data, kan det ta mye ressurser når det gjelder lagring og prosessering, avhengig av dine spesifikke bruksområder. På grunn av dette er det ofte ineffektivt å beholde alt i en database som kan brukes til andre formål. Løsningen ligner på skalering generelt. Vi trenger enten en plan for å skalere vår interne arkitektur for å møte disse behovene, eller vi må finne en passende sky løsning.
Den siste store forskjellen vi snakker om, er bruken av ressurser. For IT er bruken av ressurser typisk effektiv, veldefinert og konsistent. Hvis en database driver et e-handelsnettsted, er det kjente begrensninger. En IT-profesjonell vil vite omtrent hvor mange brukere det vil være over en gitt tidsperiode, slik at de kan planlegge maskinvareforsyningen basert på hvor mye informasjon som trengs for hver bruker.
Med tradisjonell IT-infrastruktur vil det ikke oppstå noen problemer hvis et prosjekt bruker bare noen få hundre rader fra en håndfull bord. Men et prosjekt som krever hver rad fra to dusin bord kan raskt bli et problem. I datavitenskap endres behovene med hensyn til behandling og lagring fra prosjekt til prosjekt, og det kan være vanskelig å støtte den typen uforutsigbarhet..
I tradisjonell IT kan ressursene deles med andre parter, som kan være et liveproduksjonssted eller et internt dev team. Risikoen her er at å kjøre et storskala datavitenskaps prosjekt kan potensielt låse de andre brukerne ut over en periode. En annen risiko er at serverne som har en database, kanskje ikke klarer å håndtere den store mengden behandling som er nødvendig. Kaller 200 000 rader fra 15 bord, og ber om datagruppering på toppen, blir et problem. Denne størrelsen på spørringer kan være ekstremt beskatning på en server som vanligvis kan håndtere tusen eller så samtidige brukere.
Den ideelle løsningen kommer ned til skybehandling. Dette tar opp to viktige faktorer. Den første er at den lar forespørselsresultater vekkes fra viktige databaser. Den andre er at den gir skaleringsressurser som passer til hvert prosjekt.
Nå som vi har snakket om behovene i dybden, la oss oppsummere dem. En IT- og datavitenskapsavdeling vil trenge følgende for langsiktig suksess:
La oss bryte alt ned i spesifikasjoner, slik at vi kan sette sammen en gjensidig fordelaktig løsning. Nå tar vi en titt på hvordan du definerer de spesifikke ressursene som trengs for en organisasjon:
Fra IT-siden er det tre hoveddefinisjoner som trengs for å skape den nødvendige infrastrukturen. Disse er:
Slik kan du bestemme hver enkelt.
Alt starter med den opprinnelige datastørrelsen som trengs, og de estimerte løpende datatillatelsene.
For de første databehovene, ta den definerte størrelsen på din nåværende database. Trekk nå noen kolonner eller tabeller som du ikke trenger i datavitenskapsprosjektene dine. Ta dette nummeret og legg til i datastørrelsen til eventuelle nye kilder du vil introdusere. Nye kilder kan inkludere Google Analytics-data eller -informasjon fra ditt salgssted. Denne summen vil være datalagring vi vil se for å oppnå forhånd.
Selv om de opprinnelige lagringsbehovene er nyttige på forhånd, må du fortsatt vurdere de løpende datafunksjonene, da du sannsynligvis vil legge til mer informasjon i databasen over tid. For å finne denne informasjonen, kan du beregne dine daglige lagt data fra dine tilgjengelige data. Ta en titt på mengden informasjon som er lagt til i databasen din i løpet av de siste 30 dagene, og del deretter den med 30. Gjenta deretter for hver informasjonskilde du vil bruke, og legg dem sammen.
Selv om dette ikke er presist, er det et gammelt utviklingsmantra som du bør fordoble ditt estimat, og vi skal bruke det her. Hvorfor? Vi ønsker å redegjøre for uforutsigbare endringer som kan påvirke behovet for datalagring, for eksempel bedriftens vekst, behov per prosjekt eller bare generelle områder.
Med det nummeret som nå er definert, multipliserer det med 365. Dette er nå din forventede datavekst i ett år, som når det legges til ditt opprinnelige beløp, vil bestemme hvor mye lagringsplass du bør se på å skaffe.
I motsetning til datalagringsbehov er behandlingen behov mye vanskeligere å beregne nøyaktig. Hovedmålet her er å avgjøre om du vil sette tung løft på spørsmål eller på en lokal maskin (eller sky-instans). Husk her at når jeg snakker om en lokal maskin, betyr jeg ikke bare den datamaskinen du vanligvis bruker - du trenger sannsynligvis en slags optimalisert arbeidsstasjon for de mer intensive beregningene.
For å gjøre dette valget, hjelper det å tenke på det største datavitenskapsprosjektet som du kan kjøre innen neste år. Kan din dataløsning håndtere en forespørsel av den størrelsen uten å bli utilgjengelig for alle andre interessenter? Hvis det kan, så er det godt å gå uten ekstra ressurser som trengs. Hvis ikke, må du planlegge på å få en riktig størrelse arbeidsstasjon eller skaleringsblokker.
Etter at du har bestemt deg for hvor du skal lagre og behandle dataene, er neste avgjørelse hvordan. Opprette en ETL-prosess vil holde databehandlingsdatabasen ordentlig og oppdatert, og forhindre at den bruker unødvendige ressurser fra andre steder.
Her er hva du bør ha i ETL-dokumentasjonen din:
Med alle datapunkter i hånden er det på tide å velge ut en løsning. Denne delen vil ta litt forskning og vil stole tungt på dine spesifikke behov, som på overflaten har de en tendens til å ha mange likheter.
Tre av de største skyløsninger-Amazon Web Services (AWS), Google Cloud Platform (GCP) og Microsoft Azure-tilbyr noen av de beste prisene og funksjonene. Alle tre har relativt liknende kostnader, selv om AWS er spesielt vanskeligere å beregne kostnader for (på grunn av sin a la carte prisstruktur).
Utover pris, hver tilbyr skalerbar datalagring og muligheten til å legge til behandlingsinstanser, men alle kaller sine "forekomster" med et annet navn. Når du undersøker hvilke som skal brukes til din egen infrastruktur, tar du hensyn til hvilke typer prosjekter du vil utnytte mest, da det kan skifte verdien av hver enkelt pris og funksjonssett.
Men mange selskaper velger ganske enkelt hvilken som helst linje med deres eksisterende teknologi stabel.
Du vil kanskje også sette opp din egen infrastruktur internt, selv om dette er betydelig mer komplisert og ikke for svak av hjertet.
Med alle dine ender på rad, kan du starte implementeringen! For å hjelpe deg, er det noen hardt opptjente tips for å gjøre prosjektet enklere - fra tone til utførelse.
Når du først legger sammen ETL-prosessen, må du ikke teste hele greia på en gang! Dette kan føre til alvorlig belastning på ressursene dine og øke skyens kostnader drastisk dersom det er en feil, eller hvis du må forsøke prosessen flere ganger.
I stedet er det en god ide å kjøre prosessen ved å bruke bare de første 100 rader eller så av opprinnelsestabellene dine først. Kjør så full overføring når du vet at det vil fungere.
Det samme gjelder for alle store spørringer du kjører på en sky-instans. Å gjøre en feil som trekker i millioner av data er mye vanskeligere på et system enn en som bare trekker i noen få - spesielt når du betaler per GB.
De fleste sky-operatører tilbyr dette som en funksjon, så du trenger ikke å bekymre deg for det. Teamet ditt bør fortsatt diskutere om de ønsker å lage sine egne vanlige sikkerhetskopier av dataene, selv om det kan være mer effektivt å rekonstruere dataene hvis behovet oppstår.
Når du flytter kundedata til skyen, må du sørge for at alle involverte er oppmerksomme på selskapets retningslinjer for dataadministrasjon for å unngå problemer på veien. Dette kan også hjelpe deg med å spare penger på mengden data som lagres i skyen.
Når du utfører ETL fra en tabellbasert database til en ustrukturert, vær forsiktig med navngivningsprosedyrer. Hvis navnene bare er grossistoverført over, vil du sannsynligvis ha mange felt fra forskjellige tabeller som deler samme navn. En enkel måte å overvinne dette på, er å navngi de nye dimensjonene i den ustrukturerte databasen som Oldtablename _ Kolonne og deretter omdøpe dem derfra.
Nå kan du planlegge grunnleggende om analyse- og datavitenskapsinfrastrukturen. Med mange av de viktigste spørsmålene og svarene som er definert, bør prosessen med implementering og innkjøp av lederinnkjøp gå mye mer jevnt.
Har du problemer med å få svar på ditt eget firma? Gledte jeg over noe viktig? Gi meg beskjed i kommentarene!
Accentsconagua