很多 SAP 项目做到数据平台这一层时，都会碰到一个很现实的问题。业务数据并不只存在于一个数据库里。订单可能来自 SAP S/4HANA，客户主数据可能来自另一套业务系统，历史数据可能留在本地 SAP HANA，分析团队又可能把部分数据放在 Databricks。真正进入分析阶段以后，我们面对的已经不是单纯的数据库查询问题，而是数据怎样进入 SAP HANA Cloud、怎样保持更新、怎样在进入数据库之前完成必要的清洗和转换、出现同步故障以后又怎样快速定位的问题。
SAP HANA Cloud 的 Replication 能力正是围绕这条链路展开。SAP 当前的 Feature Scope 把这部分能力概括得很紧凑，包括连接多种数据源、复制数据、在复制过程中进行过滤或者转换、利用Flowgraph完成抽取转换加载，以及监控整个数据集成过程。与它并列的另一项能力是地址数据质量，可以对地址进行解析、标准化、校验、纠错和补充，并为有效地址增加地理编码信息。
只有把这几句话放回 SAP HANA 的整体数据访问架构中，才能看清它们真正解决的是什么问题。
Replication 并不是简单地把一张表复制一遍
谈 SAP HANA Cloud 的数据复制，容易产生一个误解，以为所谓 Replication 就是把源数据库的一张表完整拷贝到目标数据库。
真正的企业级数据复制远比一次性的INSERT INTO SELECT复杂。
源系统中的业务数据一直在变化。销售订单被创建，交货状态发生改变，客户地址被修改，库存数量持续更新。SAP HANA Cloud 如果只是每天凌晨重
