• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
HBaseCon 2013: Mixing Low Latency with Analytical Workloads for Customer Experience Management
 

HBaseCon 2013: Mixing Low Latency with Analytical Workloads for Customer Experience Management

on

  • 1,112 views

Presented by: Neil Ferguson, Causata

Presented by: Neil Ferguson, Causata

Statistics

Views

Total Views
1,112
Views on SlideShare
1,112
Embed Views
0

Actions

Likes
1
Downloads
3
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    HBaseCon 2013: Mixing Low Latency with Analytical Workloads for Customer Experience Management HBaseCon 2013: Mixing Low Latency with Analytical Workloads for Customer Experience Management Presentation Transcript

    • Mixing low latency with analytical workloads for Customer Experience Management Neil Ferguson, Development Lead June 13, 2013
    • Causata Overview • Real-time Offer Management – Involves predicting something about a customer based on their profile – For example, predicting if somebody is a high-value customer when deciding whether to offer them a discount – Typically involves low latency (< 50 ms) access to an individual profile – Both on-premise and hosted • Analytics – Involves getting a large set of profiles matching certain criteria – For example, finding all of the people who have spent more than $100 in the last month – Involves streaming access to large amounts of data (typically millions of rows / sec per node) – Often ad-hoc
    • Some History • Started building our platform 4 ½ years ago • Started on MySQL – Latency too high when reading large profiles – Write throughput too low with large data sets • Built our own custom-built data store –Performed well (it was built for our specific needs) –Non-standard; maintenance costs • Moved to HBase last year – Industry standard; lowered maintenance costs – Can perform well!
    • Our Data • All data is stored as Events, each of which has the following: – A type (for example, “Product Purchase”) – A timestamp – An identifier (who the event belongs to) – A set of attributes, each of which has a type and value(s), for example: • “Product Price -> 99.99 • “Product Category” -> “Shoes”, “Footwear”
    • Our Storage • Only raw data is stored (not pre-aggregated) • Event table (row-oriented): – Stores data clustered by user profile – Used for low latency retrieval of individual profiles for offer management, and for bulk queries for analytics • Index table (“column- oriented”): – Stores data clustered by attribute type – Used for bulk queries (scanning) for analytics • Identity Graph: – Stores a graph of cross-channel identifiers for a user profile Stored as an in-memory column family in the Events table
    • Maintaining Locality • Data locality (with HBase client) gives around a 60% throughput increase – Single node can scan around 1.6 million rows / second with Region Server on separate machine – Same node can scan around 2.5 million rows / second with Region Server on the local machine • Custom region splitter: ensures that (where possible), event tables and index tables are split at the same point – Tables divided into buckets, and split at bucket boundaries • Custom load balancer: ensures that index table data is balanced to the same RS as event table data • All upstream services are locality-aware
    • Querying Causata For each customer who has spent more than $100, get product views in the last week from now: SELECT S.product_views_in_last_week FROM Scenarios S WHERE S.timestamp = now() AND total_spend > 100; For each customer who has spent more than $100, get product views in the last week from when they purchased something: SELECT S.product_views_in_last_week FROM Scenarios S, Product_Purchase P WHERE S.timestamp = P.timestamp AND S.profile_id = P.profile_id AND S.total_spend > 100;
    • Query Engine • Raw data stored in HBase, queries typically performed against aggregated data – Need to scan billions of rows, and aggregate on the fly - Many parallel scans performed: - Across machines (obviously) - Across regions (and therefore disks) - Across cores • Queries can optionally skip uncompacted data (based on HFile timestamps) – Allows result recency to be traded for performance • Some other performance tuning: - Shortcircuit reads turned on (available from 0.94) - Multiple columns combined into one
    • Parallelism Single Region Server, local client, all rows returned to client, disk-bound workload (disk cache cleared before test), ~1 billion rows scanned in total, ~15 bytes per row (on disk, compressed), 2 x 6 core Intel(R) X5650 @ 2.67GHz, 4 x 10k RPM SAS disks, 48GB RAM
    • Request Prioritization • All requests to HBase go through a single thread pool • This allows requests to be prioritized according to sensitivity to latency • “Real-time” (latency-sensitive) requests are treated specially • Real-time request latency is monitored continuously, and more resources allocated if deadlines are not met
    • Questions… Email: neilf at causata dot com Web: http://www.causata.com Twitter: @causata