更改表中字段时如何兼容历史数据？
比如下面这个例子是一个分析淘宝商家移动店铺数据的产品，其中菜单“流量来源”就是店铺流量分析。在店铺发展初期，“淘宝内免费”、“付费流量”、“自主接入”可以支持商家方对店铺数据的分析。然而，随着门店业务的不断发展，对流量分析的粒度要求越来越细化，但单纯的流量划分已经不能满足业务方的需求。希望对淘客内部流量有更细致的分类，帮助商家对店铺流量有更细致的了解，从而根据不同的流量大小调整运营策略，促进店铺销售数据的发展。
现状:淘内免费付费流量接入
期待:免费搜索我的淘宝淘宝，其他淘宝微淘宝手扫等等。
需求:更改“流量来源”数据表中的字段。
当原有产品不能满足当前业务发展时，为了满足业务新需求，服务新场景。我们必须改变原来的产品设计和表中的字段设计。更改“数据表”的字段很容易导致数据冲突，包括数据类型冲突和数据格式冲突。
如果在更改表字段时不考虑数据冲突的影响以及如何兼容历史数据，就会导致产品中数据的完整性和一致性出现问题。比如上面的案例，如果不做历史数据兼容性处理，选择在3.19号上线新的统计功能，那么流量划分会有两种不同的统计方法，19号之前的流量数据划分和19号。
历史数据在某种意义上成了“脏数据”，有“垃圾数据进，垃圾数据出”的说法。对于分析结果来说，数据质量甚至比分析方法和模型更重要。混有脏数据的输出结果对业务造成严重影响，甚至做出错误决策，带来不可磨灭的损失。
因此，我们有必要解决“表变字段”后的数据冲突，兼容历史数据，减少变化对数据的负面影响。那么问题来了，怎么才能做到和史料兼容呢？
01历史数据需要保存？
在表的变更字段发生数据冲突后，我们在兼容历史数据之前可以思考一个问题:是否所有的历史数据都需要保留？我们来看看下面两个场景。
场景1
某电商to b产品在一次迭代中，在“店铺销售”的菜单中增加了“客单价”这个字段，那么历史数据中的客单价对我们有什么意义吗？
场景2
我们设计了一套问卷来统计国内大学生不同专业的就业情况，并在一段时间后修改了问题，那么收集到的历史数据对我们是否还有意义？
通过两个具体场景，我们可以发现不同场景下“历史数据”的留存策略是不同的:
场景1中的“客单价”可以帮助复制店铺的历史客单价，与当前的“客单价”进行对比，指导店铺策略。在这种情况下，历史数据非常重要，需要保存。
但场景2中收集的“你的国家是什么”与“国内大学生”这一题目存在矛盾，而该题目是为解决这一矛盾而修改的，所以该题目收集的史料无效，可以直接毫无保留地丢弃。
历史数据是对过去业务情况的记录和反馈，但不是所有的历史数据都有意义，也不是所有的历史数据都需要保留。在考虑历史数据的兼容性之前，建议从实际场景出发，分析“历史数据”对业务的价值和意义。如果是无关或错误的数据，直接丢弃历史数据就可以了。对于要保存的历史数据，我们需要考虑冲突在哪里，如何兼容。
如何与历史数据兼容
在思考了史料的价值和意义之后，我们决定保留史料，那么如何才能做到与史料兼容呢？首先需要区分不同的数据表变化会带来什么样的数据冲突，然后根据不同的冲突情况提出相应的兼容方案。
1.添加字段
我们经常会遇到在表上“加字段”的情况，比如增加新的业务字段，增加新的统计项目。
如果不兼容，添加的字段中将有新数据，但没有历史数据。在这种情况下，我们需要判断历史数据是否可以完成，如果可以，完成历史数据；如果不能完成，新增字段的历史数据将显示为空白。
2.减少字段
当出现“减少字段”的情况时，如果不处理，减少的字段不会有新的数据，但是有历史数据。在这种情况下，我们的处理方法是保留历史数据，减少统计后该字段的空白显示。
3.原有的字段统计逻辑或规则发生变化。
当统计逻辑或规则发生变化时，如果不进行数据兼容，由于新数据和历史数据的统计方法不一致，数据结果会有所不同。这时候就需要判断历史数据是否可以按照新的统计逻辑进行转换，如果可以，就按照新的逻辑重新统计；如果不能保留历史数据，并记录统计逻辑的变化。
4.在原始字段中向下钻取或合并统计数据。
这种变化会导致新领域与历史领域的关系，这就需要我们完成历史资料。例如，将字段A钻取到一个新字段B+一个新字段C，并根据钻取规则补充新字段B和C的历史数据值。
在实际场景中，会同时出现多种数据冲突，采用的解决方案也是多种方案的组合。
比如下面这个案例，我们迭代了“客户管理”模块，通过调查发现内部销售团队希望在“客户管理”菜单中增加“客户微信”字段，并提供根据客户等级自动计算“下次回访时间”的功能，于是我们调整了“客户管理”字段。
表格修改为:增加“客户微信”和“下次回访时间”字段，减少“创建时间”字段。有“加场”和“减场”两种情况。通过分析“客户微信”和“下次回访”这两个字段对现有客户的意义，可以收集客户的微信联系方式和具体回访时间，方便业务员开展业务，两个字段的数据也可以完成。减少的“创建时间”字段对业务几乎没有影响，可以丢弃。基于以上考虑，我们对“客户管理”菜单进行了如图所示的处理。
迭代上线后，产品生提出“下次回访时间”直接显示时间，对销售团队来说不直观。“下次回访时间”可以进一步处理，更加直观，因为“下次回访时间”字段原来的时间格式支持当前的规则转换，所以时间可以转换。
处理“下次就诊时间”的显示并计算“下次就诊时间”和当前时间之间的差值:
原始统计格式:yyyy-mm-dd
新的统计格式:x天回访；逾期x天。
随着业务的发展，我们遇到了字段的统计逻辑和规则无法转换的情况。“客户管理”中“意向产品”的可选项目由“商品1、商品2、商品3”变为“商品5、商品6、商品7”。变更前后的数据不可能简单地兼容，但是变更前后的数据对业务是有意义的，所以我们需要
从上面的案例中我们发现，换表并不只有一个冲突，我们采用的各种解决方案都有。
03兼容历史数据的价值和方案
表字段的变化会导致历史数据和变化数据的冲突，数据冲突会导致产品层面的数据不一致，进而导致用户无法理解前后的数据，从而对产品产生怀疑甚至负面情绪。
简单地在表中增减字段，对用户的影响相对较小，会降低用户的可读性。比如上面的案例，添加或删除字段会让用户混淆一些有数据的案例和一些没有数据的案例，增加理解成本。
但是，统计逻辑的改变不仅仅是简单的用户体验问题，还会对业务产生实际影响。比如上述意向产品中的可选产品发生了变化。如果历史数据在时间上不兼容，并对相关变化进行说明，很容易给业务员带来之前的商品还能销售的误判，最终导致订单错误甚至下单后无法发货，给公司业务带来实质性的损失。
可见，兼容历史数据的价值在于解决了这一系列的数据冲突，既保证了产品层面的数据一致性，又让用户了解了数据变化的原因，减少了用户的负面情绪和理解成本。更重要的是，既能帮助用户恢复业务，又能起到业务指导作用，避免意外和损失。
但是，历史数据的兼容性并不适用于所有场景。当我们涉及到较大的变化时，比如由于业务发生较大变化，原有的表字段被完全推翻重新设计时，不建议采用上述兼容方案。我们可以选择新旧数据交替过渡，原表提供对旧数据的支持，创建新表支持新字段的显示。这样就完成了历史存量业务向新业务的过渡。例如，如果需要重建整个项目，可以选择数据迁移方案。
现在遇到史料冲突，又需要兼容的时候，可以判断如何选择吗？