我正在尝试在连接到 Azure Data Lake Gen2 帐户的 Azure Databricks 工作区中简化开发人员/数据科学家的笔记本创建过程。现在，每个笔记本的顶部都有这个：
%scala
spark.sparkContext.hadoopConfiguration.set("fs.azure.account.auth.type.<datalake.dfs.core.windows.net", "OAuth")
spark.sparkContext.hadoopConfiguration.set("fs.azure.account.oauth.provider.type.<datalake>.dfs.core.windows.net", "org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider")
spark.sparkContext.hadoopConfiguration.set("fs.azure.account.oauth2.client.id.<datalake>.dfs.core.windows.net", <SP client id>)
spark.sparkContext.hadoopConfiguration.set("fs.azure.account.oauth2.client.secret.<datalake>.dfs.core.windows.net", dbutils.secrets.get(<SP client secret>))
spark.sparkContext.hadoopConfiguration.set("fs.azure.account.oauth2.client.endpoint.<datalake>.dfs.core.windows.net", "https://login.microsoftonline.com/<tenant>/oauth2/token")
我们的实现试图避免安装在 DBFSS 中，因此我一直在尝试查看是否可以使用集群上的 Spark 配置来定义这些值（每个集群可以访问不同的数据湖）。
但是，我还无法让它发挥作用。当我尝试各种口味时：
org.apache.hadoop.fs.azure.account.oauth2.client.id.<datalake>.dfs.core.windows.net <sp client id>
org.apache.hadoop.fs.azure.account.auth.type.<datalake>.dfs.core.windows.net OAuth
org.apache.hadoop.fs.azure.account.oauth.provider.type.<datalake>.dfs.core.windows.net "org.apache.hadoop.fs.azurebfs.oauth2.ClientCredsTokenProvider"
org.apache.hadoop.fs.azure.account.oauth2.client.secret.<datalake>.dfs.core.windows.net {{secrets/secret/secret}}
org.apache.hadoop.fs.azure.account.oauth2.client.endpoint.<datalake>.dfs.core.windows.net "https://login.microsoftonline.com/<tenant>"
我收到“初始化配置失败” 上面的版本看起来默认尝试使用存储帐户访问密钥而不是 SP 凭据（这只是使用一个简单的ls命令进行测试以确保其有效）。
ExecutionError: An error occurred while calling z:com.databricks.backend.daemon.dbutils.FSUtils.ls.
: Failure to initialize configuration
at shaded.databricks.v20180920_b33d810.org.apache.hadoop.fs.azurebfs.services.SimpleKeyProvider.getStorageAccountKey(SimpleKeyProvider.java:51)
at shaded.databricks.v20180920_b33d810.org.apache.hadoop.fs.azurebfs.AbfsConfiguration.getStorageAccountKey(AbfsConfiguration.java:412)
at shaded.databricks.v20180920_b33d810.org.apache.hadoop.fs.azurebfs.AzureBlobFileSystemStore.initializeClient(AzureBlobFileSystemStore.java:1016)
我希望有办法解决这个问题，尽管如果唯一的答案是“你不能这样做”，这当然是一个可以接受的答案。
因此，在测试某些代码时，我发现粘贴在查询窗口中的代码行为异常。以下是我从哪里获得代码的简化示例：
declare @a nvarchar(max) = '';
select @a = 'select ' + cast(n as char(1)) + ';' + char(13) + 'GO' + char(13) from nums where n = 1;
print @a
exec sp_executesql @a
这是在SSMS的查询窗口中执行的。当然，它会出错，因为该GO分隔符在动态SQL中不起作用。
但是，只是为了确认代码本身是否正确，我将其复制到了新的查询窗口中。继续示例：
select 1;
GO
select 1
GO
第一条语句给出语法错误，第二条语句将GO视为列别名。有趣的是，如果我只是直接在该查询窗口中键入代码，这仍然是正确的。它并没有影响其他窗口或新窗口，只是我将PRINT结果粘贴到的窗口中。
关于这一点的最后一个有趣的事实是，如果LEN()将上面的示例在“错误”查询窗口中与在可正常工作的查询中进行比较，则“错误”查询的长度为26个字符，但正常情况下为31个字符。
我发现退格所有字符似乎无济于事，但是如果我执行全选并删除操作，似乎可以解决此问题。我认为这意味着它将得到一个不可打印的字符，但是如果我执行“全选”并使用“显示所有符号”选项复制到Notepad ++中，则看不到任何注意事项。
有谁知道为什么SSMS会有这种行为？我正在使用版本17.9（如果有问题，请针对SQL Server 2014实例运行）。