xxfye

上面说什么线程适合 cpu 密集型，协程适合 io 密集型，基本上都在胡说八道。

协程的本质是一种在允许在应用态自定义的任务调度策略/方式/单元。
线程本质则是系统自带的任务调度策略/方式/单元，对应用是透明无感的。

只是某些场景只用线程的话，导致线程过多，线程切换导致大量无意义的性能开销，为了避免线程的频繁切换，因此搞出了协程。

协程是要以线程作为载体的！！！你起一百万个协程，底层还是要起几十个线程去执行这些协程，只不过这些协程的切换完全可以由应用自定义协程的调度策略（一般由运行时或编译器来做这件事情）。

常见协程的误区：

协程也可以是抢占式的，比如 go 的协程调度就是抢占式的。

cpu 密集型应用一样能适用于协程。
比如说 dataframe OLAP 引擎，就是用 tokio 的协程做任务调度。没做什么调整就得到了很高的性能。
其他 OLTP 引擎，一般都是 Cpp 或者 Java ，没有完善的协程机制，导致不得不实现 pipeline 模型的做自定义算子调度，复杂度大大提高。

上一次知乎看见华为穿越时空因用鲲鹏 920 抄袭 A77 后，现在华为又用时空机抄袭苹果高通的未来技术来了。
华为真是糟践时空机了啊。

1. hash
2. 加序号
3. 按照 hash 分区
4. 逐个处理分区
5. 分区内排序
6. 分区外归并排序

只有单机的话，可以考虑用 duckdb ，多机就用 spark 吧。

@drymonfidelia 看错了，还以为是 6GB 的 csv 文件在线处理呢，那确实不适合 duckdb 。

还是上 spark 吧，硬盘配大点就行。

203 亿行 csv 有那么大吗，我们每天备份全量的 17 亿行信息，保留几十天，用 orc 存储，也就几百 G 。

duckdb 值得拥有