DataPipeline的常見問題和解題思路

這篇文章給大家分享的是有關DataPipeline的常見問題和解題思路。小編覺得挺實用的，因此分享給大家做個參考。一起跟隨小編過來看看吧。

Q1: DataPipeline支持的讀取方式

A：DataPipeline在成立之初只有一種模式，只支持實時流同步，在我們看來這是未來的一種趨勢。

但在后來發現，很多客戶實際上有批量同步的需求。比如，銀行在每天晚上可能會有一些月結、日結，證券公司也有類似的結算服務。基于一些歷史原因，或出于對性能、數據庫配置的考慮，可能有的數據庫本身不能開change log。所以實際上并不是所有情況下都能從源端獲取實時的流數據。

考慮到上述問題，我們認為一個產品在支撐數據融合過程中，必須能同時支撐批量和流式兩種處理模式，且在產品里面出于性能和穩定性考慮提供不同的處理策略，這才是一個相對來說比較合理的基礎架構。

詳情參見：DataPipeline CTO陳肅：構建批流一體數據融合平臺的一致性語義保證

Q2：目標端的連接方式是什么

A：對于關系型數據庫，寫入方式為JDBC，未來版本將通過文件加載的方式提高吞吐率。其它類型的目的地，根據具體類型各不相同。例如FTP目的地用的是FTP Client，Kafka目的地用的是Kafka Producer。

Q3：采集和寫入能否對數據進行加密

A：如果是要對數據內容加密可以使用高級清洗。

Q4：DataPipeline安裝部署模式

A：DataPipeline 產品是采用Docker容器的部署方式，支持Docker集群；支持虛擬環境（VMW）部署，但不推薦，DataPipeline正在研發支持非Docker部署。

Q5：DataPipeline是否支持圖形化監控

A：DataPipeline支持讀寫速率、數據量、任務進度、錯誤隊列、操作記錄、表結構等圖形化監控。

Q6：數據庫日志保留策略多久合適

A：如，MySQL Binlog保留策略，建議保留日志策略>=3天。

Q7: 后續增量導入數據如何保證一致性

A：DataPipeline默認支持at least once同步機制，保證數據不會在同步過程中丟失。這適合源端有主鍵、目的地有主鍵去重能力的場景，例如關系型數據庫到關系型數據庫的同步。

如果類似Hive這樣沒有主鍵去重能力的目的地，DataPipeline支持開啟任務級別的端到端一致性選項，通過多階段提交協議來保證數據一致性。

Q8：監控報警一般在項目上如何使用

A：DataPipeline的數據任務有監控看板和報警兩種方式，報警會發送到指定的郵箱，根據錯誤類型，可以選擇重啟或通知技術支持，DataPipeline會有工程師協助客戶排查錯誤。

Q9：是否方便擴容

A：DataPipeline支持動態擴容，當集群資源緊張時，無需暫停現有任務，增加新節點后，即可以實現集群的擴容。

Q10：如果一條數據多次、頻繁變化，DataPipeline如何保證數據的并行和順序？

A：DataPipeline源端會將任務按照一定原則拆分為多個互不干擾的子任務進行并行執行。例如：在JDBC源讀取場景下，如果任務包括多張表，每個表是由一個獨立線程進行順序讀取的，線程并行度可以在任務屬性中進行設置。

為了保證順序寫入和讀取，默認每個單獨子任務會創建一個獨立的topic，設置一個分區，這樣目標端消費的時候，同一個topic只有一個consumer在進行消費，從而保證消費的順序性。如果可以接受非順序消費，也可以為一個topic創建多個分區，這樣目的端可以更好地利用Kafka的并行能力提高吞吐量。

以上就是DataPipeline的常見問題和解題思路的詳細內容了，看完之后是否有所收獲呢？如果還想學到更多技能或想了解更多相關內容，歡迎關注億速云行業資訊。