分散式日誌傳輸系統Databus(一)--系統介紹

bjehp發表於2021-05-23

Databus系統是微博DIP團隊開源的分散式日誌傳輸系統。它是一個分散式、高可用的,用於採集和移動大量日誌資料的服務。它基於流式資料的簡單而靈活的架構,具備健壯性和容錯性,具有故障轉移與恢復機制。它採用簡單的可擴充套件的資料投遞模型,允許使用者自定義擴充套件傳輸元件。

主要特性

  • All-In-One 所有的日誌傳輸通道整合到一個系統,避免針對每種業務相應地定製一套日誌傳輸元件,這樣隨著業務的增多,運維壓力會劇增。
  • 熱載入 在JVM無需重啟的情況下,可以新增、更新、刪除指定的日誌傳輸通道,且不會影響到其他傳輸通道的正常工作。
  • 容錯性 對於Databus分散式系統,若出現少量傳輸節點異常崩潰,那麼異常崩潰節點的資料流量會切至其他節點,不影響整個系統的正常執行。

系統架構

Databus系統可對接多種資料來源和資料目的地,將資料來源的日誌同步到資料目的地。常用的資料來源有:Kafka、本地檔案、ScribeClient等,常用的資料目的地有:Kafka、HDFS等。

Databus系統的核心處理模組包含四部分:Source、Converter、Sink、Store。Source模組負責收集資料來源的日誌,Converter模組負責對日誌轉換,如:重新命名Topic名稱、對訊息體的ETL和過濾,Sink模組負責把日誌同步到資料目的地,Store模組負責把寫入資料目的地失敗的日誌暫存起來,根據策略進行後續的處理。

Databus系統的監控報警模組主要包含:資料量統計、靈活的Exporter外掛、異常報警。資料量統計用於統計Source端的讀取量和Sink端的寫入量,便於全鏈路的資料對賬。系統暴露了Exporter介面,使用者只需針對特定的儲存系統實現相應的Exporter,即可把監控資訊採集過去,配置圖表後做直觀的展示。另外若日誌寫入資料目的地失敗,可通過配置策略傳送報警。

databus-architecture

資料流模型

Databus系統的資料流模型設計為一個Source對應一個Sink,一個Source和與其對應的Sink組成一個Pipeline管道,各個Pipeline相互獨立、互不影響。通過這種Pipeline模型,使用者新增、刪除、變更某個Pipeline,不會影響到其他Pipeline的資料傳輸,且使用熱部署的方式不需要重啟程式。做到儘可能少的中斷資料流,保障日誌傳輸的實時性。

databus-dataflow

安裝部署

編譯

git clone https://github.com/weibodip/databus.git
cd databus
mvn clean package -DskipTests

初始化環境

mkdir -p /data0/workspace
mv ../databus /data0/workspace
mkdir /var/log/databus/

新增配置

可以在 /data0/workspace/databus/pipelines 目錄下新增多個配置檔案,每個配置檔案抽象為一個 pipeline,各個 pipeline 的日誌傳輸互相獨立,互不干擾。這裡以讀取本地檔案的日誌記錄,並寫入 kafka topic 的 pipeline 配置為例。

vim /data0/workspace/databus/pipelines/file-to-kafka-example.properties
pipeline.name=file-to-kafka-example

pipeline.source=com.weibo.dip.databus.source.FileSource
pipeline.converter=com.weibo.dip.databus.converter.TopicNameConverter
pipeline.store=com.weibo.dip.databus.store.DefaultStore
pipeline.sink=com.weibo.dip.databus.sink.KafkaSinkV010

#source
source.file.directory=/data0/log/databus/test/
source.file.include.pattern=^.*\\.test\\.log$
source.file.category=test
source.file.delete.after.read=true
source.file.retention.second=7200

#converter
topic.mappings=test:test

#sink
sink.kafka.bootstrap.servers=hostname1:9092,hostname2:9092,hostname3:9092
sink.kafka.key.serializer=org.apache.kafka.common.serialization.StringSerializer
sink.kafka.value.serializer=org.apache.kafka.common.serialization.StringSerializer

啟停操作

系統預設的JDK路徑:/usr/local/jdk1.8.0_144,可根據情況修改 bin/databus-server.sh 的 JAVA_HOME。

# 啟動
/data0/workspace/databus/bin/databus-server.sh start

# 檢視執行狀態
/data0/workspace/databus/bin/databus-server.sh status

# 檢視日誌
tailf /var/log/databus/server.log

# 停止
/data0/workspace/databus/bin/databus-server.sh stop

與 Flume 對比

Flume 的模型抽象上有 Channel 的概念,這樣便於多路複用資料流,其常見的場景:

  • 一個 source 複製到多個 channel
  • 制定規則將一個 source 拆分到多個 channel

Flume 的多路複用資料流,增加了資料處理的靈活性,但是常用的 Channel 也存在一些問題:

  • FileChannel 會降低資料寫入和讀取速度。
  • MemoryChannel 增加對伺服器記憶體的佔用,資料傳輸通道過多時甚至會導致程式的OOM。
  • KafkaChannel 浪費一部分的頻寬資源;且引入額外元件,會導致傳輸鏈路變長,降低服務穩定性。

考慮到 Channel 在目前的實現上存在一些問題,去掉 Channel 在一些不需要多路複用資料流的場景下,資料傳輸表現效果會更好。Databus 的設計理念在於去掉 Channel,其相比 Flume 的優勢在於:

  • 模型抽象簡單,方便理解,一個 source 對應一個 sink。
  • 配置項簡單,對於數十行的 Flume 配置,Databus 可能只需十幾行即可搞定。
  • 資料傳輸延遲低,去掉 Channel 元件,縮短了資料鏈路,尤其對於非記憶體的 Channel,降低資料延遲的效果更明顯。
Flume Databus
模型抽象 source-channel-sink source-sink
配置 繁多冗長 簡潔
靈活性 一個source對應多個sink 一個source對應一個sink
資料傳輸延遲 較高 較低

結語

專案實現了很多常用的Source 和 Sink,並對每個Source 和 Sink 的特性、適用場景,以及配置引數進行了說明,方便使用者快速上手。詳細內容可查閱專案的GitHub地址:https://github.com/weibodip/databus

Databus系統在微博業務的日常使用場景中,已經承接了各種Source 和Sink 的資料傳輸業務。在大資料和高併發場景的檢驗下,系統曾暴露出一些問題,而這些問題已經得到修復,目前系統已穩定執行多年。不過在程式的世界裡,Bug是無法避免的,在使用過程中如有遇到問題,歡迎提 Issue,我們會盡快修復~

相關文章