I85PREP
⌘ K
Cloudera CDP Data Analyst study materials
Cloudera CDP Data Analyst study resources

Cloudera CDP Data Analyst: Analytics on Apache Kudu and Apache HBase

Cloudera CDP Data Analyst · Work through your exam, one topic at a time.

All guide sections

Analytics on Apache Kudu and Apache HBase

Kudu and HBase are CDP's operational stores, and the exam tests the design constraints that make them fast or unusable: primary keys and partitioning in Kudu, rowkey design in HBase, and how Impala pushes predicates down to Kudu.

Kudu essentials

  • A primary key is mandatory and its columns must be declared first and cannot be null. Kudu tables are ordered by primary key, which makes range scans cheap.
  • Data is distributed with hash partitioning (spreads writes, e.g. HASH (id) PARTITIONS 16) and range partitioning (time-based retention, e.g. by created_date).
  • Supported DML from Impala: INSERT, UPDATE ... SET ... WHERE pk = ..., DELETE, and UPSERT. An UPDATE/DELETE must specify all primary key columns in the WHERE clause.
  • Kudu has no secondary indexes. Query performance depends on primary key and partition-column predicates; anything else is a full scan.
  • Kudu is a good fit for dimensions that are both updated in place and joined in Impala, and for tables needing low-latency single-row lookups with columnar scans.

HBase essentials

  • Pure key-value: one rowkey, column families, versioned cells, TTL. Access patterns are Get by rowkey and Scan over a rowkey range.
  • Rowkey design drives everything: monotonically increasing keys (timestamps, sequential IDs) hotspot one RegionServer. Salt or hash-prefix the key (e.g. substr(md5(id),1,2)||id) or reverse it.
  • Wide scans need start and stop rowkeys; without a prefix you scan the whole table.

Worked example

A 200M-row customer dimension must be upserted nightly and joined to fact tables in Impala dashboards.

CREATE TABLE cust (
  id BIGINT, created_date DATE, email STRING, region STRING,
  PRIMARY KEY (id, created_date)
)
PARTITION BY HASH (id) PARTITIONS 16, RANGE (created_date)
(
  PARTITION VALUES < '2025-01-01',
  PARTITION VALUES < '2026-01-01'
)
STORED AS KUDU;

Nightly loads use UPSERT INTO cust SELECT ... FROM stage; dashboard joins filter on id or created_date so Impala prunes partitions. A query filtering only on email scans every partition.

Traps

  • Issuing an UPDATE without the full primary key in WHERE - Impala rejects it.
  • Assuming Kudu supports secondary indexes or arbitrary INSERT OVERWRITE PARTITION.
  • Too few hash buckets on a high-write table: a single tablet becomes the bottleneck.
  • HBase full scans from a missing rowkey prefix, or hotspotting from sequential rowkeys.