DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Data Engineering
  3. Big Data
  4. Handling Big Data with HBase Part 3: Architecture Overview

Handling Big Data with HBase Part 3: Architecture Overview

Scott Leberknight user avatar by
Scott Leberknight
·
Dec. 17, 13 · Interview
Like (2)
Save
Tweet
Share
24.71K Views

Join the DZone community and get the full member experience.

Join For Free

 this is the third blog in a series of introductory blogs on  apache hbase  . in the second part , we saw how to interact with hbase via the shell. in this part, we'll look at the hbase architecture from a bird's eye view. 

hbase is a  distributed  database, meaning it is designed to run on a cluster of dozens to possibly thousands or more servers. as a result it is more complicated to install than a single rdbms running on a single server. and all the typical problems of distributed computing begin to come into play such as coordination and management of remote processes, locking, data distribution, network latency and number of round trips between servers. fortunately hbase makes use of several other mature technologies, such as apache hadoop and apache zookeeper, to solve many of these issues. the figure below shows the major architectural components in hbase.

hbase architecture

in the above figure you can see there is a single hbase master node and multiple region servers. (note that it is possible to run hbase in a multiple master setup, in which there is a single active master.) hbase tables are partitioned into multiple regions with each region storing a range of the table's rows, and multiple regions are assigned by the master to a region server.

hbase is a  column-oriented  data store, meaning it stores data by columns rather than by rows. this makes certain data access patterns much less expensive than with traditional row-oriented relational database systems. for example, in hbase if there is no data for a given column family, it simply does not store anything at all; contrast this with a relational database which must store  null  values explicitly. in addition, when retrieving data in hbase, you should only ask for the specific column families you need; because there can literally be millions of columns in a given row, you need to make sure you ask only for the data you actually need.

hbase utilizes  zookeeper  (a distributed coordination service) to manage region assignments to region servers, and to recover from region server crashes by loading the crashed region server's regions onto other functioning region servers.

regions contain an in-memory data store (memstore) and a persistent data store (hfile), and all regions on a region server share a reference to the write-ahead log (wal) which is used to store new data that hasn't yet been persisted to permanent storage and to recover from region server crashes. each region holds a specific range of row keys, and when a region exceeds a configurable size, hbase automatically splits the region into two child regions, which is the key to scaling hbase.

as a table grows, more and more regions are created and spread across the entire cluster. when clients request a specific row key or scan a range of row keys, hbase tells them the regions on which those keys exist, and the clients then communicate directly with the region servers where those regions exist. this design minimizes the number of disk seeks required to find any given row, and optimizes hbase toward disk transfer when returning data. this is in contrast to relational databases, which might need to do a large number of disk seeks before transferring data from disk, even with indexes.

the hdfs component is the hadoop distributed filesystem, a distributed, fault-tolerant and scalable filesystem which guards against data loss by dividing files into blocks and spreading them across the cluster; it is where hbase actually stores data. strictly speaking the persistent storage can be anything that implements the hadoop  filesystem  api, but usually hbase is deployed onto hadoop clusters running hdfs. in fact, when you first download and install hbase on a single machine, it uses the local filesystem until you change the configuration!

clients interact with hbase via one of several available apis, including a native java api as well as a rest-based interface and several rpc interfaces (apache thrift, apache avro). you can also use dsls to hbase from groovy, jython, and scala.

conclusion to part 3

in this part, we got a pretty high level view of hbase architecture. in the next part, we'll dive into some real code and show the basics of working with hbase via its native java api.

references

  • hbase web site,  http://hbase.apache.org/ 
  • hbase wiki,  http://wiki.apache.org/hadoop/hbase 
  • hbase reference guide  http://hbase.apache.org/book/book.html 
  • hbase: the definitive guide,  http://bit.ly/hbase-definitive-guide 
  • google bigtable paper, http://labs.google.com/papers/bigtable.html
  • hadoop web site,  http://hadoop.apache.org/ 
  • hadoop: the definitive guide,  http://bit.ly/hadoop-definitive-guide 
  • fallacies of distributed computing,  http://en.wikipedia.org/wiki/fallacies_of_distributed_computing 
  • hbase lightning talk slides,  http://www.slideshare.net/scottleber/hbase-lightningtalk 
  • sample code, https://github.com/sleberknight/basic-hbase-examples
Big data Relational database hadoop Database Architecture

Published at DZone with permission of Scott Leberknight, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Top Five Tools for AI-based Test Automation
  • Why Does DevOps Recommend Shift-Left Testing Principles?
  • Debugging Threads and Asynchronous Code
  • A Real-Time Supply Chain Control Tower Powered by Kafka

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: