我都没找到市面上有招Datasphere的，虽然我感觉学了也没什么意义。但是今天闲着，就来学学看。
在Datasphere里有replication flow,相当于从第三方数据源拉数据到DSP里进行物理保存。这里涉及到数据库。还记得在HANA那篇我还有点模糊印象，HANA数据写入的时候，因为它是列存储，用到了Main storage和delta storage这种不同空间。可能传统数据库里也一样，要Delta merge,Staging还有commit这些机制。
在DSP里也是的，我要把数据拉进来，首先是写到一个buffer里，然后merge到local table里去。
这么设计有什么好处？
-
保证数据一致性
-
提升大批量数据加载性能
-
保证查询期间不会看到没加载完的数据（ 不能说你要加载1000万条，结果用户查的时候你才正在加，才加到500万条）
我们要的状态就只有两种，要么你看到没加载前的，要么是加载完成的。
HANA里面一直都是，数据进来，到Delta Storage，然后delta merge到main storage。
下面这个图是之前我写在HANA里的，我也没有DSP里的。如果我们来沿用这个概念，我可以理解成Main Storage里的肯定像是一个excel表，是已经按索引排序好的。这种就会查询很快，但是修改很慢。因为你假设在拍好序的1，3，7，9，11，13.。。中间插个2，4，5那每插一条，数据库都得重新排序。而给你一个Delta的空间就相当于说，好了，你新进来的数据别在我这个Main主档案室瞎搞，我这里都排好序了。你先去放到旁边的临时Delta仓库。放到临时仓库也是入库了。只要入了，就能读取。我读取的时候，肯定都能读到了。
数据先进来，然后我再找机会慢慢把临时仓库的也给merge到主档案室。过程就是下面这样：
先看左边，很好理解，插入到delta1,读取读的是Main 1 + Delta1 。
再看中间，Main1 和 Delta1正常被读取，新写入的插到Delta 2。现在同时被读的是 Main 1+Delta1+Delta2。而HANA后台创建了Main2， 这个Main 2就是Main 1+Delta 1的merge工作。也就是说这里HANA的脑子是这么想的，好了我现在在处理Main1和Delta1了，我再给你弄一个新的临时仓库Delta2来放新写入的数据。（这个跟BW的区别就在于，ADSO激活会锁表，但是HANA这里不会，既不会让你停止读取，也不会让你停止写入。一切都不受影响）
这里还有一点，就是在Main2工作的时候，它是去读取Main 1 + Delta1 然后进行压缩。这个Delta1可能是数据进来了有很多了，然后我进行压缩。所以可以肯定的一点是，它这个merge的时候占双倍内存，然后merge完成后瞬间释放Main1和Delta1，完成新指针切换。那就有一个疑问了，如果Main 1占了500G，那岂不是merge的时候要占到1000G往上？这个我管不着了，可能是basis要管的。
这张图上write和merge都有双箭头，我不理解。。。我猜是不是数据库交互时候的commit操作？
然后还有问题，merge是什么时候触发？我看BW4HANA的最后一步是有merge的，但是如果merge导致双倍内存占用，这就涉及到HANA性能问题了哦？到底该什么时候merge？我这个暂时还不知道。。。
再回过头来，既然DSP也是在HANA Cloud上，S4在HANA上，那还搞什么数据复制啊，直接view不就行了？永远拿到最新的veiw。根本不需要存储成本。
SAP不是也吹都是data fabric么？看到这个我就头疼。说明理想远比现实骨感。如果我一路从SAC钻进DSP的model再通过remote view一路直导S4老家。一点都不搬数据，那么会把S4整瘫。而且财务数据是要冻结的。不能说我查的时候还在动态实时变化。很多时候我只能给别人看某个时间节点后的数据。
而且有些数据有复杂的转换。做个几十步转换都是有的，先做个join，再做个union，然后来个计算，再搞个货币转换，如果全部远程。可想而知性能扛不住。
所以，还得搞混合模式，费性能的就复制过来，数据量小的就实时。