通过Pyspark写入Mainframe格式文件

Question

我需要读取 hive 数据库表并以 EBCDIC 编码的文本格式写入该信息，因为它将用作大型机进程的输入。 我们正在使用 cp037 编码。 为此，我将 hive 表读入 df，然后调用自定义 udf 将数值转换为 COMP3 格式（用于在大型机中存储数值），然后使用大型机 EBCDIC 字符集的 cp037 对其进行解码。 问题是在写入文本文件或显示值时添加了一些额外的垃圾字符。

首先，我确保自定义 udf 工作正常。 为此，我使用 cp037 编码回自定义 udf 的 output，下面的 output 即将到来，这是完美的和预期的。 这里的 newcol1 是 field1 的 MF comp3 等价物，newcol2 是 field2 的 MF COMP3 等价物。

root
 |-- field1: long (nullable = true)
 |-- newcol1: binary (nullable = true)
 |-- field2: long (nullable = true)
 |-- newcol2: binary (nullable = true)
+---------------+----------------------+---------------------------+----------------+
|field1         |newcol1               |field2                     |newcol2         |
+---------------+----------------------+---------------------------+----------------+
|2023097000     |[00 02 02 30 97 00 0C]|320264                     |[00 03 20 26 4F]|
|2023097000     |[00 02 02 30 97 00 0C]|343012                     |[00 03 43 01 2F]|
|2023100000     |[00 02 02 31 00 00 0C]|343012                     |[00 03 43 01 2F]|
|2023100000     |[00 02 02 31 00 00 0C]|320264                     |[00 03 20 26 4F]|
+---------------+----------------------+---------------------------+----------------+

但是当我在解码垃圾字符后尝试编写/显示相同内容时

after doing decoding
root
 |-- field1: long (nullable = true)
 |-- newcol11: string (nullable = true)
 |-- field2: long (nullable = true)
 |-- newcol21: string (nullable = true)

+---------------+--------+---------------------------+--------+
|field1        |newcol11|field2                     |newcol21|
+---------------+--------+---------------------------+--------+
|2023097000     |^@^B^B~Pp^@^L |320264                     |^@^C~@^W|   |
|2023097000     |^@^B^B~Pp^@^L |343012                     |^@^C?^A^G   |
|2023100000     |^@^B^B~Q^@^@^L |343012                     |^@^C?^A^G   |
|2023100000     |^@^B^B~Q^@^@^L |320264                     |^@^C~@^W|   |
+---------------+--------+---------------------------+--------+

大型机文件如下所示（请注意，我已将 HEX 设置为 ON 以显示实际的字节）

********************************
                                
                                
 -------------------------------
2023097000...Ì.p..320264..Ì..|  
FFFFFFFFFF00073900FFFFFF00722444
20230970000228070C32026403806F00
 -------------------------------

如果您注意到字节 X'78' 是添加的垃圾字符。

我正在使用的 pyspark 文件写入命令是 df.coalesce(1).write.format('text').option("encoding","cp037").mode('overwrite').save('/some_location/test /comp3_outputdata/')

似乎在写入文本格式时它不支持编码选项。

根据下面的链接，似乎 pyspark 在调用文本方法时不支持编码。

在 Pyspark 文本方法中传递编码选项

我负担不起任何其他格式，因为我的 output 文件将被大型机进程直接获取。 有人可以帮我解决这个问题吗？

Answer 1

COMP-3 是 COBOL 中使用的术语，指的是 IBM Z 硬件上的压缩十进制格式。 其他格式包括二进制的 COMP。 将其视为 int32。

在十进制格式中，有几个十进制指令可以处理各种算术运算的数字。 目前尚不清楚您想在问题中做什么，但由于您参考了 COMP-3，因此有一个合理的假设，即您希望 COBOL 程序使用CP-037代码页将您的数字数据处理为压缩十进制和文本信息。 旁注，CP-037 通常用于欧洲系统，而 CP-1047 用于北美系统。

压缩十进制的二进制结构与代码页无关。

在您的情况下，您需要根据数据类型处理每一列。 在你的情况下，你会根据你的例子得到这样的东西：

field1 - 海峡
newcol1 - comp-3
field2 - 海峡
newcol2 - comp-3

而不是使用 CP 037 编码（仅对 field1 和 field2 有效）转换整个记录，您需要通过转换来转换 field1 和 field2。 对于 newcol1 和 newcol2，您希望它们保持不变。 将它们复制到新的 output 记录或保持不变。 因为它们是二进制编码，所以会产生像您在 x'78' 中看到的那样古怪的翻译。

Answer 2

在解决这个特定的问题陈述时，我们遇到了多个问题，因此在这里写下我们解决问题所遵循的详细过程，以供将来参考

1. 问题 1 -> 在 MF 文件中获取垃圾值（这是该线程的原始问题陈述）。 为此，正如@Hogstrom 所建议的那样，我们只是对 comp 特定字段进行了编码（使用 cp037），而不是对整个文件进行了编码。 当我们遇到同样的问题时，我们仍然修复了 sft 配置文件。 我们使用带有参数的 MBCS SFT 配置文件（下面给出的链接）来明确指定源和目标编码。 当我们将源编码为 utf-8 并将目标编码为 cp037 时，问题就解决了。

https://www.ibm.com/docs/en/cpl?topic=zos-mbcs-conversion-during-microsoft-windows-copy

2. 问题 2 -> 在代码页 cp037 中，X'15' 和 X'25' 可以互换，都表示换行符。 我们面临的问题是，如果有一个 x'15' 的十六进制字节作为 comp3 字段的一部分，则该值将更改为 x'25'。 我们做了很多研究，似乎没有直接的方法来解决它，它是这个特定代码页中的一种错误。 我们就此与 IBM 进行了讨论，他们建议我们使用代码页 IBM1047。 请注意@Hogstrom 在他的回复中已经提到了这一点，但不知何故我没有注意到这一点。 请注意，整个文件编码仍然是 utf8，但目标编码从 cp037 更改为 cp1047。

3. 问题 3 -> 这次我们注意到在每一行中都添加了一些额外的空格。 没有明确的逻辑...例如，没有为 2.7 添加额外的空间，但为 2.5 添加了额外的字符。 尽管所有与数据相关的问题都已解决，但这对我们造成了布局问题。 为了解决这个问题，我们强制将整个 pyspark output 文件从 utf8 编码为 cp1047。 由于在 pyspark 中我是以文本模式编写的，并且在 API 中不支持编码，我们为此编写了一个单独的 python 代码

4. 问题 4 -> 此时，我们注意到我们在每个 rec 的末尾添加了一个额外的字符 x'15'。 这是显而易见的，因为 pyspark 文本写入 API 使用 \n 作为默认行分隔符。 为解决此问题，我们使用了自定义行分隔符，并在以下 python 代码中使用 rstrip 删除该自定义行分隔符。 这解决了问题

5. 问题 5 -> 最后在 MBCS sft 配置文件设置中，output 文件将始终处于 VB 模式，而在我们的例子中，我们需要同时支持 VB 和 FB。 因此，我们删除了 MBCS SFT 配置文件并使用模式 = 二进制的简单 SFT 配置文件。 这满足了要求并创建了具有完美布局的完美文件。

我希望上述步骤能够帮助任何人解决他们在处理类似需求时可能遇到的任何类型的问题。