笔者之前的文章《为什么 SAP Knowledge Graph 能让 LLM 输出的内容更靠谱》，介绍了 SAP HANA Cloud 于去年发布的 Knowledge Graph Engine（简称 KGE）.
传统 OLTP/OLAP 与属性图分析往往各有所长：关系模型擅长结构化数据管理，属性图则擅长路径发现与连通性分析。
可当业务问题走向语义对齐、跨域推理、多源知识整合与当今炙手可热的 AI 领域里的 LLM Grounding 时，就需要以 RDF 与 SPARQL 为核心的知识图谱栈来表达可复用的事实与本体。
有鉴于此，SAP 在 TechEd 2024 宣布了为 SAP HANA Cloud 新增 Knowledge Graph Engine 的计划，并在 2025 年陆续提供 GA 能力，使其成为 HANA 多模型体系里专门面向 Knowledge Graph 的引擎，与已有的属性图引擎与向量引擎并列协同。
SAP HANA Cloud Knowledge Graph Engine 的核心特征，用一句话概括：在同一个 HANA Cloud 数据库里提供原生 RDF 三元组存储、SPARQL 1.1 查询与更新、命名图管理、以及 SQL 与 SPARQL 之间的互操作，并能与向量引擎、空间引擎等组件做混合检索与混合推理，从而把结构化表、语义图谱、嵌入向量与地理空间语义放进一条查询管线里。
从时间线来看这是一个相当新的功能。
SAP HANA 还有一些发布已经很长时间，但因为种种原因并不为所有人熟知的功能和特性，比如 SDA – Smart Data Access.
之前我的知识星球里有一些朋友咨询，他们的 SAP 系统需要查询外部 PostgreSQL 数据库，具体应该怎么实现。
很遗憾，在 ABAP 系统里没有办法使用 OPEN SQL 「直接连接」MySQL 和 PostgreSQL 这两种外部数据库。
至于原因，笔者这篇文章已经做了很清楚的阐述：
SAP ABAP 系统到底支不支持通过 OPEN SQL 直接访问外部的 MySQL 和 PostgreSQL 数据库？
不过我们可以换一种思路，不在 OPEN SQL 这个方向死磕。另辟蹊径的办法之一就是利用 SAP HANA 的 SDA 能力。
HANA SDA 的全称 Smart Data Access，这项能力可以在 SAP HANA 中把远端数据源「虚拟化」为本地对象进行访问。
对这些虚拟表进行查询时，无需把数据预先复制进 HANA，而是像访问本地表一样，同样能达到访问远端数据库表或视图的效果。
SAP HANA 的优化器会尽量把筛选、聚合等运算下推到远端，以减少网络数据搬运。
SDA 的官方文档：
https://help./docs/SAP_HANA_PLATFORM/6b94445c94ae495c83a19646e7c3fd56/a07c7ff25997460bbcb73099fb59007d.html
开发人员只需在 HANA 里创建一个虚拟表，该虚拟表仅持久化远端数据源的元数据，真正的业务数据仍在远端数据源。
查询命中虚拟表时，HANA 会作为代理，自动去访问远端数据源，整个查询过程对于数据访问的发起者来说都是透明的。
在云与本地的混合场景中，HANA Cloud 支持多种远端源类型与适配器，既包含通过 ODBC 访问的传统数据库，也包含通过 HTTP/REST 访问的数据源。
SDA 支持的所有远端数据源类型见下表，可以在上面提到的官网里找到。
HANA SDA 工作原理与核心构件
Remote Source：描述如何连接远端数据库或系统，包括适配器类型、网络参数与凭据等。创建远端数据源的 SQL 是 CREATE REMOTE SOURCE.
Virtual Table（虚拟表）：定义好远端源后，通过 CREATE VIRTUAL TABLE 在本地创建一个指向远端数据库表的虚拟表作为代理。该对象只保存元数据，真正的数据始终保留在远端库中。
Predicate Pushdown（谓词下推）：HANA 优化器会尽可能把过滤、聚合等操作下推到远端执行，以减少拉回的数据量，降低网络开销。
下面聊一聊 SAP HANA Smart Data Access 的一些典型项目使用场景。
跨系统联邦查询(Federation Query)与报表
所谓联邦查询，通俗的说就是在多个「异构的外部数据源」之上执行一条 SQL 语句，在「不进行物理搬迁数据」的情况下返回汇总结果。
以 Google Cloud 的 BigQuery 为例，它提供 EXTERNAL_QUERY 来把查询下推到外部数据库，例如 Cloud SQL、AlloyDB、Spanner，执行完再把结果以临时表返回到 BigQuery，且自动做类型映射，这属于标准的联邦模式。
SAP HANA SDA 提供的联邦查询能力，比起 Google Cloud 的 BigQuery 丝毫不逊色。
在 SAP S/4HANA 与 BW/4HANA 并存的企业里，SDA 可以在 HANA Cloud 上把 S/4 的表虚拟进来，与云端自建表或第三方系统数据做 Join，构建统一视图用于即席分析，这一切发生在下图右侧 SAP HANA 的 Federation Adapter Framework 之中。
近线存储与冷热分层
所谓近线存储(Near-Line Storage)，是一种介于在线与离线之间的存储与查询层，它把访问频率低、更新稀少、但依然需要被业务按需检索的历史数据，从昂贵的在线数据库内存或高性能磁盘，迁移到更便宜、更大容量、可读但通常不可写的介质或数据库中，同时保持对业务查询的透明或半透明可见。
在 SAP 生态圈的近线存储场景中，一个最佳实践就是将历史冷数据落在 SAP IQ，热数据保留在 HANA.
SAP IQ 是一款面向企业级数据仓库与分析工作负载的列式关系型数据库，遵循标准 SQL，针对超大规模数据集的扫描、聚合与并发查询做了系统性优化，强调以列存储、位图与多级索引、强压缩实现更低存储成本与更高吞吐。
在企业数据平台里，SAP HANA 与 SAP IQ 这一对组合可谓是互补的黄金搭档：把不常访问的历史数据从 BW/BW4HANA 归档到 SAP IQ，而高频在线数据保留在 HANA；通过 SDA 把 IQ 里的归档透明地虚拟进 HANA 的外部视图里，既保留查询完整性，又把总成本拉低。
混合云与混合数据园区
在混合连接拓扑下，SDA 可以把 SAP HANA Cloud 同多种远端数据源进行接入，即下图架构图展示的所谓 Hybrid Landscape.
从协议视角看，上图的 Hybrid Landscape 的远程连接覆盖 ODBC、HTTP REST 与 JDBC 三类主干通道。
SDA 原生支持基于 ODBC 与基于 REST API 的远程连接；当你需要走 JDBC 连某些云数据源时，则引入 Data Access Agent 托管相应的 JDBC 适配器。
面向 ODBC 与 REST 的适配器已经内置在 SAP HANA Cloud 的数据库层；而 JDBC 适配器需在云端配置启用 Data Access Agent 才可使用。
从支持的目标数据源看，典型映射如下：
-
连接 SAP HANA 数据库：走 hanaodbc 适配器。
-
连接 Google BigQuery：走 bigqueryrest 适配器，属于 REST 路径。
-
连接 Amazon Athena：走 athena REST 适配器。
-
连接 Azure SQL 与 Snowflake：走 azuresql 与 snowflake 适配器，这两类通过 JDBC，需要启用 Data Access Agent.
这些适配器详细的启用和配置步骤，参考 SAP 官网：
https://help./docs/hana-cloud-database/sap-hana-cloud-sap-hana-database-data-access-guide/creating-remote-sources-smart-data-access
当然，SAP HANA Smart Data Access 也并非支持所有类型的 Remote 数据库，比如 PostgreSQL 就不被 SDA 支持。
那如果确实要把 SAP HANA 和 PostgreSQL 连接起来该怎么办？
SAP Note 2892211 – Hana SDA connection to Postgresql 回答了这个问题，解决方案是使用 SAP HANA 另一个技能：Smart Data Integration. 这个技能我们后续的文章详细再聊。