本文主要結合實踐總結了大規模報告穩定性保障方法。
專案背景
隨著資料化管理思維的逐漸深入人心，無論是網易集團內部使用者還是外部商業化客戶，越來越多的人在大規模使用有數BI。以嚴選為例，日常有訪問量的報告有5w+，這些報告覆蓋了使用者、商品、渠道、流量、營銷、倉儲、供應商、財務等幾乎所有業務板塊，有些報告嵌入在管理層用的app中，有些報告用在了業務週會或覆盤會，有些報告嵌入業務系統輔助業務決策...，在日常工作中發揮著重要的作用，高峰期圖表日查詢量10w+，這給報告的穩定性保障帶來很大的挑戰。
報告的穩定性保障，不僅僅要保障平臺的穩定性，更重要是要保障報告圖表查詢的可用性和效能。但是由於報告數量多，而且不同於普通業務服務，不同圖表的查詢耗時和耗資源差異非常大，底層資源始終是有限的，統一去保障難度很大，也無法保障業務核心報告的高可用性。
探索規劃
平臺的穩定性保障是有成熟的方法的，不是本文的重點。報告查詢的穩定性保障在我們實際工作中佔了更多的精力，在實踐中我們借鑑了服務分級保障的思想，不同的報告對業務重要性一定是有差別的，我們將重點報告標記出來，優先保障重點報告。當然這個重點、非重點是從要業務視角自上而下去看的。
保障物件明確之後，我們還要識別出重點報告依賴的資料產出鏈路和資料查詢鏈路上的相關元件和任務，這些元件和任務也需要重點保障，比如重點報告依賴的ETL任務、資料查詢依賴的impala引擎等等，我們需要為重點報告的表產出鏈路和資料查詢鏈路的元件和任務分配獨立的資源。
在資料查詢鏈路上，由於OLAP引擎的隔離性不是太好，最好使用獨立的叢集資源，實際中還可以根據重點報告的應用場景再去細分，比如看板類的和分析類的場景也最好也能隔離開，減少相互影響。
有了獨立的資源保障，我們還需要為重點報告制定核心指標去量化穩定性，這裡重點看三個指標，分別是圖表首訪快取命中率、圖表查詢錯誤率、圖表慢查詢比例。
重點報告圖表首訪快取命中率，這個是快取預載入效果的指標，保障使用者首次開啟報告的時候儘可能命中預快取秒開。
重點報告圖表查詢錯誤率，這個是圖表可用性的指標，相當於重點報告圖表查詢介面錯誤率，目前主要看整體的錯誤率，實際中也可以為不同的報告制定不同的錯誤率要求，這裡的錯誤率主要是指使用者瀏覽狀態下的查詢報錯。
重點報告圖表慢查詢比例，這個是圖表效能的指標，這個指標要先為圖表制定一個效能基線，比如<5s算慢查詢，實際中可以為不同的圖表制定不同的效能基線。
實踐方案
核心指標明確之後，我們需要為這些指標做相應的系統報告去監控、診斷和優化，不斷去改善這三個指標。我們主要通過事前（報告發布稽核、報告壓測）、事中（監控、診斷、干預）、事後（首訪快取命中率治理、查詢錯誤率治理、慢查詢治理）三部分來保障和優化，這裡主要結合網易高效能查詢引擎Impala的實踐來說明。
3.1 報告發布稽核
報告的開發本質上也是一種軟體開發，要完成高質量的交付，報告發布也需要有稽核流程，尤其是重點報告。稽核主要是兩方面，一方面要檢查下報告依賴的表和模型、報告製作上是否符合規範，比如表的儲存格式是否合理、表小檔案是否合理、模型是否用了分割槽欄位篩選、報告單個頁面圖表是否過多等等，這個有數BI報告上提供了“資料醫生-效能診斷”功能，可以自動診斷檢查；另一方面也要根據預估的併發數去壓測報告，看看報告效能是否達到要求，資源佔用上是否存在風險。
3.2 報告壓測
報告發布和效能優化都需要通過壓測來驗證，壓測分為兩種型別，一種是單個報告壓測，比如報告上線壓測、報告優化後的壓測驗證；另一種是場景化壓測，比如上班高峰期的流量壓測，場景壓測可以基於使用者的訪問日誌，模擬使用者的訪問流量去壓測。
3.3 監控和診斷
除了平臺常規的基礎監控和應用監控外，我們還要給重點報告核心指標新增相應業務監控，比如快取預載入數量監控、重點報告查詢錯誤監控、重點報告抽取任務出錯監控、重點報告慢查詢監控等等，有了核心指標監控我們可以發現問題及時處理。
針對某些特定的錯誤，可以提供診斷的能力，比如持續出現“圖表查詢高峰”錯誤，可以診斷下是因為哪些報告的影響，緊急情況下也可以根據需要暫時禁用報告來保障整體穩定性。
3.4 報告治理
要持續提升重點報告的穩定性和效能，定期的治理和優化必不可少，因為報告訪問量、表的資料量、表結構、表產出時間都存在一些不確定的變化。報告治理主要分為首訪快取命中率治理、報告查詢錯誤率治理、慢查詢治理三大塊。
要提升重點報告首訪快取命中率，核心是要提高重點報告快取預載入的完成比例，可以從以下三個方面優化：
（1）優化重點報告的表產出時間，重點報告依賴的表產出時間提前，才有更多的時間buffer去做快取預載入，這個需要資料開發和分析師同學一起從資料產出鏈路上去優化。
（2）提升重點報告快取預載入的優先順序，這個可以提升重點報告相較於普通報告快取預載入的先後順序，從而提升重點報告快取預載入完成率，同時重點報告也會根據最近訪問量等指標再去細分優先順序。
（3）對於一些快取預載入超時或出錯次數比較多的報告可以降低優先順序。
要降低重點報告查詢錯誤率，要對圖表查詢錯誤做分類治理：
（1）查詢超時的圖表要做慢查詢優化治理（見圖表慢查詢優化部分）。
（2）圖表查詢高峰錯誤需要診斷出可疑的報告/圖表進行優化。
（3）系統錯誤要通過系統優化來解決，比如後設資料錯誤可以增加後設資料重新整理重試，服務重啟錯誤可以增加查詢重試等等。
（4）業務錯誤要推進報告作者治理，比如原表被刪除、原表變更導致某些欄位不存在、資料來源連線不上等等。
圖表慢查詢治理方面，統一的治理有以下幾類：
（1）耗時耗資源圖表治理：top耗資源、top耗時圖表往往嚴重影響叢集整體效能和穩定性，多個慢圖表併發查詢時更容易出現查詢高峰，所以這部分治理是重中之重。當然這個治理也要結合圖表的訪問量去看的，訪問量大的圖表影響也越大。
（2）小檔案治理：小檔案過多會導致後設資料比較大，增加後設資料同步壓力，而且也會影響HDFS的效能。
（3）定時重新整理治理：耗時耗資源的圖表定時重新整理頻率過快，也會顯著增加叢集負載，可以降低頻率或者關閉定時重新整理。
具體到單個慢圖表，常見的效能優化思路有：
（1）模型強制分割槽篩選：大表全表掃描對效能影響較大，百萬以上大表建議使用分割槽表，同時在模型上設定強制分割槽篩選，減少資料掃描範圍，也從源頭控制全表掃描的可能。
（2）抽取到MPP：自定義SQL如果有篩選或聚合使得結果集減少可以抽取到MPP，通過MPP去查詢，減少複雜SQL實時計算；後續產品上也支援抽取寬表模型到MPP，這在CK引擎上會有比較大的效能提升。
（3）物化模型：模型中關聯的表過多導致效能差，可以使用資料任務預計算或者使用網易impala物化檢視物化模型。
（4）列表篩選器使用獨立維表：列表篩選器的資料需要從模型寬表明細對應列上去重計算得到，資料量大時效能較慢。如果列表篩選器成員比較固定的情況，可以列表篩選器走獨立維表，通過跨模型關聯篩選圖表。
（5）重新整理表統計資訊：Impala是基於代價模型進行執行計劃優化，表統計資訊缺失會對執行計劃的優劣產生重要影響，可以提前重新整理表統計資訊。
（6）時間/日期轉換：將“字串”型別的欄位轉換為“日期、日期時間”型別時，使用原始型別（即字串型別）進行比較則不需要在SQL中進行欄位型別轉換，可提高查詢效能。
（7）表儲存格式治理：text儲存格式資料過濾能力差，建議儘量使用高效能列式儲存格式Parquet。
小結
報告穩定性和效能保障是BI最重要的使用者體驗之一，方法上還需要不斷實踐總結，目前產品上已經有重點報告功能支援，後續還會有更多穩定性保障相關的系統報告和治理產品功能支援。
目前在集團內部雲音樂的治理已經頗具成效，核心指標方面，首訪快取命中率大於90%，重點報告日查詢錯誤率低於0.5%，重點報告圖表查詢>5s比例低於5%，今年和雲音樂一起制定了重點報告查詢錯誤率SLA目標，嚴選環境治理也正在進行中。
作者簡介
雪亮，網易技術專家，有數BI技術負責人，曾負責嚴選資料中臺、資料產品及服務研發，曾擔任《成為前端開發工程師》和《前端微專業》的JS課程講師，十多年網際網路產品研發和管理經驗。