关于文件数据格式

[gongweibao]

Goals

• 找到或者设计一个文件格式， 可以方便的切分文件，以便于task的分发
• 独立于某个系统

可以选择的方式

• SSTable
  • Sorted String Table
  • LoadSSTable的时候首先要加载索引，然后才能定位、分割
• SeqenceFile
  • 比较复杂

设计的简化的方式

我们的目标主要是文件可以分割，其实可以不用索引，比如

file format:
    file_type : paddle_seq
    reserve  : reserve bytes for future
    chunk     : 
    ...

chunk format:
    header	  : magic number
    checksum     : checksum of (chunk_len+chunk_data)
    reserve          :  reserve bytes for future
    chunk_len 	      :  len(chunk_data)
    chunk_data       :  many or one records

chunk_data format:
    record_len : len(record_data)
    record_data:  user's data
    ...

• checksum的作用：

  • 我们的数据可能来自用户自己生成，通过公网传输，防止出现数据的错误
  • 出现错误后，只丢失一个chunk
  • 和header配合做一个检查chunk的边界

• magic number的选择

  • 0xffffffff之类的header比较常见，容易重复
  • 一个 随机的MD5值出现的概率很低，可以大大减少冲突的机会

任务分发和处理

• task信息：

  • file_path + begin_pos + end_pos
  • 根据文件大小和task的个数进行分割

• trainer读取:

  • 首先seek到begin_pos
  • find header,
    • 然后尝试按照一个完整的记录去读取
    • 出现错误继续循环find header
    • 直到超过end_pos

[wangkuiyi]

有道理。

我看了一下：Hadoop的SequenceFile和Google的RecordIO文件格式很像。RecordIO是一种Web服务用来记录log的文件格式，通常是数据处理作业（例如MapReduce jobs）的输入。因为一个Web服务进程可能挂掉，挂之前的输出可能没能正确地写入RecordIO文件；而进程被Borg/Kubernetes重启后，如果要向同一个文件里继续写，则需要这个文件格式可以允许未来读的时候跳过“坏的”records。这是records被分成chunk，并且每个chunk里要有header/magic number和checksum的原因。

2010年我离开Google去腾讯的时候，叶航军也加入了腾讯。他写了一套RecordIO的实现。后来他去了小米。发现如果每次进程被重启的时候，不是向同一个文件输出log，而是新开一个文件写log，那么就不需要chunking和magic number了。

[wangkuiyi]

从我们的需求考虑，chunking的一个好处是：不需要在文件里写入chunkOffsets了。因为每个chunk开始的地方有chunkSize，所以可以跳着读。这样跳着读一遍文件后，就可以在内存里build chunkOffsets了。

[helinwang]

SSTable会用解压缩很快的算法对每个大block进行压缩，我们要不要也考虑下把数据分成大小block，大block是多条小block，小block是一条data instance。进行压缩可以加快disk IO，减少网络带块。master schedule task以大block为粒度。
@gongweibao @wangkuiyi

[gongweibao]

这样跳着读一遍文件后，就可以在内存里build chunkOffsets了。

我的理解：

• master跳读(seek)一遍文件代价还是比较大的，特别是chunk多的情况下。如果不用magicnumber和checksum等文件separator方便文件可分割，还是保留chunkoffsets索引，这样master处理的代价小。
• 考虑到数据在用户机器上生成，不能保证用户是否用ctrl+c停止掉，也就是最后的chunkoffsets索引未必是完整的，需要在index前后加边界和checksum。单纯用静态的sperator是不靠谱的。

[gongweibao]

@helinwang 恩。压缩可以设置可配置。文本的压缩率还好，图像基本压缩不动。而且我觉得一旦启动压缩，用户的风扇估计就要开始狂响了。可以测试一下。

我们自己在服务器上生成，只要文件不是频繁更新都还好。

[helinwang]

@gongweibao 主要是看解压算法快不快吧，有很多算法解压是很快的。