Apache HBase® on the
Stackable Data Platform

Simply change the desired replica count in your HBaseCluster CRD and apply it. The operator adds or removes RegionServer pods and rebalances regions automatically, so the cluster can absorb higher load or reduce footprint without manual intervention.

Perform rolling upgrades by bumping the version in the CRD. The operator restarts components in a safe order (RegionServers first, then Masters), keeping the cluster available while moving to the new version – subject to any upstream upgrade notes.

Yes. Authentication is handled via Kerberos; with Stackable you store keytabs and principals as Kubernetes Secrets (managed by the Secret Operator), and the operator wires the JAAS configuration into the HBase components. Combine this with TLS to encrypt traffic between clients, RegionServers and Masters.

Yes. Superset supports fine-grained role-based acceHow do I secure HBase?ss control (RBAC). Permissions can be assigned to roles, which you then map to users or groups. With Stackable’s operator, these policies can be managed declaratively and version-controlled, which makes it easier to enforce security boundaries across multiple teams.

Yes. The operator supports HA Masters, automatic Region re-assignment on failures, and Kubernetes best practices like PodDisruptionBudgets, anti-affinity and persistent volumes. This gives you failover and high availability with predictable day-2 operations (upgrades, scaling, monitoring).

HBase is designed to run on HDFS. In Kubernetes you typically run HDFS (backed by persistent volumes) as part of the platform. Azure Data Lake Storage (ADLS) is also supported as a full replacement for HDFS. S3 (via Hadoop S3A) can be used for snapshot export, backups, and bulk data movement.

Use snapshots and the built-in ExportSnapshot utilities for fast, consistent backups of tables or namespaces. You can ship snapshots to external storage (e.g. HDFS or S3-compatible object storage) and complement this with replication for DR scenarios.

Yes. Metrics are exposed for Prometheus, and ready-made Grafana dashboards show cluster health, RPC latency, block cache effectiveness, compactions, region states and more. This gives operators real-time visibility and alerting out of the box.

Use NiFi or Kafka for ingestion and streaming pipelines, then query HBase data via Trino (through the Phoenix connector) or Apache Phoenix directly for SQL access. For dashboards, connect Superset to Trino/Phoenix to visualize results while HBase serves low-latency reads and writes underneath.

Yes. Spark can read from and write to HBase using the HBase client/connector (or via Phoenix for SQL semantics). This is ideal for batch processing, feature generation for ML and complex transformations that complement HBase’s real-time access patterns.

Use the HBase shell or client APIs to create or alter tables and column families. Many changes can be applied online; some properties require a brief disable/enable cycle. In GitOps setups, keep your table definitions and policies version-controlled so schema changes are reviewed and repeatable.

Yes, HBase stores byte arrays and handles sparse, wide tables well. For very large blobs, a common pattern is to store the object in an object store and keep a pointer or metadata in HBase; this keeps cell sizes efficient and read paths fast.

HBase is optimized for low-latency random reads/writes and operational/time-series workloads (OLTP-style). For interactive SQL analytics, pair HBase with Trino (via Phoenix) or Spark. This gives you the best of both worlds: fast operational access in HBase and powerful analytical queries via the SQL/compute layer.

The operator has been tested on major managed and self-hosted Kubernetes platforms: EKS, AKS, GKE, OpenShift, IONOS and K3s. This flexibility lets you deploy HBase reliably across cloud providers or on-premise infrastructure, while still benefiting from declarative management and operator automation.