分表分庫的處理

1）傳統(tǒng)數(shù)據(jù)庫的分表分庫處理：

2）在大數(shù)據(jù)系統(tǒng)中的做法是構(gòu)建分布式數(shù)據(jù)庫訪問引擎（中間層），將分布在不同數(shù)據(jù)庫中的表集成為一張表，業(yè)務(wù)系統(tǒng)像單表一樣使用

3）分布式數(shù)據(jù)庫訪問引擎位于數(shù)據(jù)持久層與JDBC驅(qū)動之間，實現(xiàn)了以下功能：

高效同步與批量同步

1）數(shù)據(jù)同步流程：創(chuàng)建表--同步工具中配置數(shù)據(jù)庫連接/表/字段--測試

2）存在問題：

① 數(shù)據(jù)量增大時，每天會有大量重復的配置工作，降低開發(fā)人員熱情

② 不同數(shù)據(jù)庫有個性配置

3）解決方式：

① 實現(xiàn)配置流程一鍵化操作，并封裝web接口進一步達到批量化的效果

② 開發(fā)數(shù)據(jù)庫管理平臺，統(tǒng)一管理數(shù)據(jù)、數(shù)據(jù)結(jié)構(gòu)；實現(xiàn)對不同數(shù)據(jù)源配置透明化，通過庫名表名唯一的定位數(shù)據(jù)

增量與全量數(shù)據(jù)同步：

1）數(shù)據(jù)量超出一定閾值，每個周期同步全量數(shù)據(jù)會消耗大量資源。在這種情況下可以只同步增量數(shù)據(jù)并與前一天的全量數(shù)據(jù)進行合并。

2）當前流行的大數(shù)據(jù)平臺基本不支持update操作，所以我們用全外連接+全量覆蓋的方式更新數(shù)據(jù)。即將當天增量數(shù)據(jù)與前一天全量數(shù)據(jù)做全外連接，然后重新加載最新的全量數(shù)據(jù)。

數(shù)據(jù)漂移的處理

1）數(shù)據(jù)漂移發(fā)生在數(shù)據(jù)倉庫的最底層ODS層，當日業(yè)務(wù)數(shù)據(jù)中包含前一天或者后一天凌晨的數(shù)據(jù)，或者當天的變更數(shù)據(jù)丟失

2）原因：數(shù)據(jù)在ODS層按時間分區(qū)存儲，時間戳的準確性導致了數(shù)據(jù)漂移。

時間戳分四類：

① 數(shù)據(jù)庫表中的數(shù)據(jù)更新時間（modified_time）

② 數(shù)據(jù)庫日志中的數(shù)據(jù)更新時間 (log_time)

③ 數(shù)據(jù)庫表中業(yè)務(wù)發(fā)生時間 (proc_time)

理論上這3個時間時相同的，事件中往往存在偏差，理由如下：

① 前臺業(yè)務(wù)手工修正數(shù)據(jù)未更新modified_time

② 由于網(wǎng)絡(luò)壓力，modified_time和log_time晚于proc_time

3）數(shù)據(jù)漂移場景

① 依據(jù)modified_time劃分，會發(fā)生因為未更新modified_time而導致數(shù)據(jù)遺漏，或者由于網(wǎng)絡(luò)壓力凌晨的數(shù)據(jù)漂移到后一天

②?依據(jù)log_time劃分，由于網(wǎng)絡(luò)壓力，業(yè)務(wù)發(fā)生時未能實時更新數(shù)據(jù)，導致凌晨的數(shù)據(jù)漂移到后一天

③ 依據(jù)proc_time劃分，僅僅包含一個業(yè)務(wù)記錄，遺漏過程的變化記錄