Cloudera CDP Data Analyst common mistakes
Cloudera CDP Data Analyst · Understand the traps and how to avoid them.
Writing queries that rely on Hive-style implicit type coercion and multi-insert or lateral view syntax, then submitting the same SQL for Impala questions where it fails or is rejected.
Candidates learn Hive first and assume Impala is a drop-in replacement. Impala has stricter typing, different function coverage (for example less mature complex-type handling and different string/regex functions), and no support for some Hive-only DDL and multi-table insert patterns. Under exam pressure they reuse familiar syntax without checking the engine.
What to do instead
Before answering, identify the engine named in the question. Build a small comparison table in your notes: supported DDL, complex type handling, functions, and transaction/ACID support. Practice rewriting the same query for both engines and note exactly which clause changes.
Treating Kudu and HBase as interchangeable key-value stores and proposing the wrong one for a given workload (for example recommending HBase for predicate-heavy analytical scans or Kudu for sparse, very wide, write-heavy schemas).
Both are often described only as 'NoSQL on Hadoop'. Candidates memorize that both support fast random access but miss Kudu's columnar design, primary key ranges, and SQL/Impala integration versus HBase's sparse column families, row-key-only indexing, and scan patterns.
What to do instead
Anchor each store to a design intent: Kudu for mutable row-level updates with columnar scans over a defined primary key and native SQL access; HBase for very large sparse tables with row-key-centric access and column families. For each scenario question, ask whether the access path is a key-range scan plus column projection (Kudu) or a pure row-key lookup/scan over sparse attributes (HBase).
Assuming a table's permissions are the whole story and ignoring column masking, row filtering, and tag-based policies when predicting query results or failures.
Ranger policies can be column-scoped and can apply dynamic masking or row-level filters. Candidates check only database/table SELECT grants and conclude a user sees all rows or all raw values, missing that the query succeeds but returns masked or filtered data.
What to do instead
When a question describes a user, a table, and a tag or column, enumerate three layers: object-level grants, column-level grants, and tag/row-filter policies. Decide separately whether the query is allowed and what data shape comes back. Remember masking yields success with altered values, while missing column privilege yields a denial.
Diagnosing slow queries by guessing at a single cause instead of reading the execution plan for exchange, join strategy, and scan volume, and instead proposing 'increase memory' as the fix.
Distributed engines fail for structural reasons: broadcast vs partitioned joins, skew, missing or stale statistics, small files, and over-broad scans. Candidates jump to resource settings because those are the settings they remember, without evidence from the plan.
What to do instead
Follow a fixed triage order: check the plan for the dominant operator, verify table and column statistics freshness, confirm partition pruning is happening, then look at join strategy and skew, and only then at memory and spill. For each symptom in a question, name the plan-level evidence that would confirm it before choosing a remedy.
Confusing partition columns with regular columns when filtering or loading data, and writing queries that scan all partitions or fail to produce partitions on write.
In Hive and Impala, partition columns are not stored inside the data files and behave differently in predicates and inserts. Candidates write a filter that prevents pruning (for example wrapping the partition column in a function) or omit the partition clause in dynamic partition inserts.
What to do instead
Treat partition columns as directory structure: filter them with direct equality or range comparisons so pruning applies, and always specify the partition clause on insert. Practice explaining why a function applied to a partition column disables pruning.
Answering Spark and CDE questions with local-mode, single-machine assumptions, ignoring how work is distributed across executors and how dependencies and resources are packaged for a job.
Analysts often use Spark through notebooks or SQL shells and never reason about partitions, shuffles, or job submission artifacts. Exam questions about CDE jobs, scheduling, and resource configuration then get answered as if the driver did all the work.
What to do instead
Learn the job anatomy: application, driver, executors, stages split at shuffles, and tasks per partition. For CDE, know what a job definition contains (artifact, entry point, resource configuration, schedule) and how dependencies are shipped. Predict behavior by asking where a shuffle occurs and how many partitions result.
Mixing up the roles of Ranger, Atlas, and the shared governance layer, attributing lineage to Ranger or access control to Atlas.
The products are introduced together as a governance stack, and candidates remember the acronyms without separating authorization from metadata and lineage. Questions that ask which component enforces a policy or records lineage then get answered by association rather than function.
What to do instead
Memorize one-line mandates: Ranger authorizes and audits access; Atlas catalogs technical metadata, lineage, and classifications; the shared layer ties tags and classifications to enforcement across services. For any question, first classify it as 'who may access' versus 'what is this data and where did it come from'.
Choosing visualization and BI connection approaches without matching them to concurrency, latency, and refresh requirements, for example recommending direct live queries against a batch table for a high-concurrency dashboard.
Candidates focus on whether a connection is technically possible rather than on the workload profile. They overlook that interactive engines suit ad hoc and moderate concurrency, while high-concurrency dashboards usually need an extract or an aggregation layer refreshed on a schedule.
What to do instead
For each BI scenario, write down concurrency, acceptable latency, and freshness. Then map: live interactive SQL for ad hoc and low-to-moderate concurrency; scheduled extracts or pre-aggregated tables for high-concurrency, low-latency dashboards. Justify the choice with the three numbers.
Treating nulls, deduplication, and late-arriving data as afterthoughts, producing counts and joins that silently drop or double-count records.
In distributed SQL, null semantics in joins and aggregates, plus duplicate rows from non-unique join keys, change results without errors. Candidates validate on small samples where duplicates and nulls happen not to appear.
What to do instead
Adopt a preparation checklist before writing the final query: profile key uniqueness, count nulls in join and filter columns, and decide explicit null handling. Use anti-join or left-join-with-null-check patterns to quantify unmatched rows, and verify row counts before and after each join.
Reading a scenario question as a general knowledge prompt instead of extracting the stated constraints, so the answer is defensible in the abstract but wrong for the described environment.
Exam scenarios embed decisive details such as engine version, data volume, update pattern, concurrency, or the specific user and tag. Candidates answer from memory of the technology in general and skip the constraint that eliminates the other options.
What to do instead
Before evaluating options, restate the scenario in one line: workload type, data shape, engine, access pattern, and the user or policy involved. Eliminate options that contradict a stated constraint, then choose among survivors. If two options remain, prefer the one that matches the named engine and access pattern.