用微信扫码二维码

分享至好友和朋友圈

1. 业务背景

2. 现状与问题

2.1 现状概述

2.2 存在的问题

3. 解决思路

4. 实战揭秘

4.1 什么是ECP系统？

4.2 ECP系统有哪些功能？

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

4.4 名词解释

4.5 整体设计

4.6 系统演示

5. 结语

5.1 总结

5.2 计划

5.3 致谢

1. 业务背景

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

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

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

2. 现状与问题

2.1 现状概述

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

1、确定需求方使用的索引

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. 解决思路

抽象流程步骤，将索引刷新流程标准化&自动化&可视化，以提高效率和准确性。

系统赋能，释放人力资源，提供完备的任务治理能力，包括中断复原、进度可视化、QPS限流和心跳检测等功能。

存量与增量隔离，利用架构部提供基于标签的流量路由能力，实现数据清洗存量数据与增量数据的环境隔离。

权限操纵与数据沉淀，接入公司统一权限治理系统，实现数据源与脚本治理、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 数据源

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数据清洗工作更加高效便捷。我们非常感谢您的支持和关注，敬请等待！

5.3 致谢

在此感谢搭档@闫展同学的辛勤付出和不懈努力，也要感谢交易团队其它同学在此期间的任务分担，以及转转FE的低代码平台，ECP系统的顺利上线离不开团队成员间的紧密合作和相互支持。等待未来我们能走得更远，推动ECP系统健壮成长。

郭世杰，转转交易营销技术部研发工程师，主要负责订单方向的研发工作。在代码和人生中，拥抱变化，勇于面对挑战，追求卓越。

特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。

Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.