一個數據庫老兵(10幾年數據庫+數據倉庫+大數據經驗)遇到了這樣一個難題：
有個訂單表有2個字段，一個是 order_date 訂單日期，一個是 entry_date 入庫日期，平時業務系統查詢使用的是 order_date，表呢是根據order_date 按天分區，每天凌晨ETL工具會根據 entry_date 將昨天入庫的數據抽到數據倉庫，他抱怨抽數的過程非常慢，因爲每天入庫的訂單有幾百萬到上千萬單，因爲表是根據 order_date 分區的，ETL工具抽數又是用的 entry_date 來進行的過濾，這顯然不能分區裁剪，每次ETL抽數據都要對訂單表全表掃描，掃描所有分區，這個表一共有20幾億數據，這當然慢了，也許有人會說，可以對 entry_date 建立本地(local)索引，是的，這是一個不錯的辦法，但是這也不是最優解，每天有幾百萬到上千萬單，通過索引返回幾百萬到上千萬數據也是非常慢的，會引起大量的單塊讀I/O。
其實聽他描述到一半我就知道他要說什麼了，這個問題我在2012年就遇到過。
如果數據庫支持物化視圖，可以創建on commit 且按照 entry_date 分區的物化視圖，業務平時查詢原始訂單表，ETL抽數據查詢物化視圖就行，物化視圖是根據 entry_date 分區的，這樣就可以分區裁剪，大大滴提升性能。
如果數據庫不支持物化視圖，可以改造業務系統，每次新訂單寫雙份數據，一個表按照 order_date分區，一個表按照 entry_date 分區。
其實這個問題在 OLAP 中經常遇到， 不管是 HADOOP ，還是列存儲數據庫，還是常見的關係數據庫，都可以用 "雙表" 這種技術來解決性能問題，數據寫雙份，表按不同查詢列分區/分桶 就可以了