DB 與 Elasticsearch 混合應用之數據離線同步

作者介紹

李猛，Elastic Stack 深度用戶，通過 Elastic 工程師認證，2012年接觸 Elasticsearch，對 Elastic Stack 技術棧開發、架構、運維等方面有深入體驗，實踐過多種大中型項目；為企業提供 Elastic Stack 諮詢培訓以及調優實施；多年實戰經驗，愛搗騰各種技術產品，擅長大數據，機器學習，系統架構。

序言

首先解釋下即時、實時與離線概念定義，最近碰到很多的認知誤區，需要糾正下。

即時概念

當數據變更之後馬上就可以查詢變更，內部採用事務隔離機制，查詢的數據必須阻塞直到數據更新完畢，如單實例關係數據庫數據發生變更後，然後馬上可查詢到。

實時概念

在數據同步場景中，包括異構數據源和同構數據源之間，泛指在可接受的很快時間範圍內同步完成，一般的認知是秒級左右，也可以毫秒或者微秒，依據業務需求與實現能力定義。如 MySQL 主從同步也做不到即時性，只能實時性，業務系統如果做讀寫分離，也僅限非即時數據

離線概念

相比實時定義，離線沒有很強的時間即時性要求，一般強調數據的吞吐量，一般常規定義分鐘級、小時級、自然天。如大數據BI應用中，數據同步要求普遍T+1。

前一篇文章《DB與ES混合應用之數據實時同步》，我們主要分享了實戰項目中基於CDC機制構建的數據實時同步技術方案，整體技術棧鏈路長，中間環節多，需要複雜的代碼編程，投入成本高，不利於快速投入生產應用。實際在多數業務系統場景中，離線同步需求佔比最高，下面這篇文章，我們主要探討DB到ES的數據離線同步問題。

背景要求

DB到Elasticsearch離線同步的業務應用場景有很多，相比實時同步業務應用場景，更能體現選擇Elasticsearch替代DB作為查詢引擎的優越性，以下介紹幾個離線同步的業務場景。

歷史數據查詢

在電商或者物流行業，日均會產生很多訂單數據，未完成的訂單數據實時性查詢頻率高，需要做很多上下游的數據流轉處理；相反已經完成的訂單數據查詢頻率不高，但是日積月累的歷史訂單數據會增加很快，若系統架構設計將實時數據與歷史數據合併一起等同對待，那麼運行一段時間數據系統會出現很多致命的性能問題，如實時數據查詢更新會變慢，用戶體驗下降，歷史數據查詢量大，一次查詢可能會將系統嚴重阻塞。

常規的做法是將實時數據與歷史數據分離設計，實時數據查詢頻率高，單次查詢數據量小，系統響應快；歷史數據查詢頻率低，單次查詢的數據量多，系統響應稍慢，甚至可以接受慢一些。

介於傳統關係型數據庫的侷限性，同樣採用 Elasticsearch 應對此係統場景，實時數據查詢走Elastic實時集群，歷史數據走Elastic歷史集群，實時數據同步可以使用CDC機制，歷史數據同步得需要專用離線通道方法。

業務技術重構

隨著公司業務調整與業務發展，業務系統也需要相應持續的重構，不僅業務模型要重構，技術架構也需要重構，由於人的原因或者技術發展的原因，原有的數據庫系統難以滿足業務需求，此時需要更換到更合適的數據庫系統。

如很多基於Mongodb存儲的業務系統，其實切換到Elasticsearch更加合適，速度更快，成本更低（後續案例在編輯...），那麼系統重構之後就需要將數據從Mongodb全量同步到Elasticsearch，這也屬於離線同步場景。

關係性數據庫侷限性就不用說了，大名鼎鼎的Mongodb其實也有很多業務應用短板，或者應用誤區，如很多基於Mongodb存儲的業務系統，其實切換到Elasticsearch更加合適，速度更快，成本更低，切換成本也很低（詳細見另一篇文章《為什麼要從Mongodb遷移到Elastic》），那麼系統重構之後就需要將數據從Mongodb全量同步到Elasticsearch，這也屬於離線同步場景。

技術產品

離線同步相比實時同步，技術複雜度降低很多，場景苛刻需求也要小很多，因此技術方案的選擇度更多，有很多非常優秀的專用工具產品，只需要稍微配置即可啟用，下面我們介紹幾個當下很流行的產品（個人喜好問題），簡要分析它們的優秀特性以及架構原理。

Logstash

Logstash是Elastic官方產品，掌握Elastic-stack必備之一

• 基於Jvm平臺JRuby語言開發，開源免費
• 產品架構設計簡潔優秀，模塊設計層次分明， input -> filter -> output
• 支持pipeline模型，且多個pipeline之間可以相互依賴
• 產品功能豐富，支持的數據源眾多，也支持自定義編輯，其中包括Ruby腳本
• 支持泛JDBC協議，採用SQL表達式，從DB抽取數據到ES，支持CRON定時，可做實時同步
• 與Elastic-stack可集成一體，在Kibana可以查看監控數據
• 單實例運行模式，多實例之間無集群通信，不支持集群，易掌握部署
• 非平臺型工具，輕量級

Logstash 在開發圈中流行度不大，但在運維圈流行度很高，主要得益於ELK組合的概念普及，其實在數據同步方面，是最簡單的最實用的產品工具之一。

Data X

DataX是阿里出品的數據同步工具，定位多種數據庫之間離線數據同步

• 基於Java開發，插件機制
• 產品架構設計簡單，兩大概念模塊，reader->writer
• 支持DB到Elastic數據同步，採用SQL表達式，僅限制離線同步
• 單實例運行模型，多實例之間無集群通信，無集群模式支持，易掌握使用
• 非平臺型工具，輕量級

DataX工具稱不上優秀，得益於阿里巴巴的名氣，使用簡潔與性能吞吐好，獲得開發圈很大的支持，在很多一次性離線數據同步項目中，應用很廣。

NiFi

NiFi是Apache的頂級產品項目之一，由美國軍方早期開發捐獻開源，定位數據同步領域。

• 基於Java語言開發，插件機制，支持自定義開發
• 產品架構設計優秀，Processor 核心模塊概念，
• 功能強大，支持複雜的腳本功能，包括java，javascript，python，ruby等
• 支持DB到Elastic數據同步，可採用SQL表達式方式，也可以採用CDC機制
• 即可實時同步，也可離線同步，且可支持多種Processor組合
• 友好的操作界面，可視化配置
• 平臺型產品，支持集群部署
• 入門簡單，精通門檻高

NiFi雖然歷史悠久，但在國內知名度卻不高，不如Hadoop圈的Sqoop等，不過CDH已經在最新版中集成。個人非常喜歡這款產品，因為其平臺化的系統架構，前面介紹的DataX與Logstash都屬於雕蟲小技的工具。

Flink

Flink是當前大數據圈最有人氣的流式處理產品，在實時計算領域應用最廣。

• 基於Java語言編寫，平臺型產品
• 分佈式架構設計，機制功能豐富，支持檢查點機制，程序容災、狀態持久等
• 豐富的編程模型，層次分為 Streaming->Dataset->Table->SQL
• 支持流式計算與離線計算，其中支持泛JDBC數據源離線同步到Elastic
• 集群化運行模式，需要自主編寫數據處理代碼。

Flink雖然定位在實時計算領域，但由於其底層架構設計的特點，離線計算支持也非常好，提供了友好的編程模型，可快速開發部署，類似的產品還有Spark，這裡就不做更多的展開討論。

ETL工具

專業ETL產品太多了，就不展開討論了，由專業的BI從業人員講述更合適...

• Kettle
• DataStage
• Informatica

技術平衡

以上我們介紹了好幾種當下流行的數據同步工具，有的支持離線同步，有的也支持實時同步，其實還有更多其它不錯的工具產品，每一種工具產品都有它的侷限性與優越性，千萬不可一概而論，也不可全都上，需要綜合業務與技術平衡。

客觀認知

每種工具產品都有它的定位，需要客觀的認知評估。在業務系統中數據離線同步場景需求多種多樣，沒有一個完美的產品可以應對所有場景需求。

如DataX屬於直接型同步工具，中間沒有數據處理功能，其Mysql模塊雖然支持所謂的增量型同步，但分批次的連續型同步方式需要藉助人工觸發，這會造成一些不方便，但是數據吞吐量很好。

有一次客戶現場服務說Logstash居然不支持JDBC寫入數據的插件，然後得出結論此工具產品做的不好，理由是不滿足多個數據庫之間數據同步，考慮到他們屬於傳統實體企業就沒有做過多的討論，實際上Logstash已經做的非常好，適合的數據同步場景很多，相比DataX多了一個分批次連續的定時機制，不知道要減少多少工作量。

混搭組合

業務系統中數據離線同步場景多種多樣，單一工具產品無法完成所有場景，需要混合多種工具產品完成。

如NiFi平臺型產品，功能很強大很豐富，也支持從本地文件讀取數據，但是此方式太重，程序包本身很大，需要好幾個G磁盤容量，可能需要同步的數據量都沒有NiFi安裝包大，所以此時應該選擇一些單機版本的工具產品，如Logstash等

技術融合

每種產品工具都有它的架構設計理念，有它的獨特技術特點，掌握並很好融合需要一定的精力和時間，否則會出現很多衍生問題。如Flink從開發層面來看，入門簡單並可完成數據同步代碼的開發，但是真正複雜的是架構運維掌控能力，Flink是平臺型產品，本身複雜度很高。

技術融合能力分層

• 開發層面，瞭解產品各種Api特性，能夠熟練響應各種需求
• 架構層面，深入瞭解產品基本原理，對其基本的能力有很客觀的認知
• 運維層面，掌握產品的運維能力，各種異常情況有響應的保障手段

結語

經驗總結

數據同步是一個仁者見仁，智者見智的話題，成熟的產品工具可以快速響應需求，重新編寫程序可以更好的定製化需求，因人而異，因需求而異。
Elastic有很多優秀特性，即可以應對實時數據場景，也可以應對歷史數據場景，有點兒幾乎無所不能。“Elastic用的好，下班下的早”。

內容來源

本文內容來源在業務系統中大量運用DB與ES混合實戰，得出的一些實戰與思考，提供後來者借鑑參考，內容原創轉載請註明。

專題課程

Elastic目前在國內幾乎所有信息科技公司都在使用，無論是幾個人的工作室，還是規模千人大型公司，應用的領域非常廣，非常受歡迎。Elastic雖然入門簡單，要想使用好，需要很長時間磨合，為此，我們專門特點設計了專題課程。幫助個多人或公司用好。
首先從數據同步開始，包括離線數據同步與實時數據同步，如何把DB的數據導入到Elastic，且能應付各種數據請關注我們的《DB與ES數據同步實戰專題》，實戰課程理論很少，主要是案例代碼，課程系列如下：

• Logstash系列
• DataX系列
• NiFi系列
• Flink系列
• CDC系列

聲明：本文由原文作者“李猛”授權轉載，對未經許可擅自使用者，保留追究其法律責任的權利。

【阿里雲Elastic Stack】100%兼容開源ES，獨有9大能力，提供免費X-pack服務（單節點價值$6000）