概要：

　　在DELL燃7000筆記本電腦上(i5-7200u)，對億級事實表&維度表的探索式分析，平均響應性能從11.9秒優化到8.9秒，提升程度約25%，這一切歸功于Smartbi+Vertica的高性能自助分析解決方案!

　　難點：

　　星型模型又稱Star-schema，是一種數據庫的建模(組織數據)的方式，它與三范模型3-NF的知名度等高。由于這類模型都是以“事實表”為核心，圍繞幾個維度表，所以非常形象的被稱為“星型”。

　　在沒有犧牲空間換時間(OLAP)的數據分析場景下，這樣的建模方式非常有利于數據更新，因為維護事實表的增量以及事實表和維度表的數據一致性比較快速，或者說ETL的時間窗口比較小。但其對于查詢類型的分析應用，卻需要消耗大量的“關聯”運算，對CPU來說是比較操作，因此在很多大數據量的數據倉庫系統中，往往其查詢性能并不好。

　　更具挑戰的是，在需要提供自助探索的分析平臺上(比如Smartbi的透視分析以及Tableau等)，業務人員無法預料的會動態生成各種查詢請求，從技術的角度說就是SQL沒有規律，任何字段都可能是where條件、group分組以及計算字段，這就導致索引等傳統DBA的手段毫無用武之地。

　　干貨

　　關注過Smartbi公眾號的同學可能知道，Smartbi在7月份與Vertica進行了戰略合作，基于這個新一代列式MPP數據庫發布了“高性能自助分析解決方案“，在隨后9月的workshop中提供了1個億級的星型數據模型和22個性能測試案例。

　　我在本人筆記本電腦對V201709版星型模型做了性能測試，平均響應時間為11.9秒，個人感受只能是差強人意。22個測試案例的結果如下，單位為秒：

　　筆記本電腦型號燃7000，配置如下，只不過操作系統為了安裝Vertica改成了linux：

　　這個配置和價位是非常親民的吧，尤其這顆CPU在牙膏廠(Intel)的產品里根本排不上號。

　　言歸正傳，最近本人研究了一下Smartbi的這個星型數據模型，對其做了2項調整工作，第一是將3個維度表的關聯字段改成了整型(當然首先是在維度表增加了車型、姓名、城市的整數編號，其次是在事實表增加這3個字段)，第二是對事實表按年份進行了分區。

　　同樣按照22個案例進行了測試，就得到了25%的性能提升，達到8.9秒，結果棒棒的!

　　具體來說，前3個測試案例是對事實表3個字段的分組求和，不涉及任何優化的內容，所以沒有什么改變，甚至由于隨機性的誤差還有一些下降。從第四個開始，2個優化手段開始發揮作用，平均提升更大(30%)。

　　既然此次優化用了2個手段，那么它們各自有多大貢獻呢?(原諒本人懶得重新測)

　　將測試案例的三類對比來看，因為”同比計算“和”條件匯總“都用到年份作為條件，我們暫且可以認為它們更能體現按年做分區的優化作用，這里它們分別提升了27%和32%，比普通的全表匯總提升的21%更有效果，就認為有5%-10%的提升吧。

　　另外從這個圖可以看到，以前同比計算的平均性能比全表匯總明顯要慢，但優化后基本差不多了，都在11秒左右。而按年條件匯總的平均性能從6秒提升到4秒，真的是非常優秀了!

　　總結

　　只有用列式數據庫，才可能降低大數據量分析對IO的硬性要求，使得采用筆記本做數據分析成為可能。但能把1億數據量的星型模型玩轉自助分析的，目前也就是Smartbi+Vertica，最后給Smartbi透視分析的同環比計算、分組字段和自由鉆取點個贊，以后有空再繼續挑戰這個任務!

　　寫在最后：該優化的模型已經被Smartbi采納，用于后續的workshop活動!