SQL Database in Fabric：一键集成AI的云数据库新范式

微软正在将SQL能力从本地延伸到云端，再融入Fabric统一数据平台。在近期的技术演示中，SQL Database与Fabric产品团队高级产品经理Sukhwant Kaur详细展示了这一产品的设计理念、核心能力与典型场景。本文基于该演示，梳理SQL Database in Fabric如何以"简化、自治、为AI优化"三大支柱，改变开发者构建智能应用的方式。

Fabric是什么：一个平台承载所有数据工作负载

在深入SQL Database之前，有必要理解它所在的底座。Microsoft Fabric是微软面向AI转型的统一数据平台，将数据库、数据集成、分析、实时智能和BI等工作负载汇聚到同一平台。所有Fabric工作负载共享同一治理模型和OneLake存储层，这意味着没有数据孤岛、没有重复治理，也不需要把独立服务缝合在一起。平台各处内置Copilot，从编写查询到生成洞察都能提供辅助。

SQL Database in Fabric正是在这一框架下构建的，底层引擎与SQL Server、Azure SQL一致，开发者可以继续使用VS Code、SSMS等熟悉的工具。

OneLake是Fabric的租户级统一逻辑数据湖，本质上相当于整个组织共享的“OneDrive for data”。所有Fabric工作负载（包括SQL Database、数据工厂、Power BI、实时智能等）都将数据以Delta Parquet格式写入这一个存储账户，无需在服务之间搬运或复制数据。OneLake支持快捷方式（Shortcuts），可以引用外部ADLS Gen2、S3等存储中的数据而不产生副本，同时提供统一的权限与治理入口。这种单一份数据底座的架构，正是Fabric能够消除数据孤岛、避免重复治理的根本原因，也是SQL数据“自动镜像”后能被跨引擎直接查询的前提。

三大设计支柱：简化、自治、AI优化

产品团队围绕三个支柱设计SQL Database in Fabric，演示中也按此结构逐一展开。演示者还分享了已观察到的典型场景：运营数据存储、事件驱动应用、Power Apps、Web应用、元数据驱动的管道、向量与相似度搜索、RAG应用、反向ETL、Power BI写回以及参考数据存储。

简化：分钟级创建，自动镜像到OneLake

"简化"的核心目标是让用户把时间花在解决业务问题上，而不是管理数据库。创建过程只需命名数据库，无需服务器配置，几十秒即可完成，配合示例数据几分钟内就能开始查询。编辑器提供完整的T-SQL体验与IntelliSense，Copilot内置于编辑器中，可帮助写查询、生成洞察甚至排查性能问题。计费通过Fabric容量模型统一结算，一份容量、一张账单。

更具差异化的是自动镜像功能。SQL数据会以近实时方式复制到OneLake，无需任何配置，在创建数据库时自动发生。这带来三重价值：运营数据与分析数据统一，不必构建和维护ETL管道；数据以开源Delta格式落地，对所有用户可访问；通过快捷方式和SQL分析端点，可以跨平台查询数据而无需复制。过去在Azure SQL上做分析需要先建ETL把数据搬到数据仓库，现在这一步被完全省去。

Delta格式（Delta Lake）是一种构建在Parquet之上的开源表格式，为数据湖带来ACID事务、模式演进和时间旅行（time travel）等数据库级能力。它通过事务日志（_delta_log）记录每次写入，使并发读写和回滚成为可靠操作。在Fabric中采用Delta作为默认开放格式，意味着SQL Database镜像出的数据不仅可被Spark笔记本、Power BI Direct Lake等Fabric内引擎高效读取，也能被Databricks、Trino、Snowflake等外部平台直接消费，无需专有格式转换。这层开放性是把“运营数据”与“分析数据”真正打通的格式基础。

自治：把运维复杂度交给平台

客户反馈的痛点是数据库平台管理复杂、选型困难。产品团队的思路是自动化配置与管理的每个环节。每个SQL Database in Fabric都是无服务器架构，由Fleet Manager即时配置，用户一键创建后由平台处理扩展与管理。数据库自动获得区域冗余高可用，资源跨区域复制无需配置；智能查询处理能力如自动计划校正可检测查询计划回归并自动回退到先前计划，缺失索引会被自动检测并创建。备份与计量由系统全面托管，支持任意时间点还原。

安全方面，全面推行Microsoft Entra身份验证以实现无密码认证，审计可自动收集登录尝试和安全变更等关键事件。数据静态加密默认使用微软托管密钥，对治理要求严格的组织可使用Azure Key Vault中的自有密钥。与Microsoft Purview集成后，SQL数据库可像其他Fabric项一样按敏感度打标签，并自动应用集中管理的策略。

AI优化：在T-SQL内完成向量检索与RAG

这是演示中篇幅最重的部分。SQL Database in Fabric原生支持vector数据类型，可直接连接Azure OpenAI模型，在T-SQL中生成向量嵌入、执行相似度搜索并构建RAG应用，无需中间件或外部管道。数据与嵌入数据可以存放在同一位置。

演示展示了完整链路：先创建数据库作用域凭据，再用CREATE EXTERNAL MODEL定义嵌入模型，随后用AI_GENERATE_EMBEDDINGS函数为产品表生成嵌入并写入新增列。检索时，把用户问题（如"我想要一辆不贵的红色自行车"）转换为向量，通过向量距离函数找到最接近的条目。这一语义搜索正是RAG的基础。

演示者用通俗方式解释RAG：大语言模型知识广博，但不了解你的领域数据。向量搜索负责取回领域上下文，把上下文与问题一起送给模型，相当于给模型划出护栏——只基于给定上下文作答，而不是从"野外"知识里编造。演示中两个存储过程配合完成这一流程：一个负责组装payload并调用外部REST端点，另一个执行相似度搜索并调用前者。实际测试中，当用户询问"红色便携山地公路车"时，系统识别出当前没有红色款，转而推荐了另一款畅销车型——像一个真正的销售助手那样回应。

对于希望低代码构建AI应用的团队，Fabric生态提供了数据代理（Data Agent）功能，点击新建并指向SQL数据即可生成聊天应用；笔记本、数据管道、数据流和Direct Lake模式的Power BI也可参与其中。

向量嵌入是把文本、图像等非结构化内容映射为高维浮点数数组的过程，语义相近的内容在向量空间中距离更近。检索时通常使用余弦距离或欧氏距离衡量相似度，SQL Database中的向量距离函数即基于此。RAG（检索增强生成）正是利用这一特性：先从领域知识库中检索出与问题最相关的若干条记录，将其作为上下文拼入提示词，再交由大语言模型生成答案。相比微调模型，RAG无需重新训练即可让模型掌握私有数据，且答案可溯源到原始记录，因此在企业知识问答、客服助手等场景中被广泛采用。文中“给模型划出护栏”的比喻，指向的正是这种基于给定上下文作答、抑制幻觉的机制。

迁移与源控制：从既有数据库平滑过渡

演示还覆盖了两个工程实践话题。其一是迁移工具：选择DACPAC文件作为源，验证环节会列出哪些对象可顺利迁移、哪些存在问题，结果可导出为Excel、CSV或JSON。选定目标工作区和数据库名后开始迁移，完成后工具会列出发现的问题，用户可逐条借助AI修复脚本，再通过Fabric中的复制作业完成数据搬运。使用前需确认工作区有活动容量、本地数据网关已安装并验证、已创建网关启用的Fabric SQL连接。

其二是源控制与CI/CD。每个SQL Database in Fabric都可被源控制，Fabric Web界面直接支持GitHub与Azure DevOps。工作流分三段：在Fabric中提交数据库对象到Git仓库并与实时数据库同步；在VS Code或Visual Studio中用SQL项目开发，构建过程会校验对象引用并捕获语法问题；最后通过SQL Package命令行工具自动化部署，支持bacpac导入导出或在CI/CD环境中迭代部署DACPAC。演示完整走通了从编辑器提交、VS Code修改数据、创建脚本提交推送，到部署管道发布到生产、并在表中确认部署完成的流程。

DACPAC（Data-tier Application Package）是SQL Server生态中的数据层应用程序包，本质是一个zip压缩文件，内含数据库对象的定义（schema）而非数据本身。它由SQL项目构建生成，可用于部署或升级数据库结构，也是SQL Package命令行工具的核心输入之一。相比之下，bacpac同时包含schema与数据，适合整库迁移或导入导出。在CI/CD流程中，DACPAC常被用来做增量部署：工具会对比目标数据库与DACPAC的差异，自动生成必要的变更脚本。理解DACPAC与bacpac的区别，有助于判断迁移场景中何时只需同步结构、何时需要连同数据一起搬运。

端到端架构：一个数据库连接整条AI链路

演示结尾给出了一张许多客户正在采用的架构图。SQL数据库位于中心，连接到Microsoft Foundry生成嵌入并存储在同一位置；数据近实时镜像到OneLake后，业务用户可基于OneLake创建Power BI报表而不给SQL数据库增加负载，分析人员也可用笔记本将部分数据与其他OneLake项组合。面向消费者的一侧，可通过GraphQL创建API层，把端点交给开发者构建聊天机器人应用，全程可以低代码甚至无代码完成。

从这次演示可以看出，SQL Database in Fabric的定位不是又一个云数据库，而是把数据库、分析、治理与AI能力压缩进同一条流水线。对已经在使用SQL Server或Azure SQL的团队而言，迁移门槛被刻意做低；对想快速验证RAG类应用的开发者而言，向量能力直接内置在T-SQL里，省去了搭建外部向量库和同步管道的工程成本。这种"数据库即AI应用底座"的思路，值得在选型时纳入考量。