Why it matters
Hive democratized big data. Before it, working with HDFS meant writing MapReduce in Java. After Hive, any analyst who knew SQL could query terabytes. That shift is what turned Hadoop from a research project into an enterprise platform.
Even today, when Spark SQL is faster and Presto is more interactive, Hive stays in production for batch ETL, historical data, and the huge ecosystem of tables and views built over years.
The architecture
Hive has four main components. The metastore holds table schemas, partition information, and location pointers. The driver parses SQL and coordinates execution. The compiler turns SQL into a logical plan and then a physical plan targeting an execution engine. The execution engine (MR, Tez, or Spark) actually runs the work.
Data lives in HDFS as files (Parquet, ORC, text, sequence). Hive tables are metadata that describes how to interpret those files as rows and columns.
How it works end to end
A query starts at the driver, which parses SQL and asks the metastore for schema and partition info. The compiler builds a logical plan, applies the cost-based optimizer, and produces a physical plan. The execution engine runs the plan as jobs — MapReduce tasks classically, Tez DAG in modern deployments, or Spark stages when Hive-on-Spark is enabled.
Results are either returned to the client (small queries) or written to HDFS (large queries). Sessions can maintain state via HiveServer2, which is the thin server that accepts JDBC/ODBC connections.