背景：
最近在做资料整合的工作，主要是系统之前，有两份用户数据，分别服务两个不同的APP应用，但是，目前要做资料整合，规则就是那边用户的资料新，就用那边的资料。 比如，A 和 B 两个应用，用户C先用了A应用shu，然后用了B应用，B应用那边新增的资料，就相对比较新，整合完后，用户C就统一为B 应用的资料。
看起来很简单，但是有以下难点：
1. A应用，他有自己特殊的数据，比如，签名；B应用，他有自己特殊的数据，比如，头像；如何整合，让以后用户C，使用A应用，就可以获取到A应用特殊的数据；使用B应用，就获取到B用户特殊的数据；
2.资料是采用最新的，存在一个问题，资料有多维属性，但是，时间戳只有一份。如何控制好多维属性的更新，和预估可能的后果。
最初，方案的设想，是后端做数据的汇总，然后统一为一份数据，但是，有两个问题，第一，当时数据中心还没有对应的工具，第二，数据汇总，出错的话，回滚的成本比较高，暂时放弃。（但是，最后还是采用这种方案。）
后面，打算放弃应用B的数据，统一采用应用A的数据，这样实现简单，但是对应用B有一定是损害。
第三，程序层面做汇聚，判断时间戳，为对应的数据源获取数据。采用这种方式，实现相对复杂，但是可控。
由于产品的坚持，最后，使用了第三种方案。原先的计划和方案讨论完，实现后部署到现网，出现了一个大的问题。由于A应用没有头像时间戳（本来产品是计划发布A应用，让A应用有头像时间戳的），而B应用有头像时间戳。会导致一个问题，本来C本来在B应用上面有头像，而在A应用上面没有头像，但是A的数据比较新，则使用A的数据，这样，会导致用户原来的头像没有生效。
后面，讨论多种方案，由于客户端也存在异常的情况，导致该方案回滚，最后，统一采用最初的方案。
经过此次整合，得出的经验如下：
1.数据整合，涉及方方面面，在用户量少的情况下，越快做越好；
2.多维数据的交叉，程序层面做数据的判断，由于可能存在多种异常的情况，分支较多，容易出错，最好，还是从后端的数据汇聚层，做统一的整合。
资料整合