分散式日誌傳輸系統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，我們會盡快修復~

相關文章