摘自阿里大資料之路
通常我們把從源系統同步進入數倉的第一層資料稱為 ods或者staging層資料，接入層 。
資料漂移是接入層資料的乙個頑疾。
資料漂移定義：接入層ods表同乙個業務日期資料中包含前一天或者後一天凌晨附近的資料或者丟失當天的變更資料。
通常落地數倉的ods表會按時間切分做分割槽儲存，實際上往往由於時間戳字段的準確性問題導致發生資料漂移。通常有四類時間戳：
modified_time:資料庫記錄某條資料更新的時間。log_time:資料庫日誌記錄某條資料更新的時間。
proc_time:具體業務過程發生時間。
extract_time:資料記錄被抽取時間。
理論上這四個時間是一致的，但由於以下原因會出現資料漂移：
1）同一條記錄的資料抽取時間extract_time明顯是晚於另外三個時間的，如果用這個字段切分，ods某個分割槽中的資料會包含前一天末尾的資料，並丟失當天末尾的資料。2）如果用資料庫記錄的更新時間modified_time，前台業務系統手工訂正資料時可能會遺忘同步更新該時間，導致該抽取的資料被遺漏掉。
3）另外，由於網路或者系統壓力問題，log_time或者modified_time可能會晚於proc_time，導致資料漂移。
4）如果我們直接使用proc_time時間進行切分，這種情況僅僅對包含乙個業務過程的ods表有效果，如果該錶每條記錄需要儲存多個業務過程，則用proc_time切分會丟失其他發生在當天的業務過程記錄。
既然很難解決資料漂移的問題，那麼就在ods每個時間分割槽中向前、向後多冗餘一些資料，保證資料只會多不會少，而具體的資料切分讓下游根據自身不同的業務場景用不同的業務時間proc_time來限制。但是這種方式會有一些資料誤差，例如乙個訂單是當天支付的，但是第二天凌晨申請退款關閉了該訂單，那麼這條記錄的訂單狀態會被更新，下游在統計支付訂單狀態時會出現錯誤。
1) 首先根據log-time分別冗餘前一天最後15分鐘的資料和後一天凌晨開始15分鐘資料，並用modified_time過濾非當天資料，確保資料不會因為系統問題而被遺漏
2) 然後根據log_time獲取後一天15分鐘的資料；針對此資料按照主鍵根據log_time做公升序排列去重，因為我們要獲取的是最接近當天記錄變化的資料（資料庫日誌將保留所有變化的資料，但是落地到ods表的是根據主鍵去重獲取的最後狀態的資料）
3) 最後將前兩步結果資料做全外連線，通過限制業務時間proc_time來獲取我們所需要的資料.
資料倉儲 5
前幾天，都在忙一些配置的問題，而且都不是自己能掌控的一些東西 今天，算是開始了一些實質性的東西，今天，用過cognos的同事，給這邊演示了一下cognos的三個studio的使用，包括 report studio framework transfer 的使用，了解到的資訊主要如下 1 要通過fram...
資料倉儲與資料庫比較，Hive資料倉儲與資料庫比較
hive是乙個翻譯工具，將sql翻譯為底層mr程式的，它不是資料庫，只不過在表現形式上和資料庫有很多類似而已 比如表 database 欄位等 資料庫可以增刪查改，資料倉儲只可以增刪查 資料倉儲支援很大規模的資料 資料庫支援的資料規模較小 資料倉儲沒有索引，資料庫有 資料倉儲可擴充套件性強，資料庫弱...
資料庫與資料倉儲
簡而言之，資料庫是面向事務的設計，資料倉儲是面向主題設計的。資料庫設計是盡量避免冗餘，一般採用符合正規化的規則來設計，資料倉儲在設計是有意引入冗餘，採用反正規化的方式來設計。資料庫是為捕獲資料而設計，資料倉儲是為分析資料而設計，它的兩個基本的元素是維表和事實表。維是看問題的角度，比如時間，部門，維表...