企业真正开始建设 SAP HANA 数据平台时，很快就会碰到一个绕不开的问题，数据到底应该留在原来的业务系统里，需要时远程查询，还是干脆复制一份进入 SAP HANA。这两个选择看起来只差一个复制动作，背后的系统架构却完全不同。如果采用远程访问，SAP HANA 中保存的往往只是 Virtual Table 一类的逻辑入口。查询真正发生时，SAP HANA 再访问远端系统，部分计算甚至可以通过 Query Pushdown 下推到远端数据库完成。SAP HANA Cloud 当前的 Smart Data Access 就承担着这类 Federation 场景，数据不必真的复制进入 HANA。而数据复制走的是另一条路。源系统里的数据会被真正搬进 SAP HANA，在目标端形成物理表或者 Replica Table。业务查询发生时，大部分计算可以直接依赖 HANA 自己的 Column Store、并行执行引擎和内存计算能力，不再要求每一次查询都跨网络访问源系统。SAP 官方在介绍扩展型 SAP HANA Landscape 时，把常见复制技术归纳为三条非常有代表性的路线，Trigger-based Replication、ETL-based Replication 和 Log-based Replication。对应的主要产品分别是 SAP Landscape Transformation Replication Server、SAP Data Services 和 SAP Replication Server。这三种方案表面上都在做数据复制，设计思想却截然不同。SLT 关注的是变化什么时候发生。SAP Data Service
从远程数据源复制到 SAP HANA，SLT、Data Services 与日志复制到底该怎么选
企业真正开始建设 SAP HANA 数据平台时，很快就会碰到一个绕不开的问题，数据到底应该留在原来的业务系统里，需要时远程查询，还是干脆复制一份进入 SAP HANA。这两个选择看起来只差一个复制动作，背后的系统架构却完全不同。如果采用远程访问，SAP HANA 中保存的往往只是 Virtual Table 一类的逻辑入口。查询真正发生时，SAP HANA 再访问远端系统，部分计算甚至可以通过 Query Pushdown 下推到远端数据库完成。SAP HANA Cloud 当前的 Smart Data Access 就承担着这类 Federation 场景，数据不必真的复制进入 HANA。而数据复制走的是另一条路。源系统里的数据会被真正搬进 SAP HANA，在目标端形成物理表或者 Replica Table。业务查询发生时，大部分计算可以直接依赖 HANA 自己的 Column Store、并行执行引擎和内存计算能力，不再要求每一次查询都跨网络访问源系统。SAP 官方在介绍扩展型 SAP HANA Landscape 时，把常见复制技术归纳为三条非常有代表性的路线，Trigger-based Replication、ETL-based Replication 和 Log-based Replication。对应的主要产品分别是 SAP Landscape Transformation Replication Server、SAP Data Services 和 SAP Replication Server。这三种方案表面上都在做数据复制，设计思想却截然不同。SLT 关注的是变化什么时候发生。SAP Data Service