All in ECP，转转一站式ES数据清洗解决方案

1. 业务背景

转转作为国内头部的循环经济产业公司，目前业务架构是中台模式。中台负责提供通用的交易能力，灵活快速响应业务需求，业务方负责前台探索创新，为用户提供有价值的服务。

转转交易中台目前分为基础服务、订单、促销、天路、支付等方向，每个方向都拥有各自业务所需的ES索引，索引量级20+，数据量十亿以上。

随着转转业务的快速增长，目前研发对于ES类需求的手动支撑已无法满足业务的快速迭代诉求。目前不仅缺乏技术沉淀和数据积累，而且上手门槛高且效率低。为了解决痛点，ECP(Elasticsearch Chain Planning)系统应用而生。

2. 现状与问题

2.1 现状概述

根据历史经验，目前索引重建需要如下步骤：

1、确定需求方使用的索引
2、找到该索引最新一次使用的模板，编辑模板
3、根据模板创建一个新的索引（indexName_vn），其中n代表版本号
4、修改该索引的写逻辑handler
5、上线索引写服务
6、配置新老索引双写
7、找到或编写导出ID数据的(Shell或Python)脚本，执行并导出存量ID源（沙箱已被限制MySQL命令）
8、上传到清洗机上（沙箱或者线上），调用索引写服务的接口，触发数据清洗
9、修改索引读服务配置，增加对新字段的查询配置
10、切换索引别名，将流量指向新索引
11、停止双写
12、删除旧索引

2.2 存在的问题

1、人工操作脚本（Shell或Python）导出所有待清洗ID数据；目前沙箱已禁用MySQL命令(出于安全考虑)；文本比较大，经常遇到内存不足或磁盘不足的情况。
2、重建索引成本高，步骤多且效率低，订单索引重建一次大概需要5~7天的时间(Bulk方式)。
3、清洗进度无感知，无法预估完成时间。
4、无法断点续刷，失败后需要人工介入找到临界点后手动触发，费时费力。
5、索引存量清洗与增量清洗未隔离，可能会影响线上正常业务。正常渠道产生的增量数据和刷索引产生的存量会放置到同一个阻塞队列中，然后处理器读取该阻塞队列，进行数据处理，若处理失败，会将该条记录写入到Fail文件中，一分钟后读取该文件再次放置到阻塞队列中处理，如下图:

3. 解决思路

1. 抽象流程步骤，将索引刷新流程标准化&自动化&可视化，以提高效率和准确性。
1. 系统赋能，释放人力资源，提供完备的任务管理能力，包括中断恢复、进度可视化、QPS限流和心跳检测等功能。
1. 存量与增量隔离，利用架构部提供基于标签的流量路由能力，实现数据清洗存量数据与增量数据的环境隔离。
1. 权限控制与数据沉淀，接入公司统一权限管理系统，实现数据源与脚本管理、ES集群与索引管理(含模板管理)、任务管理，及操作日志记录等。

4. 实战揭秘

4.1 什么是ECP系统？

ECP(Elasticsearch Chain Planning)系统，即一个基于Elasticsearch的数据传输链路计划管理平台。在转转技术体系内，致力于协助研发运营人员高效管理ES的索引新建、数据清洗、索引重建等任务计划，并提供可靠的一站式任务流解决方案，提升ES类需求的响应效率。

4.2 ECP系统有哪些功能？

4.2.1 任务管理

任务管理包含ES索引新建、数据清洗、索引重建等任务流。它提供了多个独立模块，包括索引新建删除、别名切换、数据清洗、索引预热、双写管理等，同时还拥有任务进度可视化、暂停和恢复、QPS限流、中断自动恢复等能力，此外还留存了任务过程数据，方便日后复盘和查看。

4.2.2 数据源和脚本管理

主要管理数据库基本信息和获取源数据的SQL脚本，供任务获取源数据使用。它具有数据库连接检测、SQL语法校验及格式化等辅助功能。

4.2.3 集群和索引管理

主要管理索引的基本信息，如索引的名称、别名、磁盘占用、所属集群、分片数量、健康状态、部门归属等。

4.2.4 索引模板管理

主要针对索引模板进行集中管理，避免散落丢失，索引模板通常用于索引新建操作。

4.3 ECP系统解决了什么问题？

4.3.1 解决了ES索引重建数据清洗任务流程中的卡点和难点

例如原来刷ES索引需要从数据库手动导出一份ID文件，并传输至ES写服务的服务器上，然后远程RPC触发开始执行，过程中需要人工值守，中断手动重试。还有编写导ID的Shell或Python脚本、服务器之间文件上传下载、远程RPC端口转发、源索引模板缺失、进度不可见、中断无感知等重重难点。不但上手门槛高效率低，事倍功半；而且操作不规范，与公司日益规范化进程相悖。这次ECP解决了这些问题，使整个任务操作流程简单、顺畅、高效、规范。

4.3.2 解决ES索引数据清洗环境耦合及速率问题

原先ES索引存量数据清洗与线上增量数据共用同一队列，当清洗速率过大时，会影响线上正常数据的消费时效，影响用户体验，例如用户已经支付成功了，但是看到的仍是未支付等问题。本次ECP利用架构提供的基于标签的流量路由能力将存量与增量进行了机器隔离，彻底解决该痛点。理论上在下游服务承受范围内，只要增加ES写服务机器，即可提升存量数据清洗的速率。

4.3.3 解决索引、模板、脚本分散导致的需求响应低效问题

原先的索引、模板、脚本散落在各个角落，每次需求过来需要翻找上次需求使用的脚本和模板，由于人员的流动，经常找不见旧的脚本或模板，而需要研发重新造轮子。这样不但耗费时间精力，需求响应慢，业务感知较差；而且没有技术和数据的沉淀，缺乏系统性的持续迭代，进而提高效率。本次ECP将这些收拢起来，便于日后持续提效。

4.4 名词解释

4.4.1 任务

任务指为了完成某个目标而建立的活动或工作。具有目标明确、时间限制、进度追踪等特性。ECP系统中的任务通常有存量ID清洗任务，存量文件清洗任务，索引构建任务等。

4.4.2 索引簇(cù)和索引

索引簇是索引的抽象，索引簇定义了索引的唯一标识、模板、属性等，但没有具体的实现，类似于Java中的接口或类；而索引是索引簇的实例。例如：在订单列表场景中，“我卖出的”订单列表索引簇(唯一标识是：order_list)，实际索引实例为(order_list_v2)，假设业务需要新增一个索引字段，那么我们会新建索引实例(order_list_v3)，这里v2和v3索引都属于索引簇(order_list)的实例。

4.4.3 数据源

即数据的来源，在ECP中，分为ID源，文本源和MySQL源。

4.4.4 脚本

即MySQL源和SQL脚本的组合，可以从数据库中读取源数据。

4.5 整体设计

4.6 系统演示

4.6.1 新建任务

4.6.2 任务执行

5. 结语

5.1 总结

总的来说，ECP系统是一个基于Elasticsearch的数据传输链路计划管理平台，致力于为用户提供更加高效、便捷的数据清洗解决方案。我们会持续迭代系统的功能，以满足不断变化的业务需求和用户期望。

5.2 规划

目前ECP系统v1.0版本上线不久，仍处于团队内测阶段，索引刷新类需求提效已初露锋芒。接下来我们将持续完善和打磨，并计划在未来增加更多实用的功能。例如，清洗任务定时执行、reindex支持、别名切换回滚以及数据一致性校验等功能，这些功能将使日常的ES数据清洗工作更加高效便捷。我们非常感谢您的支持和关注，敬请期待！