COLLECT_LIST保留重复元素和插入顺序，不自动去重或排序，NULL值正常收集，支持复杂类型，但大数据量易OOM，需谨慎评估是否需全量聚合。
COLLECT_LIST 会保留重复元素和插入顺序
Spark SQL 的 COLLECT_LIST 不是去重操作，它按数据实际到达的分区和行序把值攒成数组，相同值多次出现就会多次出现在结果里。如果你需要去重，得额外套一层 ARRAY_DISTINCT 或改用 COLLECT_SET ——但后者不保证顺序。
常见错误是误以为 COLLECT_LIST 等价于 Python 的 set() 或 SQL 的 DISTINCT，结果聚合后发现数组里一堆重复项，还纳闷“为什么没自动 dedup”。
- 它在 shuffle 阶段按分组 key 拉取所有匹配行，不做任何过滤或排序预处理
- 若上游用了
ORDER BY（比如在窗口函数中），顺序可被控制；但单纯GROUP BY+COLLECT_LIST不保证全局顺序 - 空值（
NULL）会被正常收集进数组，不会跳过
在 GROUP BY 场景下直接使用 COLLECT_LIST
这是最常见用法：对每组生成一个元素列表。注意列名必须明确，不能写 *，且非聚合列必须出现在 GROUP BY 子句中。
SELECT user_id, COLLECT_LIST(item_id) AS items FROM events GROUP BY user_id
如果想让列表按时间排序，得先排序再聚合：
SELECT user_id, COLLECT_LIST(item_id) AS items FROM ( SELECT user_id, item_id FROM events ORDER BY event_time ) t GROUP BY user_id
- 子查询里的
ORDER BY在 Spark 中仅对单个 task 有效，跨 partition 仍不保序；更稳妥的做法是用窗口函数加ROW_NUMBER标序号，再在外层按序号排序后聚合 - 若
item_id是字符串类型，结果数组元素类型自动推导为array<string></string>；数值列同理，类型一致 - 遇到内存压力大时（比如某 user_id 关联百万级 item_id），
COLLECT_LIST可能触发 OOM，此时应考虑采样或限制长度
用 COLLECT_LIST 处理嵌套结构或复杂类型
它支持结构体（struct）、map、甚至其他 array 类型。例如把多行属性打包成结构体列表：
SELECT user_id,
COLLECT_LIST(NAMED_STRUCT('category', category, 'score', score)) AS preferences
FROM user_scores
GROUP BY user_id
结果是 array<struct<category:string,score:double>>。这种写法比拼 JSON 字符串更安全，下游可用 TRANSFORM 或字段访问符（如 preferences.category）进一步展开。
- 结构体内字段名必须合法（不能含空格或特殊符号），否则报错
Invalid column reference - 如果某行中
category为NULL，整个 struct 仍被加入数组，只是对应字段为NULL - 嵌套太深（比如 array of struct of array）会让序列化开销明显上升，执行计划里能看到
SerializeFromObject耗时突增
性能与替代方案：什么时候不该用 COLLECT_LIST
当分组后单条输出的数组长度超过几万，或者总数据量超亿级时，COLLECT_LIST 很容易成为瓶颈。它的本质是把分布式数据全拉到一个 task 做合并，反向放大 shuffle 压力。
- 替代思路一：用
STRING_AGG拼接成字符串（更省内存，但失去类型信息） - 替代思路二：用
AGGREGATE+ 自定义初始值和合并逻辑，控制中间状态大小（比如只保留 top-N） - 替代思路三：改用广播 join + 预聚合表，把集合构建提前到 ETL 阶段，查询时直接读物化结果
真正难的不是写对语法，而是判断“这个列表到底要不要全量收集”——业务上是否真的需要全部 item_id？还是只需要计数、最大值、最近三个？多数时候，原始需求里藏着过度聚合的假设。
