1：大資料穩定性建設
大資料平臺承載著公司（推薦、搜索、bi、渠道推廣）等多條核心業務線，一旦某環節出現問題，可能影響很多線上用戶，基于以上情況聯合運維一起做線上穩定性建設，把各個體系的監控、預警提升到一個新高度，
2：如何構建線上穩定性
我們的組件監控在1.0版本中已上prometheus+grafana，線上各種組件監控已經有初步的保障，但是線上很多業務細節的監控缺乏保障，監控的顆粒度不夠，到真正出現問題，所有人手忙腳亂，大資料平臺一定需要業務賦能+穩定性治理，在業務賦能的的同時，逐步完善保障體系，
| 穩定性建設模塊 | 具體的預案 |
| 線上服務治理 | 1：大資料資料塊預警 2：監控application，做到保活、c端服務支持彈性擴容3:線上依賴的jar管理， |
| 組件穩定性建設 | 1：kylin,clickhouse,hbase,redis,elasticsearch 存盤優化、組件監控、保活， |
| ETL鏈路檢查 | 1：核心資料例外指標監控2：資料空洞、重跑、補充等， |
| 埋點鏈路資料檢查 | 1：埋點收集例外檢測2：線上問題追蹤，反查，資料補充， |
| 推薦服務檢查 | 1：推薦核心鏈路執行情況監控，例外、任務執行失敗通知 2：線上常用key資料檢查， |
| 線上hot key檢查 | 1：梳理核心業務hotkey,ttl以及命名規范，2：hotkey value 資料備份，以及資料更新， |
| 發布管理 | 1:代碼review 2:壓測 3：發布公約 4：發布的節點以及流程 5:跟蹤發布以及復盤， |
| 線上灰度 | 1:線上灰度制定以及監控 2：線上問題跟進 3：資料復盤，反推業務優化， |
3：組件穩定性建設
1:dolphinscheduler任務執行檢查
線上所有的任務都是基于dolphin提交flink、spark、shell 、http等，定時檢查任務的執行狀態來決定是否報警，通過查詢dolphinscheduler資料庫，所有的任務的命名嚴格規定，只允許TEMP打頭的任務可以不上線，其他任務必須上線（如果有人下線任務，5分鐘內就會有相關的報警）， 定時輪序一定時間段內的任務執行狀態，把超時、失敗的任務發出，讓相關人員跟進處理，
2：etl 鏈路檢查
1：檢測所有sql的錄入格式，sql依賴的source、sink 以及format sql，把錄入不合理的sql第一時間報警出來(推薦使用sql-table-name-parser 或 alibaba druid)，
2：spark sql執行所有數倉分層資料，我們會記錄任務的執行時間，單條sql執行的時間過長，會提醒相關人員跟進優化，把一些slow sql 扼殺在搖籃之中，
3:任務重試，如果單條任務執行失敗，把該條sql依賴的鏈路重新執行，確保相關資料的準確性以及可靠性，
3：kylin 資料檢查
1:kylin是bi系統的核心，我們針對cube segment回刷、cube膨脹率檢查、segment auto merge、segment構建時長檢查、segment空洞檢查、cube構建歷史檢查并重跑失敗job 等（7070是kylin 埠，直接模擬相關頁面請求，即可完成相關邏輯）
2：kylin 系統提供相關的api，只需要發起相關的http請求，在請求的時候把相關的header資訊帶上，即可繞過相關驗證，（使用ejlchina 實作相關http請求，支持websocket、http，使用比較輕便）
4：推薦相關資料檢查
推薦相關的資料我們主要通過定時備份資料，把hotkey資料備份到資料庫，萬一遇到冷啟動任務執行失敗，我們可以立即回寫最近一天的資料到hbase或redis
5：鏈路資料檢查
主要檢查kylin、elasticsearch、clickhouse 的資料同環比資料檢測，以及資料條數檢測，確保核心資料出現差異，第一時間預警跟進，
6：hdfs 檔案快治理
hdfs檔案管理是一個長期建設的程序，1：歷史的埋點資料歸檔 2：遷移歷史ods資料 3：每天新增的磁區資料合并4：hive表健康檢查 5：原始埋點資料壓縮，
4：總結
穩定性建設是一個長期的程序，大家在做業務專案的同時，一定要思考技術的創新以及穩定性建設，每一個專案都是自己的招牌，只有自己不斷的讓大家覺得你靠譜，未來才能有更大的專案以及更大的挑戰，反思與復盤一定會讓你突飛猛進，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/290216.html
標籤：其他