Similarities:
Despite their underlying architectural differences, Hive intentionally mimics many aspects of RDBMS to provide a familiar experience for data analysts and developers:
Tabular view of data objects: Both Hive and RDBMS present data in a structured, tabular format, organized into rows and columns. This abstraction is fundamental to how users interact with the data.
Directories and files viewed as tables: In Hive, the distributed files and directories in HDFS are logically mapped onto tables. Users query these "tables" as if they were conventional database tables, abstracting away the complexities of distributed file storage.
Types of columns in tables: Both systems enforce data types for columns (e.g., INT, STRING, BOOLEAN, FLOAT, DOUBLE, TIMESTAMP, etc.), ensuring data integrity at a schema level.
ccess to tables through HQL very similar to SQL: HQL's syntax is heavily inspired by SQL-92, making it easy for users with SQL experience to adapt to Hive. Commands like SELECT, FROM, WHERE, GROUP BY, JOIN, CREATE TABLE, INSERT INTO, and ALTER TABLE are largely consistent.
API interface the same as JDBC programming interface: Hive provides a JDBC (Java Database Connectivity) driver, allowing applications to connect and interact with Hive using standard JDBC APIs. This enables broad integration with existing tools and programming paradigms. Many BI tools and ETL platforms use this JDBC interface to connect to Hive, just as they would to an RDBMS.
Differences:
The core architectural differences between Hive and RDBMS stem from their primary design goals and the environments they operate in:
Load and read-only data management system based on implementation of HDFS:
Hive: Primarily designed for batch processing and analytical queries on large volumes of historical data. It's optimized for high-throughput reads and appends, often performing full table scans. Data loading typically involves adding new files to HDFS directories that correspond to tables. While modern Hive with ACID transactions supports updates and deletes, its fundamental design still leans towards append-only and bulk operations on immutable data.
RDBMS: Designed for online transaction processing (OLTP), handling frequent, small, and fast read/write/update operations. They are optimized for transactional integrity and quick lookup of individual records.
Hive: Historically, UPDATE operations were not supported or were implemented as a "coarse-grained transformation." This meant that an UPDATE on a few rows might effectively involve re-writing entire partitions or even the entire table. With the introduction of ACID transactions (via ORC files and the transactional property), Hive now offers more "fine-grained" updates and deletes, but it's still distinct from how RDBMS handle them. The underlying mechanism often involves writing new delta files and compaction processes.
RDBMS: UPDATE operations are inherently "fine-grained." Changes are applied directly to specific rows or blocks on disk with atomicity and isolation, making them efficient for single-record modifications.
No transaction processing system:
Hive: Historically, Hive lacked a traditional ACID (Atomicity, Consistency, Isolation, Durability) transaction processing system. Operations were not atomic across multiple statements, and concurrent writes could lead to inconsistencies. This was acceptable for its primary analytical workload where eventual consistency was often sufficient.
RDBMS: ACID compliance is a cornerstone of RDBMS design. Transactions ensure that database operations are reliable, even in the event of errors or concurrent access, critical for applications requiring high data integrity (e.g., banking systems).
