背景：今天被人问到一个10G的超大CSV如何最快速度读取，并插入到数据库中。一般读取文件都是单线程一直往下读，但是如果文件特别大的情况下就会很慢。如何快速读取？脑海里面"多线程"一下子就浮出水面了，想要快速读取文件，肯定得多线程一起读取。那问题来了，一个文件怎么样进行多线程读取，首先得知道每个线程要负责读取的位置，才可以多线程完整的读取一行的数据。

linux文件底层存储结构

在回答这个问题之前，我们先要了解一下linux操作系统底层是如何存储文件的，知道这个底层原理之后，我们才能更好的问答这个问题。

从上图我们可以看出，操作系统里面包含文件系统，可以快速根据文件路径定位到文件具体位置，文件本身并非直接存储在磁盘上面的，一个文件由很多块组成，根据不同的文件系统，每一个块的默认大小也都不一样，比如在 Windows 系统下，默认的 NTFS 文件系统的文件块大小为 4KB。

读取方案设计

想要最快速度读取文件里面的内容，无疑要用到多线程，那如何用多线程去读取文件呢？这也是有所讲究的，如果用错方法可能多线程的速度还不如单线程去获取。

按行多线程读取

直接读取文件的总行数，然后按照10个线程来计算，每一个线程要处理多少范围行数的数据，最后线程各自对同一份文件进行数据处理。

这种方案最大的问题就是忽略了各个线程在读取指定行数的复杂度，并非O（1）而是O（n）,所以线程在读取文件的时候，检索数据这个过程会耗费一定时间，总体查询速度并不高，甚至可能比单线程更慢。

大转小后多线程读取

将大文件拆分为一个个小文件，然后多线程去读取各个小文件，这样速度会比读取一个大文件快很多，而且读取的程序也比较简单。

例如linux提供了split命令，可以按照行和字节进行拆分。但是不管是按照行或者字节，底层都是通过直接多线程读取文件块，来快速处理的。

split在按行拆分的情况下，如果要处理大量的文件，可以将每个文件拆分成若干个块，然后使用多线程来同时处理这些块，以提高拆分效率。每个线程读取一个块，处理完后，将结果保存到对应的输出文件中。 在按字节拆分的情况下，同样可以使用多线程来加快拆分速度。可以将文件划分为若干个块，每个线程读取一个块，然后根据指定的字节数进行拆分，并将结果保存到对应的输出文件中。

这种大文件转小文件，然后多线程读取的方式，如果是离线分析，那肯定是首选，但是如果是在线程序分析，将文件拆分再读取，过程会很繁琐，实现上面也比较复杂，也不是非常推荐这种方案。

多线程按块读取

获取文件的size，假如文件是10G，按照10线程，每一个线程负责1G范围的数据检索，例如线程1负责0指针位置的块，线程2负责1G指针位置块，到线程10负责9G指针位置块。

除了1线程，其它线程都从原本位置向前查找换行符，找到之后从当下位置开始，一直读取到2G位置的下一个换行符。这样就可以多线程快速的读取一个文件的数据，但是会有极少数数据的重复获取。

因为按照字节位置索引文件的复杂度是O（1），也就是知道文件的指针之后，可以马上读取该指针下的数据，这样可以避免第一种方案中需要遍历一遍文件内容，才能找到对应行的指针位置的问题。多线程按块读取方案相对上面两种，无疑是最快的一种方式。

复盘总结

其实多线程按块读取之后还可以继续优化，为什么呢？因为线程再多，最大的读取速度也受限于：文件所在机器的IO、应用机器和文件所在机器的网络、应用机器的IO这几方面，可以继续在这几方面优化。看似简单大文件读取操作，却涉及底层文件系统。所以处理问题或者设计方案，一定要多考虑几层，可以基于底层原理来设计方案，才是最可靠的。