我们一直在 SQL Server 2019 (CU2) 机器上试验 Polybase，使用 SQL Server 外部数据源，但性能并不好 - 在大多数情况下提高了 1400%。在每种情况下，我们查询的所有表/视图都来自指向同一外部数据源的外部表。我们尝试过运行在本地框上分解的查询，并使用与作为外部表拉入的视图相同的查询。我们还将来自远程服务器的每个统计数据脚本化到外部表上，没有任何变化。您可以使用示例查询在下面看到性能差异。
服务器在资源方面设置相同：32GB 的 RAM、8 个 vCPU、SSD 磁盘，并且没有其他正在运行的查询。我尝试过两台不同的远程服务器，一台运行带有最新 SP/CU 的 SQL Server 2016，另一台运行 CU2 的单独 2019 机器。服务器是在同一台主机上运行的虚拟机，我们已经排除了任何类型的主机争用。
示例查询：
SELECT
StockItem_StockNumber, BlanktypeId, NameHTML, BackgroundStrainName, IsExact, IsConditional
,ROW_NUMBER() Over(Partition By StockItem_StockNumber, BlanktypeId Order By pt.Name, p.Name, gptr.Text) as row_num
,pt.Name as Level1, p.Name as Level2, gptr.Text as Level3, MGIReference_JNumber
,gptr.Type as Level3Type
FROM
StockItemBlanktypes sig
INNER JOIN Blanktypes g on g.BlanktypeId = sig.Blanktype_BlanktypeId
INNER JOIN BlanktypeStockTerms gpt on gpt.Blanktype_BlanktypeId = g.BlanktypeId …我什至不确定我是否正确地提出了这个问题，但我会尝试 - 我有一堆从 Linux 系统上的 Oracle 导出生成的巨大文本文件。每个文件大小约为 30 GB，我有大约 50 个。
目标是将此数据导出到 Azure SQL 数据仓库。在这种情况下，考虑到数据的大小，BCP 不是正确的方法，所以我不得不使用 Polybase。
从 ASCII 转换为 UTF8 编码后，我在查询外部表时遇到了问题。Polybase 不能很好地处理固定宽度的文本文件，每行都有一个换行符。
文本文件看起来像这样：
101,102,103,104,105,106,107 108,108,109,110,111,112,113 114,115,116,117,118,119,120 121,122,123 --这里什么都没有，只是一个空行 201、202、203、204、205、206、207 208,209,210,211,212,213,214 215,216,217
Polybase 尝试从 101 到 107 进行处理，并且出现错误，抱怨此文件中没有足够的列可供处理。
这是我认为正在发生的事情：固定宽度和换行符使其将换行符视为行分隔符。
如何将此文件转换为如下所示：
101,102,103,104,105,106,107,108,108,109,110,111,112,113,114,115,116,117,118,119,120,121,122,123{CR}
201,202,203,204,205,206,207,208,209,210,211,212,213,214,215,216,217{CR}{LF}
编辑：这是来自文件的示例数据。我在 Windows VM 上用 git bash 打开它。
这些文件应该有 167 列，,作为列分隔符。问题是，由于每行产生多行，因此很难从 Polybase 外部表处理它们。