Columnar Access with HBase Lecture BigData Analytics Julian M. Kunkel julian.kunkel@googlemail.com University of Hamburg / German Climate Computing Center (DKRZ) 2016-12-16 Disclaimer: Big Data software is constantly updated, code samples may be outdated.
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Outline 1 Introduction 2 Excursion: ZooKeeper 3 Architecture 4 Accessing Data 5 Summary Julian M. Kunkel Lecture BigData Analytics, 2016 2 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Overview of HBase [29, 30] Column-oriented key-value database for structured data Based on Google’s BigTable Simple data and consistency model Row column1 column2 ... “Hans” bla 19 ... “Julian” NULL 20 ... Scalable for billion of rows with millions of columns Sharding of tables: distribute keys automatically among servers Stretches across data centers Custom query language Real-time queries Compression, in-memory execution Bloom filters and block cache to speed up queries Use HDFS and supports MapReduce Uses ZooKeeper for configuration, notification and synchronization Interactive shell (invoke hbase shell) Julian M. Kunkel Lecture BigData Analytics, 2016 3 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Data Model [29] Namespace: Logical grouping of tables for quota, security Table: A table (namespae:table) consists of multiple rows Row: Consists of a row key and (many) columns with values Key/values are binary (converted from any data type) WARNING: hbase shell stores all data as STRING Column: Consists of a column family and a qualifier (cf:q) Column family: string with printable characters Cell: Combination of row, column Contains value (byte array) and timestamp (last modification) Timestamp: versions that change upon update Student grading table (timestamps are not shown) Row=Matrikel a:name a:age l:BigData1516 l:Analysis1 12/13 ... stud/4711 Hans 19 1.0 2.0 ... stud/4712 Julian 20 NULL 1.7 ... Julian M. Kunkel Lecture BigData Analytics, 2016 4 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Main Operations [29] get: return attributes for a row put: add row or update columns increment: increment values of multiple columns scan: iterate over multiple rows (potentially filtering) delete: remove a row, column or family Data is marked for deletion Finally removed during compaction Schema operations create: create a table, specify the column families alter: change table properties describe: retrieve table/column family properties list: list tables create_namespace: create a namespace drop_namespace: remove a namespace Julian M. Kunkel Lecture BigData Analytics, 2016 5 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Example Interactive Session 1 $ create ’student’, cf=[’a’,’b’] # a,b are the column families 2 0 row(s) in 0.4820 seconds 3 $ put ’student’, ’mustermann’, ’a:name’, ’max mustermann’ # create column on the fly 4 $ put ’student’, ’mustermann’, ’a:age’, 20 5 # we can convert 20 to a bytearray using Bytes.toBytes(20), otherwise it is a string 6 $ put ’student’, ’musterfrau’, ’a:name’, ’sabine musterfrau’ 7 $ scan ’student’ 8 ROW COLUMN+CELL 9 musterfrau column=a:name, timestamp=1441899059022, value=sabine musterfrau 10 mustermann column=a:age, timestamp=1441899058957, value=20 11 mustermann column=a:name, timestamp=1441899058902, value=max mustermann 12 2 row(s) in 0.0470 seconds 13 $ get ’student’,’mustermann’ 14 COLUMN CELL 15 a:age timestamp=1441899058957, value=20 16 a:name timestamp=1441899058902, value=max mustermann 17 2 row(s) in 0.0310 seconds 18 # Increment the number of lectures attended by the student in an atomic operation 19 $ incr ’student’, ’max mustermann’, ’a:attendedClasses’, 2 20 COUNTER VALUE = 2 21 # delete the table 22 $ disable ’student’ # deactivate access to the table 23 $ drop ’student’ Julian M. Kunkel Lecture BigData Analytics, 2016 6 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Inspecting Schemas list <NAME>: List tables with the name, regex support 1 $ list ’stud.*’ 2 TABLE 3 student describe <TABLE>: List attributes of the table 1 $ describe ’student’ 2 COLUMN FAMILIES DESCRIPTION 3 {NAME => ’a’, BLOOMFILTER => ’ROW’, VERSIONS => ’1’, IN_MEMORY => ’false’, ↪→ KEEP_DELETED_CELLS => ’FALSE’, DATA_BLOCK_ENCODING => ’NONE’, TTL => ↪→ ’FOREVER’, COMPRESSION => ’NONE’, MIN_VERSIONS => ’0’, BLOCKCACHE => ↪→ ’true’, BLOCKSIZE => ’65536’, REPLICATION_SCOPE => ’0’} 4 {NAME => ’b’, BLOOMFILTER => ’ROW’, VERSIONS => ’1’, IN_MEMORY => ’false’, ↪→ KEEP_DELETED_CELLS => ’FALSE’, DATA_BLOCK_ENCODING => ’NONE’, TTL => ↪→ ’FOREVER’, COMPRESSION => ’NONE’, MIN_VERSIONS => ’0’, BLOCKCACHE => ↪→ ’true’, BLOCKSIZE => ’65536’, REPLICATION_SCOPE => ’0’} alter: Change table settings 1 # Keep at most 5 versions for the column family ’a’ 2 $ alter ’student’, NAME => ’a’, VERSIONS => 5 3 Updating all regions with the new schema... 4 0/1 regions updated. 5 1/1 regions updated. Julian M. Kunkel Lecture BigData Analytics, 2016 7 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Remove Irrelevant Responses from Scans Scan options allow to restrict the rows/keys/values to be retrieved LIMIT the number of returned rows COLUMNS specify the prefix of columns/families ROWPREFIXFILTER restricts the row names 1 # filter columns using scan properties 2 $ scan ’student’, {COLUMNS=>[’a:age’,’a:name’], LIMIT=>2, ROWPREFIXFILTER =>’muster’} 3 ROW COLUMN+CELL 4 musterfrau column=a:name, timestamp=1449395009213, value=sabine musterfrau 5 mustermann column=a:age, timestamp=1449395005507, value=20 6 mustermann column=a:name, timestamp=1449395001724, value=max mustermann 7 8 # scan rows with keys "STARTROW" <= "ROW" < "ENDROW" 9 $ scan ’student’, {COLUMNS=>[’a:age’,’a:name’], STARTROW => "muster", ENDROW => ↪→ "mustermann"} 10 musterfrau column=a:name, timestamp=1449395009213, value=sabine musterfrau Julian M. Kunkel Lecture BigData Analytics, 2016 8 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Client Request Filters [30] Filters are Java classes restricting matches; overview show_filters Filter list: combines multiple filters with AND and OR Compare values of one or multiple columns Smaller, equal, greater, substring, prefix, ... Compare metadata: column family and qualifier Qualifier prefix filter: Return (first few) matching columns Column range filter: return a slice of columns (e.g., bb-bz) Compare names of rows Note: it is preferable to use scan options Example in the hbase shell [32], [33] 1 # Apply regular filters 2 $ scan ’student’,{ FILTER => "KeyOnlyFilter()"} 3 musterfrau column=a:name, timestamp=1449395009213, value= 4 mustermann column=a:age, timestamp=1449395005507, value= 5 mustermann column=a:name, timestamp=1449395001724, value= 6 # return only rows starting with muster AND columns starting with a or b AND at most 2 lines 7 $ scan ’student’,{ FILTER => "(PrefixFilter (’muster’)) AND MultipleColumnPrefixFilter(’a’,’b’) AND ColumnCountGetFilter(2)" } 8 mustermann column=a:age, timestamp=1449395005507, value=20 9 $ scan ’student’,{ FILTER => "SingleColumnValueFilter(’a’,’name’,=,’substring:sabine musterfrau’)"} 10 musterfrau column=a:name, timestamp=1449395009213, value=sabine musterfrau 11 # return all students older than 19 12 $ scan ’student’,{ COLUMNS=>[’a:age’], FILTER => "SingleColumnValueFilter(’a’,’age’,>,’binary:19’)"} 13 mustermann column=a:age, timestamp=1449407597419, value=20 Julian M. Kunkel Lecture BigData Analytics, 2016 9 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Consistency [29] Row keys cannot be changed Strong consistency of reads and writes Mutations of multiple rows are not atomic (need more than one API call) All mutations are atomic (no partial succeed) Multiple column families of one row can be changed atomically Order of concurrent mutations not defined Successful operations are made durable The tuple (row, column, version) specifies the cell Normally version is the timestamp, but can be changed The last mutation to a cell defines the content Any order of versions can be written (max number of versions defined by cf) Get and scan return recent versions but maybe not the newest A get may return an old version but between subsequent gets the version may never decrease (no time travel) Any row returned must be consistent (isolates ongoing column mutations) A scan must return all mutations completed before it started It MAY contain later changes Content read is guaranteed to be durable Deletes masks (hides) newer puts until compaction is done Julian M. Kunkel Lecture BigData Analytics, 2016 10 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Co-Processors [43] Coprocessor concept allow to compute functions based on column values Similar to database triggers Hooks are executed on the RegionServers implemented in observers Can be used for secondary indexing, complex filtering and access control Scope for the execution All tables (system coprocessors) On a table (table coprocessor) Observer intercepts method invocation and allows manipulation RegionObserver: intercepts data access routines on RegionServer/table WALObserver: intercepts write-ahead log, one per RegionServer MasterObserver: intercepts schema operations Currently must be implemented in Java Can be loaded from the hbase shell Julian M. Kunkel Lecture BigData Analytics, 2016 11 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary 1 Introduction 2 Excursion: ZooKeeper 3 Architecture 4 Accessing Data 5 Summary Julian M. Kunkel Lecture BigData Analytics, 2016 12 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Zookeeper Overview [39, 40] Centralized service providing Configuration information (e.g., service discovery) Distributed synchronization (e.g., locking) Group management (e.g., nodes belonging to a service) Simple: Uses a hierarchical namespace for coordination Strictly ordered access semantics Distributed and reliable using replication Scalable: A client can connect to any server Source: ZooKeeper Service [40] Julian M. Kunkel Lecture BigData Analytics, 2016 13 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Hierarchical Namespace [40] Similar to file systems but kept in main memory znodes represent both file and directory Source: ZooKeeper’s Hierarchical Namespace [40] Nodes Contain a stat structure: version numbers, ACL changes, timestamps Additional application data is read together with stats Watch can be set on a node: triggered once when a znode changes Ephemeral nodes: are automatically removed once the session that created them terminates (e.g., server crashes) Julian M. Kunkel Lecture BigData Analytics, 2016 14 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Consistency Guarantees Atomicity: no partial results Single System Image: same data regardless to the server connected Reliability: an update is persisted Timeliness: a client’s view can lack behind only a certain time Optional: sequential consistency Updates are applied in the order they are performed Note: znodes need to be marked as sequential if this is needed Reliability: Server failures are tolerated Quorum: Reliable as long as ceil(N/2) nodes are available Uses Paxos consensus protocols with atomic message transfer Julian M. Kunkel Lecture BigData Analytics, 2016 15 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Architecture: Updating Data [40] Writes are serialized to storage before applied to the in-memory db Writes are processed by an agreement protocol (Paxos) All writes are forwarded to the leader server Other servers receive message proposals and agree upon delivery Leader calculates when to apply the write and creates a transaction Source: ZooKeeper Components [40] Julian M. Kunkel Lecture BigData Analytics, 2016 16 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary 1 Introduction 2 Excursion: ZooKeeper 3 Architecture 4 Accessing Data 5 Summary Julian M. Kunkel Lecture BigData Analytics, 2016 17 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Distribution of Data [30] Use HDFS as backend to store data Utilize replication and place servers close to data Server (RegionServer) manage key ranges on a per table bases Buffer I/O to multiple files on HDFS Performs computation (and data filtering) Regions: base element for availability and distribution of tables One Store object per ColumnFamily One Memstore for each store to write data to files Multiple StoreFiles (HFile format) for each store (each sorted) Catalog Table HBase:meta (not splittable) Contains a list of all regions < table >, < regionstartkey >, < regionid > Table splitting Upon initialization of a table only one region is created Auto-Splitting: Based on a policy, a region is split into two Typical policy: split when the region is sufficiently large Increases parallelism, automatic scale-out Manual splitting can be triggered Julian M. Kunkel Lecture BigData Analytics, 2016 18 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Sharding of a Table into Regions Logical table Row keys RegionServers Server 1 Server2 Server3 aa… ab… ... Region 1 F... Keys A-F G… Region 2 H... Keys G-H I... Region 3 ... Keys I-M M... N... ... Region 4 Q... Keys N-Q R... ... Region 5 ZZ.. Keys R-Z Distribution of keys to servers, values are stored with the row Julian M. Kunkel Lecture BigData Analytics, 2016 19 / 37
Introduction Excursion: ZooKeeper Architecture Accessing Data Summary Storage Format [30] HFile format [35] Cell data is kept in store files on HDFS Multi-layered index with bloom filters and snapshot support Sorted by row key Append only, deletion writes key type with tombstone Compaction process merges multiple store files Record format. Source: [36] Julian M. Kunkel Lecture BigData Analytics, 2016 20 / 37
Showing the first 20 pages. Download the document to see it all.
No comments yet. Be the first!
Comments (0)
No comments yet. Be the first!