2021年11月23日至12月3日，中國信息通信研究院（以下簡稱「中國信通院」）對第13批分布式分析型數據庫共計27款產品進行了大數據產品能力評測。阿里雲實時數倉Hologres（原阿里雲交互式分析）在報表任務、交互式查詢、壓力測試、穩定性等方面通過了中國信通院分布式分析型數據庫性能評測（大規模），並以8192個節點刷新了通過該評測現有參評的規模記錄。在本次評測中，Hologres是目前通過中國信通院大數據產品分布式分析型數據庫大規模性能評測的規模最大的MPP數據倉庫產品。通過該評測，證明了阿里雲實時數倉Hologres能夠作為數據倉庫和大數據平台的基礎設施，可以滿足用戶建設大規模數據倉庫和數據平台的需求，具備支撐關鍵行業核心業務數據平台的能力。在Hologres實例的雲原生調度和運維體系建設上，團隊也聯合阿里云云原生等團隊，解決了在超大規模集群；在運維能力建設上，團隊通過自動化、智能化的運維體系建設，解決了實例部署和穩定性保障的問題。一 超大規模部署面臨的挑戰隨着互聯網的發展，數據量出現了指數型的增長，單機的數據庫已經不能滿足業務的需求。特別是在分析領域，一個查詢就可能需要處理很大一部分甚至全量數據，海量數據帶來的壓力變得尤為迫切。同時，隨着企業數字化轉型進程的加速，數據的時效性變得越來越重要，如何利用數據更好的賦能業務成為企業數字化轉型的關鍵。
大數據實時數倉場景相比數據庫的規模往往是成倍增加：數據量增加（TB級、PB級甚至是EB級）、數據處理的複雜度更高、性能要更快、服務和分析要同時滿足等等。
而使用過開源OLAP系統的用戶，尤其是通過開源OLAP自建集群的用戶，都有一些比較深刻的體會，就是部署和運維困難，包括ClickHouse、Druid等，都面臨了如下難題：
同時，隨着規模的增加，規模優勢和高性能吞吐下的壓力，實時數倉的部署和運維難度呈指數級增加，系統面臨了諸多調度、部署和運維上的各種挑戰：
如何解決調度能力滿足在單集群萬台規模下服務實例的秒級拉起和彈性伸縮能力的要求；
如何解決大規模集群自身的容量規劃、穩定性保障、機器自愈，提升相關的運維效率；
如何實現實例和集群的監控時效和準確性的雙重要求，包括怎麼在分鐘內完成問題發現和分鐘級的問題解決得益於阿里雲強大的雲原生基礎服務研發能力，實時數倉Hologres通過優秀的架構設計和阿里雲大數據智能運維中台的能力等多個核心能力的建設，解決這些挑戰，為用戶提供了一個性能強大、擴展能力優秀、高可靠、免運維的實時數倉產品。本文將會從超大規模部署與運維體系建設出發，分析超大規模實時數倉面臨的挑戰和針對性的設計及解決方案，實現在高負載高吞吐的同時支持高性能，並做到生產級別的高可用。
二 基於雲原生的大規模調度架構設計隨着雲技術的興起，原來越多的系統剛開始利用Kubernetes作為容器應用集群化管理系統，為容器化應用提供了自動化的資源調度，容器部署，動態擴容、滾動升級、負載均衡，服務發現等功能。Hologres在設計架構之初就提前做了優化，採用雲原生容器化部署的方式，基於Kubernetes作為資源調度系統，滿足了實時數倉場景上的超大規模節點和調度能力。Hologres依賴的雲原生集群可以支持超過1萬台服務器，單實例可以達到8192個節點甚至更大的規模。
1 Kubernetes萬台調度Kubernetes官方公布集群最大規模為5000台，而在阿里雲場景下，為了滿足業務規模需求、資源利用率提升等要求，雲原生集群規模要達萬台。眾所周知Kubernetes是中心節點式服務，強依賴ETCD與kube-apiserver，該塊是性能瓶頸的所在，突破萬台規模需要對相關組件做深度優化。同時要解決單點Failover速度問題，提升雲原生集群的可用率。
通過壓測，模擬在萬台node和百萬pod下的壓力，發現了比較嚴重的響應延遲問題，包括：
etcd大量的讀寫延遲，並且產生了拒絕服務的情形，同時因其空間的限制也無法承載 Kubernetes 存儲大量的對象；API Server 查詢延遲非常高，並發查詢請求可能導致後端 etcd oom；Controller 處理延時高，異常恢復時間久，當發生異常重啟時，服務的恢復時間需要幾分鐘；Scheduler 延遲高、吞吐低，無法適應業務日常運維的需求，更無法支持大促態的極端場景為了突破k8s集群規模的瓶頸，相關團隊做了詳細調研，找到了造成處理瓶頸的原因：
發現性能瓶頸在kubelet，每10s上報一次自身全量信息作為心跳同步給k8s，該數據量小則幾KB大則10KB+，當節點到達5000時，會對kube-apiserver和ETCD造成寫壓力。etcd 推薦的存儲能力只有2G，而萬台規模下k8s集群的對象存儲要求遠遠超過這個要求，同時要求性能不能下降；用於支持集群高可用能力的多API Server部署中，會出現負載不均衡的情況，影響整體吞吐能力；原生的scheduler 性能較差，能力弱，無法滿足針對混部、大促等場景下的能力。
etcd設計新的內存空閒頁管理算法，大幅優化etcd性能；通過落地 Kubernetes 輕量級心跳、改進 HA 集群下多個 API Server 節點的負載均衡，解決了APIServer的性能瓶頸；通過熱備的方式大幅縮短了 controller/scheduler 在主備切換時的服務中斷時間，提高了整個集群的可用性；通過支持等價類處理以及隨機鬆弛算法的引入，提升了Scheduler的調度性能三 Hologres運維體系建設1 Hologres運維體系總覽針對OLAP體系碰到的問題和痛點，以及在超大規模部署壓力下的運維挑戰，同時依託阿里雲大數據運維中台，我們設計了Hologres的運維體系，解決資源和集群交付等自動化問題、集群和實例級別的實時可觀測性問題和智能化的自愈體系，提升Hologres的SLA到生產可用級別。
2 集群自動化交付Hologres 是完全基於雲原生的方式設計和實現的，通過存儲計算分離的方式，解耦了計算資源和存儲資源；其中計算節點的部署通過K8s集群進行部署和拉起。通過自研的運維管理系統ABM，在集群交付上，我們對集群進行抽象設計，分離出資源集群和業務集群的概念；資源集群的交付，ABM和底層平台進行打通，進行資源集群的創建和容量維持；在業務集群上，ABM提供基於K8s 概念的部署模板，將管控等節點在資源集群上快速拉起，完成交付。
3 可觀測性體系系統的可觀測性能幫助業務更好的管理集群水位和問題排查等，從而提升企業級管控能力。在可觀測性上，不僅需要透出更加簡單易懂的監控指標，還需要有成熟的日誌採集系統，從而實現更簡單的運維，只需要為業務問題負責。基於阿里雲的監控產品和Hologres的可觀測性需求，我們設計了Hologres的實時監控能力。
Metric監控體系為了支持詳細的系統能力觀察、性能監控、快速的問題定位和debug，Hologres 支持了非常豐富的Metric監控體系，這也對整個Metric鏈路的採集、存儲和查詢提出了非常高的要求。在監控鏈路上，Hologres 選擇了阿里巴巴自研的Emon平台，除了支持億級Metric每秒的寫入，Emon還支持自動downsample、聚合優化等能力；同時在後端我們通過實時鏈路，可以把核心Metric吐到雲監控，方便用戶自助的對實例進行監控觀察和問題定位。日誌採集和監控在日誌採集上，Hologres採用了成熟的雲產品SLS，可以支持中心式的日誌排查和過濾 ；同時考慮到Hologres的日誌量也非常龐大，在採集上採用了分模塊和分級的機制，在控制成本的同時，能很好的解決問題排查和審計的需要。同時，SLS也提供了基於關鍵字等方式的監控方案，可以對關鍵錯誤進行告警，以方便及時處理問題。基於元倉的可用性監控在Metric和日誌的採集及告警上，更多的是體現某一個模塊上的問題，上面的手段還無法完整的回答某一個實例的可用性。基於此，我們構建了一個Hologres運維數倉，通過多維度的事件、狀態進行綜合判斷實例是否工作正常。在元倉中會收集和維護多維度數據，包括實例的meta數據、Hologres中各模塊的可用性判斷標準、實例各模塊的狀態、事件中心，包括運維事件、客戶事件、系統事件等；在進行實例可用性判斷的同時，元倉還提供了用於實例診斷、實例巡檢等各種數據。當前元倉的能力已經產品化發布為慢Query日誌，用戶可以通過慢query日誌，進行自助化問題診斷和調優。4 智能運維提升產品SLA在可觀測性完善的基礎上，為了提升問題定位的速度和縮短實例恢復時間，即提升Hologres的MTTR，基於阿里雲大數據運維中台提供的基礎能力和智能運維方案，我們構建了完整的Hologres SLA管理體系和故障診斷及自愈體系。
1 SLA體系基於Hologres運維元倉的數據和實例可用性定義，我們建立了Hologres實例級別可用性的管理系統，實例可用性數據會進入ABM的SLI數據庫，SLI根據數據和條件觸發實例可用性監控，在監控發出的同時，會觸發實例的診斷，系統根據診斷結果，判斷是否進行自愈，如果是已知可以自動恢復情況，會觸發自愈，進行故障的自動恢復；如果是未知情況，會觸發生成人工工單，工單系統會由人跟進完成，並逐步形成自愈的action。2 智能巡檢智能巡檢解決的是集群或者實例的一些隱性和不緊急的問題，避免一些小問題的日積月累引發質變影響線上的穩定性；除了一些比較清晰定義的巡檢項，智能巡檢還引入了聚類算法等，對系統指標進行分析，這也會幫助我們發現一些集群中的離散節點，進行及時處理，避免問題節點導致影響整個實例的可用性。
3 智能診斷和自愈智能診斷既依賴運維元倉的數據，同時還會依賴診斷相關的算法支持，包括日誌聚類、根因分析等，進行錯誤日誌的聚類，對聚類結果進行打標。在ABM提供的算法和工程能力支持下，實例診斷已經在幫助業務進行問題的快速定位，提升問題解決的效率，縮短了實例的MTTR。
四 Hologres產品級運維能力除了上面介紹的Hologres服務本身的運維穩定性保障。在Hologres 產品側，通過多種方式提升系統的穩定性：
採用高可用架構設計，穩定支撐阿里集團歷年雙11等大促流量峰值，經歷大規模生產考驗，包括
多形態replication解決數據讀寫分離，主要包括多副本提高吞吐、單實例資源組隔離、多實例共享存儲高可用
除了Hologres本身架構的設計，同時也為用戶提供多元化的觀測指標，實時監控集群狀態和事後復盤，無需複雜操作，只需為業務負責：
多維度監控指標：CPU、內存、連接數、IO等監控指標實時查詢，實時預警；
慢query日誌：發生的慢Query或失敗Query通過時間、plan、cpu消耗等各項指標進行診斷、分析和採取優化措施，提高自助診斷能力；
執行計劃可視化：通過多種可視化展現的方式，對Query進行運行分析、執行分析，詳細算子解讀，並進行優化建議引導，避免盲目調優，降低性能調優門檻，快速達到性能調優的目的。五 總結通過對大規模調度下面臨的調度性能瓶頸的分析和針對性的優化，Hologres 可以完成8192節點甚至更大規模的實例交付和擴縮容。同時基於雲原生的Hologres智能運維體系建設，解決了大規模集群和實例下面臨的運維效率和穩定性提升問題，使得Hologres在阿里巴巴內部核心場景歷經多年雙11生產考驗，在高負載高吞吐的同時實現高性能，實現生產級別的高可用，更好的支撐業務，為企業的數字化轉型提供了良好的支持。
阿里雲實時數倉Hologres：
https://www.aliyun.com/product/bigdata/hologram?spm=a2cbu.13822726.0.0.56711a9cIKkCzv
Redis入門到精通（進階篇）本課程從Redis入門開始，面向不同層次的學習者設計課程，既可以帶領初學者入門，同時也為已經入門的開發者提供了多個企業級解決方案，並結合當下較為集中的緩存問題進行深入剖析，並給出對應的企業級解決方案。
留言列表
留言列表