oracle datetime字段spark无法准确读取

Question

我关注这个问题已经有一段时间了，我知道我已经没有选择了。我正在加载一个拼花地板文件，其行如下：

RFS,FOI,1209591006000,64.0000,1209591007000,Y,1209591007000,04/30/2008 17:30:07,1209591007000,UPDATER

无济于事的是，spark抛出了一个错误，告诉我DecimalType的精度大于38（它的极限）。以下是相关的stacktrace：

19/07/09 20:24:02 WARN TaskSetManager: Lost task 0.0 in stage 4.0 (TID 203, ip-10-230-246-236.ec2.internal, executor 1): org.apache.spark.sql.AnalysisException: DecimalType can only support precision up to 38;
at org.apache.spark.sql.types.DecimalType.<init>(DecimalType.scala:52)

问题: 1） 我不明白哪一列可能会引发火花，似乎没有一列接近精度极限 2） 我怎样才能让spark更具体地告诉我它失败在哪一列（或者更好的是，失败在哪一行？）？ 3） 我无法在spark中打印模式，因为由于此异常，我甚至无法读取文件（存储在S3中），因此我不确定如何验证模式是否正确。 4） 拼花地板文件中的模式是否不正确？还是数据有问题

信息： -Spark是作为一个胶水作业（无服务器）运行的，但我相信它是最新版本的。 -拼花文件由HVR生成，是拼花版本v3，没有压缩

我做了一些谷歌搜索，人们说你应该手动指定模式来控制它，但在这个例子中我不能，因为这是一个大型ETL过程，我们并不总是知道模式（我们依赖拼花文件中的嵌入式模式和sparks读取能力）

Answer 1

事实证明，这是我用来将文件放在S3中的摄取工具的问题。导致问题的字段是oracle源上数据类型为“number”的任何列。有了这个特定的数据类型和我们用来将拼花地板文件放到S3中的特定摄取工具，它的数据是正确的，但不知何故，嵌入式拼花地板模式将字段显示为十进制（1000,4）。尽管该列中没有一个值的精度大于4，但供应商最终发布了一个修复程序，数据类型具有正确的精度，spark停止了抱怨