基于文件的多表join实现参考

用例：有N个文件，每个文件只有一列主键，每个文件代表一种属性。即当如PRI1主键在A文件中，说明PRI1具有A属性。这种场景，一般用于数据的筛选，比如需要既有属性A又有属性B的主键有哪些？就是这类场景。

如何处理该场景？

1.解题思路

如果抛却如题所说文件限制，那我们如何解决？

比如，我们可以将每个文件数据导入到redis中，数据结构为hash, redis-key为pri主键，hash-key为属性X, hash-value为1或不存在。在做判定的时候，只需找到对应的key, 再去判断其是否具有对应属性即可解决问题了。

这个方案看起来比较合适，但有两个缺点：1. redis内存数据库，容量有限，不一定能满足大数据量的场景; 2. 针对反向查询的需求无法满足，即想要查找既含有A属性又含有B属性的主键列表，就很难办到。

再比如，我们可以使用类似于mysql之类的关系型数据，先将单文件数据导致单表中，表名以相应属性标识命名，然后以sql形式进行临时计算即可。sql参考如下：

应该说这种解决方案算是比较好的了，在计算不大的情况下，这种复杂度在数据库领域简直是小场面了。需要再次说明的是，在数据库会新建一个个的小表，它只有一列主键数据，然后在查询的时候再进行计算。这种方案的问题在于，当标识越来越多之后，就会导致小表会越来越多，甚至可能超出数据库限制。原本是一个一般的需求，却要要求非常好数据库支持，也不太好嘛。

不过，上面这个问题，也可以解决。比如我们可以使用行转列的形式，将以上小表转换成一张大表，随后将小表删除，从而达到数据库的普通要求。合并语句也不复杂。参考如下：

如此，基本完美了。

2. 基于文件的行转列数据join

如果我没有外部存储介质，那当如何？如题，直接基于文件，将多个合并起来。看起来并非难事。

如果不考虑内存问题，则可以将每个文件读入为list, 转换为map存储，和上面的redis实现方案类似。只是可能不太现实，也比较简单，忽略实现。

再简单化，如果我们每个文件中保存的主键都是有序的，要想合并就更简单了。

基本思路是，两两文件合并，依次读取行，然后比对是否有相等的值，然后写到新文件中即可。

另外，如果要做并行计算，可以考虑使用上一篇文章提到的 fork/join 框架，非常合场景呢。

2.1. 文件行转列合并主体框架

主要算法为依次遍历各文件，进行数据判定，然后写目标文件。具体实现如下：

总体算法框架就是这样了，外部调用时，可以串行计算调用 joinById, 自行合并。也可以直接joinMultiFile, 内部进行并行计算了。然后，最后再可以按照自行要求，做顺序固化。此处并行计算的方案，正则上篇中讲到的fork/join.

2.2. 几个辅助类

如上计算过程中，需要使用一些辅助型数据结构，以表达清楚过程。以下为辅助类信息：

还是很简单的吧。

2.3. 单元测试

没有测试不算完成，一个好的测试应该包含所有可能的计算情况，结果。比如几个文件合并，合并后有几行，哪几行的数据应该如何等等。害，那些留给使用者自行完善吧。简单测试如下。

下面这个并行计算没有断言，一是懒得加，二是这种确实也复杂，这也是和分布系统排查问题难表暗合之意。另外值得一提的是，为了验证代码的稳定性，单测中添加了一个文件的随机打乱，从而保证了任意顺序都可拿到最终结果。而在实际应用中，可以按照文件行数大小排序，使用小文件与小文件合，大文件与大文件合，从而避免许多空行读而浪费性能。这也是自己实现的好处，想起来哪里想调整下，立即横刀立马。

下面给几个样例文件：

以上工具类，可以看作是对前面所示sql语义的同等实现，虽不能与官方同日而语，但也有一定的应用场景，只待各位发现。供诸君参考。（谁知道呢，也许你用MR更简单更高效）