EuraStudy
Notes/Computer Science/Big Data
Notes · Computer ScienceUK · A-Levels

Big Data

Big data is data too large, too fast or too varied for traditional tools and techniques to store and process, and this chapter explains its characteristics and how it is tackled. It covers the defining three Vs - volume, velocity and variety - the fact-based and graph-based models used to represent it, and the distributed processing that handles it, including why the functional programming paradigm is so well suited to running computations in parallel across a cluster.

3 sections·~11 min reading time·3 competencies·Level Standard 1 · Advanced 2

T·101010 / 14
Exam profile
AO1 · Know the characteristics of big data, the fact-based and graph models, and distributed processingAO2 · Explain why functional programming and distributed processing suit big data, and apply the MapReduce patternAO3 · Evaluate the challenges of storing, processing and drawing conclusions from big data
Operators:explaindescribejustifycompareevaluate

basic level

AS-Level students meet big data mainly as context; the full detail is A-Level.

higher level

The full A-Level expects the characteristics of big data, fact-based and graph models, and the link between functional programming, immutability and distributed/parallel processing.

Depth

Reading depth: In depth

Text

Text size: Standard

Contents · 3 sections▾
  1. Big Data
    • 01What is big data? The three Vs◐
    • 02Representing big data: fact-based and graph models●
    • 03Processing big data: distributed processing and functional programming●
§ 01

What is big data? The three Vs#

●●○StandardLPAQA 7517 4.11.1LPDfE GCE Computer Science - big data

The characteristics of big data

The Vs of big dataGraph, Big data → Volume (quantity), Big data → Velocity (speed), Big data → Variety (forms), Big data → Veracity (trust)Big dataVolume(quantity)Velocity(speed)Variety(forms)Veracity(trust)
Fig. 1Big data is defined by volume (the quantity), velocity (the speed of arrival) and variety (the range of forms), with veracity (trustworthiness) a common fourth. It is the combination of these, not volume alone, that defeats traditional single-machine, fixed-schema tools.

Key points

Big data is data whose scale or nature makes it impractical for conventional database tools and single machines to store, process and analyse. It is characterised by the three Vs (shown opposite). Volume is the sheer quantity - petabytes and beyond, from sensors, transactions, social media and scientific instruments - too much for one machine's storage or memory. Velocity is the speed at which it arrives and must be processed, often as a continuous real-time stream (financial ticks, sensor feeds) rather than a static batch. Variety is the range of forms it takes - not just neat tables but text, images, audio, video and logs. A fourth V, veracity, captures how trustworthy and clean the data is.
These characteristics are exactly what traditional relational databases struggle with. Relational databases assume structured data in a fixed schema that fits (or is sharded across a few) servers, and they favour consistency over raw scale. Big data breaks all three assumptions: it is often unstructured or semi-structured, too large for one server, and arrives too fast for the careful, transactional guarantees a relational database provides. So new storage and processing approaches are needed.
Data is usefully classified by how structured it is. Structured data fits a predefined schema of rows and columns (a sales table). Unstructured data has no such model (free text, images, video), which is the bulk of big data and the hardest to analyse. Semi-structured data carries some organising tags or markers without a rigid schema (JSON, XML, log files). Recognising the mix of structure in a data source is part of understanding why it needs big-data techniques.
The value of big data is the insight extracted from it - spotting trends, predicting behaviour, personalising services, advancing science - but the challenges are real: storing it economically, processing it fast enough, cleaning noisy or biased data (veracity), and protecting the privacy of the individuals it describes (linking back to the consequences chapter). A balanced answer recognises both the opportunity and the difficulty, rather than treating 'more data' as automatically better.
Worked example

Identifying the big-data challenges in a scenario

A wind-farm operator collects readings from thousands of turbine sensors many times a second, mixing numeric telemetry, maintenance text logs and photographs. Explain which Vs are challenging.

  1. 01Volume

    Thousands of sensors sampled frequently produce an enormous, ever-growing quantity of readings - too much for a single server to hold or scan efficiently.

  2. 02Velocity

    Readings arrive continuously and many times a second, so they must be ingested and processed as a real-time stream, not a nightly batch.

  3. 03Variety

    Numeric telemetry, free-text logs and images together do not fit one relational schema - a mix of structured, semi-structured and unstructured data.

Result: All three Vs are present: the volume, velocity and variety together make this a big-data problem requiring distributed storage and processing rather than a single relational database.

Exam focus

  • State and explain the three Vs (volume, velocity, variety) and why traditional relational databases struggle with big data.
  • Distinguish structured, semi-structured and unstructured data with examples.

Typical mistakes

  • Thinking big data just means 'a lot of data' - velocity and variety matter as much as volume, and it is the combination that defeats traditional tools.
  • Assuming big data is always stored in a relational database - its scale, speed and lack of structure are precisely why relational tools are unsuitable.

Active revision

A retailer wants to analyse in real time the clicks, searches, social-media mentions and purchases of millions of customers. Explain, using the three Vs, why this is a big-data problem and why a single relational database would struggle.

Active recall

Recall the key points — then reveal.

Sources: GCE AS and A level subject content for computer science (Department for Education) · AQA A-level Computer Science 7517 specification (AQA)

§ 02

Representing big data: fact-based and graph models#

●●●AdvancedLPAQA 7517 4.11.2LPDfE GCE Computer Science - big data models

A graph-based data model

Graph modelGraph, Person: Alice → Person: Bob, Person: Alice → Post, Post → Topic: AI, Person: Bob → Topic: AIPerson: AlicePerson: BobPostTopic: AIFRIENDAUTHOREDTAGGEDFOLLOWS
Fig. 2Entities are nodes and relationships are labelled edges. Answering 'friends of friends' or 'shortest connection between two people' is a direct traversal of the graph, avoiding the many expensive joins the same query would need in a relational database.

Key points

Because big data does not fit the fixed tables of the relational model, other representations are used. The fact-based model stores data as a large collection of immutable, atomic facts - each fact is a small, timeless, indivisible piece of information that, once recorded, is never changed or deleted but only ever added to. A fact such as 'user 42 viewed product 7 at time t' is stored as-is; corrections are made by adding new facts, not overwriting old ones. This append-only, immutable design is ideal for big data: it is simple to distribute (no updates to coordinate), gives a complete historical record, and suits the write-heavy, streaming nature of big data.
The immutability of facts is the key idea and links directly to functional programming. Because facts are never modified, there is no risk of a distributed update being lost or of two machines disagreeing about a value, and the same computation can be re-run over the fact store to reproduce any result - the data is a single, growing source of truth. The trade-off is storage: keeping every fact forever uses more space than overwriting, but storage is cheap and the benefits for distribution and auditability outweigh it.
The graph-based model (graph schema) represents data as nodes (entities) connected by edges (relationships), with properties on both (shown opposite). It is the natural fit whenever the relationships between things are as important as the things themselves - social networks (people connected by friendships), recommendation systems, fraud detection, and knowledge graphs. Queries that would need many expensive joins in a relational database - 'friends of friends who like this', 'the shortest chain of connections between two people' - are direct traversals of the graph, which is why graph databases power social and recommendation features at scale.
Choosing a representation depends on the data and the questions. A fact-based store suits high-volume, high-velocity event data where a complete, immutable history matters; a graph model suits densely interconnected data where relationships drive the queries; and structured, relational data may still suit a distributed relational or column store. The unifying theme is that big data trades the relational model's strict schema and update-in-place for models that scale out across many machines and match the data's real shape.
Worked example

Choosing a model for connected data

A fraud team needs to find rings of accounts that transfer money to one another in circles. Explain why a graph model suits this better than relational tables.

  1. 01The data is relationships

    What matters is the pattern of transfers between accounts - the edges - not just the accounts themselves.

  2. 02Relational cost

    Finding a circular chain of transfers in relational tables needs the transactions table joined to itself repeatedly, once per hop - expensive and awkward for chains of unknown length.

  3. 03Graph advantage

    In a graph model each account is a node and each transfer an edge; a circular ring is a cycle, found directly by traversing edges without repeated joins.

Result: A graph-based model represents the transfers as traversable edges, so detecting cycles (fraud rings) is a natural graph traversal - far more efficient than the many self-joins a relational database would require.

Exam focus

  • Explain the fact-based model, its immutability and why an append-only design suits big data.
  • Describe the graph-based model (nodes, edges, properties) and give a scenario where it beats a relational database.

Typical mistakes

  • Thinking facts in a fact-based model are updated or deleted - they are immutable and append-only; corrections are new facts.
  • Confusing the graph-based data model with a chart or diagram - it is a store of nodes and relationships, suited to interconnected data.

Active revision

Explain why a social network that must answer 'who are the friends-of-friends of this user?' would use a graph-based model rather than a relational database, and explain how the immutability of a fact-based model helps when data is spread across many machines.

Active recall

Recall the key points — then reveal.

Sources: AQA A-level Computer Science 7517 specification (AQA)

§ 03

Processing big data: distributed processing and functional programming#

●●●AdvancedLPAQA 7517 4.11.3LPDfE GCE Computer Science - distributed processing

The MapReduce data flow

MapReduceGraph, Input (split across cluster) → Map: emit (key, value) pairs, Map: emit (key, value) pairs → Shuffle and sort: group by key, Shuffle and sort: group by key → Reduce: combine values per key, Reduce: combine values per key → OutputInput (splitacross cluster)Map: emit (key,value) pairsShuffle andsort: group bykeyReduce: combinevalues per keyOutput
Fig. 3The input is split across the cluster. The map phase applies the same function to each split independently, emitting key-value pairs; a shuffle groups all pairs by key; the reduce phase combines the values for each key into the final output. Map and reduce run in parallel across many machines.

Key points

No single machine can process big data in reasonable time, so it is handled by distributed processing: the data and the computation are split across a cluster of many machines that work on different parts in parallel, and the partial results are combined. This lets processing scale by adding more machines (horizontal scaling), and it provides fault tolerance - if one machine fails, its share can be re-run elsewhere. The challenge is coordinating the machines so the parallel work is correct and efficient.
Functional programming is exceptionally well suited to distributed processing, and this is the key link the specification draws. Pure functional code has no side effects and works on immutable data, so a function's result depends only on its inputs - it never changes shared state. This matters enormously across a cluster: because functions do not depend on or alter shared mutable data, the same function can be run on many machines over different data partitions simultaneously with no risk of interference, no locks, and no lost updates. Immutability and referential transparency make parallelism safe almost for free, whereas imperative code sharing mutable state needs careful, error-prone synchronisation.
The classic pattern realising this is MapReduce (shown opposite). In the map phase the same function is applied independently to each piece of the split data, producing intermediate key-value pairs - this is embarrassingly parallel, one machine per split. The results are then shuffled and sorted so that all pairs with the same key are grouped together. In the reduce phase a function combines all the values for each key into a final result. Counting the words across billions of documents, for example, maps each word to (word, 1) and reduces by summing the 1s per word - and the map and reduce steps run in parallel across the cluster.
The context for much of this processing is analytics and machine learning: distributed processing over big data trains models that recognise patterns, make predictions and drive recommendations, personalisation and scientific discovery. But the same caveats from the consequences chapter apply - the conclusions are only as good as the data's veracity, and models can encode bias. The examinable core is the reasoning: big data needs distributed processing; distributed processing needs safe parallelism; functional programming's immutability and lack of side effects provide exactly that, which is why the two topics are studied together.
Worked example

Counting words with MapReduce

Show how MapReduce would count word occurrences in the two short documents 'the cat sat' and 'the cat ran', explaining each phase.

  1. 01Map (in parallel)

    Each document is processed independently, emitting (word, 1) for each word. Doc 1: (the,1)(cat,1)(sat,1); Doc 2: (the,1)(cat,1)(ran,1).

  2. 02Shuffle and sort

    Pairs are grouped by key: the -> [1, 1]; cat -> [1, 1]; sat -> [1]; ran -> [1].

  3. 03Reduce (in parallel)

    For each key, sum the values: the -> 2, cat -> 2, sat -> 1, ran -> 1.

Result: The counts are the: 2, cat: 2, sat: 1, ran: 1. Because map runs independently per document and reduce independently per key, both phases parallelise across the cluster - the essence of processing big data.

Exam focus

  • Explain why functional programming (immutability, no side effects, referential transparency) is well suited to distributed, parallel processing.
  • Describe the MapReduce pattern (map produces key-value pairs, shuffle groups by key, reduce combines) and apply it to an example.

Typical mistakes

  • Not connecting functional programming to distribution - the reason it suits big data is that immutable, side-effect-free functions parallelise safely without locks.
  • Muddling the MapReduce phases: map produces key-value pairs independently; reduce combines the grouped values per key.

Active revision

Explain, with reference to side effects and immutability, why functional programming makes distributed processing safer than imperative code. Then describe how MapReduce would count how many times each word appears across a huge collection of documents.

Active recall

Recall the key points — then reveal.

Sources: AQA A-level Computer Science 7517 specification (AQA)

Contents

Section -- / 03

    • 01What is big data? The three Vs◐
    • 02Representing big data: fact-based and graph models●
    • 03Processing big data: distributed processing and functional programming●

0/3 Read

From notes into training

Big Data

Reinforce this topic with matching tasks from the question bank.

~11
min
3
Competencies
Practise

References & sources

Sources

Department for Education

  • GCE AS and A level subject content for computer science

AQA

  • AQA A-level Computer Science 7517 specification

Previous topic

Fundamentals of databases

Next topic

Fundamentals of functional programming

EuraStudy·Notes T·10·MMXXVI

Carry on to the next topic — your learning path is kept.