21天驯化AI打工仔 - SQEP 的性能再优化
Table of Content
在量化交易的世界里,数据就像是血液,而数据传输系统则是血管。一个高效的数据传输系统可以让整个量化交易平台如虎添翼,而低效的数据传输则会成为整个系统的瓶颈。
当我正为 SQEP(Standard Quotes Exchange Protocol)的性能优化绞尽脑汁时,我的 AI 助手 007 敲了敲我的"虚拟门"。
前言:数据传输的艺术¶
我:「007,我们的 SQEP 系统需要进一步优化了。我们需要决定是使用 JSON 还是 CSV 格式,还要确定最佳的批处理大小。你有什么想法吗?」
007:「BOSS,这正是我的专长!数据传输格式的选择和批处理大小的优化是提升系统性能的关键。我建议我们进行一系列基准测试,用数据说话。」
我:「听起来不错。那我们就从分析 JSON 和 CSV 格式的性能差异开始吧。」
007:「没问题!我已经准备好了测试方案。我们将测试序列化、反序列化、Redis 操作等多个维度,全方位评估两种格式的性能。」
于是,我们开始了这场数据传输优化之旅,一场关于毫秒和字节的较量...
1. SQEP-BAR-MINITE 的 JSON 和 CSV 性能测试¶
在量化交易系统中,分钟级别的 K 线数据(BAR-MINUTE)是非常重要的数据源。与日线数据相比,分钟线数据没有复权因子,但基本结构相似。
我们面临的第一个问题是:应该使用 JSON 格式(带 key)还是 CSV 格式(不带 key)来传输这些数据?
我:「007,我在想,既然 SQEP 是一个固定结构的协议,字段顺序是固定的,那么也许我们不需要在每条记录中都带上字段名(key)?」
007:「这是个好问题!从理论上讲,CSV 格式应该更节省空间,因为它不需要重复存储字段名。但 JSON 的优势在于它的灵活性和自描述性。我们需要通过实际测试来确定哪种格式在我们的场景中更高效。」
测试前的分析¶
我们决定设计一个全面的基准测试,比较 JSON 和 CSV 在以下几个方面的性能: 1. 序列化速度 2. 反序列化速度 3. 数据大小 4. Redis 操作性能(LPUSH 和 RPOP)
为了确保测试的公平性,我们使用相同的数据结构,包含以下字段:
字段名 | 数据类型 | 说明 |
---|---|---|
symbol | int | 股票代码。使用整型编码以提高性能(关于 str 和 int 类型在查询性能上的差异,可以回顾上一章节) |
frame | datetime.date | 交易日期 |
open | float64 | 开盘价 |
high | float64 | 最高价 |
low | float64 | 最低价 |
close | float64 | 收盘价 |
vol | float64 | 成交量 |
amount | float64 | 成交额 |
Tip
SQEP-BAR-MINITE 相比较于 SQEP-BAR-DAY,没有复权因子。
测试代码¶
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
007:「我已经设计好了测试框架,我们将使用 fast_json 库处理 JSON 数据,使用 pandas 处理 CSV 数据。」
我:「为什么选择 fast_json 而不是 Python 内置的 json 库?」
007:「fast_json 库在处理大量数据时性能更好,特别是在序列化和反序列化操作上。在量化交易系统中,性能是关键,所以我们应该选择最高效的工具。」
我们首先实现了数据生成函数,确保测试数据符合实际场景;然后运行了全面的基准测试,测试了不同数据量(从 100 条到 10000 条记录)下的性能表现,007 提供的完整代码如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 |
|
测试结果分析¶
JSON 和 CSV 在不同数据量下的性能对比:
数据量 | JSON序列化时间(ms) | CSV序列化时间(ms) | JSON反序列化时间(ms) | CSV反序列化时间(ms) | JSON大小(KB) | CSV大小(KB) | JSON LPUSH时间(ms) | CSV LPUSH时间(ms) | JSON RPOP时间(ms) | CSV RPOP时间(ms) |
---|---|---|---|---|---|---|---|---|---|---|
100 | 2.00 | 2.29 | 2.55 | 1.21 | 15.46 | 6.57 | 1.80 | 1.36 | 2.27 | 1.29 |
500 | 3.61 | 3.73 | 2.71 | 1.13 | 77.32 | 32.89 | 4.15 | 3.83 | 3.16 | 1.79 |
1000 | 6.77 | 6.43 | 4.87 | 1.70 | 154.62 | 65.75 | 7.63 | 6.93 | 6.03 | 2.44 |
5000 | 30.56 | 25.60 | 21.67 | 5.53 | 773.33 | 329.00 | 39.55 | 36.25 | 34.53 | 11.34 |
10000 | 61.26 | 58.02 | 37.16 | 8.45 | 1546.31 | 657.63 | 73.39 | 67.77 | 58.91 | 24.30 |
100000 | 582.51 | 550.17 | 389.43 | 76.75 | 15462.17 | 6576.42 | 791.27 | 681.79 | 611.95 | 216.75 |
1000000 | 6517.40 | 5434.37 | 5952.10 | 715.37 | 154633.64 | 65766.45 | 7434.51 | 6936.94 | 6358.97 | 2422.53 |
JSON 和 CSV 序列化和反序列化的时间对比图:
JSON 和 CSV Redis 操作(LPUSH 和 RPOP+反序列化)的时间对比图:
JSON 和 CSV 数据大小的对比图:
我:「这些结果真是令人惊讶!CSV 在几乎所有测试中都表现得比 JSON 好,特别是在数据大小和反序列化性能方面。」
007:「是的,CSV 格式的数据大小只有 JSON 的约 42%,这是因为 CSV 不需要存储字段名和额外的语法字符。在反序列化性能上,CSV 比 JSON 快 3-4 倍,这对于高频交易系统来说是非常显著的优势。」
我:「但我也注意到,在小数据量的序列化测试中,JSON 似乎略快于 CSV。」
007:「没错,这是因为 JSON 序列化可以直接操作 Python 对象,而 CSV 序列化需要处理 DataFrame 的行列结构。但随着数据量增加,这种优势逐渐减弱,在大数据量下两者性能接近。」
2. batch_size 测试¶
在确定了 CSV 格式的优势后,我们进一步探索了批处理大小(batch_size
)对性能的影响。
我:「007,在实际应用中,我们通常会批量处理数据。批处理大小会对性能产生什么影响?」
007:「这是个很好的问题。批处理大小太小会导致频繁的网络通信和序列化/反序列化操作,增加开销;批处理大小太大则可能导致内存压力和响应延迟。我们需要找到一个平衡点。」
测试代码¶
我们设计了一个新的测试,固定总数据量为 100 万条记录,测试不同批处理大小(1、10、100、1000、10000)下的性能表现,007 提供的代码如下:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 |
|
局部优化测试代码的运行速度¶
在训练过程中,我们发现 batch_size = 1
时,测试代码运行的速度会非常慢。经过对代码的解读,主要影响到运行速度的是代码中的 benchmark_redis_operations
函数的准备批次数据的部分,具体是下面的代码:
1 2 3 4 |
|
我们考虑到的优化方法:直接使用 df 进行测试,不再构造 dfs。
注意到,这里我们测试了两种方法:
json_str = self.serialize_json(df.iloc[i:i+batch_size])
:速度慢,推送 1000 条的时间约为 0.7065sjson_str = df.iloc[i:i+batch_size].to_json()
:速度较快,推送 1000 条的时间约为 0.2415s
所以我们采用了第二种 to_json
的方式来加速我们的测试进度。同理,to_csv
也采用了类似的方式(但是我们不用修改代码,因为原代码 serialize_csv
函数中已经使用了 to_csv
)。
测试结果分析¶
测试结果显示,批处理大小对性能有显著影响。
批处理大小 | JSON LPUSH时间(ms) | CSV LPUSH时间(ms) | JSON RPOP时间(ms) | CSV RPOP时间(ms) | JSON LPUSH(ops/s) | CSV LPUSH(ops/s) | JSON RPOP(ops/s) | CSV RPOP(ops/s) |
---|---|---|---|---|---|---|---|---|
1 | 186,223.97 | 547,001.14 | 1,017,224.69 | 663,153.29 | 5,369.88 | 1,828.15 | 983.07 | 1,507.95 |
10 | 24,913.60 | 68,968.42 | 105,345.91 | 68,332.99 | 40,138.72 | 14,499.39 | 9,492.54 | 14,634.22 |
100 | 3,629.02 | 15,537.92 | 15,147.84 | 8,599.99 | 275,556.49 | 64,358.69 | 66,016.02 | 116,279.23 |
1000 | 2,734.42 | 7,085.08 | 5,951.21 | 2,141.66 | 365,708.00 | 141,141.63 | 168,033.05 | 466,927.74 |
10000 | 2,243.54 | 5,408.75 | 4,156.64 | 1,104.85 | 445,723.73 | 184,885.67 | 240,578.88 | 905,102.93 |
批处理的 Redis 操作(LPUSH 和 RPOP+反序列化)的操作数对比:
批处理的 Redis 操作(LPUSH 和 RPOP+反序列化)的时间对比:
批处理大小对性能的影响:
007:「从测试结果来看,批处理大小为 10000 时,系统性能达到最佳。这是因为这个大小在网络通信开销和内存压力之间取得了良好的平衡。」
我:「有趣的是,当批处理大小超过 10000 后,性能开始下降。这可能是因为太大的批处理会增加内存压力和序列化/反序列化的时间。」
007:「是的,而且我们还发现,无论批处理大小如何,CSV 格式在所有测试中都保持了对 JSON 的性能优势,特别是在读取操作(RPOP+反序列化)方面。」
总结:数据传输的艺术与科学¶
通过这一系列的测试和优化,我和 007 一起深入探索了数据传输的艺术与科学。我们的发现可以总结为以下几点:
-
格式选择:在固定结构的数据传输场景中,CSV 格式比 JSON 更高效,特别是在数据大小和反序列化性能方面。
-
批处理大小:批处理大小对性能有显著影响,在我们的测试中,10000 条记录的批处理大小提供了最佳性能。
我:「007,这次的优化真的让我大开眼界。数据传输看似简单,实际上蕴含着丰富的优化空间。」
007:「是的,Boss。在量化交易系统中,毫秒级的性能提升可能意味着巨大的竞争优势。通过选择合适的数据格式和批处理大小,我们可以显著提升系统性能。」
我:「而且,我们的发现不仅适用于 SQEP,也可以应用到其他需要高效数据传输的系统中。」
007:「没错!数据传输的优化是一门艺术,也是一门科学。它需要理论分析,也需要实际测试。通过两者的结合,我们找到了最适合我们系统的解决方案。」
在量化交易的世界里,性能就是金钱。通过这次 SQEP 的再优化,我们不仅提升了系统性能,也加深了对数据传输本质的理解。正如 007 所说,这是一场关于毫秒和字节的较量,而我们,已经找到了制胜之道。