Loading... > 自己在写量化框架的时候, 对于课题<<回测与投研是自己写还是避免造轮子集成现有的成熟框架>>我前前后后研究了许多, 总结来看, 把时间成本当成主要考虑因素的话, 如果你达到了一定的编程水平就没必要自己再去实现了, 一个开源成熟的如backtarder这样的框架(速度快, 运行稳定, 扩展性很强, 功能最丰富), 不会出问题, 想怎么改自己可以在源码基础上就怎么改, 轻松的集成到自己的量化交易框架中, 而且bt经过了长时间的打磨, 非常稳定, 哪怕是踩到坑自己也能优化掉; > > 后续 -> 我打算写一个系列的文章用来记录集成bt时所遇到的小问题与采坑, 分享出来留给需要的人; * 本次分享内容: 1. 在接入clickhouse后, 测试加载数据的速度; 往往这块是Backtrader回测慢的诟病, 一个tick级别的回测光载入数据就好非常长的时间; 2. 针对max_block参数进行调优, 看看设置为什么样的值才能使得加载速度相对最快; `注意: 既然是性能测试, 这里需要声明一下硬件条件: ``macbookpro2019, 2.4 GHz 四核i5, 16gRAM, 500gSSD(random r/w 1800M/S左右)` 3. 最后, 再来看看使用ck来存储Tick级别数据所占用的存储空间 ## preload加载数据性能测试 * 数据原始大小100多万行, 20多列, 以时间为顺序, 加载其中的9列, 先上结果: ``` data: 452540 rows, time_cost: 0:00:18.143022 data: 1034066 rows, time_cost: 0:00:38.903254 ``` **结论 -> 基本上, 百万行的加载速度是30多秒, 也就是说30多秒后就开始执行回测逻辑了;** ## max_block参数调优 * ck在读取大数量的时候, 不建议一次性读完, 而是分块read block by block, 这里有个每次最大max_block参数的设定, 设为多少合适? 数据量保持不变, 先上测试结果: ``` # total data: 452540 rows # max_1 0:03:54.581788 # max_1000 0:00:14.383140 # max_100000 0:00:18.143022 # max_500000 0:00:15.151686 0:00:14.700034 # max_1000000 0:00:13.714196 # max_5000000 0:00:13.502082 # total rows: 1034066 rows # max_1 # max_1000 # max_100000 0:00:38.903254 # max_1000000 0:00:33.330855 # max_5000000 0:00:34.929998 ``` **结论 -> max_block的值刚好超过你要读取的数据量为可以达到相对最快的速度; 例如: 百万行, 设为100w** ## Tick级别数据的存储量 * 结论:**启用lz4压缩存储百万行的Tick数据, 20多列, 只占用10MB! 原始大小130MB**  © 允许规范转载