不知不覺中，大家已經陪伴DataPipeline走過了3年時間。在這期間，得益於客戶們的積極反饋和溝通，我們總結了一些日常工作中比較常見的問題，並基於這些問題進行了總結。
爲避免突兀，我們會先從比較基礎且通用的問題開始，進而陸續放出一些稍加複雜的問答，希望大家在接下來的日子裏持續關注我們的更新~
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的並行能力提高吞吐量。
本篇集中介紹了10種問題答疑，如果你在工作中遇到了類似的問題，或者對一些答疑心存疑惑，歡迎與我們交流。