功能遠超Sqoop、DataX、Flume、Logatash、Filebeat等採集工具
深知其他組件的侷限性，才能彰顯DBus的優越感
當前有很多數據採集工具（Sqoop、DataX、Flume、Logatash、Filebeat等），他們或多或少都存在一些侷限性。
一個共性問題是缺乏統一的數據源端管控，所以也就無法找到統一的數據入口，那後續處理元數據或者血緣分析會異常困難。
除此之外，現有各種數據採集工具的數據同步方法也有一定的侷限性。比如：
（1）各個數據使用方在業務低峯期各種抽取所需數據（缺點是存在重複抽取而且數據不一致）
（2）由統一的數倉平臺通過sqoop到各個系統中抽取數據（缺點是sqoop抽取方法時效性差，一般都是T+1的時效性）
（3）基於trigger或時間戳的方式獲得增量的變更（缺點是對業務方侵入性大，帶來性能損失等）
這些方案都不能算完美，要想同時解決數據一致性和實時性，比較合理的方法應該是基於日誌的解決方案，同時能夠提供消息訂閱的方式給下游系統使用。在這個背景下DBus就誕生了。
DBus到底是什麼？給我一個完美的解釋
DBus（數據總線）項目爲了統一數據採集需求而生， 專注於數據的收集及實時數據流計算，通過簡單靈活的配置，以無侵入的方式對源端數據進行採集，採用高可用的流式計算框架，對公司各個IT系統在業務流程中產生的數據進行匯聚，經過轉換處理後成爲統一JSON的數據格式（UMS），提供給不同數據使用方訂閱和消費，充當數倉平臺、大數據分析平臺、實時報表和實時營銷等業務的數據源。支持多租戶管理，提供租戶級資源、數據隔離機制。
看DBus官網，瞭解更多更新一手資料
https://github.com/BriData/DBus
看DBus架構，聚焦DBus兩大核心功能
DBUS主要分爲兩個部分：
（1）貼源數據採集
（2）多租戶數據分發
兩個部分之間以Kafka爲媒介進行銜接。無多租戶資源、數據隔離需求的用戶，可以直接消費源端數據採集這一級輸出到kafka的數據，無需再配置多租戶數據分發
繼續深入貼源數據採集功能模塊
DBUS源端數據採集大體來說分爲兩部分：
讀取RDBMS增量日誌的方式來 實時獲取增量數據日誌，並支持全量拉取；基於logtash，flume，filebeat等抓取工具來實時獲得數據，以可視化的方式對數據進行結構化輸出；
以下爲具體實現原理：
主要模塊如下：
（1）日誌抓取模塊：從RDBMS的備庫中讀取增量日誌，並實時同步到kafka中；
（2）增量轉換模塊：將增量數據實時轉換爲UMS數據，處理schema變更，脫敏等；
（3）全量抽取程序：將全量數據從RDBMS備庫拉取並轉換爲UMS數據；
（4）日誌算子處理模塊：將來自不同抓取端的日誌數據按照算子規則進行結構化處理；
（5）心跳監控模塊：對於RDMS類源，定時向源端發送心跳數據，並在末端進行監控，發送預警通知；對於日誌類，直接在末端監控預警。
（6）web管理模塊：管理所有相關模塊。
繼續深入多租戶數據分發功能模塊
對於不同租戶對不同源端數據有不同訪問權限、脫敏需求的情形，需要引入Router分發模塊，將源端貼源數據，根據配置好的權限、用戶有權獲取的源端表、不同脫敏規則等，分發到分配給租戶的Topic。這一級的引入，在DBUS管理系統中，涉及到用戶管理、Sink管理、資源分配、脫敏配置等。不同項目消費分配給他的topic。