Synapse Pipeline - 如何指定 Pipeline Run 的标识？ (SP/UAMI 等)

Question

我在受控的企业环境中使用 Synpase Spark Pools。 我查询 AAD 的权限有限，但我可以创建 UAMI 并将它们分配给资源。

当我访问我的 Synpase 工作区时，我可以创建一个 Spark 作业定义来从 ADLS 读取一些数据。 查看 Monitor 选项卡下的 Apache Spark Applications 列表，我可以看到这些作业使用我的身份 (tim.davies@work.com) 作为“提交者”，并且由于我已经为自己授予了对数据存储的 rx 访问权限，所以这些工作成功了。

现在，如果我创建一个管道，并将其配置为运行我的 Spark 作业定义，它会因授权错误而失败。 回到 Apache Spark Applications list under Monitor 我看到我的管道有一个不同的身份用作提交者，这可以解释为什么它没有被授权访问数据。

首先，我不确定现在使用哪个身份作为提交者，我无法将 UUID 识别为我的 Synapse Workspace SAMI 或 UAMI（但我无法查询 AAD 以获取更多信息）。

但是总的来说，我突然想到我可能希望能够为我的管道分配明确的 UAMI 以在其下运行。 这可能吗？ 或者是否有不同的 model 来管理这个？

Answer 1

据我了解，这里的问题是了解如何从 Spark 作业中读取来自 ADLS 的数据。 由于您可以访问 ADLS，因此工作正常。 我认为您必须在 ADLS 上设置 Synapse 工作区的权限，它应该可以正常工作。

Answer 2

对此的更新速度稍慢，但我已经在理解方面找到了一些答案，如果不是一个解决方案的话。 对于关注或研究相同问题的任何人，在此处分享将很有用。

首先，当通过门户/UI 访问 Synapse 工作区时，笔记本或独立“Apache Spark 作业定义”使用的可操作身份是登录用户的身份（通过“ AAD 直通”） . 这对用户体验非常有用，尤其是在 Notebooks 中，您只需要确保您作为个人对您使用的任何数据源都有个人访问权限。 在某些情况下，如果您的用户身份没有此访问权限，您可以改用Workspace 链接服务身份，但并非总是如此！ （继续阅读）

但是，一旦您切换到使用管道，所使用的标识就是工作区的系统分配托管标识 (SAMI) ，它是在资源创建时创建和分配的。 这没关系，但了解粒度很重要，即。 有权访问资源的是工作区，而不是单个管道。 因此，如果您想运行具有不同访问级别的管道，您将需要将它们部署到隔离的 Synapse 工作区（具有不同的 SAMI）。

其中之一是我在原始问题中提到的“提交者”的身份，它在所有 Apache Spark 应用程序的 Synapse 工作区的监视器选项卡下可见。 当以用户（例如 Notebooks）身份运行时，此提交者 ID 是我的 AAD 用户名，这很简单。 但是，当作为管道运行时，提交者 ID 是“ ee20d9e7-6295-4240-ba3f-c3784616c565 ”，我的意思是每个人都使用相同的 UUID。 原来这是ADF作为企业应用的id。 例如，与将 Workspace SAMI 放在这里相比，这不是很有用，但这是为了防止其他人掉进那个兔子洞！

您可以创建一个额外的用户分配托管身份 (UAMI) 并将其分配给工作区，但这不会被执行管道使用。 UAMI 可由 Workspace 链接服务使用，但它有一些自身的限制（如下所述）。 另外我的经验是，在创建工作区时分配的 UAMI 将无法正确“关联”到工作区，直到我在门户中手动创建第二个 UAMI。 我没有深入研究这个问题，因为事实证明 UAMI 对我没有好处，但似乎是一个简单的错误。

现在我的具体用例是在 Synapse Pipelines 中运行 Apache Spark 应用程序，使这项工作正常进行的直接方法是确保 Workspace SAMI 可以访问所需的资源，并且您可以使用 go。如果您只是想实现它工作然后做这个并停在这里，但如果你想看得更深一点继续......

某些Microsoft 文档中的建议是，您应该能够在 Spark 应用程序中使用工作区链接服务，以便访问资源。 但这不起作用，我一直在与 Microsoft 讨论相同的问题，他们已经确认并正在调查。 所以在这一点上值得注意的是日期（02/02/ 2023——对美国读者来说很容易明确;-)），因为这个问题可能会在以后得到解决。 但是现在您在 Spark 代码中的唯一选择是退回到用户/工作区身份。

只是想一想为什么这很重要，它并不是真正的隔离，因为工作区中运行的任何资源都可以访问任何链接服务。 这实际上更像是身份和资源管理的问题，即。 最好将正在使用和分配给资源的身份与资源本身分开。 在大多数情况下，我们宁愿对具有个人身份的组执行此操作，如果管理过程冗长（我的），那么我宁愿不必在每次创建资源时都重复它们。

无论如何，现在就足够了，如果在我仍在关注的情况下发生变化，将会更新...