微服務盛行下，數據庫表拆分的越來越細。很多查詢都會涉及多張表關聯之後才能滿足對應業務查詢訴求。在海量數據基礎之上，直接關聯查詢，響應時間超出用戶忍耐時間。因此構建寬表，對針對寬表直接查詢得到結果是個通用的方案。但構建寬表涉及的相應表常常會更新，就使寬表構建變的複雜了。
我們常常看到的各支持的訂單/交易查詢，在應對海量數據的時候，只支持近期很短時間的查詢。如招商銀行提供近8個月的交易查詢，稍微還好一點。
微信支付寶做得很好，都支持歷史數據全部能查。
那麼技術上如何實現呢？
常常大家採用分佈式數據庫來存儲海量數據，Hbase是個常用的存儲組件。
在構建解決關聯查詢延時，構建寬表方面，下面給出三種方案，一探究竟。
1、在源數據庫直接SQL查詢join後結果，落存寬表庫Hbase等。要注意的說是，輪動拉取的時間，要有所有可變表的時間。缺點：依賴源數據庫計算能力，會延時非實時。SQL操作直接得到結果，不用建立中間模型，簡單快捷。能針對oracle數據日誌不能解析的情況下做數據寬表。SQL任務可在streamingSets調度平臺配置定時任務。
2、單表獲取解析源數據庫表binlog日誌，在Hbase處設計業務表模型做插入更新維護該模型，業務上設計每張表與寬表關係，以便FLink接收到每張表的更新時，能找到對應寬表記錄，做寬表相應更新處理。優點：準實時，模型構建可重複利用，減少混亂龐雜數據。缺點，Flink處理有開發任務，開發週期較長。這是目前當前流行FLink的流行做法。
3、單表獲取解析源數據庫表binlog日誌，使用Spark 流處理，對小段RDD通過Spark sql做join關聯，落存Hbase。這種方式，是將關聯計算從數據源處計算移到spark計算層。可以通過抽象存儲與執行計算，通過配置SQL的方式完成寬表構建，減少編碼。 缺點：根據業務間隔設置微批時間段。少數實在超過時間範圍外的（更新）數據會丟失。 對在每個時間段內，沒有關聯上的數據，需要有補償機制。
因為我們公司構建了基於impala+kudu的實時數倉，寬表構建，在方案一中，依賴數據源的關聯計算能力，可能會使數據庫負重，從而影響數據庫性能。在此方案上，一種優化是，升級數據源，把數據源升級成TIDB，增強數據源的計算能力，使其不受影響。另一種方式是， 將關聯計算從數據源處執行移到終端數倉階段做關聯計算得到寬表數據。 同樣，該方案根據定時任務也有相應延時，但不會丟失數據。
