Den måde, store data bliver store på, er gennem en konstant strøm af indgående data. I miljøer med stort volumen ankommer disse data med utrolige hastigheder, men de skal stadig analyseres og lagres.
John Hugg, softwarearkitekt hos VoltDB, foreslår, at vi i stedet for blot at gemme de data, der skal analyseres senere, måske er nået til det punkt, hvor de kan analyseres, da de indtages, mens vi stadig opretholder ekstremt høje indtagssatser ved hjælp af værktøjer som Apache Kafka.
- Paul Venezia
For mindre end et dusin år siden var det næsten umuligt at forestille sig at analysere petabytes af historiske data ved hjælp af råvarehardware. I dag er Hadoop-klynger bygget fra tusinder af noder næsten almindelige. Open source-teknologier som Hadoop gentænkte, hvordan man effektivt behandler petabytes på petabytes data ved hjælp af råvare og virtualiseret hardware, hvilket gør denne mulighed tilgængelig for udviklere overalt. Som et resultat opstod feltet med big data.
En lignende revolution sker med såkaldte hurtige data. Lad os først definere hurtige data. Big data oprettes ofte af data, der genereres med utrolige hastigheder, såsom klik-stream-data, økonomiske ticker-data, logaggregation eller sensordata. Ofte forekommer disse begivenheder tusinder til titusinder af gange i sekundet. Ikke underligt, at denne type data almindeligvis kaldes en "brandslange."
Når vi taler om brandslanger i store data, måler vi ikke volumen i de typiske gigabyte, terabyte og petabyte, som datalagre kender. Vi måler volumen udtrykt i tid: antallet af megabyte pr. Sekund, gigabyte pr. Time eller terabyte pr. Dag. Vi taler om hastighed såvel som volumen, som bliver kernen i forskellen mellem big data og datalageret. Store data er ikke bare store; det er også hurtigt.
Fordelene ved big data går tabt, hvis friske, hurtige data fra brandslangen dumpes i HDFS, en analytisk RDBMS eller endda flade filer, fordi evnen til at handle eller advare lige nu, mens tingene sker, er tabt. Brandslangen repræsenterer aktive data, øjeblikkelig status eller data med løbende formål. Datalageret er derimod en måde at se gennem historiske data på for at forstå fortiden og forudsige fremtiden.
At handle på data, når det ankommer, er blevet betragtet som dyrt og upraktisk, hvis ikke umuligt, især på råvarehardware. Ligesom værdien i big data låses værdien i hurtige data op med den genoptænkte implementering af meddelelseskøer og streaming-systemer som open source Kafka og Storm, og den reimagined implementering af databaser med introduktionen af open source NoSQL og NewSQL-tilbud .
Optagelse af værdi i hurtige data For at behandle data, der ankommer til titusinder til millioner af begivenheder i sekundet, har du brug for to teknologier: For det første et streaming-system, der er i stand til at levere begivenheder så hurtigt som de kommer ind; og for det andet et datalager, der er i stand til at behandle hver vare så hurtigt som den ankommer. Levering af hurtige data Kafka blev designet til at være en meddelelseskø og til at løse de opfattede problemer med eksisterende teknologier. Det er en slags über-kø med ubegrænset skalerbarhed, distribueret implementering, multitenancy og stærk vedholdenhed. En organisation kunne implementere en Kafka-klynge for at tilfredsstille alle sine behov for meddelelseskø. Stadig i sin kerne leverer Kafka beskeder. Det understøtter ikke behandling eller forespørgsel af nogen art.
