構建現代化的BI報表系統

Background

對於任何企業服務（SaaS）或者面向大衆（To C）的系統，報表是內部運營中最重要的部分。報表內業務一般存在如下幾個難題：

1. 變動頻繁。尤爲是SaaS類企業，報表需求是很是的頻繁變動單，所以很難將報表需求進行固化，進行鍼對化的優化。
2. SQL複雜。報表一般是直接從源數據庫經過SQL的方式加載出來，計算與查詢都很是複雜，沒辦法簡單的徹底優化。
3. 實時性。實時性是報表業務最具備價值的點。實時性表如今數據更新的實時性以及加載報表的實時性。若是加載一個報表須要半小時那天然是極大的消耗耐心的事情。

那麼，咱們對於報表業務的架構需求就很清晰了：

1. 知足數據增加的需求。AWS Redshift與Google Cloud Big Query 都是現代的海量存儲分析引擎，咱們優先選擇它們。
2. 儘量的實時性。 這要求咱們在ETL階段，最好可使用MySQL Slave的方式進行數據提取。
3. 儘量的靈活機動性。 這要求不能進行任何的預計算。

業務架構

big_query.jpg

實施步驟

1. 挑選合適的ETL工具進行從生產環境的transactional database中提取數據。
2. ETL將數據寫入到數據倉庫中(全量數據庫倉庫，半年熱數據倉庫集)。
3. BI 應用程序或者本身開發的API鏈接到數據庫倉庫進行數據讀寫。

爲何須要熱數據倉庫?

1. 由於從redshift/big query等系統查詢數據是秒級響應，作不到毫秒級響應。當咱們須要最快速的出面向C端的報表業務的時候，延遲是很重要的。而一般，C端報表的數據時長比較短。