HBase for Architects
•
74 likes•33,693 views
HBase can be an intimidating beast for someone considering its adoption. For what kinds of workloads is it well suited? How does it integrate into the rest of my application infrastructure? What are the data semantics upon which applications can be built? What are the deployment and operational concerns? In this talk, I'll address each of these questions in turn. As supporting evidence, both high-level application architecture and internal details will be discussed. This is an interactive talk: bring your questions and your use-cases!
Report
Share
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to HBase for Architects
Similar to HBase for Architects (20)
More from Nick Dimiduk
More from Nick Dimiduk (10)
Recently uploaded
Recently uploaded (20)
HBase for Architects
- 1. © Hortonworks Inc. 2011 Apache HBase For Architects Nick Dimiduk Member of Technical Staff, HBase Seattle Technical Forum, 2013-05-15 Page 1
- 2. © Hortonworks Inc. 2011 Page 2 Architecting the Future of Big Data
- 3. © Hortonworks Inc. 2011 Agenda • Background – (how did we get here?) • High-level Architecture – (where are we?) • Anatomy of a RegionServer – (how does this thing work?) • TL;DR – (what did we learn?) • Resources – (where do we go from here?) Page 3 Architecting the Future of Big Data
- 4. © Hortonworks Inc. 2011 Background Architecting the Future of Big Data Page 4
- 5. © Hortonworks Inc. 2011 Apache Hadoop in Review • Apache Hadoop Distributed Filesystem (HDFS) – Distributed, fault-tolerant, throughput-optimized data storage – Uses a filesystem analogy, not structured tables – The Google File System, 2003, Ghemawat et al. – http://research.google.com/archive/gfs.html • Apache Hadoop MapReduce (MR) – Distributed, fault-tolerant, batch-oriented data processing – Line- or record-oriented processing of the entire dataset * – “[Application] schema on read” – MapReduce: Simplified Data Processing on Large Clusters, 2004, Dean and Ghemawat – http://research.google.com/archive/mapreduce.html Page 5 Architecting the Future of Big Data * For more on writing MapReduce applications, see “MapReduce Patterns, Algorithms, and Use Cases” http://highlyscalable.wordpress.com/2012/02/01/mapreduce-patterns/
- 6. © Hortonworks Inc. 2011 So what is HBase anyway? • BigTable paper from Google, 2006, Dean et al. – “Bigtable is a sparse, distributed, persistent multi-dimensional sorted map.” – http://research.google.com/archive/bigtable.html • Key Features: – Distributed storage across cluster of machines – Random, online read and write data access – Schemaless data model (“NoSQL”) – Self-managed data partitions Page 6 Architecting the Future of Big Data
- 7. © Hortonworks Inc. 2011 High-level Architecture Architecting the Future of Big Data Page 7
- 8. © Hortonworks Inc. 2011 Page 9 Architecting the Future of Big Data Logical Architecture Distributed, persistent partitions of a BigTable a b d c e f h g i j l k m n p o Table A Region 1 Region 2 Region 3 Region 4 Region Server 7 Table A, Region 1 Table A, Region 2 Table G, Region 1070 Table L, Region 25 Region Server 86 Table A, Region 3 Table C, Region 30 Table F, Region 160 Table F, Region 776 Region Server 367 Table A, Region 4 Table C, Region 17 Table E, Region 52 Table P, Region 1116 Legend: - A single table is partitioned into Regions of roughly equal size. - Regions are assigned to Region Servers across the cluster. - Region Servers host roughly the same number of regions.
- 9. © Hortonworks Inc. 2011 Page 11 Architecting the Future of Big Data Physical Architecture Distribution and Data Path ... Zoo Keeper Zoo Keeper Zoo Keeper HBase Client JavaApp HBase Client JavaApp HBase Client HBase Shell HBase Client REST/Thrift Gateway HBase Client JavaApp HBase Client JavaApp Region Server Data Node Region Server Data Node ... Region Server Data Node Region Server Data Node HBase Master Name Node Legend: - An HBase RegionServer is collocated with an HDFS DataNode. - HBase clients communicate directly with Region Servers for sending and receiving data. - HMaster manages Region assignment and handles DDL operations. - Online configuration state is maintained in ZooKeeper. - HMaster and ZooKeeper are NOT involved in data path.
- 10. © Hortonworks Inc. 2011 Page 13 Architecting the Future of Big Data Logical Data Model A sparse, multi-dimensional, sorted map Legend: - Rows are sorted by rowkey. - Within a row, values are located by column family and qualifier. - Values also carry a timestamp; there can me multiple versions of a value. - Within a column family, data is schemaless. Qualifiers and values are treated as arbitrary bytes. 1368387247 [3.6 kb png data]"thumb"cf2b a cf1 1368394583 7 1368394261 "hello" "bar" 1368394583 22 1368394925 13.6 1368393847 "world" "foo" cf2 1368387684 "almost the loneliest number"1.0001 1368396302 "fourth of July""2011-07-04" Table A rowkey column family column qualifier timestamp value
- 11. © Hortonworks Inc. 2011 Anatomy of a RegionServer Architecting the Future of Big Data Page 14
- 12. © Hortonworks Inc. 2011 Page 16 Architecting the Future of Big Data RegionServer HDFS HLog (WAL) HRegion HStore StoreFile HFile StoreFile HFile MemStore ... ... HStore BlockCache HRegion ... HStoreHStore ... Legend: - A RegionServer contains a single WAL, single BlockCache, and multiple Regions. - A Region contains multiple Stores, one for each Column Family. - A Store consists of multiple StoreFiles and a MemStore. - A StoreFile corresponds to a single HFile. - HFiles and WAL are persisted on HDFS. Storage Machinery Implementing the data model
- 13. © Hortonworks Inc. 2011 TL;DR Architecting the Future of Big Data Page 21
- 14. © Hortonworks Inc. 2011 For what kinds of workloads is it well suited? • It depends on how you tune it, but… • HBase is good for: – Large datasets – Sparse datasets – Loosely coupled (denormalized) records – Lots of concurrent clients • Try to avoid: – Small datasets (unless you have lots of them) – Highly relational records – Schema designs requiring transactions * Page 22 Architecting the Future of Big Data * Transactions might not be as necessary as you think, see “Eric Brewer on why banks are BASE not ACID” http://highscalability.com/blog/2013/5/1/myth-eric-brewer-on-why- banks-are-base-not-acid-availability.html ** Or maybe not, “We believe it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions.” – Google Spanner paper, http:// research.google.com/archive/spanner.html
- 15. © Hortonworks Inc. 2011 How does it integrate with my infrastructure? • Horizontally scale application data – Highly concurrent, read/write access – Consistent, persisted shared state – Distributed online data processing via Coprocessors (experimental) • Gateway between online services and offline storage/analysis – Staging area to receive new data – Serve online, indexed “views” on datasets from HDFS – Glue between batch (HDFS, MR1) and online (CEP, Storm) systems Page 23 Architecting the Future of Big Data
- 16. © Hortonworks Inc. 2011 What data semantics does it provide? • GET, PUT, DELETE key-value operations • SCAN for queries • INCREMENT, CAS server-side atomic operations • Row-level write atomicity • MapReduce integration – Online API (today) – Bulkload (today) – Snapshots (coming) Page 24 Architecting the Future of Big Data
- 17. © Hortonworks Inc. 2011 What about operational concerns? • Provision hardware with more spindles/TB • Balance memory and IO for reads – Contention between random and sequential access – Configure Block size, BlockCache, compression, codecs based on access patterns – Additional resources – “HBase: Performance Tuners,” http://labs.ericsson.com/blog/hbase-performance-tuners – “Scanning in HBase,” http://hadoop-hbase.blogspot.com/2012/01/scanning-in- hbase.html • Balance IO for writes – Configure C1 (compactions, region size, compression, pre-splits, &c.) based on write pattern – Balance IO contention between maintaining C1 and serving reads – Additional resources – “Configuring HBase Memstore: what you should know,” http://blog.sematext.com/ 2012/07/16/hbase-memstore-what-you-should-know/ – “Visualizing HBase Flushes And Compactions,” http://www.ngdata.com/visualizing- hbase-flushes-and-compactions/ Page 25 Architecting the Future of Big Data
- 18. © Hortonworks Inc. 2011 Resources Architecting the Future of Big Data Page 26
- 19. © Hortonworks Inc. 2011 Join the Community! • hbase.apache.org – blogs.apache.org/hbase/ • Mailing lists – hbase.apache.org/mail-lists.html – user@hbase.apache.org • IRC – irc.freenode.net#hbase • JIRA – issues.apache.org/jira/browse/HBASE • Source – git clone git://git.apache.org/hbase.git – svn checkout http://svn.apache.org/repos/asf/hbase/trunk hbase • Conference Season – HBaseCon 2013, June 13, hbasecon.com – Hadoop Summit, June 26-27, hadoopsummit.org Page 27 Architecting the Future of Big Data
- 20. © Hortonworks Inc. 2011 HBase@Hortonworks • Mean Time To Recovery (MTTR) – HDFS improvements, faster recovery of META, log replay instead of log splitting, improving failure detection • Testing – Integration test suite, system tests, destructive testing, ChaosMonkey, load tests, Namenode HA, test coverage and consistency • Compaction Improvements – Pluggable compaction, tier based compaction, stripe / leveldb compactions, etc • IPC / Wire compatibility – Migration to Google’s Protocol Buffers • HBase MapReduce improvements (Import / Export, etc) – Performance improvements, API uniformity/usability • Hardening 0.94 – Assignment Manager, Log splitting, Region splits, Replication • Not to mention: – Windows support, Security, Snapshots, Hadoop2, 0.96, LOTS of bug fixes and community reviews Page 28 Architecting the Future of Big Data
- 21. © Hortonworks Inc. 2011 Thanks! Architecting the Future of Big Data Page 29 M A N N I N G Nick Dimiduk Amandeep Khurana FOREWORD BY Michael Stack hbaseinaction.com Nick Dimiduk github.com/ndimiduk @xefyr n10k.com