What is hbase master

In Linux and Unix, the number of processes is set using the ulimit -u command. This should not be confused with the nproc command, which controls the number of CPUs available to a given user.

Under load, a ulimit -u that is too low can cause OutOfMemoryError exceptions. Configuring the maximum number of file descriptors and processes for the user who is running the HBase process is an operating system configuration, rather than an HBase configuration. It is also important to be sure that the settings are changed for the user that actually runs HBase.

Refer to the man page for limits. In the following example, the first line sets both soft and hard limits for the number of open files nofile to for the operating system user with the username hadoop. The second line sets the number of processes to for the same user.

The following table summarizes the versions of Hadoop supported with each version of HBase. Older versions not appearing in this table are considered unsupported and likely missing necessary features, while newer versions are untested but may be suitable. Based on the version of HBase, you should select the most appropriate version of Hadoop. No distinction is made here. See the Hadoop wiki for information about vendors of Hadoop. Hadoop 2. HBase does not support running with earlier versions of Hadoop.

See the table below for requirements specific to different HBase versions. Hadoop 3. Starting around the time of Hadoop version 2. As such, HBase expressly advises downstream users to avoid running on top of these releases.

Note that additionally the 2. For reference, see the release announcements for Apache Hadoop 2. The Hadoop PMC called out the 3. As such, HBase expressly advises downstream users to avoid running on top of this release. For reference, see the release announcement for Hadoop 3. Because HBase depends on Hadoop, it bundles Hadoop jars under its lib directory. The bundled jars are ONLY for use in stand-alone mode.

In distributed mode, it is critical that the version of Hadoop that is out on your cluster match what is under HBase. Replace the hadoop jars found in the HBase lib directory with the equivalent hadoop jars from the version you are running on your cluster to avoid version mismatch issues. Make sure you replace the jars under HBase across your whole cluster.

Hadoop version mismatch issues have various manifestations. Check for mismatch if HBase appears hung. Not having this configuration in place makes for strange-looking failures. One manifestation is a complaint about missing blocks.

For example:. See also casestudies. An Apache ZooKeeper quorum is required. The exact version depends on your version of HBase, though the minimum ZooKeeper version is 3. HBase has two run modes: standalone and distributed. Out of the box, HBase runs in standalone mode. Whatever your mode, you will need to configure HBase by editing files in the HBase conf directory.

In this file you set HBase environment variables such as the heapsize and other options for the JVM , the preferred location for log files, etc. This is the default mode. Standalone mode is what is described in the quickstart section. ZooKeeper binds to a well-known port so clients may talk to HBase.

A sometimes useful variation on standalone hbase has all daemons running inside the one JVM but rather than persist to the local filesystem, instead they persist to an HDFS instance. You might consider this profile when you are intent on a simple deploy profile, the loading is light, but the data must persist across node comings and goings.

Writing to HDFS where data is replicated ensures the latter. To configure this standalone variant, edit your hbase-site. The pseudo-distributed vs. A quickstart has been added to the quickstart chapter. See quickstart-pseudo. Some of the information that was originally in this section has been moved there.

A pseudo-distributed mode is simply a fully-distributed mode run on a single host. Use this HBase configuration for testing and prototyping purposes only.

Do not use this configuration for production or for performance evaluation. By default, HBase runs in stand-alone mode. Both stand-alone mode and pseudo-distributed mode are provided for the purposes of small-scale testing. For a production environment, distributed mode is advised.

In distributed mode, multiple instances of HBase daemons run on multiple servers in the cluster. Just as in pseudo-distributed mode, a fully distributed configuration requires that you set the hbase. Typically, the hbase. These configuration basics are all demonstrated in quickstart-fully-distributed.

Typically, your cluster will contain multiple RegionServers all running on different servers, as well as primary and backup Master and ZooKeeper daemons. Each host is on a separate line. All hosts listed in this file will have their RegionServer processes started and stopped when the master server starts or stops. A cluster that is used for real-world work would contain more custom configuration parameters. Most HBase configuration directives have default values, which are used unless the value is overridden in the hbase-site.

See " Configuration Files " for more information. The backup Master instances will sit idle unless the main Master becomes unavailable. See quickstart-fully-distributed for a walk-through of a simple three-node cluster configuration with multiple ZooKeeper, backup HMaster, and RegionServer instances. Of note, if you have made HDFS client configuration changes on your Hadoop cluster, such as configuration directives for HDFS clients, as opposed to server-side configurations, you must use one of the following methods to enable HBase to see and use these configuration changes:.

Add a copy of hdfs-site. An example of such an HDFS client configuration is dfs. If for example, you want to run with a replication factor of 5, HBase will create files with the default of 3 unless you do the above to make the configuration available to HBase. Make sure HDFS is running first. You can ensure it started properly by testing the put and get of files into the Hadoop filesystem. These do not need to be started. You should now have a running HBase instance. HBase logs can be found in the logs subdirectory.

Check them out especially if HBase had trouble starting. HBase also puts up a UI listing vital attributes. If the Master is running on a host named master. Once HBase has started, see the shell exercises section for how to create tables, add data, scan your insertions, and finally disable and drop your tables. Shutdown can take a moment to complete. It can take longer if your cluster is comprised of many machines.

If you are running a distributed operation, be sure to wait until HBase has shut down completely before stopping the Hadoop daemons.

For the list of configurable properties, see hbase default configurations below or view the raw hbase-default. Not all configuration options make it out to hbase-default. Some configurations would only appear in source code; the only way to identify these changes are through code review. The documentation below is generated using the default hbase configuration file, hbase-default.

Temporary directory on the local filesystem. The directory shared by region servers and into which HBase persists. The URL should be 'fully-qualified' to include the filesystem scheme. The mode the cluster will be in. Possible values are false for standalone mode and true for distributed mode. Comma separated list of servers in the ZooKeeper ensemble This config. For example, "host1. By default this is set to localhost for local and pseudo-distributed modes of operation.

For a fully-distributed setup, this should be set to a full list of ZooKeeper ensemble servers. Client-side, we will take this list of ensemble members and put it together with the hbase. These WAL cleaners are called in order, so put the cleaner that prunes the most files in front. Always add the above default log cleaners in the list.

The value is in milliseconds. These HFiles cleaners are called in order, so put the cleaner that prunes the most files in front.

Always add the above default hfile cleaners in the list as they will be overwritten in hbase-site. Whether or not the Master listens to the Master web UI port hbase. Splitting a region, how long to wait on the file-splitting step before aborting the attempt. Default: This setting used to be known as hbase. Split is now run master-side hence the rename If a 'hbase.

Enables automatic port search if hbase. Useful for testing, turned off by default. Same property is used by the Master for count of master handlers. Too many handlers can be counter-productive. Make it a multiple of CPU count. If mostly read-only, handlers count close to cpu count does well. Start with twice the CPU count and tune from there. Factor to determine the number of call queues. A value of 0 means a single queue shared between all the handlers.

A value of 1 means that each handler has its own queue. Split the call queues into read and write queues. The specified interval which should be between 0. A value of 0 indicate to not split the call queues, meaning that both read and write requests will be pushed to the same set of queues. A value lower than 0. A value of 0. A value greater than 0. A value of 1.

Example: Given the total number of call queues being 10 a read. Given the number of read call queues, calculated from the total number of call queues multiplied by the callqueue. Example: Given the total number of read call queues being 8 a scan.

The number of consecutive WAL close errors we will allow before triggering a server abort. A setting of 0 will cause the region server to abort if closing the current WAL writer fails during log rolling.

Even a small value 2 or 3 will allow a region server to ride over transient HDFS errors. Maximum size of all memstores in a region server before new updates are blocked and flushes are forced. Updates are blocked and flushes are forced until size of all memstores in a region server hits hbase.

The default value in this configuration has been intentionally left empty in order to honor the old hbase. Maximum size of all memstores in a region server before flushes are forced. Determines the type of memstore to be used for system tables like META, namespace tables etc. By default NONE is the type and hence we use the default memstore for all the system tables. Maximum amount of time an edit lives in memory before being automatically flushed.

Default 1 hour. Set it to 0 to disable automatic flushing. The host name or IP address of the name server DNS which a region server should use to determine the host name used by the master for communication and display purposes.

A split policy determines when a region should be split. DisabledRegionSplitPolicy blocks manual region splitting. Limit for the number of regions after which no more region splitting should take place. This is not hard limit for the number of regions but acts as a guideline for the regionserver to stop splitting after a certain limit.

Default is set to ZooKeeper session timeout in milliseconds. It is used in two different ways. First, this value is used in the ZK client that HBase uses to connect to the ensemble.

So, even though HBase might propose using 90 seconds, the ensemble can have a max timeout lower than this and it will take precedence. The host name or IP address of the name server DNS which a ZooKeeper server should use to determine the host name used by the master for communication and display purposes. Port used by ZooKeeper peers to talk to each other. Port used by ZooKeeper for leader election.

The number of ticks that the initial synchronization phase can take. The number of ticks that can pass between sending a request and getting an acknowledgment. Limit on number of concurrent connections at the socket level that a single client, identified by IP address, may make to a single member of the ZooKeeper ensemble. Set high to avoid zk connection issues running standalone and pseudo-distributed.

Default size of the BufferedMutator write buffer in bytes. For an estimate of server-side memory-used, evaluate hbase. General client pause value. Used mostly as value to wait before running a retry of a failed get, region lookup, etc.

See hbase. Set this property to a higher value than hbase. Maximum retries. Retry interval is a rough function based on hbase. At first we retry at this interval but then with backoff, we pretty quickly reach retrying every ten seconds.

Change this setting and hbase. The maximum number of concurrent mutation tasks a single HTable instance will send to the cluster. The maximum number of concurrent mutation tasks a single HTable instance will send to a single region server. The maximum number of concurrent mutation tasks the client will maintain to a single Region. That is, if there is already hbase. The max number of concurrent pending requests for one server in all client threads process level.

If you use a fix number of threads to access HBase in a synchronous way, set this to a suitable value which is related to the number of threads will help you. Number of rows that we try to fetch when calling next on a scanner if it is not served from local, client memory. This configuration works together with hbase. The default value is Integer. If you know ahead of time that you will not require more than a certain number of rows from a scan, this configuration should be set to that row limit via Scan setCaching.

Higher caching values will enable faster scanners but will eat up more memory and some calls of next may take longer and longer times when the cache is empty. Do not set this value such that the time between invocations is greater than the scanner timeout; i.

Specifies the combined maximum allowed size of a KeyValue instance. This is to set an upper boundary for a single entry saved in a storage file. Since they cannot be split it helps avoiding that a region cannot be split any further because the data is too large.

It seems wise to set this to a fraction of the maximum region size. Setting it to zero or less disables the check. Maximum allowed size of an individual cell, inclusive of value and all key components. A value of 0 or less disables the check. The default value is 10MB. This is a safety setting to protect the server from OOM situations. This is maximum number of iterations to atomic bulk loads are attempted in the face of splitting operations 0 means never give up.

Request Compaction after bulkload immediately. If bulkload is continuous, the triggered compactions may increase load, bring about performance side effect. The max percent of regions in transition when balancing. The default value is 1. So there are no balancer throttling. If set this config to 0. The default value of this parameter is 0. This config is used to set default behaviour of normalizer at table level. In master side, this config is the period used for FS related behaviors: checking if hdfs is out of safe mode, setting or checking hbase.

Using default value should be fine. In regionserver side, this config is used in several places: flushing check interval, compaction check interval, wal rolling check interval. Specially, admin can tune flushing and compaction check interval by hbase. It determines the flushing check period of PeriodicFlusher in regionserver.

If unset, it uses hbase. It determines the compaction check period of CompactionChecker in regionserver. How many times to retry attempting to write a version file before just aborting. Each attempt is separated by the hbase. Memstore will be flushed to disk if size of the memstore exceeds this number of bytes. Value is checked by a thread that runs every hbase.

If FlushLargeStoresPolicy is used and there are multiple column families, then every time that we hit the total memstore limit, we find out all the column families whose memstores exceed a "lower bound" and only flush them while retaining the others in memory.

The "lower bound" will be "hbase. If none of the families have their memstore size more than lower bound, all the memstores will be flushed just as usual. If the memstores in a region are this size or larger when we go to close, run a "pre-flush" to clear out memstores before we put up the region closed flag and take the region offline. On close, a flush is run under the close flag to empty memory. During this time the region is offline and we are not taking on any writes.

If the memstore content is large, this flush could take a long time to complete. The preflush is meant to clean out the bulk of the memstore before putting up the close flag and taking the region offline so the flush that runs under the close flag has little to do.

Block updates if memstore has hbase. Useful preventing runaway memstore during spikes in update traffic. Without an upper-bound, memstore fills such that when it flushes the resultant flush files take a long time to compact or split, or worse, we OOME. Enables the MemStore-Local Allocation Buffer, a feature which works to prevent heap fragmentation under heavy write loads. This can reduce the frequency of stop-the-world GC pauses on large heaps.

The amount of off-heap memory all MemStores in a RegionServer may use. Unit: megabytes. Maximum file size. Time between major compactions, expressed in milliseconds. Set to 0 to disable time-based automatic major compactions. User-requested and size-based major compactions will still run. This value is multiplied by hbase. The default value is 7 days, expressed in milliseconds. If major compactions are causing disruption in your environment, you can configure them to run at off-peak times for your deployment, or disable time-based major compactions by setting this parameter to 0, and run major compactions in a cron job or by another external mechanism.

A multiplier applied to hbase. The smaller the number, the closer the compactions will happen to the hbase. Larger values delay compaction, but when compaction does occur, it takes longer to complete.

The number of flush threads. With fewer threads, the MemStore flushes will be queued. With more threads, the flushes will be executed in parallel, increasing the load on HDFS, and potentially causing more compactions.

If more than this number of StoreFiles exist in any one Store one StoreFile is written per flush of MemStore , updates are blocked for this region until a compaction is completed, or until hbase. The time for which a region will block updates after reaching the StoreFile limit defined by hbase. After this time has elapsed, the region will stop blocking updates even if a compaction has not been completed.

The minimum number of StoreFiles which must be eligible for compaction before compaction can run. The goal of tuning hbase. Setting this value to 2 would cause a minor compaction each time you have two StoreFiles in a Store, and this is probably not appropriate. If you set this value too high, all the other values will need to be adjusted accordingly. For most cases, the default value is appropriate empty value here, results in 3 by code logic.

In previous versions of HBase, the parameter hbase. The maximum number of StoreFiles which will be selected for a single minor compaction, regardless of the number of eligible StoreFiles. Effectively, the value of hbase. Setting it larger means that more StoreFiles are included in a compaction.

For most cases, the default value is appropriate. A StoreFile or a selection of StoreFiles, when using ExploringCompactionPolicy smaller than this size will always be eligible for minor compaction.

HFiles this size or larger are evaluated by hbase. Because this limit represents the "automatic include" limit for all StoreFiles smaller than this value, this value may need to be reduced in write-heavy environments where many StoreFiles in the MB range are being flushed, because every StoreFile will be targeted for compaction and the resulting StoreFiles may still be under the minimum size and require further compaction.

If this parameter is lowered, the ratio check is triggered more quickly. This addressed some issues seen in earlier versions of HBase but changing this parameter is no longer necessary in most situations. Default: MB expressed in bytes.

The effect of raising hbase. If you feel that compaction is happening too often without much benefit, you can try raising this value. Default: the value of LONG. For minor compaction, this ratio is used to determine whether a given StoreFile which is larger than hbase. Its effect is to limit compaction of large StoreFiles.

The value of hbase. A large ratio, such as 10, will produce a single giant StoreFile. Conversely, a low value, such as. A moderate value of between 1.

When tuning this value, you are balancing write costs with read costs. Raising the value to something like 1. However, during reads, HBase will need to seek through fewer StoreFiles to accomplish the read.

Consider this approach if you cannot take advantage of Bloom filters. Otherwise, you can lower this value to something like 1. Allows you to set a different by default, more aggressive ratio for determining whether larger StoreFiles are included in compactions during off-peak hours.

Works in the same way as hbase. Only applies if hbase. The amount of time to delay purging of delete markers with future timestamps. If unset, or set to 0, all delete markers, including those with future timestamps, are purged during the next major compaction.

The start of off-peak hours, expressed as an integer between 0 and 23, inclusive. Set to -1 to disable off-peak. The end of off-peak hours, expressed as an integer between 0 and 23, inclusive. There are two different thread pools for compactions, one for large compactions and the other for small compactions. This helps to keep compaction of lean tables such as hbase:meta fast.

If a compaction is larger than this threshold, it goes into the large compaction pool. In most cases, the default value is appropriate.

Default: 2 x hbase. The value field assumes that the value of hbase. Setting it to true helps prevent minor compactions from polluting the page cache, which is most beneficial on clusters with low memory to storage ratio or very write heavy clusters.

You may want to set it to false under moderate to low write workload when bulk of the reads are on the most recently written data. The maximum number of KeyValues to read and then write in a batch when flushing or compacting. Enables StoreFileScanner parallel-seeking in StoreScanner, a feature which can reduce response latency under special conditions. Percentage of maximum heap -Xmx setting to allocate to block cache used by a StoreFile. Default of 0. This allows to put non-root multi-level index blocks into the block cache at the time the index is being written.

When the size of a leaf-level, intermediate-level, or root-level index block in a multi-level block index grows to this size, the block is written out and a new block is started. Where to store the contents of the bucketcache. One of: offheap, file, files, mmap or pmem. Allows you to tune the minimum available compaction throughput when the PressureAwareCompactionThroughputController throughput controller is active.

It is active by default. Allows you to control aggregate compaction throughput demand when the PressureAwareCompactionThroughputController throughput controller is active. The maximum throughput will be tuned between the lower and upper bounds when compaction pressure is within the range [0. If compaction pressure is 1. A comma-separated list of sizes for buckets for the bucketcache. Can be multiple sizes.

List block sizes in order from smallest to largest. The sizes you use will depend on your data access patterns. Must be a multiple of else you will run into 'java. The HFile format version to use for new files. Also see the configuration 'hbase. The size in bytes of a single block "chunk" of a compound Bloom filter.

This size is approximate, because Bloom blocks can only be inserted at data block boundaries, and the number of keys per data block varies. This is for the RPC layer to define how long millisecond HBase client applications take for a remote call to time out. It uses pings to check connections but will eventually throw a TimeoutException.

Operation timeout is a top-level restriction millisecond that makes sure a blocking operation in Table will not be blocked more than this. In each operation, if rpc request fails because of timeout or other reason, it will retry until success or throw RetriesExhaustedException.

But if the total time being blocking reach the operation timeout before retries exhausted, it will break early and throw SocketTimeoutException. The number of cells scanned in between heartbeat checks. Heartbeat checks occur during the processing of scans to determine whether or not the server should stop scanning in order to send back a heartbeat message to the client. Heartbeat messages are used to keep the client-server connection alive during long running scans.

Small values mean that the heartbeat checks will occur more often and thus will provide a tighter bound on the execution time of the scan. Larger values mean that the heartbeat checks occur less frequently. This is another version of "hbase. For those RPC operation within cluster, we rely on this configuration to set a short timeout limitation for short operation. Set no delay on rpc socket connections. When set to a non-empty value, this represents the external facing hostname for the underlying server.

When set to true, regionserver will use the current node hostname for the servername and HMaster will skip reverse DNS lookup and use the hostname sent by regionserver instead. Note that this config and hbase. Full path to the kerberos keytab file to use for logging in the configured HMaster server principal.

The kerberos principal name that should be used to run the HMaster process. Full path to the kerberos keytab file to use for logging in the configured HRegionServer server principal.

The kerberos principal name that should be used to run the HRegionServer process. An entry for this principal must exist in the file specified in hbase. The policy configuration file used by RPC servers to make authorization decisions on client requests. Only used when HBase security is enabled. List of users or groups comma-separated , who are allowed full privileges, regardless of stored ACLs, across the cluster.

HBase HMaster is a lightweight process that assigns regions to region servers in the Hadoop cluster for load balancing. Responsibilities of HMaster —. These are the worker nodes which handle read, write, update, and delete requests from clients. Region Server process, runs on every node in the hadoop cluster. HBase uses ZooKeeper as a distributed coordination service for region assignments and to recover any region server crashes by loading them onto other region servers that are functioning.

ZooKeeper is a centralized monitoring server that maintains configuration information and provides distributed synchronization.

Whenever a client wants to communicate with regions, they have to approach Zookeeper first. HMaster and Region servers are registered with ZooKeeper service, client needs to access ZooKeeper quorum in order to connect with region servers and HMaster. In case of node failure within an HBase cluster, ZKquoram will trigger error messages and start repairing failed nodes. ZooKeeper service keeps track of all the region servers that are there in an HBase cluster- tracking information about how many region servers are there and which region servers are holding which DataNode.

HMaster contacts ZooKeeper to get the details of region servers. Various services that Zookeeper provides include —. Understanding the fundamental of HBase architecture is easy but running HBase on top of HDFS in production is challenging when it comes to monitoring compactions, row key designs manual splitting, etc. If you would like to learn how to design a proper schema, derive query patterns and achieve high throughput with low latency then enrol now for comprehensive hands-on Hadoop Training.

Anything that is entered into the HBase is stored here initially. Later, the data is transferred and saved in Hfiles as blocks and the memstore is flushed.

Zookeeper is an open-source project that provides services like maintaining configuration information, naming, providing distributed synchronization, etc. Zookeeper has ephemeral nodes representing different region servers. Master servers use these nodes to discover available servers.

In addition to availability, the nodes are also used to track server failures or network partitions. HBase - Architecture Advertisements.