ES动态映射导致的线上疑案

一. 事件背景

在凤巢的推广平台中，有对物料进行不同属性进行筛选排序的需求，由于物料的量级很大（单用户千万级物料），并且有根据物料关键词搜索和某些特定值搜索，所以需要一个全文检索的搜索引擎来满足物料筛选的需求。ElasticSearch是一个基于Lucene的搜索服务器，它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。由于它的实时搜索，稳定，可靠，快速，凤巢业务端利用它来实现全文检索的功能。
由于用户的物料是存储在MySql集群的，各种修改编辑操作也是对DB的操作，ES里检索的数据要保持一致性，必须要有数据流进行同步，于是我们就有了这样的一条数据流同步体系:

这一次的新需求需要在fusion模块中进行开发，让它支持新的字段的解析并同步ES,于是这次的问题就是围绕fusion来展开的

二. 案发过程

在线下进行开发的过程中，正好遇到了一些需要在ES里新增的字段，并且需要在消费数据流模块fusion配上这几个字段的映射逻辑与同步规则。其中还涉及到了一些中间的变量，但是不需要新增ES的，于是在映射的配置文件xxx.yaml里也加上了这几个中间变量，但是没有修改ES的schema(因为不想让内存中计算的中间字段占用多余的存储空间）。于是设计完后在线下进行了代码的部署，于是很开心的进行了开发和测试。自己测试无误后，还邀请QA同学帮忙一起测试。等到大家都确认没有了问题之后，我们就开始上线消费数据流的fusion模块了。
但是没想到诡异的事情出现了:线上的数据流全量导入基准刷数据的时候特别慢，一直卡着。而且上线之后，测试了一些字段的数据流同步是正常畅通的。结果到了第二天，由于有事出行了，帮忙处理ES的同学立刻告诉我线上数据流同步出现了问题，并且有大量的重试消费日志打满了很多机器的磁盘。于