June 2013 CHUG: HBase Schema Design Basics

Copyright © 2013 Segel & Associates
All Rights Reserved.
HBase 101:
Schema Design Basics
Chicago area Hadoop User Group (C.H.U.G)
Monday, July 15, 13

Agenda
Introduction:
About the speaker
(blah blah blah)
What is Hadoop/HBase.
Why HBase?
RDBS vs HBase
What HBase isn’t.
Schema Design
HBase Schema Components
Design walk through I
Design walk through II
Secondary Indexing
Summary / Questions
Monday, July 15, 13

About the Speaker
Michael has been working with Hadoop related
technologies since 2009. Currently an Independent
Consultant working for Segel & Associates.
Likes long walks off of short piers. ;-)
Founding member of Big Data Anonymous
(Its a real disease people!)
Monday, July 15, 13

A Quick Review of
Hadoop
Big data is becoming an increasingly important part of
every business. (1300+ members in CHUG!)
MapReduce is a distributed programming model that makes
it easier for developers to analyze massive datasets.
Hadoop is a distributed computing framework and has
many components such as MapReduce.
HDFS has historically been a “write once, read
many” (WORM) ﬁle system
Implementing create-update-delete (CRUD) operations a
challenge
Monday, July 15, 13

The Hadoop Ecosystem
HDFS - Distributed File System
MapReduce - A distributed framework for executing
work in parallel
Hive - A SQL like syntax with a meta store to allow
SQL manipulation of data stored on HDFS.
Pig - A top down scripting language to manipulate
HBase - A NoSQL, non-sequential data store
Monday, July 15, 13

What is HBase?
A NoSQL database
‘Column Oriented’ (At the storage layer)
Highly distributed
Highly scalable
A non-relational persistent object store...
Monday, July 15, 13

What is not HBase
A relational database
Has Transactional Support
Built on a traditional, updatable ﬁle system
(updates are via cells)
A stand alone system (but could be...)
The only NoSQL game in town
Hbase is not...
Monday, July 15, 13

RDBMS vs HBase
RDBMS HBase
ACID compliant No ACID compliance
Sharding/Partitions Distributed Regions
SQL Key lookup/key range scans
Triggers/Stored Procedures Coprocessors
Indexes (B+Tree, R-Tree) No indexing
Highly Normalized Denormalized
Primitive data types Byte arrays
In-place updates Cell versioning
Monday, July 15, 13

Audience Participation:
Questions?
How many students have a strong RDBMS
background?
Data Modeling?
Use of a non relational engine like Pick?
(Revelation, U2, ... COBOL)?
Monday, July 15, 13

Why HBase?
Handles unstructured or semi-structured data.
Handles enormous data volumes.
Flexible. Ad-hoc access as well as full or partial
table scans.
Cost-effective scalability.
Near linear scalability.
Part of the Hadoop ecosystem.
Monday, July 15, 13

Lets take a look at
SCHEMAS
Monday, July 15, 13

Schemas Design
HBase is not an RDBMS
No SQL language or syntax.
Joins in HBase are expensive
HBase can store complex types within a single
column.
Column Families are a factor in designs.
Schema Design is one of the more difﬁcult things
when working with HBase.
Monday, July 15, 13

What makes up HBase
Tables
Column Families
Columns
cells (versions)
(from a conceptual point of view)
(more on this later ... )
Monday, July 15, 13

A PRACTICAL EXAMPLE...
Sales Receipt
Acme Supply You want it, we’ve got it!
Date 12/22/2012
Receipt # abc123
Acme Supply
310 Erie St.
Chicago, IL 60654
Phone (312) 555-12112
Fax (312) 555-1214
sales@acme.com
SOLD
TO
Wylie Coyote
P.O.Box 123
Rock River Canyon, AZ
Payment Method Check No. Job
Qty Item # Description Unit Price Discount Line total
10 12345677 250 LB. Steel Anvils $150.00 10% $1350.00
Shipping $550.00
Total Discount
Subtotal $1900.00
Sales Tax
Total $1900.00
Thank you for your business!
Acme Supply
•Order Entry System
• Order Entry
• Pick Slip
• Shipping
• Invoice
Monday, July 15, 13

RDBMS
Extension
Number
Area_Code
Country_Code
Phone_Type
Phone_ID
Customer_ID
Cust_Phone
Customer_ID
Customer
First_Name
Last_Name
Company
email_addr
City
State
ZIP
Ext_Zip
Street 1
Street 2
Address_ID
Customer_ID
Adress_Type
Address
Attribute
Attribute
Attribute
Attribute
Total
SubTotal
Taxes
Shipping
Customer_ID
Billing_Address
Ship_to_Address
Invoice_ID
Date
Invoice
unit_cost
unit_price
manufacturer
description
product_id
sku_code
upc_code
Product
qty
sale_unit_price
product_id
Line_number
Line_ID
Invoice_ID
Invoice_Line
Monday, July 15, 13

RDBMS
Extension
Number
Area_Code
Country_Code
Phone_Type
Phone_ID
Customer_ID
Cust_Phone
Customer_ID
Customer
First_Name
Last_Name
Company
email_addr
City
State
ZIP
Ext_Zip
Street 1
Street 2
Address_ID
Customer_ID
Adress_Type
Address
Attribute
Attribute
Attribute
Attribute
Total
SubTotal
Taxes
Shipping
Customer_ID
Billing_Address
Ship_to_Address
Invoice_ID
Date
Invoice
unit_cost
unit_price
manufacturer
description
product_id
sku_code
upc_code
Product
qty
sale_unit_price
product_id
Line_number
Line_ID
Invoice_ID
Invoice_Line
These table structures contain
the Detail information in a
Master/Detail Relationship.
Requires a FOREACH to pull
data for an invoice.
Monday, July 15, 13

RDBMS:
What did we see?
Highly normalized design
Lots of joins to get a single record.
Requires a FOR EACH loop to fetch
the detail records. (Or a join against
the master record.)
Monday, July 15, 13

Now Lets Look at
HBase!
The defined schema contain table name and column
families. Columns are not defined. (# Versions per
column are!)
Data is stored in key-value pairs. The key is the primary
index. (There really is no index per se.)
The value is a set of one or more columns which contain
Java Byte arrays.
Each table should be considered stand alone. The only
exception would be indices created on non-key fields.
(Secondary Indexes... More on this later...)
Monday, July 15, 13

How to translate the model
to HBase:
Traditional Entity Relation Design tools are of limited use.
Each table should be atomic, with only weak relationships to
other tables.
A record should be completely contained in a single row.
Deﬁne your record based on the data present.
Encapsulate data by grouping related data within the
record.
Monday, July 15, 13

Remember our Invoice?
Company
Company Address
Customer Name
Ship To: Address
Date(s)
Phone #(s)
Line Items:
SKU
Description
Qty
Unit Price
Total Price
SubTotal
Tax(s)
Total
Monday, July 15, 13

Remember our Invoice?
Company
Company Address
Customer Name
Ship To: Address
Date(s)
Phone #(s)
Line Items:
SKU
Description
Qty
Unit Price
Total Price
SubTotal
Tax(s)
Total Here are a couple of groupings
that encapsulate data.
Monday, July 15, 13

HBASE SCHEMA
sub_total
taxes
discount
total
line_items
reference_docs
customer_id
customer_name
customer_phone
customer_billing_address
customer_shipTo_address
company_address
inv_date
company_name
invoice_id
Invoice
This is just an example.
There are other options!
Question(s) for the Audience:
Should this be a table?
What about a column family?
[Hint: Think of the entire system e.g. Order Entry... ]
Monday, July 15, 13

LETSTAKE A CLOSER LOOK
sub_total
taxes
discount
total
line_items
reference_docs
customer_id
customer_name
customer_phone
company_address
inv_date
company_name
invoice_id
Invoice
Monday, July 15, 13

sub_total
taxes
discount
total
line_items
reference_docs
customer_id
customer_name
customer_phone
company_address
inv_date
company_name
invoice_id
Invoice
The invoice_id is our row key. This is a
unique ID speciﬁc to one and only one
invoice.
Bonus question:
Is this really a good row key?
Monday, July 15, 13

sub_total
taxes
discount
total
line_items
reference_docs
customer_id
customer_name
customer_phone
company_address
inv_date
company_name
invoice_id
Invoice
The invoice_id is our row key. This is a
unique ID speciﬁc to one and only one
invoice.
Bonus question:
Is this really a good row key?
These represent structures which
encapsulate primitive data types
Monday, July 15, 13

Lets Look at our Key
Fastest access is
when accessing a
single record based
on the full key.
Scans more
expensive, full
table scans very
expensive
sub_total
taxes
discount
total
line_items
reference_docs
customer_id
customer_name
customer_phone
company_address
inv_date
company_name
invoice_id
Invoice
invoice_id is unique
How do we access invoices?
What are our use cases?
Why is it not a good key?
Monday, July 15, 13

So what makes a good key?
Uniqueness
Easy access for known and predominant
Use Cases
You need to Know your data.
You need to Know your access patterns.
Not in sort order- Sequential #s and
sorted input are bad for inserts and
table splits. (Hot spots)
Monday, July 15, 13

So how do we access
Orders/Invoices/etc...
By speciﬁc Invoice #
Pick Slips
Customer inquiries
By customer number/id Then Order/Invoice#
Customer inquiries
∴ The key should be: customer_id | invoice_id
? But what about a Timestamp?
Monday, July 15, 13

SEQUENTIAL KEYS ANDTABLE SPLITS
Row$ID Column$Data$
1 something
2 Cat
3 Dog
4 word
7 silly
11 newspaper
17 git
27 snarf
43 pink
68 brain
107 takeover
169 SomethingAelse
267 MoreAData
421 AndAsomeAmoreAdata.
665 Snark
1050 LewisACarrollA
1657 Alf
2616 POJO
4129 Busted
6517 SomeAmoreAdataA
10286 TimeAtoASplit
New Data
Pre-Split
Just before the table splits we can
see how the data is going to be
split in to regions.
Monday, July 15, 13

Row$ID Column$Data$
1 something
2 Cat
3 Dog
4 word
7 silly
11 newspaper
17 git
27 snarf
43 pink
68 brain
107 takeover
169 SomethingAelse
267 MoreAData
665 Snark
1050 LewisACarrollA
1657 Alf
2616 POJO
4129 Busted
10286 TimeAtoASplit
New Data
Pre-Split
To become
Region A
Monday, July 15, 13

Row$ID Column$Data$
1 something
2 Cat
3 Dog
4 word
7 silly
11 newspaper
17 git
27 snarf
43 pink
68 brain
107 takeover
169 SomethingAelse
267 MoreAData
665 Snark
1050 LewisACarrollA
1657 Alf
2616 POJO
4129 Busted
10286 TimeAtoASplit
New Data
Pre-Split
To become
Region A
To become
Region B
Monday, July 15, 13

TABLE SPLITS
Row$ID Column$Data$
1 something
2 Cat
3 Dog
4 word
7 silly
11 newspaper
17 git
27 snarf
43 pink
68 brain
107 takeover
169 SomethingAelse
Row$ID Column$Data$
267 More(Data
421 And(some(more(data.
665 Snark
1050 Lewis(Carroll(
1657 Alf
2616 POJO
4129 Busted
6517 Some(more(data(
10286 Time(to(Split
16236 Some)new)data)
25628 Whinnie
40452 Pooh
63850 Davincci
100784 Code
159081 Tigger)is)Awsome
New Data
Post-Split
Region A Region B
Monday, July 15, 13

TABLE SPLITS
Row$ID Column$Data$
1 something
2 Cat
3 Dog
4 word
7 silly
11 newspaper
17 git
27 snarf
43 pink
68 brain
107 takeover
169 SomethingAelse
Row$ID Column$Data$
267 More(Data
665 Snark
1050 Lewis(Carroll(
1657 Alf
2616 POJO
4129 Busted
10286 Time(to(Split
25628 Whinnie
40452 Pooh
63850 Davincci
100784 Code
New Data
Post-Split
Region A Region B
As we can see, the
Region splits in to A
and B.As new rows
are added, they are
added to the right,
Monday, July 15, 13

TABLE SPLITS
Row$ID Column$Data$
1 something
2 Cat
3 Dog
4 word
7 silly
11 newspaper
17 git
27 snarf
43 pink
68 brain
107 takeover
169 SomethingAelse
Row$ID Column$Data$
267 More(Data
665 Snark
1050 Lewis(Carroll(
1657 Alf
2616 POJO
4129 Busted
10286 Time(to(Split
25628 Whinnie
40452 Pooh
63850 Davincci
100784 Code
New Data
Post-Split
Region A Region B
As we can see, the
Region splits in to A
and B.As new rows
are added, they are
added to the right,
Region B will grow
until it splits and then
Monday, July 15, 13

Putting this in Perspective
When the region splits, it will split in half.
All of the new writes will continue to be appended to
the right side of the youngest region.
Then that region will split.
Over time you will have many regions where they
contain approximately 1/2 the region’s max file size.
In the end, all inserts will ‘hot spot’ to the last
region and it will split leaving two half filled regions.
So you have two bad side effects, ‘hot spotting’ and
lots of half filled regions.
Monday, July 15, 13

Alternatives:
Hashing the row key...
If we hash the row key using a SHA-1 hash, or MD5 Hash the key
will be inserted in a ‘random’ order.
No regional ‘hotspotting’
In order to fetch rows efﬁciently, you need to know your entire key,
hash it, then use get() to fetch the speciﬁc row.
Hashing works great if you know your entire row key.
Hashing kills if you want to do partial key scans.
Some truncate the hash and prepend it to the key to get the
desired distribution and also guarantee uniqueness. (This is different
from using a salt.
Monday, July 15, 13

Keep to a low Salt diet!
http://blog.sematext.com/2012/04/09/hbasewd-avoid-
regionserver-hotspotting-despite-writing-records-with-
sequential-keys/
Concept is to use a ‘preﬁx-salt’ and ‘round robin’ the
inserts.
While it solves the issue of a single region hotspotting,
it has some nasty side effects:
Complicates scan()
Complicates get()
Monday, July 15, 13

Key Design Summary
Think about your data.
Think about how you access the data and
what should be in the key.
Avoid sequential keys if possible, understand
the issues with hashing the key.
Keys are sorted in Byte[] order
Keep it simple. (KISS)
There are always alternatives so YMMV.
Monday, July 15, 13

Column Families
The Good, The Bad and the Ugly
The Good: Column families allow you to partially
segregate related data with the same key.
The Bad: All actions to a table occur to all
column families at the same time. The more
column families, the longer splits, and
compactions take. Rule of thumb... no more than
3-5 column families per table.
The Ugly: The Bad gets worse when you
consider that when you split a region of a table,
all of the Column Families’ regions are split too.
This can lead to lots of small regions.
Monday, July 15, 13

Column Family
Use Case
Customer Orders
Order Entry
Pick Slips
Shipping Slips
Invoices
All column families use the
same row Key
Each column family contains
unique data, speciﬁc to step
in the order process.
Denormalize the data. Repeat
information as needed.
Column Family rows are
roughly the same size.
Monday, July 15, 13

Schema Summary
Review
Consider column families, but use sparingly.
Focus on data access patterns.
The key to success is in the key itself.
Secondary indexing is always an option. (We
will talk about this in the next section.)
Monday, July 15, 13

Advanced
Schema Design
Monday, July 15, 13

Complex Data Types
Columns are Byte[]
Its possible to now think in storing data in 3
dimensions.
Row x Column (2D)
Row x Column x Structured Blob (3D)
Monday, July 15, 13

Storing Structure
Options
Byte[] are essentially
blobs. Almost anything
goes.
Types of Objects
Strings (String.toByte())
Custom Java Structures
Avro
Java Serialization
Custom
toString().toByte()
Avro
We Like Avro!
Monday, July 15, 13

Avro Makes life Easier
Avro is a data serializer and RPC
system
Created by Doug Cutting (Also of
Hadoop Fame)
Language independent (Java, C, C++,
C#, others) APIs
Schema based, deﬁned with JSON
Supports Dynamic Typing
Untagged Data results in smaller
serialized size.
No manually assigned ﬁeld IDs. When
schemas change, old and new schema
are present.
Avro can serialize to both a binary and
JSON format
Splittable and compressible
Avro is both a service and a class library
Focus on Java APIs
http://avro.apache.org/docs/current/api/
java/index.html
Avro relies on UTF-8 for Strings
Monday, July 15, 13

Schemas
Avro Schema for the Address ﬁeld
address-rec.avpr
{
! "namespace":"com.CHUG",
! "name": "AddressRecord",
! "type": "record",
! "ﬁelds":[
! ! {"name":"street1","type":"string","comment":"First street address."},
! ! {"name":"street2","type":[“null”,"string"],"comment":"Second street address."},
! ! {"name":"city","type":"string"},
! ! {"name":"state","type":"string"},
! ! {"name":"zip","type":"string"}
! ]
}
This is just
one example.
Monday, July 15, 13

Secondary
Indexing
Monday, July 15, 13

Adding an Index
HBase naturally does not support indices
Which type of Index to implement is up to
you
Inverted Table
Lucene
Solr
Monday, July 15, 13

Indexing Issues
HBase writes are atomic.
Index maintenance has to be synchronized with the
base table.
Co-Processors are still not fully baked.
Writes to Index will incur additional costs. (Index
region will most likely not be on the same RS as the
base table’s region.)
All code will be custom. You are on your own.
YMMV in terms of Performance.
Monday, July 15, 13

So What have we learned?
Row key design is everything.
Denormalizing data is critical.
HBase is not rational, so to keep your sanity, forget
your rational modeling techniques.
Avro is a powerful feature you can use to add another
dimension to your schema.
Secondary indexing is possible!
Know your Data!
Monday, July 15, 13

Some Key Take Aways
Pearls of Wisdom
There are more than one way to skin a cat. So you need to take what was
presented with a grain of Kosher salt. (The grains are bigger.)
You need to experiment on your own. Reading someone’s blog or slide deck is no
replacement for hands on experience.
Just because Facebook does something, doesn’t mean its a good idea. They have a
different way of looking at problems and what works for them will not necessarily
work for you.
It takes years of experience to know when to break the rules and which rules
you can break.
Good clean code will always out perform the rest. Always stick to the KISS
methodology.
Monday, July 15, 13

Questions?
Thank you for coming and we hope
that you’ve liked the show.
Congratulations
Chicago Blackhawks!
2013 Stanley Cup
Champions
Monday, July 15, 13

June 2013 CHUG: HBase Schema Design Basics

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie June 2013 CHUG: HBase Schema Design Basics

Ähnlich wie June 2013 CHUG: HBase Schema Design Basics (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

June 2013 CHUG: HBase Schema Design Basics