Memra

Big Data: the Vs, Schema-on-Read & the Hadoop Ecosystem

Define big data by the three (plus two) Vs, contrast schema-on-read with schema-on-write, and name what each piece of the Hadoop ecosystem does — the foundation the rest of the chapter builds on.

What makes data "big"

Big data is a moving target: at any moment it means amounts, types, or speeds of data that *challenge the current state-of-the-art technology*. The standard memory frame is the three Vs:

- Volume — the sheer quantity (terabytes, petabytes, and beyond). - Variety — the mix of structured (tables), semi-structured (JSON, XML, logs), and unstructured (text, images, video, sensor streams) data. - Velocity — the speed at which data arrive and must be processed (batch vs. real-time streaming).

Two more Vs are often added: veracity (how trustworthy/clean the data are) and value (the business outcome that justifies storing it at all). The driver behind the explosion is the Internet of Things (IoT) — billions of connected devices, from fitness bands to jet engines, each generating data streams that a single relational server cannot ingest economically.

Schema-on-write vs. schema-on-read

The relational world is schema-on-write: data *must* fit a predefined table structure (columns, types, constraints) *before* it can be stored. The structure is enforced at write time, which guarantees quality but demands you know the schema up front and makes change expensive.

Big-data systems flip this to schema-on-read: store the raw data in its native form *now*, and decide how to interpret it *only when you read it* for a particular analysis. This is exactly what a data lake does — a large repository of raw internal and external data kept in native format until needed. Schema-on-read is powerful for *exploratory* analytics where the questions aren't known yet, at the cost of pushing the interpretation burden onto every consumer of the data.

Worked example: counting word frequencies with MapReduce

MapReduce is the algorithm that made petabyte-scale processing practical. Its insight: *move the computation to the data*, not the data to the computation. It has two phases:

MAP    each node runs the same function on its LOCAL block, emitting (key, value) pairs
SHUFFLE  pairs with the same key are grouped and routed to the same reducer
REDUCE each reducer combines all values for one key into a final result

To count how often each word appears across a huge corpus:

Map:    "the cat sat"  ->  (the,1) (cat,1) (sat,1)
        "the dog ran"  ->  (the,1) (dog,1) (ran,1)
Reduce: the -> 2,  cat -> 1,  sat -> 1,  dog -> 1,  ran -> 1

Only the small *(key, value)* intermediates cross the network; the bulky raw text never moves. Hadoop is the open-source framework that implements MapReduce, and its ecosystem layers cleanly:

- HDFS — the distributed file system: splits files into blocks, scatters them across nodes, keeps three copies of each block by default for fault tolerance. (Append-only; no in-place update; no indexing.) - YARN — the resource manager (the cluster's "OS scheduler"): decides which jobs run where. - MapReduce — the parallel processing engine (the "CPU"). - Pig — a *procedural* scripting tool (PigLatin) for data preparation / ETL — the "data factory." - Hive — a *declarative*, SQL-like tool (HiveQL) that compiles to MapReduce jobs — the "data warehouse" presentation layer for analysts who know SQL.

Hadoop is built for large-scale batch analytics — it is *not* for transaction processing or real-time single-record lookups. For moderate, well-indexed data, a relational database still wins.

NORMAL ~/memra/learn/comp-378/big-data-vs-schema-on-read-hadoop utf-8 LF