All in ECP,轉轉一站式ES數據清洗解決方案
一、業務背景
??轉轉作為國內頭部的循環經濟產業公司,目前業務架構是中臺模式。中臺負責提供通用的交易能力,靈活快速響應業務需求,業務方負責前臺探索創新,為用戶提供有價值的服務。
??轉轉交易中臺目前分為基礎服務、訂單、促銷、天路、支付等方向,每個方向都擁有各自業務所需的ES索引,索引量級20+,數據量10億+。
??隨著轉轉業務的快速增長,目前研發對于ES類需求的手動支撐已無法滿足業務的快速迭代訴求。目前不僅缺乏技術沉淀和數據積累,而且上手門檻高且效率低。為了解決痛點,ECP(Elasticsearch Chain Planning)系統應用而生。
二、現狀與問題
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文件中,一分鐘后讀取該文件再次放置到阻塞隊列中處理,如下圖:
三、 解決思路
- 抽象流程步驟,將索引刷新流程標準化&自動化&可視化,以提高效率和準確性。
- 系統賦能,釋放人力資源,提供完備的任務管理能力,包括中斷恢復、進度可視化、QPS限流和心跳檢測等功能。
- 存量與增量隔離,利用架構部提供基于標簽的流量路由能力,實現數據清洗存量數據與增量數據的環境隔離。
- 權限控制與數據沉淀,接入公司統一權限管理系統,實現數據源與腳本管理、ES集群與索引管理(含模板管理)、任務管理,及操作日志記錄等。
四、 實戰揭秘
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.1 總結
總的來說,ECP系統是一個基于Elasticsearch的數據傳輸鏈路計劃管理平臺,致力于為用戶提供更加高效、便捷的數據清洗解決方案。我們會持續迭代系統的功能,以滿足不斷變化的業務需求和用戶期望。
5.2 規劃
目前ECP系統v1.0版本上線不久,仍處于團隊內測階段,索引刷新類需求提效已初露鋒芒。接下來我們將持續完善和打磨,并計劃在未來增加更多實用的功能。例如,清洗任務定時執行、reindex支持、別名切換回滾以及數據一致性校驗等功能,這些功能將使日常的ES數據清洗工作更加高效便捷。