很多 SAP HANA Cloud 项目真正进入数据集成阶段之后，都会碰到一个很现实的问题。总部还有 SAP HANA On-Premise，外围系统运行着 Microsoft SQL Server，一部分业务数据库已经迁到 Microsoft Azure，新的分析应用却开始统一落到 SAP HANA Cloud。数据当然可以通过远程连接访问，但随着查询量增大，网络延迟、跨系统 Join、远端数据库负载以及数据新鲜度之间的矛盾会越来越明显。这时，架构讨论通常会从一个看似简单的问题开始。数据到底应该留在源系统，通过 Virtual Table 实时访问，还是应该复制到 SAP HANA Cloud 本地？SAP HANA Cloud 给出的答案并不是二选一。通过 SAP HANA Smart Data Integration，也就是 SDI，以及 SAP HANA Smart Data Access，也就是 SDA，我们可以在数据虚拟化、快照复制和实时复制之间建立一套相当灵活的数据访问架构。SAP 官方当前的 Getting Started Guide 也明确把 Remote Data Replication 分成 SDI 和 SDA 两条主要技术路径。这里最容易产生误解的地方，是把 SDA、SDI、Virtual Table、Replica Table、Replication Task 甚至 SAP HANA 自身的 Table Replication 混成一个概念。实际上，它们解决的是不同层次的问题。理解远程数据复制，最合适的切入点不是从某个 SQL 命令开始，而是从数据究竟在哪里执行开始。 SAP HANA Cloud 远程数据复制全景解析，SDI、SDA 与 Remote Table Replication 到底该怎么选
很多 SAP HANA Cloud 项目真正进入数据集成阶段之后，都会碰到一个很现实的问题。总部还有 SAP HANA On-Premise，外围系统运行着 Microsoft SQL Server，一部分业务数据库已经迁到 Microsoft Azure，新的分析应用却开始统一落到 SAP HANA Cloud。数据当然可以通过远程连接访问，但随着查询量增大，网络延迟、跨系统 Join、远端数据库负载以及数据新鲜度之间的矛盾会越来越明显。这时，架构讨论通常会从一个看似简单的问题开始。数据到底应该留在源系统，通过 Virtual Table 实时访问，还是应该复制到 SAP HANA Cloud 本地？SAP HANA Cloud 给出的答案并不是二选一。通过 SAP HANA Smart Data Integration，也就是 SDI，以及 SAP HANA Smart Data Access，也就是 SDA，我们可以在数据虚拟化、快照复制和实时复制之间建立一套相当灵活的数据访问架构。SAP 官方当前的 Getting Started Guide 也明确把 Remote Data Replication 分成 SDI 和 SDA 两条主要技术路径。这里最容易产生误解的地方，是把 SDA、SDI、Virtual Table、Replica Table、Replication Task 甚至 SAP HANA 自身的 Table Replication 混成一个概念。实际上，它们解决的是不同层次的问题。理解远程数据复制，最合适的切入点不是从某个 SQL 命令开始，而是从数据究竟在哪里执行开始。 RELATED READING
延伸阅读
更多一线实战笔记与深度复盘，助您持续精进
)
