資料親和架構核心要解決資料和程式的繫結問題，那麼資料在程序間同步就尤為重要。因為效能的關係，增量同步是首選，全量同步只有在初始化或者出現異常的情況下，才會考慮。在流資料中，因為有時序，比較容易實現，而在靜態資料中，比如檔案或者資料庫中，通常沒有嚴格的時序，只有快照，要做增量比較困難。

        以物理時間流動為參照系，任何一個數據集都可以分為某個時間點的快照，以及後續的變更。而該時間點快照即視為靜態資料，除非在應用層裡為這些資料插入時序資訊，否則是難以做增量同步的。作為一個通用解決方案，不能假設應用層會加入時序資訊。在該時間點之後的變更，只要流經同步系統，系統就可以自動為這些變更增加時序，實現增量同步。於是乎，資料同步就可以被分解成兩個部分，一是靜態資料同步，另一個是天然的增量同步。

        將靜態資料視為一個檔案，那麼檔案的增量同步系統，如rsync和git等系統已經為我們提供現成的解決方案，完成可以借鑑。需要注意的是，和傳統的二進位制或者文字檔案同步不一樣，浮點資料具有特殊性，同樣一個浮點數，可以有多種表現方式，這些值在現實中是一樣的，但在二進位制層面卻完全不同，可能會導致無效的增量變化。幸運的是，資料庫在浮點數格式化這塊為我們提供了不錯的方法。

        雖然資料庫標準查詢介面只提供快照，但主流的資料庫，都額外提供了CDC系統，幫助我們捕獲資料庫本身資料的增量變化，事實上，資料庫的binlog本身就是一個嚴格時序的資料流儲存方式。因此資料庫同步依然符合上述模式：快照+增量。而檔案型別的資料儲存系統，和資料庫不同，可以在寫入之前截獲資料流來實現增量變更資訊。記憶體型別的資料儲存也是同樣解決方案。

        資料同步的另外一個問題，就是一致性問題。由於同步導致資料分佈在多個節點或者程序中，也因此引入中了分散式系統中，必須面對的CAP原則。具體要達到哪種程度的一致性，可以由應用層制定策略，底層架構實現對應的機制即可。