之前谈到数据同步，但我们知道，业务服务使用的数据和存储的数据是不完全一样。服务用到的数据是存储数据集合或者混合衍生集合的子集。因此，进程之间数据的同步更像是物化视图的同步。除了Oracle外，mysql对物化视图并没有很好的支持。而且文件和NoSQL类的数据管理系统，也有类似的子集同步需求。
子集同步本身，我们需要将这个过程分成几个步骤。首先是内存中数据同步，其次是静态数据的筛选，最后是增量数据的筛选。当子集被筛选出来后，在同步技术上和数据同步这个节所提到的数据库和静态文件同步技术，并没有本质上的差别。不同的是，子集同步多出一个步骤筛选。子集因为存在筛选，所以在范围上和数据同步是不一样的。数据亲和架构一直强调，进程和数据绑定，架构自动同步进程需要的数据，而子集所定义的数据范围才真正是进程所需要的数据。因此，子集同步才是真正有意义，是进程所需要的数据同步。
筛选触发的增量和存储触发的增量，在技术上有很大的问题。存储触发的增量在实践中比较简单，原始数据和变更后的数据存储在同一个地方，两者直接对比，就可以发布变更的数据。筛选则不同，筛选包括四个步骤：（1）捕获原始数据的变更；（2）原始数据条件判断；（3）原始数据的字段选择；（4）和同一记录的上一次结果比对差异。与此同时，筛选计算是在内存中完成的，和结果存储通常不是在一个地方，只有在计算结果和上次存储结果存在差异，才被认为发生了变更。子集的增量变更因为存在上述两点，导致难度要高于全集的增量变更。在市面上，并没有完成这个功能的现成组件。
子集的增量是基于存储增量变化的流式变化，在加上筛选，从广义上来看，可以视为一种流式计算。但从业务开发者角度来看，却不能视之为一个流式计算，因为他需要更为简单的接口和实现方式，如SQL语法。在数据亲和架构的设计之初，就是从业务开发这角度来思考这个问题，因此，如何提高开发效率也是一个重要的考虑因素。
