训练运行缓慢

[jxie8301-pixel]

现在数据加载是：
Qlib Bin (5000股 × N字段 = 5000*N次小文件I/O)
→ Python表达式引擎逐个计算N+特征
→ 全范围DataFrame全量物化 (5-10GB内存)
→ Processor截面标准化 (groupby+transform)
每次加载数据都要重新计算，导致整体上相当的慢，是否可以采用以下模式：

原始数据 → Parquet bucket shards (已计算好的特征)
→ manifest.parquet (symbol→bucket映射)
→ meta.json (特征名/日期范围)

训练加载 → 列裁剪 + 行过滤 + 批量读取
→ date→row_indices 倒排索引
→ rolling窗口直接按日期索引

[DarkLink]

您的瓶颈分析完全正确，尤其是 bin 文件 I/O 和表达式引擎逐字段计算这两块，也是我们注意到了的痛点。

这个方案的核心 tradeoff 是用灵活性换速度——预计算 Parquet + partitioned by date 之后，列裁剪和行过滤对 rolling 场景收益极大（同一个 feature set，不断滚日期窗口）。但代价是每次改特征定义就得重建整个 store。

目前我们还处在模型选型和特征集调优阶段（多个模型、多个 feature set 变体在并行实验， 整个rolling目前也只是功能具备我们还没有实际应用），配置还没收敛。如果现在就上 Parquet store，每次加一个表达式或调整标准化逻辑就要重跑 builder，现阶段工程优先级不高。

所以计划是这样的：

短期：继续用 Qlib 内置的 DiskExpressionCache / DiskDatasetCache 顶着，表达式级别的缓存至少能避免同一字段重复计算
中期：等模型阵容和特征集稳定下来，进入 rolling training 阶段时，按这个方案做一个 Parquet feature builder，一次性把最终特征集预计算好存下来
实现路径可以分两步走——先写独立的 builder 脚本（从 qlib bin 读原始数据 → 算特征 + 标准化 → 写 date-partitioned Parquet），再写一个新的 DataHandler 子类对接 Parquet store，这样不影响现有流程，可以独立验证收益
感谢提出这个方向，issue 先保留当作中期优化 roadmap。