ACA Big Data common mistakes
ACA Big Data · Understand the traps and how to avoid them.
Treating MaxCompute tables as if they were row-store OLTP tables and expecting point-row UPDATE/DELETE and low-latency single-row lookups to behave like a relational database.
Candidates carry over RDBMS mental models and miss that MaxCompute is a columnar, append-oriented, batch compute engine where full-table scans are cheap but row-level mutation is expensive or requires special handling.
What to do instead
Memorize MaxCompute's storage/compute separation and columnar batch model, and map each workload type (point lookup, bulk transform, incremental update) to the correct product (e.g., transactional/OLTP store vs. MaxCompute) before answering.
Confusing DataWorks node scheduling concepts - assuming a node runs immediately on save, or mixing up the roles of scheduling dependencies, baseline, and instance status.
The DataWorks operations model (submit vs. commit vs. publish, upstream/downstream dependencies, instance generation, rerun/backfill) is unique to the platform and is learned only by reading the operations documentation, not from general workflow knowledge.
What to do instead
Build a mental timeline: develop → commit → publish to scheduling → generate instances per cycle → run when dependencies satisfied. Practice distinguishing 'failed instance', 'blocked instance', and 'not-yet-generated instance'.
Assuming the default MaxCompute project setting allows public data sharing or cross-project access without explicitly granting permissions, and answering as if any user can read any table.
Candidates underestimate Alibaba Cloud's layered authorization (RAM, project-level roles, table-level ACLs, package sharing) and assume a permissive default.
What to do instead
Learn the permission chain: RAM identity → project membership/role → object-level grants/ACLs → package (cross-project sharing). For any access question, verify each layer is satisfied before concluding access is allowed.
Mixing up the purposes of DataWorks Data Integration (batch sync) and real-time synchronization / streaming products, choosing a batch sync task for a scenario that requires sub-minute latency.
The product names and overlapping capabilities are easy to conflate, and candidates optimize for 'it can move data' rather than the latency and trigger semantics required.
What to do instead
Classify the requirement first: batch/periodic, CDC real-time, or stream computation. Then map to the specific tool. Memorize which tool supports which source/sink and latency profile.
Answering streaming questions as if a stream job guarantees exactly-once end-to-end by default, or ignoring how state, checkpointing, and watermarks affect correctness.
Candidates know the words 'exactly-once' and 'checkpoint' but not the conditions under which they hold, so they pick the most optimistic answer.
What to do instead
For every streaming question, identify the delivery guarantee at each stage (source, processing, sink) and the role of state/checkpoint/watermark. Only claim end-to-end exactly-once when the sink is transactional/idempotent.
Treating partitioning and clustering keys as interchangeable, or choosing a partition key that produces skew (e.g., partitioning on a low-cardinality or unevenly distributed column).
Candidates focus on 'partitioning is good for performance' without reasoning about data distribution, small-file problems, and scan pruning.
What to do instead
For each design question, evaluate cardinality, skew, and query filter patterns. Partition on high-selectivity, evenly distributed, commonly filtered columns; use clustering for secondary filter/join columns.
Confusing RAM users, RAM roles, and Alibaba Cloud accounts when answering security/operations questions, and assuming a RAM user automatically inherits all account-level data permissions.
Identity vs. permission vs. resource ownership are separate concepts, and the exam tests whether you know which entity is being authenticated and authorized.
What to do instead
Draw the identity hierarchy (account → RAM user/role → policy) and remember that policies grant API/action permissions while data-object access is granted separately in the data service. Check both for every access scenario.
Reading a visualization/dashboard question as purely aesthetic and ignoring the underlying query cost and data freshness implications of the chosen chart or dataset.
Candidates separate 'BI' from 'data engineering' and forget that dashboards are backed by queries against MaxCompute or accelerated engines, with real-time vs. scheduled refresh trade-offs.
What to do instead
For analytics questions, always connect the visual requirement to the data source, refresh cadence, and query cost. Choose accelerated/imported datasets for high-concurrency dashboards and direct query for freshness.
Assuming a failed DataWorks or MaxCompute job can always be fixed by simply rerunning it, without checking idempotency, downstream impact, and whether partial output was already written.
Candidates treat rerun as a universal remedy and overlook that non-idempotent writes or already-consumed downstream instances can cause duplication or inconsistency.
What to do instead
Before recommending rerun/backfill, verify the task is idempotent (overwrite or partition-replace), identify affected downstream instances, and confirm whether upstream data has changed.
Memorizing product names and marketing one-liners without being able to map a business scenario (e.g., log analysis, recommendation, real-time risk control) to the correct combination of Alibaba Cloud Big Data products.
The fundamentals domain rewards architectural judgment, but candidates study isolated product facts instead of end-to-end reference architectures, so scenario questions expose the gap.
What to do instead
Build 3–4 reference architectures (batch data warehouse, real-time pipeline, log analytics, BI serving) and practice placing each product into ingest, store, compute, schedule, and serve layers.