如何为客户端开放Azure Data Lake SQL查询权限最佳实践

结论：你完全可以直接通过Databricks原生能力实现客户端SQL查询权限开放，不需要强制搭配其他额外服务；只有存在特殊场景需求时，才需要搭配对应Azure生态服务补全能力。

这是和你当前ADLS Gen2+Databricks+Delta+Power BI链路适配度最高的方案，没有额外的数据同步、服务运维成本：

• 第一步先把现有所有对外提供查询的Delta表统一注册到Unity Catalog元存储下，替换掉老旧的内置Hive元存储。Unity Catalog原生支持细粒度权限管控，可以精确到单表、单列、单行的SELECT权限授权，完全满足最小权限分配要求，不会泄露其他非授权数据。
• 为客户端创建专属的身份凭证：优先用Azure AD服务主体做鉴权，小范围测试也可以用受限的Databricks个人访问令牌（PAT）。注意不要给客户端开放Databricks工作区的交互式笔记本、作业开发权限，只分配对应SQL Warehouse的连接权限、目标表的只读查询权限。
• 单独部署一个专供外部客户端查询的Serverless SQL Warehouse（原SQL Endpoint），绝对不要和你跑数据转换的ETL集群混用。这个Warehouse可以配置按需启停、查询超时时间、单查询扫描数据量上限，成本完全可控。客户端通过标准JDBC/ODBC驱动连接这个端点，就可以用标准SQL查询Delta表，使用体验和连接常规关系型数据库没有区别。
• 所有查询操作默认会留存全量审计日志，可以追溯谁在什么时间查了什么数据，满足对外授权的合规要求。

只有出现以下明确需求时，才需要新增其他服务，常规场景完全不需要：

• 如果你需要给客户端提供免配置的网页端查询入口，不想让客户端自行配置JDBC/ODBC连接，直接用Databricks自带的SQL Query Editor、SQL Dashboard功能给对应账号授权即可，不需要额外服务；如果需要高度定制化的自助查询门户，可以基于Azure App Service搭轻量前端，后端直连Databricks SQL端点即可，这个属于可选定制项，不是必需组件。
• 如果你面对的是数百以上规模的只读查询用户、并发查询量极高，想要进一步降低单位查询成本，可以定期把Delta表的查询快照同步到Azure Synapse Serverless SQL池对外提供查询端点，但这个方案会新增数据同步链路的运维成本，中小并发场景下性价比极低，不推荐。
• 如果你需要对接企业现有统一身份体系，直接把Unity Catalog和现有Azure AD租户打通，用Azure AD安全组做批量权限映射即可，不需要额外部署权限管控服务。

• 绝对不要直接给客户端开放ADLS Gen2存储层的读权限：这种方式无法实现行/列级细粒度管控，也没法做查询限流、操作审计，极易出现数据泄露、异常大查询打满存储带宽影响现有ETL和Power BI报表刷新的问题。
• 不要复用现有ETL作业集群给外部客户端做查询：会出现查询作业和数据转换任务的资源抢占，很容易导致数据转换链路延迟、失败。

内容的提问来源于stack exchange，提问作者TDS_Mars