由一次最佳化聯想到認知和實時數倉的問題

     好幾天沒寫了，最近忙，今天告一段落。再不寫本週就沒產出了，這不是我風格啊。

     今天幫一個開發看了一個場景，一個報表場景，一個SQLIO幾乎用盡。5分鐘一次，一次2分鐘。可能大家認知中報表就應該這樣。或者在hadoop中經歷涅槃最後展現一個結果（後臺伺服器累的要死）。其實這是不對的，但是大家認知是這樣很難改變。以前我也認為這樣，但是隨著原理通透以及思路清晰，有時候我會說一些可能“反”認知的觀點。可能“磚家”就這樣，和大家一樣的觀點沒什麼好說的。以今天這個為例，我讓他做了一個小小的改動，120秒，變成60毫秒。2000倍的提升對於我來說一點也沒有興奮。20萬倍以下的提升我已經沒有興奮點了。我僅僅想表達，大家不要以為報表天生就該慢，這個認知要轉變。

   不少時候是一個錯誤的結論，然後以訛傳訛就固化了下來。比如有人說MySQL1000萬以上效能極度衰減（如果說是全表查詢這個成立，但是這絕對不是資料庫的問題），我現在手裡就有一個十幾億的表。有人說Oracle處理不了大資料（可能對大資料有誤解，如果10TB的全表，的確不快。但是exadata可以做），我以前就有過一個表上百億資料，沒問題呀。

   所以千萬不要聽非資料庫專業的人和你談這些，會帶偏的。

   今天我聽到最多的是實時數倉和HATP。實時數倉有三種路線：

第一種是Lambda架構，存在離線和實時兩條鏈路。實時部分以訊息佇列的方式實時增量消費，一般以Flink+Kafka的組合實現，維度表存在關係型資料庫或者HBase；離線部分一般採用T+1週期排程分析歷史存量資料，每天凌晨產出，更新覆蓋前一天的結果資料，計算引擎通常會選擇Hive或者Spark。優點是資料準確度高，不易出錯；缺點是架構複雜，運維成本高。這樣乾的基本是公司花很大代價的錢，效果好不好不知道了。誰用誰知道。

第二種是Kappa架構，相較於Lambda架構，它移除了離線生產鏈路，思路是透過傳遞任意想要的offset(偏移量)來達到重新消費處理歷史資料的目的。優點是架構相對簡化，資料來源單一，共用一套程式碼，開發效率高；缺點是必須要求訊息佇列中儲存了存量資料，而且主要業務邏輯在計算層，比較消耗記憶體資源。這樣乾的是公司機器多，當然也是誰用誰知道。

以上兩種投入人力物力都不小。

第三種是實時OLAP變體架構，是Kappa架構的進一步演化，它的思路是將聚合分析計算由OLAP引擎承擔，減輕實時計算部分的聚合處理壓力。優點是自由度高，可以滿足資料分析師的實時自助分析需求，減輕了計算引擎的處理壓力；我個人覺得像HATP。比如OB、TiDB、Oracle、heatwave等等。

     好了不管哪種吧。我們退一萬步以上都好，都沒有問題（我覺得除了第三種問題少點，其他兩種怎麼可能沒問題？）那麼都做到了實時傳輸或者準實時傳輸。接下來見真章的時候來了，該出報表了，體現出數倉的作用了。結果最後一下拉胯了，資料實時送到倉庫了，結果一個報表出了1個小時。這還能叫實時嗎？

  所以實時數倉（我個人觀點）是實時傳輸和實時報表兩個方面。如何實時傳輸（HATP這種主從轉換以及行列轉換，效率最高問題最少）、如何實時報表，那完全是建模和實現邏輯的問題。設計是關鍵。