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

Cloudera CDP Data Analyst: Data Analysis Foundations on CDP

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

All guide sections

Data Analysis Foundations on CDP

This domain tests whether you can choose the right CDP service, storage format, and table type for a workload, and whether you understand that Hive, Impala, Spark, and Kudu all resolve tables through one shared Hive Metastore.

The analyst stack in CDP

  • Storage: HDFS or Ozone files, or Kudu/HBase for operational data. Table definitions live in the Hive Metastore (HMS).
  • Engines: Hive on Tez (batch, spill-to-disk, fault tolerant), Impala (MPP, interactive, no mid-query recovery), Spark (ETL/ML), plus Kudu and HBase for row-level access.
  • Compute isolation: Cloudera Data Warehouse (CDW) virtual warehouses and Cloudera Data Engineering (CDE) virtual clusters give separate compute per workload while sharing data and metadata.

Table types and when each wins

  • External Parquet/ORC tables - the default for immutable, read-heavy analytical data: columnar, compressed, partition-pruned.
  • Hive ACID (transactional) tables - ORC-backed and bucketed, supporting UPDATE, DELETE, MERGE; the choice for slowly changing dimensions you must not rewrite wholesale.
  • Apache Iceberg - snapshot isolation, time travel, hidden partitioning; increasingly used for large mutable datasets.
  • Kudu - primary-key ordered, supports upserts and fast point or range scans; good when the same table must be updated and joined in Impala.
  • HBase - sparse key-value lookups by rowkey; no SQL joins.

Format rules of thumb: Parquet for wide aggregations and BI scans, Avro for row-oriented landing with schema evolution, ORC when Hive ACID or index-backed predicate pushdown matters.

Worked example

A 2 TB clickstream lands daily; five dashboards need event counts by page and country, refreshed hourly, with no post-load corrections. Choose an external Parquet table partitioned by dt (and country only if its cardinality is low), registered in HMS so Impala serves dashboards while Spark runs the loader. If the requirement changed to “fix 0.1% of rows in place every hour,” the correct move is Hive ACID, Iceberg, or Kudu - not rewriting partitions.

Traps

  • Assuming Impala can UPDATE/DELETE on plain Parquet tables - it needs a transactional format.
  • Confusing partitioning (directory pruning) with bucketing (hash files enabling efficient joins).
  • Forgetting MSCK REPAIR TABLE or ALTER TABLE ADD PARTITION after files land outside the engine.
  • Treating HDFS block size as the same thing as the small-files problem - it is the file count per partition that hurts.