本文的題目雖然有點小寫意，卻是純粹的技術分析貼，借用一個火鍋店的故事，探討報表查詢場景下的延遲問題和一點資料庫的特性。很久之前，有一家老字型大小的火鍋店，顧客盈門，生意紅火 ...
本文的題目雖然有點小寫意，卻是純粹的技術分析貼，借用一個火鍋店的故事，探討報表查詢場景下的延遲問題和一點資料庫的特性。
很久之前，有一家老字型大小的火鍋店，顧客盈門，生意紅火。涮火鍋嘛，大家都知道的，首先是倒入鍋底湯料，等湯燒開了，往裡面放蔬菜、肉片、海鮮等各種食材，等食材熟了就可以吃了。從食材下鍋到吃進嘴裡，有個等待的過程，時間的長短取決於兩個因素，一是火鍋下麵的炭是不是充足，火是不是燒得足夠旺；二是食材一次不能放太多，特別是一些冷凍狀態的食材，否則就會等比較長的時間。
對於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去過的店，真有不讓客戶自己放食材的，但具備“工作負載管理”能力的大鍋還沒碰到，沒準有一天真會出現呢。
