火鍋、報表與數據庫的故事

本文的題目雖然有點小寫意，倒是純粹的技術分析貼，借用一個火鍋店的故事，探討報表查詢場景下的延遲問題和一點數據庫的特性。

好久以前，有一家老字號的火鍋店，顧客盈門，生意紅火。涮火鍋嘛，你們都知道的，首先是倒入鍋底湯料，等湯燒開了，往裏面放蔬菜、肉片、海鮮等各類食材，等食材熟了就能夠吃了。從食材下鍋到吃進嘴裏，有個等待的過程，時間的長短取決於兩個因素，一是火鍋下面的炭是否是充足，火是否是燒得足夠旺；二是食材一次不能放太多，特別是一些冷凍狀態的食材，不然就會等比較長的時間。

對於BI系統來講，各類食材就是上游系統提供的數據，BI系統的工做就是加工數據並相應客戶的查詢請求，就是加熱食材的過程。BI系統，或者說做爲其核心的數據庫，就是這個火鍋，磁盤大小至關於鍋的容量，CPU與內存至關於鍋下面的炭火。

這家店比較特別的地方是爲了凸顯客戶的尊貴，食材是由服務員負責放入鍋中，食客只管吃。此外，火鍋的管理模式是每桌的火鍋由一個服務員負責全流程管理，包括火鍋的清洗、上菜等等。

不一樣項目組負責集市的開發過程，運維環節也是由各自的管理員來負責，用戶只是最終報表的使用者。

在正常狀況下，食材被放入火鍋後5分鐘就能夠吃了，客戶很滿意。不知何時開始，狀況了發生變化，食客等待的時間越拖越長。終於有一天，客人午飯點的火鍋到了晚餐時間還沒吃上，客人很惱火找到老闆投訴。

業務用戶反映報表查詢的速度很慢，並且愈來愈慢，最後忍無可忍。

老闆找來大堂經理和大廚解決問題，通過各類跟蹤、調研，你們終於發現了問題所在。原來向火鍋中放食材的時候，有個服務員會往裏面加冰塊，咱們以爲他有點糊塗，叫他小胡吧。小胡不是一我的在戰鬥，店裏的服務員很多都是小胡的同鄉，也有這個習慣。顯然，冰塊會延緩食物的受熱過程，因此小胡們服務的客人都要多等好久才能吃到食物，致使了客人的投訴。

對於BI系統來講，延遲緩慢的一個主要緣由是SQL寫得不合理，致使查詢效率很低，也就是咱們說的爛SQL，就像小胡加的冰塊，無謂消耗了不少系統資源。

正好，老闆以爲多個火鍋也有問題，每一個火鍋的清理都是由不一樣的服務員負責，管理起來也費勁，是否是能夠搞一個大火鍋，順便解決管理的問題。

靠技術來帶動管理，是否是最佳方式 Ivan是有些存疑的，但有時確實有這樣的效果。

大廚針對「小胡加冰」問題和老闆的管理需求，提出瞭解決方案，代號「一口大鍋」。方案包括兩部分，一是換口火力猛的大鍋，二是對小胡們進行培訓。具體來講，首先須要一口大火鍋（某款MPP數據庫）替代如今每桌使用的普通火鍋（單機數據庫），但要具有兩個條件。一是大鍋的火力夠猛，造價低，實在不夠用還能夠擴展（基於X86服務器，可水平擴展）；二是後廚團隊掌握相應的使用技巧（由於批量加工上已經使用了這種技術，團隊對這種技術比較熟悉）。大廚選定的這款大鍋是九宮格火鍋，每桌食客用一個格子，體驗基本是不受影響的。（這個地方不要較真哈^Q^）（項目開發團隊和用戶都是面對邏輯上獨立的數據集市；同時，MPP數據庫具有必定的工做負載管理能力。）同時，再出臺新的操做規範，針對小胡和他的同鄉們進行培訓，嚴禁往火鍋里加冰塊（發佈新的SQL開發規範，要求開發人員不能寫爛SQL）

「一口大鍋」因爲其劃時代的革命性，立刻在火鍋業傳開，Ivan也聽到了這個方案，嘮叨一下本身的見解。

首先來講「操做規範」

這家老店日常也很重視培訓、整改，服務員也都是兩年以上的老員工，以前已經對小胡們進行過屢次培訓。同類的培訓和規範已經長期、反覆推行，此次真能改掉小胡們的壞習慣嗎？

對於IT系統，當然，人員基本技能是直接影響系統的交付和運維質量，若是同類的培訓和規範已經長期、反覆的推行，在培訓者和受訓方都沒有更替的狀況下，更加細緻的規範能不能提高SQL質量？這項措施雖然是政治正確，但能達到什麼樣的效果，實際上是還蠻可疑的。

若是是普通的大鍋，服務員們都在同時操做，一旦有人加冰，全部食客都受到影響，不是更難發現那個惹得麻煩的小胡嗎？若是可以把影響夠隔離開就行了。

對通常的系統建設來講，僅靠細緻的管理制度來強化人員的執行水平，實際上是代價高、風險大的事情。而系統架構的設計，其實就是要在更高的層面經過優雅的架構設計規避這種風險。有位同業專家曾經講過，「真正好的系統，是能夠從架構設計上避免運維事件的發生」，其實說的就是這個道理。

銀行業監管機構定義了一些系列運維事件定義，用於監督銀行的IT系統安全運營。
例如，一級事件：因爲重要信息系統服務異常、在業務服務時段致使兩個（含）以上省（自治區、直轄市）全部分支行業務沒法正常開展達3個小時（含）以上，或一個省（自治區、直轄市）全部分支行業務沒法正常開展達6個小時（含）以上的事件定爲特別重大突發事件

因此，Ivan認爲培訓是必要的，但系統的穩健運行不能過度依賴執行層面的因素。

再來講「大鍋的構造」

MPP數據庫這口大鍋可以解決隔離問題嗎？Ivan以爲可能仍是要商榷的。不少MPP數據庫都會聽從的一個基本原則，就是將數據打散平均分配在全部數據節點上。例如一張表有10億條記錄，MPP集羣有10個節點，則每一個節點會平均存儲1億條記錄。對這張表的查詢會推送到每一個節點上，然後彙總結果返回給數據庫的調用方。這樣，若是存在一個爛SQL，實際上會拖慢全部節點的速度，只不過當MPP集羣足夠大的時候，能夠更快的執行完這個爛SQL。

處理不一樣任務間的資源競爭問題，就要談到「工做負載管理」功能。簡單來講，工做負載管理就是對不一樣的工做任務所須要的資源進行細化分配，來大體鎖定任務間對資源的佔用，不會搶佔資源，致使某些任務受到影響，甚至被餓死的狀況。這裏的資源包括CPU、內存和磁盤I/O，其中磁盤I/O由於其因爲其物理尋道方式，每每很難進行劃分管理的。因爲上述MPP架構的特色，數據集市合併到一個物理集羣后，數據會被平均分配到每一個節點，磁盤I/O的競爭可能會加重，給「工做負載管理」製造更大的難題。因此說，MPP大鍋的隔離性可能還不夠。對於「小胡加冰」問題，若是沒法作好工做負載管理，就只能經過增長火力的方式，是一種粗放的、資源堆積的方式，不值得提倡。即便有再大的鍋，假如某天小胡發燒，加了整桶的冰塊，全部食客仍是沒得吃，潛在的操做風險仍是太大。

有更好的大鍋嗎？

看到這裏，你們可能會有本身的答案，Ivan認爲更好的方案應該是雲數據庫或者是能夠雲化的分佈式數據庫。分佈式數據庫與MPP一個很大的區別在於數據的存儲規則上。前者每每不是平均分配，而是將有限的數據副本（一般是3副本）存儲在集羣中的幾個節點上，而這些存儲節點能夠經過必定的管理策略來約束範圍的。這樣，至少在系統層面將I/O的競爭區隔開。也就是說，無論小胡加了多少冰，若是隻影響到他本身服務的食客，那風險就被能控制在有限範圍內。固然，除了強大的工做負載管理能力，系統的高可用性也很重要，任何系統的集中都會伴隨着風險的集中，拋開系統內部設計不說，這種邏輯層面上的單點依賴每每是管理者有所顧慮的，是須要慎重對待的。

本文所論述的MPP數據庫自己一般有成熟的高可用方案，並無做爲本文的討論重點，故略過。

後記

數據時代，信息化成熟的企業一般建設了不少BI報表系統，天天各級管理人員根據報表的數據調整企業總體的經營決策和各項具體措施、行動。系統除了保證數據準確，最受關注的就是查詢的相應效率也就是延遲時間（Latency）。BI系統爲了提供用戶須要的報表要作大量的ETL工做，經過預處理加工數據並存儲下來，採用空間換時間的方式，提高用戶與系統的交互速度。批量處理和聯機查詢若是在同一個數據庫的同一時間段進行，會產生大量資源的競爭，因爲批量加工是長任務，從目前的技術來講，是很難進行協調的。因此也會採用批量和聯機進行物理分離的方式，來規避資源衝突。即便如此處理後，也會發生聯機報表查詢響應緩慢的問題。

本文提煉出一個簡化的場景，關注對聯機查詢部分存在的問題，略去了批量部分。

說回火鍋，伴隨着溼熱和汗水的夏天就要過去了，吃火鍋的季節還遠嗎？Ivan去過的店，真有不讓客戶本身放食材的，但具有「工做負載管理」能力的大鍋還沒碰到，沒準有一天真會出現呢。