Dask read_sql_table的meta参数出现LOCATION_ID__1合成列原因问询

合成列LOCATION_ID__1的产生原因 #

这个是你所用的 Dask 2021.4.1版本read_sql_table接口的已知历史处理逻辑导致的，触发条件是你同时做了两个操作：

• 给table参数传入的是自定义SQL查询语句，而非直接的数据库表名
• 显式指定了index_col="LOCATION_ID"作为索引列

旧版本Dask处理自定义查询作为数据源时，会默认把index_col对应的字段同时返回两份：一份作为Dask DataFrame的索引，另一份作为普通列追加到返回结果的所有原始列末尾。为了避免和索引重名，就自动给普通列里的重复字段加了后缀__1，就生成了你看到的LOCATION_ID__1合成列。这个列没有任何实际业务作用，完全是版本处理逻辑产生的冗余产物。

相关现象的解释 #

• 添加到列列表开头不生效、添加到末尾生效：Dask的元数据校验不仅会核对列名是否存在，还会核对列的顺序是否完全一致。这个合成列是被追加到查询返回的所有原始列末尾的，所以只有你把它加到cols列表的最后一位时，元数据的列顺序和实际返回的列顺序完全匹配，校验才会通过。
• 写入Parquet后不存在该列：你定义的空类型DataFrame里所有列默认是object类型，但实际LOCATION_ID__1的真实类型是int64，加上这个列本身是冗余的索引重复值，Dask在写入Parquet时默认会只保留有效索引和业务列，所以最终写入的文件里没有这个冗余列。

优化建议 #

• 条件允许的话可以把Dask升级到2021.06.0及以上版本，这个问题已经在后续版本修复，自定义查询指定index_col不会再生成重复的冗余列
• 如果暂时不能升级版本，读取完成后可以手动执行table_df = table_df.drop("LOCATION_ID__1", axis=1)删除冗余列之后再做后续处理，完全不影响数据准确性

内容的提问来源于stack exchange，提问作者Mark Kudryk