问题描述：

我生成mindrecord文件，按这样shema：

    data_schema = {

                   "target_sos_ids": {"type": "int32", "shape": [-1]},

                   "target_sos_mask": {"type": "int32", "shape": [-1]},

                   }

期望读出来的格式(batch_size=4, 共写入文件64samples)：

xids=[[50256    52    13    50]

 [50256 26932  3524   290]

 [50256   464  9317  6241]

 [50256  2396    11  7062]]

 xmask=[[1 1 1 1]

[1 1 1 1]

[1 1 1 1]

[1 1 1 1]]

ds.get_dataset_size=16

ds.output_shapes=[[4, 4]，[4, 4]]

实际云上读出来的格式：

xids=[[50256 0 52 0 13 0 50 0]

[50256 0 26932 0 3524 0 290 0]

[50256 0 464 0 9317 0 6241 0]

[50256 0 2396 0 11 0 7062 0]]

xmask=[[1 0 1 0 1 0 1 0]

[1 0 1 0 1 0 1 0]

[1 0 1 0 1 0 1 0]

[1 0 1 0 1 0 1 0]]

ds.get_dataset_size=16

ds.output_shapes=[[4, 8]，[4, 8]]

猜测是否生成文件是int32，读取的时候没做 cast int32

测试发现不是没有cast int32的原因，cast后结果还是一样，每个数后面都插入了0，这就又很疑惑了，到底什么原因导致

最后生成文件的时候定义格式改为{"type": "int64", "shape": [4]}， 原来是{"type": "int32", "shape": [-1]}

读取的时候再转为int32，终于ok了，问题解决

另外：

举个例子，我的text样本文件是13M大小，5000个样本，按int32生成mindrecord是49M，按int64生成是100M，另外如果我只选择生成64个样本，出来的文件还是100M，没变，这就非常奇怪了。而对应生成64个样本的TFrecord大小是45k

建议方案：

1.  生成文件数据类型选择可以选int32，或者int16，这样空间占用就小很多，目前int类型只能选int64，否则会出错

2. 生成文件大小按实际生成样本数量增长，不能按全部样本来定义