Din guide om hur du hanterar Big Data

big-data

Termen "Big Data” har blivit ett modeord, och det har hyllats som lösningen på många problem och framtidens affärsverksamhet. Men vad är det? Många människor blandar ihop Big Data med stora datamängder; denna förvirring verkar vanlig bland icke-tekniska personer. Big Data är något djupare. Det är inte bara en enorm mängd data. Det är användningen av dessa data för att skapa affärsvärde.

Tänk på big data som olika typer av "material" – om du är arkitekt kan du ha olika typer av material, som trä, stål eller betong. Dessa material kan du använda i dina projekt för att bygga något som uppfyller dina behov av funktion och form. Till exempel, om du försöker göra ett skydd snabbt och kostnadseffektivt, kan du använda stål eftersom det är billigt och lättillgängligt. Materialvalet beror på målet.

Hur fungerar big data?

Vi kan använda små datamängder för att veta vad som hänt under de senaste 10 åren (den typ av information som går in i en historiebok). Men om vi vill förutsäga vad som kommer att hända under de kommande 10 åren eller köra simuleringar om hur världen kunde ha varit annorlunda givet olika val under den tiden, behöver du Big Data.

Tyvärr är det inte lätt att ge en exakt definition av Big Data – i takt med att data blir mer komplex och dess användning utvecklas, så gör vår förståelse av Big Data. Det bästa sättet att tänka på det är om ditt projekt kräver 100 TB lagringskapacitet eller snabbare än 1 minuts frågetider på 100 PB data. Du skulle förmodligen kalla det big data (det finns ingen officiell line-in-the-sand; om du vet det när du ser det är det bra nog).

Big Data är inte heller användbart i sig. Det måste användas för att lösa ett problem – det råkar vara så att många problem löses bäst med Big Data. Till exempel Google Flu Trends (Google Trender) använder stordata för att förutsäga antalet influensafall i varje delstat baserat på antalet personer som söker efter vissa influensarelaterade sökord. US National Security Agency använder stordataanalys för att identifiera människohandelsnätverk över hela världen genom att skanna biljoner telefonsamtal och e-postmeddelanden för nyckelord eller fraser som kan indikera ett överhängande hot.

Summa summarum: Big Data låter oss göra saker som vi inte kunde tidigare eftersom vi inte skulle ha haft den lagringskapacitet eller bearbetningshastighet som behövs. Grundläggande exempel kan vara att utveckla bättre väderprognoser eller filmrekommendationer.

Hur man hanterar Big Data

Innan vi går in på de tekniska aspekterna av att lagra och söka efter big data (och det finns mycket att täcka), är det viktigt att diskutera datalager och dess utveckling. Som vi nämnde tidigare tar många organisationer "Big Data" som ett paraplybegrepp för stora mängder data; detta är inte helt korrekt. Data warehousing och Business Intelligence (BI)-verktyg gör det möjligt för hela organisationer – inte bara datavetare – att använda sina data genom att extrahera insikter från dessa enorma datamängder och presentera dem i lättförståeliga format som grafer, diagram, tabeller, etc. lättare är det för icke-tekniska anställda att förstå hur man förstår data, desto mer sannolikt är det att de använder den.

Hitta all din data

Det första steget i Big Data är att hitta all din data (den kan vara spridd över flera databaser, den kan också bara finnas på papper). Även om detta låter enkelt, är det ganska knepigt - speciellt om du har att göra med terabyte eller petabyte av information. Organisationer gör detta genom en process som kallas ETL (extract-transform-load), som innebär att man tar stora bitar av rådata och omvandlar dem till strukturerade tabeller för enklare sökningar med BI-verktyg. Denna process kan vara mycket resurskrävande eftersom många typer av hårdvara krävs: iscensättningsservrar, lastbalanserare, anslutningspooler. Det finns andra sätt att extrahera data från källor som platta filer, tredjepartsdatabaser, etc., men detta är det enklaste att implementera och det vanligaste.

När all din data har konsoliderats på en central plats där BI-verktyg kan komma åt dem, är nästa steg att bygga ett datalager som kommer att inrymma dina tillgångar för enkel sökning. Förutom att snabbt få tillgång till relevant information när det behövs, skapar du ett datalager som möjliggör samarbete mellan teammedlemmar i deras analys av dessa datauppsättningar enligt experter på RemoteDBA.com.

Skillnaden mellan en datalagringsserver och ett datalager är att det senare har inbyggda verktyg som gör att datavetare kan fråga och ladda upp sina datauppsättningar för analys. Däremot kommer en lagringsserver att göra det möjligt för dem att bara komma åt (och kanske iscensätta) en del av datan. Till exempel är Google Cloud Storage en lagringsserver medan BigQuery är en del av Googles molnlagerprodukt.

Äntligen är det dags att börja sätta igång och börja fråga efter denna stora hög med data. Men eftersom det finns flera sätt att göra detta – och alla har sina fördelar och nackdelar – är det viktigt att förstå de olika tillvägagångssätten innan du börjar.

Datalagringslösningar

Det mest grundläggande frågeverktyget som kommer med Big Data-lagringslösningar är SQL, eller Structured Query Language, som låter användare skapa satser som gör det möjligt för dem att hämta information från databaser som är byggda ovanpå dessa plattformar |LS|10|RS|. Detta tillvägagångssätt kan vara konstruktivt om du redan är bekant med SQL eftersom det tillåter dig att göra saker som JOINs, GROUP BYs, etc. Det finns dock vissa nackdelar med denna metod eftersom inte alla vet hur man läser eller skriver SQL-frågor,

Den uppenbara fördelen med att använda dessa verktyg är att de tillåter icke-tekniska anställda att enkelt "ställa frågor" om data. Det finns dock flera nackdelar med detta tillvägagångssätt:               

Dessa verktyg kan vara mycket resurskrävande eftersom de måste konvertera dina frågor till SQL innan de körs mot servern. Du måste skapa ett separat schema eller lagra varje ny datauppsättning för att ladda upp för många databaser. Om användare inte är bekanta med komplexiteten bakom relationsdatabaser och scheman, kan detta leda till några betydande irritationsmoment under analysen, till exempel att av misstag ladda upp olika datamängder under fel schema och inte veta hur man gör.

Till toppen