9.3 PolyBase 与大数据集成：不搬运，直接问

9.3 PolyBase 与大数据集成：不搬运，直接问

本节摘要：ETL 把数据搬来搬去的成本，随着数据湖的普及越来越难接受。PolyBase 提供另一条路：在 SQL Server 里为外部数据（数据湖文件、Hive、其他关系库）建外部表，查询时引擎现场去远端取数，T-SQL 联合查询本地与外部如同查一个库。本节讲清它的三层架构、数据虚拟化的用法边界、性能与安全考量，以及向"数据编织"演进的方向。

不搬运，直接问

传统集成是"复制思维"：把外部数据抽进本地再算，管道建设、调度、一致性校验全是持续成本。PolyBase 是"引用思维"：外部数据建一张外部表，元数据登记在本、数据留在原地，查询时引擎按需拉取所需片段。收益有三：零存储副本（不用为一份引用数据再买一份盘）、数据始终新鲜（源头即真相）、T-SQL 全栈（分析师不用学新语言）。场景画像很清晰：偶发跨源分析（每月对一次账）、数据湖探索（先直查再决定要不要入仓）、轻量联邦（本地客户表连接云端日志表）。反过来，高频重计算的外部负载，该走真正的数据入仓或计算下推——虚拟化是引用不是魔法，重活每次现场拉取反而是负优化。

三层架构与外部表五步

PolyBase 的骨架是三层解耦：外部数据源登记"远端在哪、用什么协议与凭据"，外部文件格式定义"数据长什么样"（分隔符、压缩、编码），外部表把两者拼成可查询的本地对象。以直查数据湖的 Parquet 文件为例，五步建通：

-- 第一步：主钥匙（凭据加密的地基）
CREATE MASTER KEY ENCRYPTION BY PASSWORD = N'强口令';

-- 第二步：数据库范围凭据（访问湖的钥匙）
CREATE DATABASE SCOPED CREDENTIAL cred_lake
    WITH IDENTITY = N'MSHDSPA', SECRET = N'访问密钥';

-- 第三步：外部数据源（远端在哪）
CREATE EXTERNAL DATA SOURCE src_lake
    WITH (LOCATION = N'abs://lakestore.dfs.core.chinacloudapi.cn',
          CREDENTIAL = cred_lake);

-- 第四步：外部文件格式（数据长什么样）
CREATE EXTERNAL FILE FORMAT fmt_parquet
    WITH (FORMAT_TYPE = PARQUET, DATA_COMPRESSION = 'org.apache.hadoop.io.compress.SnappyCodec');

-- 第五步：外部表（像普通表一样查）
CREATE EXTERNAL TABLE ext_日志事件
(
    EventTime DATETIME2, UserId BIGINT, Action NVARCHAR(64)
)
WITH (LOCATION = N'/logs/2026/08/', DATA_SOURCE = src_lake,
      FILE_FORMAT = fmt_parquet);

SELECT TOP 100 * FROM ext_日志事件
WHERE EventTime >= '2026-08-20';     -- 引擎现场去湖里拉取符合条件的文件段
​

查询下推是性能的分水岭。对支持计算下推的源（Hadoop、部分对象存储场景），过滤与聚合会被推到远端执行，网络只传结果；不支持时全量拉回本地算，外部表查询就可能慢成灾难。所以外部表查询的第一条纪律是看计划确认下推，第二条是利用文件分区布局（按日期分目录的外部表，带分区列的谓词能跳过无关文件）。2019 版后 PolyBase 从独立服务转为实例内置组件，2022 版进一步把对象存储直查做成引擎原生能力（CREATE EXTERNAL TABLE 的 REST 语义、OPENROWSET 直查函数），虚拟化的配置成本持续下降。

安全与治理：引用思维的新考题

数据虚拟化改变安全边界。数据不落本地是优点，但凭据管理与行级访问要重新设计：外部数据源的凭据放在数据库范围凭据里，权限授予用"外部表的对象权限"而不是把钥匙交给查询者——查外部表的人拿不到密钥。审计沿用第 7 章的审计框架，外部表访问与本地表一视同仁地留痕。治理上要防止"影子管道"：外部表多了以后，哪些数据被谁引用、源头 SLA 是什么，必须有登记册——数据虚拟化降低了接入成本，也降低了"随手建个外部表"的混乱成本，登记册就是那道闸。

一次应用归档：风控团队要把应用库的交易数据与数据湖的行为日志做联合分析，原方案是每周把日志抽进库（约四小时管道加一次失败修复）。改外部表方案后：交易表本地、日志外部表，联合查询直接跑，管道整个下线；代价是跨源查询耗时两分钟（仅分析师临时分析用，不进线上路径）——用"可接受的慢"换掉"必须维护的管道"，这笔账在低频场景永远划算。

直查的两副面孔：外部表与即席直查

对象存储直查有两种姿势，分场景选用。外部表是持久登记：建一次、反复查、可授权、可审计，适合"这批数据是长期数据资产"的场景；元数据在本、数据在湖上，权限与血缘都清晰。即席直查（新版直查函数）是轻装上阵：一条函数调用直接指定文件路径与格式查询，不建任何持久对象，适合探索期——分析师第一次拿到一批新文件，先直查摸清结构与数据质量，确认有价值再升级为外部表。两副面孔的分工像租房与登记户口：先短租看房，住定了再落户。
实践中要防一个坑：即席直查没有权限与成本的收敛点，路径写在查询里意味着"谁能连库谁就能查到路径指向的数据"——凭据在数据源层管理、文件级访问控制交给湖侧。治理口径一句话：探索期允许即席，转正必须外部表加登记册，9.3 前文的引用登记制度就是为这一步准备的。

本节要点回顾

• 两种思维：ETL 是复制思维（管道成本持续），PolyBase 是引用思维（零副本、源头新鲜）；
• 三层对象：外部数据源、外部文件格式、外部表，五步建通一条直查链路；
• 下推决定性能：看计划确认过滤聚合被推到远端，分区目录布局让谓词跳过无关文件；
• 低频场景的账：用可接受的查询慢，换掉必须维护的数据管道，低频联合分析永远划算；
• 安全重新设计：凭据在数据库范围层、权限给外部表不给钥匙、审计与本地表同权留痕；
• 登记册是闸门：虚拟化降低接入成本也降低混乱成本，引用关系必须入册。

数据平台的扩展能力收官。最后一节回到开发者视角：应用与数据库之间的最后一公里——工具链、驱动与连接管理。