本文只讨论几种可行性的方案。
中间件方案(基于硬盘)
通过中间件来处理是可行的，无论你是 mysql 、postgresql 、sqlite 、hbase 还是 kvrocks ，都可以在插入的时候判断同样的内容是否存在。而这些数据库是基于磁盘的，因此磁盘的 IO 决定了这个方案的上限。
以 kvrocks 为例(我前段时间刚好压测过 kvrocks)，kvrocks(部署在 SSD 上)单机指令的 TPS 为 10 万。那么处理 203 亿行数据的时间为2.3 天。我们可以部署 kvrocks 集群来增加 kvrocks 的吞吐量，由于本次需求只限制了内存，没有限制其他的 CPU 等，我们可以尽量多部署几个节点，让 kvrocks 集群的吞吐量高于我们读文件的性能即可。我在我本机 SSD 上测试的读取文件的性能为 1 秒钟 150 万行，那我们部署 15 个 kvrocks 节点即可。
优点
这个方案的好处在于只需要很小的内存。中间件简单，只要部署一下 kvrocks 集群就行了。受限于写文件性能，因此没有加行号重新写入文件。所以本方案还是推荐单线程读文件,最后处理完的结果就是最终的结果(不需要重新排序)。
中间件方案(基于内存)
使用 redis 的布隆过滤器能够很好的处理重复的数据。使用 redis 的限制是内存，我们通过这个网站来计算一下所需要的内存。
看样子内存是符合要求了。我们再计算一下所用时间。
单机 redis 的 TPS 为 20W,那么处理 203 亿行数据的时间为1 天。
集群 redis 所用的时间和 redis 的节点数有关系，集群节点数越多,则 TPS 越高。由于最大内存为 256GB ，CPU 没有限制,那么我们可以部署 9 个 redis 主节点，总共消耗 24GBb*9=216Gb 。则理想状态下处理 203 亿行数据所用时间为3 小时。
什么是理想状态？数据完全离散，每行数据都落到不同的分区。这个视具体的数据情况而定。
第二个问题是当我们部署 redis 集群后，redis 集群的吞吐量为 180 万每秒,而我们使用单线程读取文件，能达到这个量级吗？我试了一下流式读取 SSD 上的文件,每秒钟大概读 150 万的样子。如此看来读文件也不是瓶颈，而且我们还优化到了 3 小时。
优点
这个方案的好处在于中间件简单，只要部署一下 redis 集群就行了。由于是单线程读文件然后处理，因此也不需要重排序。
分治法
我当初看到这个需求的时候第一时间想要的也是分治法。我们就按照分治法的思路分析一下可行性。
[ol]
[/ol]
由于分治法会把整个文件通过 hash 算法重新分散到不同的文件中，对于文中的需求按照文件顺序，则需要添加行号来用于最后的排序。第 1 ，2 ，3 步都是用单线程进行操作。在我本机 SSD 上测试了一下，处理 1000 万条数据的时间为 2 分钟，大量的时间都花在写文件上。以同样的性能评估 203 亿行的数据执行 1,2,3 的步骤，则所花费的时间为2.9 天。
后续的处理不在赘述，因为 hash 分区重新写文件的时间太久已经明显的不如其他的方案。
Spark
答主没有用过 Spark ，不知道具体的分区消耗多少内存以及读取性能和处理性能，无法给出具体的可行性能答案。
