Cloudera CDP Data Analyst study materials
Cloudera CDP Data Analyst study resources

Cloudera CDP Data Analyst: Data Visualization and BI Integration

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

All guide sections

Data Visualization and BI Integration

This domain tests how BI tools connect to CDP, where aggregation actually happens, and why dashboards return different numbers than SQL run directly. Expect questions on Impala/Hive connectivity, Knox, Kerberos, direct-query versus extract, and Cloudera Data Visualization.

Connection paths

  • External BI tools (Tableau, Power BI, Looker) connect to HiveServer2 (Hive) or the Impala daemon via JDBC/ODBC drivers, using the host, port (21050 Impala, 10000 HiveServer2), and authentication mechanism.
  • With Kerberos, the driver needs the principal and, for HTTP transport, the matching HTTP/_HOST principal - a common misconfiguration when a JDBC connection hangs.
  • Apache Knox provides a single proxied gateway; connecting through Knox changes the host, port, and URL path, so an otherwise-correct connection string fails.
  • Cloudera Data Visualization consumes datasets over Impala/Hive, supports parameters, filters, and dashboard apps inside the platform.

Direct query versus extract

  • Direct query pushes SQL, filters, and aggregation to Impala, so results are live and partition pruning applies. Requires low-latency engines and stable concurrency.
  • Extract copies rows into the BI engine. Fast interaction, but a SELECT * of raw detail moves enormous volumes and does not benefit from CDP-side aggregation.
  • Aggregation should happen as close to the data as possible; a dashboard asking for daily totals over 4 billion rows should issue a GROUP BY dt, ... query, not pull detail rows.

Worked example

A Tableau extract over events takes 6 hours and produces a 300 GB hyper file. The dashboard only shows counts by event_type and country for the last 90 days. Reasoning: the extract pulled unaggregated detail without a partition filter. Fix: define the connection as a custom SQL aggregate with WHERE dt >= current_date - 90 and GROUP BY dt, event_type, country, letting Impala scan only 90 partitions. Extract size drops to a few hundred MB and refresh time to minutes.

Traps

  • Assuming BI-level filters push down when the workbook uses an extract - the filters run after data is copied.
  • Mismatched numbers caused by Ranger column masking or row filters applying to the BI user but not to the analyst's own query.
  • Choosing Hive rather than Impala for an interactive dashboard.
  • Forgetting REFRESH/INVALIDATE METADATA after loads, so the dashboard shows stale rows.
  • Overlooking session or result-set limits in the driver, which truncate large result sets silently.