數(shù)據(jù)同步是現(xiàn)代數(shù)據(jù)架構(gòu)里的老問(wèn)題。寫(xiě)進(jìn)去容易，實(shí)時(shí)同步難——這句話(huà)放在Elasticsearch身上尤其貼切。作為現(xiàn)代數(shù)據(jù)棧的核心組件之一，Elasticsearch和關(guān)系型數(shù)據(jù)庫(kù)、緩存、實(shí)時(shí)數(shù)倉(cāng)、消息中間件并肩作戰(zhàn)，但當(dāng)你需要把數(shù)據(jù)從一個(gè)ES集群搬到另一個(gè)ES集群時(shí)，事情就變得棘手了。

本文介紹一種基于BladePipe和ES增量數(shù)據(jù)捕獲插件的實(shí)現(xiàn)方案。核心思路是繞過(guò)ES本身不提供實(shí)時(shí)變更數(shù)據(jù)捕獲（CDC）的限制，通過(guò)插件機(jī)制自己造一條數(shù)據(jù)管道。

ES的IndexingOperationListener插件API能監(jiān)聽(tīng)I(yíng)NDEX和DELETE兩類(lèi)事件。INDEX事件涵蓋插入和更新，DELETE事件就是常規(guī)的刪除操作。問(wèn)題是：監(jiān)聽(tīng)到變化后，怎么讓下游系統(tǒng)消費(fèi)這些數(shù)據(jù)？

方案設(shè)計(jì)了一個(gè)專(zhuān)用索引cc_es_trigger_idx作為增量數(shù)據(jù)的臨時(shí)容器。這個(gè)索引的結(jié)構(gòu)里，row_data字段存INDEX操作后的完整數(shù)據(jù)，pk字段存文檔的_id。其他字段包括create_time記錄時(shí)間戳、event_type標(biāo)記事件類(lèi)型、idx_name標(biāo)識(shí)來(lái)源索引、scn作為全局遞增的序列號(hào)。

消費(fèi)端按scn字段順序批量掃描這個(gè)索引，編碼風(fēng)格和SAP Hana作為數(shù)據(jù)源時(shí)保持一致。整個(gè)流程跑通后，數(shù)據(jù)就能從源ES實(shí)時(shí)流向目標(biāo)ES。

但這里有個(gè)硬門(mén)檻：ES對(duì)插件依賴(lài)的第三方包檢查極嚴(yán)。版本沖突、依賴(lài)不匹配都會(huì)導(dǎo)致插件加載失敗。插件必須和ES版本精確匹配，包括小版本號(hào)?？紤]到為每個(gè)版本預(yù)編譯包不現(xiàn)實(shí)，這個(gè)插件選擇了開(kāi)源放在GitHub上，讓用戶(hù)按自己的環(huán)境自行編譯。

部署時(shí)需要兩步：先按文檔裝好ES增量捕獲插件，再下載BladePipe Worker（Docker或二進(jìn)制部署均可）。注意Worker規(guī)格至少選1GB內(nèi)存，配小了會(huì)直接OOM。