随便瞄了一眼，是只有 github 的么

通讯地址：安徽省合肥市包河区成都路 1266 号

服务热线：96669 （非安徽省内拨打请加拨 0551 ）

效能热线：0551-62760027

邮政编码：230601

官方网址：www.ahrcu.com

上面说什么线程适合 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 值得拥有

@liyafe1997 对呀，客户当然有权利可以分发，但是红帽就终止合同，停止你获得后续的二进制和源码的机会。这个并没有限制你已经到手的源码和二进制的分发权利。因此不违背 gpl 协议。

gpl 规则是获得二进制的人，也能获得源码。
因此只要限制二进制的获得合同就行。

可以的，红帽就是这么干的。
你订阅 redhat ，我就给源码给你。但你一旦共享出去，咱们合同立刻取消。
实际上 redhat 不是带头这样干的，高通 MTK 博通英飞凌等等都有类似协议。

gpl 只需要遵守二进制的