QPAD导出与q程序生成CSV的大小差异原因及优化方案

问题背景 #

• 从QPAD中使用“Export all as CSV”导出含嵌套日期（'D'）、符号（'S'）列表列的q表，文件大小仅22MB；
• 用q代码:path.csv 0: csv 0: table`导出同一份数据，文件大小达496MB，数据内容一致；
• 为解决CSV解析嵌套列的问题，使用自定义函数{$$[1=count x;string first x;$" "sv string x]}`处理嵌套列，但导致文件体积剧增；
• 移除3个嵌套列表列后，导出文件大小显著降低，但无法用ungroup方法处理这类列；
• 后续发现QPAD导出存在数据截断情况，对此存在担忧。

解答 #

1. QPAD处理嵌套'D'/'S'列的逻辑 #

QPAD导出CSV时，针对嵌套的日期/符号列表列采用了更紧凑的序列化策略：

• 嵌套日期列（D$()类型）：直接存储日期的底层整数表示（如2024.01.01对应整数19726），而非转为字符串格式；
• 嵌套符号列（S$()类型）：保留符号的原始紧凑格式，不会逐个转为字符串再拼接；
• 关键优化：对重复的嵌套值做字典编码/压缩，相同的嵌套列表仅存储一次，后续通过索引引用，这是体积大幅缩小的核心原因。

2. 程序中实现类似紧凑导出的方法 #

要在q代码中实现低体积导出，需针对嵌套列做针对性处理，避免全量字符串转换：

• 处理嵌套日期列：提取底层整数存储，导入时再转回日期：

  // 转换嵌套日期列为整数列表
  processNestedDate:{[col] @[col; where type each col=10h; {x}]} // 10h为日期类型type值
  

  导入时用D$将整数转回日期即可。
• 处理嵌套符号列：直接存储符号文本，导入时转回符号：

  // 转换嵌套符号列为文本列表
  processNestedSym:{[col] @[col; where type each col=11h; {string x}]} // 11h为符号类型type值
  

  导入时用$将文本转回符号。
• 启用内置压缩：导出时使用-1作为文件句柄参数，启用gzip压缩，进一步缩小体积：

  // 带压缩导出处理后的表
  :-1`:path.csv 0: csv 0: update nestedDateCol:processNestedDate[nestedDateCol], nestedSymCol:processNestedSym[nestedSymCol] from table
  

  压缩后的文件体积会接近QPAD导出的大小，且无数据丢失。

3. QPAD数据截断问题的应对 #

QPAD导出截断多因默认设置了行数或列宽限制，可通过以下方式解决：

• 调整QPAD导出设置：找到“Export”选项中的“Max rows”“Truncate long values”设置，取消限制或调大阈值；
• 优先用q代码导出：通过代码可完全控制数据范围，避免人为设置的截断限制，同时结合上述压缩方法，兼顾体积与数据完整性。

内容的提问来源于stack exchange，提问作者Alex R.