SAP HANA虚拟表与联邦查询实战：从Remote Source到性能优化

SAP HANA 里的虚拟表是个很容易被低估的东西。很多团队上了 HANA 之后，第一反应是把数据全部抽到本地列存里，觉得这样查询才快，结果 ETL 链路越堆越长，凌晨的加载窗口越排越满，业务方要一个跨系统的实时口径，数据团队得先等一轮调度跑完。我这些年做过的联邦查询场景里，虚拟表恰恰是解决这类问题的关键手段——它让你在不搬数据的前提下，直接对远端数据源发起查询，把计算压力留在该留的地方。

这篇内容围绕SAP HANA 虚拟表展开，从Remote Source的建立，到虚拟表（Virtual Table）的创建，再到联邦查询实际执行时 HANA 到底做了什么，我会把整个链路拆开讲清楚。适合已经有一定 HANA 基础、正在做跨系统数据集成、或者被 ETL 同步链路折磨过的朋友参考。哪怕你只是刚接触 Smart Data Access，看完也能明白虚拟表不是"魔法"，它的能力边界和性能陷阱在哪里，心里得有数。

1. 先搞清楚虚拟表到底解决了什么问题

1.1 从"搬数据"到"看数据"的思路转变

传统数据集成思路是 ETL：抽取、转换、加载。远端系统的数据先落到 HANA 本地表，再做建模和查询。这套模式的好处是查询性能可控，数据在本地列存里，HANA 的并行计算能力能充分发挥。但代价也很明显——数据有延迟，链路要维护，存储要翻倍，加载窗口一旦错过，下游全乱。

虚拟表走的是另一条路。它不在 HANA 里存实际数据，只存一份"元数据描述"：远端有哪张表、有哪些列、列是什么类型、在哪个 Remote Source 下。你查询虚拟表的时候，HANA 把查询语句的一部分下推到远端执行，拿回结果集再在本地做后续处理。数据始终留在源系统，HANA 只做"访问"和"部分计算"。

这个转变的意义在于：数据的时效性从"调度周期"变成了"查询时刻"。业务方要看的报表如果依赖远端系统刚产生的数据，虚拟表能直接读到最新状态，不需要等同步任务。对于跨系统的关联分析、低频但要求实时的查询场景，这个价值非常大。

但要注意，这不是说虚拟表能替代 ETL。高频、大数据量、复杂聚合的查询，走虚拟表往往性能很差，因为下推能力有限，大量数据要跨网络传输到 HANA 再计算。选型的时候必须分清场景，后面我会详细讲判断标准。

1.2 Remote Source 与虚拟表的关系定位

很多人把 Remote Source 和虚拟表混为一谈，其实它们是两个层次的东西。Remote Source 是"连接定义"，虚拟表是"对象映射"。

Remote Source 里配置的是：远端系统类型（比如另一个 HANA 实例、某类关系型数据库、大数据平台等）、主机地址、端口、认证方式、连接参数。它本质上是 HANA 里一个受管理的连接对象，所有对远端的访问都通过它走。

虚拟表则挂在某个 Remote Source 之下，指向远端的具体一张表或一个视图。创建虚拟表的时候，HANA 会去远端读取表的元数据（列名、类型、长度），然后在本地生成一个"壳"。这个壳可以被 SQL 直接查询，也可以参与本地表的 JOIN。

打个比方：Remote Source 像是你手机里存的一个联系人账号，虚拟表像是这个账号下的具体某个聊天窗口。你得先有账号，才能打开窗口；账号配置错了，窗口自然打不开。理解这个层次关系，后面排查问题的时候思路会清晰很多——连不上，先查 Remote Source；能连上但查不到数据，再查虚拟表映射。

1.3 联邦查询的能力边界在哪里

联邦查询（Federation Query）指的是 HANA 在一条 SQL 里同时访问本地表和远端虚拟表，由 HANA 的优化器决定哪些部分下推到远端、哪些在本地执行。这是虚拟表最有价值的能力，也是最容易踩坑的地方。

能力边界主要体现在三个维度：

• 下推能力：简单过滤（WHERE 条件）、列裁剪（只选需要的列）、部分聚合能否下推到远端，取决于远端系统的能力和 HANA 的适配器实现。下推得越多，跨网络传输的数据越少，性能越好。
• 数据量：虚拟表适合小结果集、点查、低频分析。如果一条查询要从远端拉回几百万行再做 JOIN，网络传输和本地内存都会成为瓶颈。
• 事务一致性：虚拟表查询不参与本地事务的隔离级别控制，远端数据的变化对查询是"读已提交"级别的可见性，跨系统的强一致性无法保证。

我见过不少团队一开始对虚拟表期望过高，想用它做实时数仓的核心链路，结果性能不达标又回头改架构。正确的定位是：虚拟表是补充手段，用于解决 ETL 覆盖不到或成本过高的场景，比如跨系统临时分析、低频维表关联、源系统实时状态查询。核心高频链路还是应该走本地化。

2. Remote Source 配置的关键细节

2.1 创建 Remote Source 的实操步骤

创建 Remote Source 有两种方式：图形化界面和 SQL 语句。图形化在 HANA Studio 或 Web IDE 里操作直观，SQL 方式便于版本化和批量部署。我倾向于用 SQL，因为可以纳入代码管理，环境迁移时直接执行脚本。

SQL 方式的核心语法结构如下（以适配某类关系型远端系统为例，具体适配器名称按实际环境选择）：

CREATE REMOTE SOURCE "RS_SOURCE_A" ADAPTER "hana" CONFIGURATION 'serverNode=10.0.0.1:30015;' WITH CREDENTIAL TYPE 'PASSWORD' USING 'user=REMOTE_USER;password=******';

几个关键点必须说清楚：

• ADAPTER：决定用哪个适配器去连远端。不同远端系统类型对应不同适配器，选错了连不上。这个值不是随便填的，得查当前 HANA 版本支持的适配器列表。
• CONFIGURATION：连接串，包含主机、端口等。不同适配器的参数名不一样，比如有的用serverNode，有的用host加port分开写。
• CREDENTIAL：认证信息。密码建议用凭证对象管理，不要明文写在脚本里，后面会讲。

创建完成后，可以用系统视图确认状态：

SELECT * FROM SYS.REMOTE_SOURCES; SELECT * FROM SYS.REMOTE_SOURCE_CREDENTIALS;

第一条看连接对象是否存在，第二条看凭证是否绑定成功。这两个视图是排查连接问题的第一站。

2.2 凭证管理的正确姿势

明文密码写在 CREATE REMOTE SOURCE 语句里，是最常见的坏习惯。脚本一旦进了代码库，密码就泄露了；环境迁移时还得手动改密码，容易出错。

正确做法是用凭证对象（Credential Object）：

CREATE CREDENTIAL FOR USER "DEVELOPER_A" COMPONENT 'SAPHANADB' PURPOSE 'REMOTE SOURCE' TYPE 'PASSWORD' USING 'user=REMOTE_USER;password=******';

然后把 Remote Source 关联到这个凭证上。凭证对象的好处是：密码和连接定义解耦，改密码不用动 Remote Source；权限可以按用户控制，不同开发者用不同凭证访问同一个 Remote Source。

注意：凭证对象的作用域和用户绑定，跨用户共享凭证需要额外的授权设计。生产环境里建议为每个 Remote Source 配置独立的服务账号凭证，不要用个人账号，避免人员变动导致连接失效。

我踩过的一个坑是：开发环境用个人账号建了 Remote Source，测试通过，上线后那个人离职账号被禁用，整条联邦查询链路直接挂掉。后来统一改成服务账号加凭证对象管理，才算稳定下来。这个教训值得记一下。

2.3 连接参数调优与超时设置

Remote Source 的连接参数直接影响查询稳定性，尤其是跨网络、跨机房的场景。几个值得关注的参数：

这些参数有的在 Remote Source 的 CONFIGURATION 里配，有的在 HANA 全局参数里调。具体位置随版本有差异，配置前查一下当前版本的参数文档。

连接池大小这个参数特别容易配错。有人觉得越大越好，结果远端系统被 HANA 的并发连接打满，影响了源系统的正常业务。我的经验是：连接池大小不超过远端系统分配给这个集成账号的连接配额的一半，留出余量给其他访问方。宁可让 HANA 侧排队，也不要打爆源系统。

3. 虚拟表创建与元数据映射

3.1 创建虚拟表的两种路径

虚拟表的创建也有两条路：一是基于已有 Remote Source 手动指定远端表名，二是通过图形化浏览远端对象树直接勾选生成。手动方式适合脚本化，图形化适合探索式开发。

手动创建的核心语法：

CREATE VIRTUAL TABLE "VT_ORDER_HEADER" AT "RS_SOURCE_A"."SCHEMA_A"."ORDER_HEADER";

这条语句执行时，HANA 会去远端读取ORDER_HEADER表的元数据，在本地生成虚拟表定义。如果远端表不存在或无权访问，创建会失败。

图形化方式在 HANA 的对象浏览器里展开 Remote Source，能看到远端的 schema 和表列表，右键生成虚拟表即可。这种方式的好处是能直观看到远端有哪些对象，适合初次对接时摸清数据结构。

两种方式生成的虚拟表本质一样，都是元数据壳。区别在于：手动方式需要你准确知道远端 schema 和表名，图形化方式帮你省去了记忆负担。生产部署建议用手动脚本，可重复、可版本化。

3.2 列映射与类型转换的坑

虚拟表创建时，HANA 会把远端列类型映射成本地类型。这个映射不是一一对应的，有些类型会"降级"或"近似"，这里是最容易出问题的地方。

举个典型例子：远端某个数值列是高精度小数，映射到 HANA 后如果精度不够，查询结果会出现舍入误差。再比如远端的时间戳类型带时区信息，映射后时区处理方式可能和预期不一致，跨时区业务要特别小心。

我的做法是：虚拟表创建后，立刻用SYS.TABLE_COLUMNS查一遍列类型，和远端定义逐列比对。

SELECT COLUMN_NAME, DATA_TYPE_NAME, LENGTH, SCALE FROM SYS.TABLE_COLUMNS WHERE TABLE_NAME = 'VT_ORDER_HEADER' AND SCHEMA_NAME = 'YOUR_SCHEMA';

发现类型不匹配的列，如果影响业务逻辑，就得考虑在远端建一个类型规范的视图，再基于视图建虚拟表，而不是直接映射原表。多一层视图看似麻烦，但能把类型问题挡在源头。

提示：远端表结构变更（加列、改类型、删列）不会自动同步到虚拟表。远端改了表结构，虚拟表可能查报错或读到脏数据。所以对接远端系统时，要和对方约定结构变更的通知机制，变更后及时重建虚拟表。

3.3 虚拟表与本地表的本质差异

理解虚拟表和本地表的差异，是判断"什么时候该用虚拟表"的基础。核心差异集中在四点：

• 存储：本地表有实际数据存储，虚拟表只有元数据，不占数据空间。
• 查询路径：本地表查询走 HANA 列存引擎，虚拟表查询要经过适配器转发到远端。
• 下推能力：本地表的所有操作都在本地执行，虚拟表只有部分操作能下推，其余要拉回本地算。
• 统计信息：本地表有完整的统计信息供优化器使用，虚拟表的统计信息往往缺失或不准，优化器可能选错执行计划。

最后一点特别隐蔽。虚拟表没有本地数据，HANA 优化器对远端数据分布一无所知，JOIN 顺序、聚合策略的选择可能很糟糕。我遇到过一条查询，本地表和虚拟表 JOIN，优化器把虚拟表当小表做驱动，结果远端返回海量数据，查询跑了十几分钟。后来手动调整 JOIN 顺序、加 hint 才解决。

所以用虚拟表，不能完全信任优化器的自动决策，关键查询要自己看执行计划，必要时干预。

4. 联邦查询执行过程拆解

4.1 一条 SQL 在 HANA 里经历了什么

当你查询一张虚拟表，或者用虚拟表参与 JOIN，HANA 内部的处理流程大致是这样的：

1. 解析与优化：SQL 解析成逻辑计划，优化器判断哪些操作可以下推到远端。可下推的部分（比如对虚拟表的过滤、列裁剪）生成远端执行片段，不可下推的部分留在本地计划里。
2. 下推执行：HANA 通过 Remote Source 的连接，把远端执行片段发给远端系统，远端执行后返回结果集。
3. 结果传输：远端结果集通过网络传回 HANA，落到本地临时结构里。
4. 本地计算：HANA 对传回的数据做本地部分的计算（比如和本地表 JOIN、本地聚合），生成最终结果。

这个流程里，下推比例决定了性能。下推得多，传输的数据少，本地计算轻；下推得少，大量原始数据跨网络搬运，性能急剧下降。

判断下推效果最直接的方法是看执行计划。HANA 的执行计划里会标注哪些操作在远端执行（Remote Execution），哪些在本地执行。如果发现本该下推的过滤条件没下推，就要查原因——可能是远端系统不支持该操作，可能是适配器能力限制，也可能是写法导致优化器无法下推。

4.2 下推能力的实测与判断

下推能力不是理论值，得实测。不同远端系统、不同适配器版本，下推支持的操作集不一样。我一般用一个小结果集但带复杂条件的查询来试探：

-- 测试过滤和列裁剪是否下推 SELECT COL_ID, COL_AMOUNT FROM "VT_ORDER_HEADER" WHERE COL_STATUS = 'ACTIVE' AND COL_DATE >= '2024-01-01';

看执行计划里 WHERE 条件是否出现在远端执行片段里。如果出现了，说明过滤下推成功；如果 WHERE 留在本地，说明远端没接这个条件，数据是全量拉回本地再过滤的——这种查询在大表上会非常慢。

聚合的下推更复杂。简单的 COUNT、SUM 有时能下推，但带复杂 GROUP BY 或窗口函数的聚合，下推支持往往有限。实测方法是构造对比查询，看远端返回的行数是聚合后的还是明细级的。

我的经验总结成一句话：能用简单过滤和列裁剪解决的，尽量在虚拟表查询里写清楚；复杂聚合和窗口计算，别指望下推，要么在远端建好聚合视图，要么把数据本地化。

4.3 JOIN 场景下的执行策略选择

虚拟表和本地表 JOIN，是联邦查询最典型的场景，也是最考验设计的地方。执行策略本质上就两种：

• 远端拉回再 JOIN：把虚拟表的数据（经过过滤和列裁剪）拉到本地，和本地表在 HANA 里 JOIN。适合虚拟表侧过滤后数据量小的场景。
• 本地数据推到远端 JOIN：把本地表的数据推到远端，在远端完成 JOIN。这种下推在多数适配器里支持有限，且要把本地数据传出去，网络和远端负载都要考虑。

实际执行时，优化器会根据统计信息选策略，但虚拟表统计信息缺失，选择经常不理想。我的实操建议是：

1. 先确保虚拟表侧的过滤条件充分下推，把拉回的数据量压到最小。
2. 如果本地表是小维表、虚拟表是大事实表，考虑把维表数据复制到远端做 JOIN，或者反过来把事实表按需本地化。
3. 关键查询用 hint 干预 JOIN 顺序，别完全交给优化器。

有个场景我印象很深：本地一张几千行的维表，和远端一张千万行的事实表虚拟表 JOIN。优化器默认把虚拟表当驱动表，拉回海量数据。改成先对虚拟表做时间范围过滤、再和本地维表 JOIN，数据量从千万级降到几万级，查询时间从分钟级降到秒级。差别就在过滤下推和 JOIN 顺序上。

5. 性能优化与常见问题排查

5.1 虚拟表查询慢的典型原因

虚拟表查询慢，原因基本逃不出这几类，我按出现频率排个序：

排查的第一步永远是看执行计划。执行计划告诉你数据在哪执行、传了多少行、用了什么策略。不看执行计划就调优，等于蒙眼开车。

第二步是量化数据量。在远端系统上单独执行下推的查询片段，看返回多少行；再对比 HANA 侧实际处理的行数。两个数字差距大，说明下推没生效或部分生效。

5.2 统计信息缺失的应对办法

虚拟表没有本地数据，HANA 收集不到准确的统计信息，优化器只能靠猜。这是虚拟表性能问题的根源之一。

应对办法有几个层次：

• 手动提供选择性提示：在查询里用 hint 告诉优化器大概的过滤选择性，帮助它选策略。
• 在远端建统计友好的视图：把复杂过滤逻辑封装到远端视图里，虚拟表基于视图建，让远端先做一轮数据收敛。
• 关键查询本地化：对性能要求高的核心查询，把相关数据定期同步到本地表，用本地表查询，虚拟表只做补充。

我个人的偏好是第三种为主、前两种为辅。虚拟表定位成"探索性查询"和"低频补充"，核心链路本地化，这样架构清晰，性能可控。把所有查询都压在虚拟表上，迟早会遇到性能天花板。

5.3 权限与连接问题的排查清单

虚拟表报错，很大一部分是权限和连接问题。整理一份排查清单，按顺序过一遍，能解决大部分问题：

1. Remote Source 是否存在且启用：查SYS.REMOTE_SOURCES，确认状态正常。
2. 凭证是否有效：查SYS.REMOTE_SOURCE_CREDENTIALS，确认凭证绑定且未过期。
3. 远端账号权限：确认远端系统上该账号对目标 schema 和表有 SELECT 权限。
4. 网络连通性：从 HANA 所在主机测试到远端主机的端口连通性。
5. 虚拟表定义是否过期：远端表结构变更后，虚拟表可能失效，需要重建。
6. 适配器版本兼容性：HANA 版本升级后，适配器可能需要同步更新。

注意：远端账号权限问题最容易被忽略。HANA 侧配置全对，但远端账号没有表的 SELECT 权限，查询照样报错。对接新系统时，先让远端管理员把权限配好，再建虚拟表，能省很多来回。

5.4 实操心得：什么时候坚决不用虚拟表

最后分享几条"坚决不用虚拟表"的判断标准，都是踩坑换来的：

• 单次查询要拉回十万行以上明细数据：网络传输和本地内存都扛不住，老老实实做 ETL。
• 需要跨系统强事务一致性：虚拟表保证不了，别硬上。
• 高频查询（每秒多次）：每次查询都要走远端连接，连接池和远端负载都吃不消。
• 远端系统本身负载已高：虚拟表查询会给远端增加压力，源系统业务优先，别去抢资源。
• 复杂分析型查询（多表 JOIN、窗口函数、复杂聚合）：下推支持有限，本地计算又缺统计信息，性能不可控。

反过来，虚拟表最适合的场景是：低频、小结果集、要求实时性、跨系统临时分析。把这几条记牢，选型时就不会跑偏。

我在实际项目里的体会是，虚拟表的价值不在于"替代 ETL"，而在于"填补 ETL 覆盖不到的缝隙"。把它放在正确的位置上，它能解决很多让人头疼的实时性和集成成本问题；放错位置，它就是性能事故的源头。技术本身没有好坏，关键是场景匹配。后续如果远端系统的下推能力有增强，或者 HANA 适配器对统计信息的支持有改进，虚拟表的适用边界还会往外扩，值得持续关注版本更新说明。