Data Storage and Computation (MaxCompute)
MaxCompute organizes data into projects, then tables, with partitions as the primary pruning mechanism. Understand table types: internal tables (data managed by MaxCompute), external tables (metadata points at OSS or other storage), and partitioned versus non-partitioned tables. Partition keys are not ordinary columns - you filter on them to avoid full scans.
Computation runs as SQL or MapReduce jobs; the unit of billing and scheduling matters. Know that MaxCompute charges for storage and for compute (SQL jobs consume compute), and that Tunnel is the bulk data upload/download service, separate from SQL. Traps: candidates assume you can update rows freely (MaxCompute is append-oriented; transactional tables exist but are a specific feature), confuse INSERT INTO with INSERT OVERWRITE (overwrite replaces the partition), and forget that DISTRIBUTE BY/SORT BY and joins on skewed keys cause long tails. Small-file problems and missing partition filters are classic performance traps.
SQL semantics to internalize: GROUP BY with COUNT(DISTINCT ...), window functions, and LEFT JOIN null behavior. A frequent question asks why a query scans the whole table - usually a missing partition predicate or a non-equality join.
Worked example: a table orders partitioned by dt. To rebuild one day, use INSERT OVERWRITE TABLE orders PARTITION (dt='2024-01-01') SELECT ... WHERE dt='2024-01-01'. Using INSERT INTO would duplicate rows.
Rule of thumb: always filter on the partition key; use OVERWRITE to replace, INTO to append; push heavy joins onto distributed keys to avoid skew.