当我尝试从云存储加载多个文件时,较大的作业几乎总是失败。当我尝试加载一个有效的单个文件时,加载批处理确实非常方便。
段: 最近的工作 加载上午11:24 gs://albertbigquery.appspot.com/uep/201409/01/wpc_5012_20140901_0002.log.gz toalbertbigquery:uep.201409
上午11点23分加载 gs://albertbigquery.appspot.com/uep/201409/01/wpc_5012_20140901_0001.log.gz toalbertbigquery:uep.201409
上午11点22分加载 gs://albertbigquery.appspot.com/uep/201409/01/* toalbertbigquery:uep.201409 错误: 文件:40 /行:1 /字段:1,遇到错误字符(ASCII 0):字段以:< >开头 文件:40 /行:2 /字段:1,遇到错误字符(ASCII 0):字段以:<5C >} >开头 文件:40 /行:3 /字段:1,遇到错字符(ASCII 0):字段以:< W o >开头: 文件:40 /行:4,列太少:预期7列但有2列。如需其他帮助: 文件:40 /行:5,列太少:预期7列但有1列。如需其他帮助: 文件:40 /行:6,列太少:预期7列但有1列。如需其他帮助: 文件:40 /行:7,列太少:预期7列但有1列。如需其他帮助: 文件:40 /行:8 /字段:1,遇到错误字符(ASCII 0):字段以:< hy >
开头这个问题最糟糕的是我不知道哪个文件是“文件:40”,顺序似乎是随机的,否则我可以删除该文件并加载数据,或者尝试在文件中找到错误。 / p>
我也强烈怀疑是否存在实际的文件错误,例如在上面的情况下我删除了所有文件但_0001和_0002(可以正常加载为单个文件)我还是得到了这个输出:
近期工作 上午11:44加载 gs://albertbigquery.appspot.com/uep/201409/01/* toalbertbigquery:uep.201409 错误: 文件:1 /行:1 /字段:1,遇到错误字符(ASCII 0):字段以:< >开头 文件:1 /行:2 /字段:3,遇到错误字符(ASCII 0):字段以: 文件:1 /行:3,列太少:预期7列但有1列。如需其他帮助: 文件:1 /行:4 /字段:3,遇到错误字符(ASCII 0):字段以:
开头有时虽然文件加载得很好,否则我会发现多个文件加载都被破坏了。
的信息: 平均文件大小约为20MB,通常一个目录是70个文件,介于1到2 GB之间。
答案 0 :(得分:1)
看起来您正在遇到BigQuery错误。
当BigQuery使用通配符模式(即gs://foo/bar*
)获取加载作业请求时,我们首先将模式扩展到文件列表。然后我们读取第一个来确定压缩类型。
GCS的一个奇怪之处在于,它没有真正的目录概念。那是gs://foo/bar/baz.csv
真的是bucket: 'foo', object: 'bar/baz.csv'
。看起来你有空文件作为目录的占位符(如gs://albertbigquery.appspot.com/uep/201409/01/
)。
这个空文件与bigquery probe-for-compression类型没有很好的协作,因为当我们扩展文件模式时,目录虚拟文件是第一个被返回的东西。然后我们打开虚拟文件,它似乎不是一个gzip文件,因此我们假设整个加载的压缩类型是未压缩的。
我们已经提交了一个错误并正在测试中。希望下周能解决这个问题。与此同时,您可以选择自己扩展模式,使用不会与目录匹配的更长模式(如gs://albertbigquery.appspot.com/uep/201409/01/wpc*
中所示),或者删除虚拟目录文件。