针对GZIP文件类型的并行读取

  • 时间:
  • 浏览:0
  • 来源:uu快3诀窍_uu快3app安卓_导航网

并行读取的前提是读取任务还可以 拆分,对于类似于于上面有八个 多形态化的文件通过记录数来拆分是最自然的想法。类似于于,上面的文件发生628410行记录,启动10个并行搞笑的话,这麼每个程序运行读取62841行记录即可。但实际操作上却非常困难,针对有八个 多大文件,不不准选着位到某一行绝对是件速率不高的操作。

记录数不行,那就通过数据量(偏移量)吧,上面的文件解压缩后有60 1MB,因此 启动10个并行搞笑的话,每个程序运行读取60 MB左右的数据(这麼通过压缩后的18MB来做拆分,这并都在实际数据的大小)。通过JAVA还可以 很容易的实现对压缩文件的流式读取,边读边解压。这事先就要求当我们 在读之间最好就还可以 知道该文件压缩前的大小。看下GZIP的压缩格式,在文件的结尾部分是保存了该信息的:

该压缩文件大小为18MB,测试解压缩的时间:

该文件中共有将近63万条记录。

对1.txt进行压缩,并查看压缩后的文件信息:

···

[weiguang.sunwg@buffer010101169107.et2sqa /home/weiguang.sunwg/sunwg/test]

$gzip 1.txt

通过解析GZIP文件尾,还可以 很方便的得到该原始文件大小,根据原始文件大小还可以 比较方便的进行并行的拆分,因此 基本保证每个并行补救的数据量差很多,补救长尾。

实现了对GZIP文件的并行读取,就还可以 很容易的通过设置更高的并行度来提高同步的速率,更好的满足用户的需求。

首先对有八个 多GZIP文件进行解压缩的测试:

最后有八个 多字节为927d c012,高低位转换后为12c0 7d92,转换为10进制为31460 4946,即为解压后文件大小。

在看下前面那个压缩后为18MB的文件,文件尾如下:

按数据量拆分,这麼保证每个拆分点都在一行记录的结尾,很多很多很多很多有每个并行这麼进行记录对齐,保证读取的是完整的一行。对齐的规则也相当简单,开头少读半行,结尾多读半行。示意图如下:



该并行读取数据头和尾分别为A0和B0,根据上面的对齐规则调整为A1和B1,保证记录对齐。确实针对一点形态化的文件都还可以 这麼操作,因此有明确的行分隔符。

解压后文件大小为60 1MB,你你你这俩 压缩率还是相当可观的。一般来说,对于形态化的数据,压缩率都比较高。这麼看来,解压的速率还是很高的,不不成为性能的瓶颈,这也是当我们 接下来通过对GZIP文件并行读取提高整体数据同步速率的前提。试想下,因此 解压缩的操作非常耗时,这麼并行读取意义就不大了。

仅仅这麼2秒就完成了对该文件的解压操作,看下解压后的文件情況:

GZIP是最常见的压缩文件格式,目前DataX是支持对该压缩文件直接的读取,但每个GZIP仅仅这麼启动有八个 多程序运行来读取,当GZIP比较大,因此 说针对GZIP中的数据有着较僵化 的操作的情況下,执行速率往往比较低下。下面就讨论下何如对针对GZIP文件类型的并行读取,大幅度提高执行速率。

比较悲催的一点是,ISIZE存储的是以2的32次方为模的值,也可是我我我说当原始文件大于4GB的事先,该值就这麼准确的反应原始文件的大小了。GZIP的规范应该过后 过后 事先制定的,当时估计还不支持这麼大的文件吧。这点先忽略吧,目前的项目中文件都在相对较小的。

当我们 来验证下,看看何如通过读取GZIP的文件尾,来计算原始文件大小。

[weiguang.sunwg@buffer010101169107.et2sqa /home/weiguang.sunwg/sunwg/test]

$xxd 1.txt.gz

0000000: 1f8b 060 8 5b15 2959 0003 312e 7478 760 ....[.)Y..1.txt.

0000010: 4be4 060 07a1 eadd 060 0000 K...........

···

最后有八个 多字节为060 0000,高低位转换后为0000 0002,意思该压缩文件对应的原始文件为有八个 多字节。