《Elastic Stack 实战手册》——三、产品能力——3.5 进阶篇——3.5.13.Transform （3） https://developer.aliyun.com/article/1228174
任务修改
ES允许我们在 Transforms 任务运行时修改任务，只需要发送如下请求：
POST _transform/<transform_id>/_update { // request body }
请求 body 是创建任务 body 的子集，即除了pivot属性只能在创建时配置外，其他属性都能在任务创建后修改。
任务销毁
当 Transforms 任务完成它的使命，我们可以彻底删除它，仅需要发送1个 Delete 请求即可，具体如下：
DELETE _transform/<transform_id>?force=true
用于指定任务id，请求可以传入1个force参数，当是true时，无论当前状态如何，都会删除任务。默认值为false，这意味着必须先将任务暂停即状态为 stopped才能将其删除。
使用建议
之前的小节已将详细的介绍了有关 Transforms 任务的 API，相信大家对它的功能已经有了一个大概的认识。其实 Transforms 的本质是使用现有的Aggregation API来处理的，那么什么时候使用Transforms什么时候使用Aggregation呢？那么作者建议有以下情况时可以考虑使用Transforms而非Aggregation。
1、当需要聚合每个分桶详细的统计，而非 Top-N 时，则可以考虑使用 Transforms，此需求在机器学习的场景中比较普遍。
2、当你有搜索1个或多个聚合结果并要求返回结果排序时，可以考虑 Transforms。虽然
Aggregation API 也可以排序和过滤，但由于每个桶有最大返回数据量的限制，所以效果没有
Transforms 好。
3、如果有对管道集合（Pipeline aggregations）排序的需求，建议用 Transforms ，原则上管道聚合不支持排序。
4、如果聚合请求场景单一且频繁，比如结果用于绘制看板，建议使用 Transforms 可以提高响应速度，减少资源消耗。
在Transform任务持续运行是，ES使用检查点机制来判断是否有变更需要同步到目标索引中。具体逻辑是，每经过frequency配置的时长，ES便会查看sync.time.field属性在当前减去
sync.time.delay到上一个检查点这段时间范围内有没有新增或变更文档。如果没有则不生成新的检查点，如果有则生成新的检测点。生成新检查点时会根据pivot.group_by的分桶设置，查看上述时间范围内有哪些分桶发生了改变，对于改变的分桶重算其统计值。整个过程需要注意2点。第一，如果新插入文档的sync.time.field属性不在当前到上一个检查点的范围内，则也不会触发生成新的检查点。比如，上一个检查点是1585344558000，之后2分钟内仅在1585346418010时插入了一个新的文档，但该文档sync.time.field属性的值是1585344557000，那么在1585346478000检验时，由于1585344557000不在 [1585344558000,1585346478000] 范围内，索引不会创建检验点，因此目标索引的统计里也不包含此条文档。第二，当生成新的检查点时，仅会更新新检查点到上一个检查点之间有变更的分桶，更新方式是基于所有索引内所有文档计算变更分桶的新汇总信息。比如，上一个检查点的时间是t1，新检查点是 t2 ，sync.time.field属性在 [ t1, t2 ] 时间范围内新增了3个文档，他们分别落在 a，c，d 3 个分桶中，那么将使用 [0,t2] 时间段内的全部文档重新计算这3个分桶，b 分桶由于没有变化则不会重新计算。
最后我们来聊一聊Transforms的限制，具体如下：
1、单个集群最多可以创建1000个 Transforms 任务。
2、目标索引最好手动创建，不要让 ES 自动创建，因为自动推断的映射可能与实际数据不符，这会导致任务在运行过程中不可用。
3、由于 Transforms 底层通常使用的是复合聚合（Composite aggregations），由于复合聚合不支持搜索上下文，如果任务正在进行时源索引有删除、更改、新增数据，那么此次任务可能会遗留这些变更，后端变更触发分桶重算时这边变更才会被统计。
4、只有当sync.time.field属性已更新并且在2次检查点的时间范围内，更改的实体才会被识别。
5、如果源索引删除了部分数据且有些分桶只在删除数据里有，新增文档不包含这些分桶，那么目标索引的这些分桶永远不会被删除成为脏数据。
6、删除 Transforms 任务不能删除目标索引即使这个目标索引是自动创建的。
7、由于 Transforms 任务底层使用复合聚合，该聚合支持分页，非常适合分桶数多的聚合。对于 Transforms 任务我们优化的重点应该是控制其资源的使用而非效率，max_page_search_size可用来控制复合聚合最大的分页数，较小的分页数可以减轻集群压力，但过小会导致每次任务耗时较长。
8、索引的index.max_terms_count控制Term查询中可以使用的最大term数，因此该值必须大于max_page_search_size，如果max_page_search_size超过index.max_terms_count，任务将失败。
9、失败的任务仍然是一项持久任务，正确是处理方式是删除它或解决失败的根本原因并重新启动。
10、由于录入 ES 的文档并不是立马可搜索的，在不可搜的时候有任务执行，则会导致统计结果不准。其原因是任务判断是否有变更的依据是搜索sync.time.field在当前时间减去sync.time.delay延迟到上一个检查点范围内是否有变更文档，不可搜会导致错过本次检测，同时下次检测的时间范围也不包含此次更新，因此只要能保证在sync.time.delay时间内文档达到可搜的状态，即可此种情况。
11、即便你的数据是date_nanos类型，但聚合精度只能达到毫秒级。
12、数据流Data streams不能作为目标索引。
创作人简介：
骆潇龙，目前在快手从事数据平台系统研发工作。致力于学习领先的数据技术，激活数据价值，赋能业务，打造具有核心竞争力的数据平台。
