This document provides an introduction to HBase internals and schema design for HBase users. It discusses the logical and physical views of HBase, including how tables are split into regions and stored across region servers. It covers best practices for schema design, such as using row keys efficiently and avoiding redundancy. The document also briefly discusses advanced topics like coprocessors and compression. The overall goal is to help HBase users optimize performance and scalability based on its internal architecture.
HBaseCon 2012 | HBase Schema Design - Ian Varley, SalesforceCloudera, Inc.
Most developers are familiar with the topic of “database design”. In the relational world, normalization is the name of the game. How do things change when you’re working with a scalable, distributed, non-SQL database like HBase? This talk will cover the basics of HBase schema design at a high level and give several common patterns and examples of real-world schemas to solve interesting problems. The storage and data access architecture of HBase (row keys, column families, etc.) will be explained, along with the pros and cons of different schema decisions.
ClickHouse Deep Dive, by Aleksei MilovidovAltinity Ltd
This document provides an overview of ClickHouse, an open source column-oriented database management system. It discusses ClickHouse's ability to handle high volumes of event data in real-time, its use of the MergeTree storage engine to sort and merge data efficiently, and how it scales through sharding and distributed tables. The document also covers replication using the ReplicatedMergeTree engine to provide high availability and fault tolerance.
This document provides an overview of NoSQL databases and compares them to relational databases. It discusses the different types of NoSQL databases including key-value stores, document databases, wide column stores, and graph databases. It also covers some common concepts like eventual consistency, CAP theorem, and MapReduce. While NoSQL databases provide better scalability for massive datasets, relational databases offer more mature tools and strong consistency models.
This talk delves into the many ways that a user has to use HBase in a project. Lars will look at many practical examples based on real applications in production, for example, on Facebook and eBay and the right approach for those wanting to find their own implementation. He will also discuss advanced concepts, such as counters, coprocessors and schema design.
HBaseCon 2012 | Lessons learned from OpenTSDB - Benoit Sigoure, StumbleUponCloudera, Inc.
OpenTSDB was built on the belief that, through HBase, a new breed of monitoring systems could be created, one that can store and serve billions of data points forever without the need for destructive downsampling, one that could scale to millions of metrics, and where plotting real-time graphs is easy and fast. In this presentation we’ll review some of the key points of OpenTSDB’s design, some of the mistakes that were made, how they were or will be addressed, and what were some of the lessons learned while writing and running OpenTSDB as well as asynchbase, the asynchronous high-performance thread-safe client for HBase. Specific topics discussed will be around the schema, how it impacts performance and allows concurrent writes without need for coordination in a distributed cluster of OpenTSDB instances.
Storm is a distributed and fault-tolerant realtime computation system. It was created at BackType/Twitter to analyze tweets, links, and users on Twitter in realtime. Storm provides scalability, reliability, and ease of programming. It uses components like Zookeeper, ØMQ, and Thrift. A Storm topology defines the flow of data between spouts that read data and bolts that process data. Storm guarantees processing of all data through its reliability APIs and guarantees no data loss even during failures.
Introduction and Overview of Apache Kafka, TriHUG July 23, 2013mumrah
Apache Kafka is a distributed publish-subscribe messaging system that allows both publishing and subscribing to streams of records. It uses a distributed commit log that provides low latency and high throughput for handling real-time data feeds. Key features include persistence, replication, partitioning, and clustering.
Apache HBase is the Hadoop opensource, distributed, versioned storage manager well suited for random, realtime read/write access. This talk will give an overview on how HBase achieve random I/O, focusing on the storage layer internals. Starting from how the client interact with Region Servers and Master to go into WAL, MemStore, Compactions and on-disk format details. Looking at how the storage is used by features like snapshots, and how it can be improved to gain flexibility, performance and space efficiency.
Hadoop Meetup Jan 2019 - Dynamometer and a Case Study in NameNode GCErik Krogen
Erik Krogen of LinkedIn presents regarding Dynamometer, a system open sourced by LinkedIn for scale- and performance-testing HDFS. He discusses one major use case for Dynamometer, tuning NameNode GC, and discusses characteristics of NameNode GC such as why it is important, and how it interacts with various current and future GC algorithms.
This is taken from the Apache Hadoop Contributors Meetup on January 30, hosted by LinkedIn in Mountain View.
This document provides an overview and introduction to NoSQL databases. It begins with an agenda that explores key-value, document, column family, and graph databases. For each type, 1-2 specific databases are discussed in more detail, including their origins, features, and use cases. Key databases mentioned include Voldemort, CouchDB, MongoDB, HBase, Cassandra, and Neo4j. The document concludes with references for further reading on NoSQL databases and related topics.
This document discusses MongoDB sharding concepts including when to scale out a database using sharding, how sharding works, and considerations for choosing a shard key. It explains that sharding partitions data across multiple servers to improve scalability and performance. It also contrasts sharding with replication, which is for high availability rather than scaling. A good shard key should have high cardinality, match common queries, and randomly distribute writes. Hashed shard keys can help with some issues but have limitations.
Apache Hive is a rapidly evolving project which continues to enjoy great adoption in the big data ecosystem. As Hive continues to grow its support for analytics, reporting, and interactive query, the community is hard at work in improving it along with many different dimensions and use cases. This talk will provide an overview of the latest and greatest features and optimizations which have landed in the project over the last year. Materialized views, the extension of ACID semantics to non-ORC data, and workload management are some noteworthy new features.
We will discuss optimizations which provide major performance gains, including significantly improved performance for ACID tables. The talk will also provide a glimpse of what is expected to come in the near future.
Salvatore Sanfilippo – How Redis Cluster works, and why - NoSQL matters Barce...NoSQLmatters
Salvatore Sanfilippo – How Redis Cluster works, and why
In this talk the algorithmic details of Redis Cluster will be exposed in order to show what were the design tensions in the clustered version of an high performance database supporting complex data type, the selected tradeoffs, and their effect on the availability and consistency of the resulting solution.Other non-chosen solutions in the design space will be illustrated for completeness.
This document provides an agenda and introduction for a presentation on Apache Cassandra and DataStax Enterprise. The presentation covers an introduction to Cassandra and NoSQL, the CAP theorem, Apache Cassandra features and architecture including replication, consistency levels and failure handling. It also discusses the Cassandra Query Language, data modeling for time series data, and new features in DataStax Enterprise like Spark integration and secondary indexes on collections. The presentation concludes with recommendations for getting started with Cassandra in production environments.
The document summarizes a meetup about NoSQL databases hosted by AWS in Sydney in 2012. It includes an agenda with presentations on Introduction to NoSQL and using EMR and DynamoDB. NoSQL is introduced as a class of databases that don't use SQL as the primary query language and are focused on scalability, availability and handling large volumes of data in real-time. Common NoSQL databases mentioned include DynamoDB, BigTable and document databases.
This document summarizes a talk about Facebook's use of HBase for messaging data. It discusses how Facebook migrated data from MySQL to HBase to store metadata, search indexes, and small messages in HBase for improved scalability. It also outlines performance improvements made to HBase, such as for compactions and reads, and future plans such as cross-datacenter replication and running HBase in a multi-tenant environment.
The document discusses Facebook's use of HBase as the database storage engine for its messaging platform. It provides an overview of HBase, including its data model, architecture, and benefits like scalability, fault tolerance, and simpler consistency model compared to relational databases. The document also describes Facebook's contributions to HBase to improve performance, availability, and achieve its goal of zero data loss. It shares Facebook's operational experiences running large HBase clusters and discusses its migration of messaging data from MySQL to a de-normalized schema in HBase.
Facebook uses HBase running on HDFS to store messaging data and metadata. Key reasons for choosing HBase include high write throughput, horizontal scalability, and integration with HDFS. Typical clusters have multiple regions and racks for redundancy. Facebook stores small messages, metadata, and attachments in HBase, while larger messages and attachments are stored separately. The system processes billions of read and write operations daily and continues to optimize performance and reliability.
Hw09 Practical HBase Getting The Most From Your H Base InstallCloudera, Inc.
The document summarizes two presentations about using HBase as a database. It discusses the speakers' experiences using HBase at Stumbleupon and Streamy to replace MySQL and other relational databases. Some key points covered include how HBase provides scalability, flexibility, and cost benefits over SQL databases for large datasets.
- MapR makes it easy to deploy and run HBase in production by providing high availability, data protection, and disaster recovery features out of the box. This includes setting up hourly snapshots and cross-datacenter mirroring with just a few commands.
- With MapR, all HBase data should be stored in a single volume called "hbase.volume" for easy management. Snapshots are taken of this volume to enable consistent backups with no downtime. The snapshots can be mirrored to other clusters for disaster recovery.
- Memory usage on RegionServers is automatically tuned by MapR's Warden service based on configuration. The defaults generally work well but guidelines are provided for tuning in large deployments.
This document contains information about HBase concepts and configurations. It discusses different modes of HBase operation including standalone, pseudo-distributed, and distributed modes. It also covers basic prerequisites for running HBase like Java, SSH, DNS, NTP, ulimit settings, and Hadoop for distributed mode. The document explains important HBase configuration files like hbase-site.xml, hbase-default.xml, hbase-env.sh, log4j.properties, and regionservers. It provides details on column-oriented versus row-oriented databases and discusses optimizations that can be made through configuration settings.
HBase is an open-source, distributed, versioned, column-oriented NoSQL database that is modeled after Google's Bigtable. It is built on top of Hadoop and HDFS for storage, and uses ZooKeeper for coordination between nodes. HBase provides big data scalability and handles failures through its master-slave architecture and write-ahead logging. Data is stored in tables as rows and columns, with columns grouped into column families for scalability.
The document discusses NHN Japan's use of HBase for the LINE messaging platform's storage infrastructure. Some key points:
- HBase is used to store tens of billions of message rows per day for LINE, achieving sub-10ms response times and high availability through dual clusters.
- The presentation covers their experience migrating HBase clusters between data centers online, handling NameNode failures, and stabilizing the LINE message storage cluster.
- It describes the custom HBase replication and bulk data migration tools developed by NHN Japan to support online cluster migrations without downtime. Failure handling and cluster stabilization techniques are also discussed.
The document discusses PostgreSQL high availability and scaling options. It covers horizontal scaling using load balancing and data partitioning across multiple servers. It also covers high availability techniques like master-slave replication, warm standby servers with point-in-time recovery, and using a heartbeat to prevent multiple servers from becoming a master. The document recommends an initial architecture with two servers using warm standby and point-in-time recovery with a heartbeat for high availability. It suggests scaling the application servers horizontally later on if more capacity is needed.
HBase is an open-source, distributed, versioned, key-value database modeled after Google's Bigtable. It is designed to store large volumes of sparse data across commodity hardware. HBase uses Hadoop for storage and provides real-time read and write capabilities. It scales horizontally and is highly fault tolerant through its master-slave architecture and use of Zookeeper for coordination. Data in HBase is stored in tables and indexed by row keys for fast lookup, with columns grouped into families and versions stored by timestamps.
HBase is a distributed, column-oriented database that runs on top of Hadoop and HDFS, providing Bigtable-like capabilities for massive tables of structured and unstructured data. It is modeled after Google's Bigtable and provides a distributed, scalable, versioned storage system with strong consistency for random read/write access to billions of rows and millions of columns. HBase is well-suited for handling large datasets and providing real-time read/write access across clusters of commodity servers.
Some of the common interview questions asked during a Big Data Hadoop Interview. These may apply to Hadoop Interviews. Be prepared with answers for the interview questions below when you prepare for an interview. Also have an example to explain how you worked on various interview questions asked below. Hadoop Developers are expected to have references and be able to explain from their past experiences. All the Best for a successful career as a Hadoop Developer!
This document provides an overview of HBase, including:
- HBase is a distributed, scalable, big data store modeled after Google's BigTable. It provides a fault-tolerant way to store large amounts of sparse data.
- HBase is used by large companies to handle scaling and sparse data better than relational databases. It features automatic partitioning, linear scalability, commodity hardware, and fault tolerance.
- The document discusses HBase operations, schema design best practices, hardware recommendations, alerting, backups and more. It provides guidance on designing keys, column families and cluster configuration to optimize performance for read and write workloads.
HDFS was originally designed for MapReduce workloads like large streaming writes and reads. However, HBase has additional requirements like small random reads, high concurrency, and durable record appends that HDFS does not optimally support. Engineers from HBase, Facebook, Cloudera, and Yahoo are working to address these issues through configuration tuning, HBase-side workarounds, and HDFS patches. Upcoming releases of CDH will integrate necessary HDFS patches to better meet HBase's needs.
The document is a presentation about Panasas storage for Saudi Aramco. It begins with an agenda that covers understanding the Panasas storage technique, its technical details, common error traces, and problem solving. It then provides bullet points on starting the session, the terminology used, how Panasas works, and fault fixing methods. The presentation defines key Panasas components like blades, directors, volumes, and snapshots. It explains how data is stored across object storage devices and reconstructed in the event of failures. Methods for upgrading, generating core dumps, and analyzing logs are also overviewed.
The document provides an overview of the Hadoop architecture including its core components like HDFS for distributed storage, MapReduce for distributed processing, and an explanation of how data is stored in blocks and replicated across nodes in the cluster. Key aspects of HDFS such as the namenode, datanodes, and secondary namenode functions are described as well as how Hadoop implementations like Pig and Hive provide interfaces for data processing.
The document discusses scalability and provides an overview of key concepts for scaling systems. It defines scalability as the ability to handle growing amounts of work in a capable manner. There are two main types of scalability: vertical, which involves getting bigger resources; and horizontal, which involves adding more resources. The document outlines several rules for scalability and discusses strategies for scaling different parts of the system like databases, caching, load balancing, and asynchronous operations.
Hadoop is a distributed processing framework for large datasets. It stores data across clusters of commodity hardware in a Hadoop Distributed File System (HDFS) and provides tools for distributed processing using MapReduce. HDFS uses a master-slave architecture with a namenode managing metadata and datanodes storing data blocks. Data is replicated across nodes for reliability. MapReduce allows distributed processing of large datasets in parallel across clusters.
Introduction to HBase. HBase is a NoSQL databases which experienced a tremendous increase in popularity during the last years. Large companies like Facebook, LinkedIn, Foursquare are using HBase. In this presentation we will address questions like: what is HBase?, and compared to relational databases?, what is the architecture?, how does HBase work?, what about the schema design?, what about the IT ressources?. Questions that should help you consider whether this solution might be suitable in your case.
Optimization on Key-value Stores in Cloud EnvironmentFei Dong
This document discusses optimizing key-value stores like HBase in cloud environments. It introduces HBase, a distributed, column-oriented database built on HDFS that provides scalable storage and retrieval of large datasets. The document compares rule-based and cost-based optimization strategies, and explores using rule-based optimization to analyze HBase's performance when deployed on Amazon EC2 instances. It describes developing an HBase profiler to measure the costs of using HBase for storage.
Similar to Intro to HBase Internals & Schema Design (for HBase users) (20)
Discovery Series - Zero to Hero - Task Mining Session 1DianaGray10
This session is focused on providing you with an introduction to task mining. We will go over different types of task mining and provide you with a real-world demo on each type of task mining in detail.
Top 12 AI Technology Trends For 2024.pdfMarrie Morris
Technology has become an irreplaceable component of our daily lives. The role of AI in technology revolutionizes our lives for the betterment of the future. In this article, we will learn about the top 12 AI technology trends for 2024.
"Building Future-Ready Apps with .NET 8 and Azure Serverless Ecosystem", Stan...Fwdays
.NET 8 brought a lot of improvements for developers and maturity to the Azure serverless container ecosystem. So, this talk will cover these changes and explain how you can apply them to your projects. Another reason for this talk is the re-invention of Serverless from a DevOps perspective as a Platform Engineering trend with Backstage and the recent Radius project from Microsoft. So now is the perfect time to look at developer productivity tooling and serverless apps from Microsoft's perspective.
Increase Quality with User Access Policies - July 2024Peter Caitens
⭐️ Increase Quality with User Access Policies ⭐️, presented by Peter Caitens and Adam Best of Salesforce. View the slides from this session to hear all about “User Access Policies” and how they can help you onboard users faster with greater quality.
Garbage In, Garbage Out: Why poor data curation is killing your AI models (an...Zilliz
Enterprises have traditionally prioritized data quantity, assuming more is better for AI performance. However, a new reality is setting in: high-quality data, not just volume, is the key. This shift exposes a critical gap – many organizations struggle to understand their existing data and lack effective curation strategies and tools. This talk dives into these data challenges and explores the methods of automating data curation.
UiPath Community Day Amsterdam: Code, Collaborate, ConnectUiPathCommunity
Welcome to our third live UiPath Community Day Amsterdam! Come join us for a half-day of networking and UiPath Platform deep-dives, for devs and non-devs alike, in the middle of summer ☀.
📕 Agenda:
12:30 Welcome Coffee/Light Lunch ☕
13:00 Event opening speech
Ebert Knol, Managing Partner, Tacstone Technology
Jonathan Smith, UiPath MVP, RPA Lead, Ciphix
Cristina Vidu, Senior Marketing Manager, UiPath Community EMEA
Dion Mes, Principal Sales Engineer, UiPath
13:15 ASML: RPA as Tactical Automation
Tactical robotic process automation for solving short-term challenges, while establishing standard and re-usable interfaces that fit IT's long-term goals and objectives.
Yannic Suurmeijer, System Architect, ASML
13:30 PostNL: an insight into RPA at PostNL
Showcasing the solutions our automations have provided, the challenges we’ve faced, and the best practices we’ve developed to support our logistics operations.
Leonard Renne, RPA Developer, PostNL
13:45 Break (30')
14:15 Breakout Sessions: Round 1
Modern Document Understanding in the cloud platform: AI-driven UiPath Document Understanding
Mike Bos, Senior Automation Developer, Tacstone Technology
Process Orchestration: scale up and have your Robots work in harmony
Jon Smith, UiPath MVP, RPA Lead, Ciphix
UiPath Integration Service: connect applications, leverage prebuilt connectors, and set up customer connectors
Johans Brink, CTO, MvR digital workforce
15:00 Breakout Sessions: Round 2
Automation, and GenAI: practical use cases for value generation
Thomas Janssen, UiPath MVP, Senior Automation Developer, Automation Heroes
Human in the Loop/Action Center
Dion Mes, Principal Sales Engineer @UiPath
Improving development with coded workflows
Idris Janszen, Technical Consultant, Ilionx
15:45 End remarks
16:00 Community fun games, sharing knowledge, drinks, and bites 🍻
Demystifying Neural Networks And Building Cybersecurity ApplicationsPriyanka Aash
In today's rapidly evolving technological landscape, Artificial Neural Networks (ANNs) have emerged as a cornerstone of artificial intelligence, revolutionizing various fields including cybersecurity. Inspired by the intricacies of the human brain, ANNs have a rich history and a complex structure that enables them to learn and make decisions. This blog aims to unravel the mysteries of neural networks, explore their mathematical foundations, and demonstrate their practical applications, particularly in building robust malware detection systems using Convolutional Neural Networks (CNNs).
The Challenge of Interpretability in Generative AI Models.pdfSara Kroft
Navigating the intricacies of generative AI models reveals a pressing challenge: interpretability. Our blog delves into the complexities of understanding how these advanced models make decisions, shedding light on the mechanisms behind their outputs. Explore the latest research, practical implications, and ethical considerations, as we unravel the opaque processes that drive generative AI. Join us in this insightful journey to demystify the black box of artificial intelligence.
Dive into the complexities of generative AI with our blog on interpretability. Find out why making AI models understandable is key to trust and ethical use and discover current efforts to tackle this big challenge.
Self-Healing Test Automation Framework - HealeniumKnoldus Inc.
Revolutionize your test automation with Healenium's self-healing framework. Automate test maintenance, reduce flakes, and increase efficiency. Learn how to build a robust test automation foundation. Discover the power of self-healing tests. Transform your testing experience.
TrustArc Webinar - Innovating with TRUSTe Responsible AI CertificationTrustArc
In a landmark year marked by significant AI advancements, it’s vital to prioritize transparency, accountability, and respect for privacy rights with your AI innovation.
Learn how to navigate the shifting AI landscape with our innovative solution TRUSTe Responsible AI Certification, the first AI certification designed for data protection and privacy. Crafted by a team with 10,000+ privacy certifications issued, this framework integrated industry standards and laws for responsible AI governance.
This webinar will review:
- How compliance can play a role in the development and deployment of AI systems
- How to model trust and transparency across products and services
- How to save time and work smarter in understanding regulatory obligations, including AI
- How to operationalize and deploy AI governance best practices in your organization
Finetuning GenAI For Hacking and DefendingPriyanka Aash
Generative AI, particularly through the lens of large language models (LLMs), represents a transformative leap in artificial intelligence. With advancements that have fundamentally altered our approach to AI, understanding and leveraging these technologies is crucial for innovators and practitioners alike. This comprehensive exploration delves into the intricacies of GenAI, from its foundational principles and historical evolution to its practical applications in security and beyond.
Intro to HBase Internals & Schema Design (for HBase users)
1. Intro to HBase
Internals &
Schema Design
(for HBase Users)
Alex Baranau, Sematext International, 2012
Monday, July 9, 12
2. About Me
Software Engineer at Sematext International
http://blog.sematext.com/author/abaranau
@abaranau
http://github.com/sematext (abaranau)
Monday, July 9, 12
4. Why?
Why should I (HBase user) care about
HBase internals?
HBase will not adjust cluster
settings to optimal based on usage
patterns automatically
Schema design, table settings
(defined upon creation), etc.
depend on HBase implementation
aspects
Monday, July 9, 12
6. Logical View: Regions
HBase cluster serves multiple tables, distinguished by
name
Each table contains of rows
Each row contains cells:
(row key, column family, column, timestamp) -> value
Table is split into Regions (table shards, each
contains full rows), defined by start and end row keys
Monday, July 9, 12
7. Logical View: Regions are
Shards
Regions are “atoms of distribution���
Each region assigned to single RegionServer
(HBase cluster slave)
Rows of particular Region served by single
RS (cluster slave)
Regions are distributed evenly across RSs
Region has configurable max size
When region reaches max size (or on request)
it is split into two smaller regions, which
can be assigned to different RSs
Monday, July 9, 12
8. Logical View: Regions on
Cluster
ZooKeeper
ZooKeeper
ZooKeeper
client HMaster
HMaster
Region Region
RegionServer
Region Region Region Region
RegionServer
RegionServer
RegionServer RegionServer
Monday, July 9, 12
9. Logical View: Regions Load
It is essential for Regions under the
load to be evenly distributed across
the cluster
It is HBase user’s job to make sure
the above is true. Note: even
distribution of Regions over cluster
doesn’t imply that the load is evenly
distributed
Monday, July 9, 12
10. Logical View: Regions Load
Take into account that rows are stored in ordered
manner
Make sure you don’t write rows with sequential
keys to avoid RS hotspotting*
When writing data with monotonically increasing/decreasing
keys, data is written at one RS at a time
Use pre-splitting of the table upon creation
Starting with single region means using one RS for some time
In general, splitting can be expensive
Increase max region size
* see https://github.com/sematext/HBaseWD
Monday, July 9, 12
11. Logical View: Slow RSs
When load is distributed evenly, watch for
slowest RSs (HBase slaves)
Since every region served by single RS,
one slow RS can slow down cluster
performance e.g. when:
data is written into multiple RSs at
even pace (random value-based row keys)
data is being read from many RSs when
doing scan
Monday, July 9, 12
13. Physical View: Write/Read Flow
HTable client client
buffer HTable
write read RegionServer
Region z Region ...
...
Store Store
MemStore MemStore
(per CF) (per CF)
flush
HFile HFile ... HFile HFile
Write Ahead Log
HDFS
Monday, July 9, 12
14. Physical: Speed up Writing
Enabling & increasing client-side buffer reduces RPC
operations amount
warn: possible loss of buffered data
in case of client failure; design for failover
in case of write failure (networking/server-
side issues); can be handled on client
Disabling WAL increases write speed
warn: possible data loss in case of RS failure
Use bulk import functionality (writes HFiles
directly, which can be later added to HBase)
Monday, July 9, 12
15. Physical: Memstore Flushes
When memstore is flushed N HFiles are created (one per
CF)
Memstore size which causes flushing is configured on
two levels:
per RS: % of heap occupied by memstores
per table: size in MB of single memstore (per CF)
of Region
When Region memstores flushes, memstores of all CFs
are flushed
Uneven data amount between CFs causes too many
flushes & creation of too many HFiles (one per CF
every time)
In most cases having one CF is the best design
Monday, July 9, 12
16. Physical: Memstore Flushes
Important: there are Memstore size
thresholds which cause writes to be blocked,
so slow memstore flushes and overuse of
memory by memstore can cause write perf
degradation
Hint: watch for flush queue size metric on
RSs
At the same time the more memory memstore
uses the better for writing/reading perf
(unless it reaches those “write blocking”
thresholds)
Monday, July 9, 12
17. Physical: Memstore Flushes
Example of good situation
*
* http://sematext.com/spm/index.html
Monday, July 9, 12
18. Physical: HFiles Compaction
HFiles are periodically compacted into bigger
HFiles containing same data
Reading from less HFiles faster
Important: there’s a configured max number of files
in Store which, when reached causes writes to block
Hint: watch for compaction queue size metric on
RSs
read Store
MemStore
(per CF)
HFile HFile
Monday, July 9, 12
19. Physical: Data Locality
RSs are usually collocated HDFS
with HDFS DataNodes MapReduce
HBase
RegionServer RegionServer
TaskTracker
TaskTracker
DataNode DataNode
Slave Node Slave Node
Monday, July 9, 12
20. Physical: Data Locality
HBase tries to assign Regions to RSs so that
Region data stored physically on the same node.
But sometimes fails
after Region splits there’s no guarantee that
there’s a node that has all blocks (HDFS level)
of new Region and
no guarantee that HBase will not re-assign this
Region to different RS in future (even
distribution of Regions takes preference over
data locality)
There’s an ongoing work towards better preserving
data locality
Monday, July 9, 12
21. Physical: Data Locality
Also, data locality can break when:
Adding new slaves to cluster
Removing slaves from cluster
Incl. node failures
Hint: look at networking IO between slaves when writing/reading
data, it should be minimal
Important:
make sure HDFS is well balanced (use balancer tool)
try to rebalance Regions in HBase cluster if possible (HBase
Master restart will do that) to regain data locality
Pre-split table on creation to limit (ideally avoid) splits
and regions movement; manage splits manually sometimes helps
Monday, July 9, 12
23. Schema: row keys
Using row key (or keys range) is the most
efficient way to retrieve the data from HBase
Row key design is major part of schema design
Note: no secondary indices available out of
the box
Row Key Data
‘login_2012-03-01.00:09:17’ d:{‘user’:‘alex’}
... ...
‘login_2012-03-01.23:59:35’ d:{‘user’:‘otis’}
‘login_2012-03-02.00:00:21’ d:{‘user’:‘david’}
Monday, July 9, 12
24. Schema: row keys
Redundancy is OK!
warn: changing two rows in HBase is not atomic operation
Row Key Data
‘login_2010-01-01.00:09:17’ d:{‘user’:‘alex’}
... ...
‘login_2012-03-01.23:59:35’ d:{‘user’:‘otis’}
‘alex_2010-01-01.00:09:17’ d:{‘action’:‘login’}
... ...
‘otis_2012-03-01.23:59:35’ d:{‘action’:‘login’}
‘alex_login_2010-01-01.00:09:17’ d:{‘device’:’pc’}
... ...
‘otis_login_2012-03-01.23:59:35’ d:{‘device’:‘mobile’}
Monday, July 9, 12
25. Schema: Relations
Not relational
No joins
Denormalization is OK! Use ‘nested entities’
Row Key Data
d:{
student_firstname:Alex,
student_lastname:Baranau,
student
professor_math_firstname:David,
* ‘student_abaranau’ professor_math_lastname:Smart,
* professor_cs_firstname:Jack,
professor professor_cs_lastname:Weird,
}
‘prof_dsmart’ d:{...}
Monday, July 9, 12
26. Schema: row key/CF/qual size
HBase stores cells individually
great for “sparse” data
row key, CF name and column name stored with each
cell which may affect data amount to be stored and
managed
keep them short
serialize and store many values into single cell
Row Key Data
d:{
s:Alex#Baranau#cs#2009,
‘s_abaranau’ p_math:David#Smart,
p_cs:Jack#Weird,
}
Monday, July 9, 12
28. Advanced: Co-Processors
CoProcessors API (HBase 0.92.0+) allows to:
execute (querying/aggregation/etc.)
logic on server side (you may think of
it as of stored procedures in RDBMS)
perform auditing of actions performed on
server-side (you may think of it as of
triggers in RDBMS)
apply security rules for data access
and many more cool stuff
Monday, July 9, 12
29. Other: Use Compression
Using compression:
reduces data amount to be stored on disks
reduces data amount to be transferred when RS reading data not
from local replica
increases amount of CPU used, but CPU isn’t usually a bottleneck
Favor compression speed over compression ratio
SNAPPY is good
Use wisely:
e.g. avoid wasting CPU cycles on compressing images
compression can be configured on per CF basis, so storing
non-compressible data in separate CF sometimes helps
data blocks are uncompressed in memory, avoid this to cause OOME
note: when scanning (seeking data to return for scan) many data
blocks can be uncompressed even if none of the data will be
returned from those block
Monday, July 9, 12
30. Other: Use Monitoring
TBD
Ganglia, Cacti, other*, Just use it!
* http://sematext.com/spm/index.html
Monday, July 9, 12