海量數據毫秒級分析的背後—超大規模實時數倉架構挑戰與實踐解析

摘要：在DTCC 2019大會上，阿里雲智能資料庫產品事業部研究員林亮做了題為《超大規模實時數倉架構挑戰與實踐解析》的演講，數據分析領域目前正在朝著在線化方向演進，數據業務在海量數據實時寫入、高並發分析、穩定性、靈活性上挑戰巨大。分析型資料庫AnalyticDB是阿里巴巴自主研發的超大規模PB級實時數據倉庫，本次演講深入分析了AnalyticDB海量數據毫秒級分析背後的架構挑戰以及工程實踐。

阿里雲智能資料庫產品事業部研究員林亮

專家簡介：林亮(花名：意博)，阿里雲智能資料庫產品事業部研究員，曾就職Google十多年，在超大規模SQL Engine和規模存儲引擎上經驗豐富。目前在負責阿里雲PB級分析型資料庫AnalyticDB架構工作。

資料庫發展

在資料庫的發展歷程中，最開始出現的就是RDBMS，出現了SQL技術與OLTP技術，傳統的關係型資料庫的主要應用主要是基本的日常事務處理。資料庫的首要功能是能夠準確記錄商業活動中的各種交易包括訂單、支付、物流等，這些記錄當然需要保證萬無一失，必須滿足事務的ACID要求，這就是我們眼中的資料庫(OLTP聯機事務處理系統)的基本要求。當各種維度的歷史數據累積起來，普通查詢已經有壓力了。商業分析師和銷售團隊要求非常精細化和具體分析，基本很難從業務資料庫從直接獲取出來。這時候通過從資料庫提取數據、清洗、將數據以適合查詢分析的方式放入數據倉庫系統，也就是通常所說的ETL，之後在此基礎之上進行OLAP。數據倉庫支持複雜的分析操作，並且提供直觀易懂的查詢結果，為商業決策提供依據。

但是隨著互聯網業務的興起，尤其是電子商務的爆發，資料庫和數據倉庫的在商業領域的界限正在變得模糊，數據倉庫的實時化要求越來越高，對業務的實時評估，對庫存的實時盤點，使得以前那種離線分析模式越來越不可行。於是，業界開始進行不斷地嘗試，比如Google Spanner這一類混合負載HTAP的NewSQL資料庫試圖解決日益增長的OLAP和OLTP兩個不同維度需求。與此同時，我們看到資料庫需求在非商業領域的快速增長。各種異構數據源的加入，包括圖、時序、時空、向量等，使得數據產生速率更快，數據維度更高，數據量更大，實時處理(包括寫入和分析)和吞吐量要求更高。

阿里巴巴——資料庫

資料庫技術的發展趨勢也是近年來阿里巴巴在支持集團業務和雲計算業務中發現的趨勢。資料庫是阿里雲底層的核心架構，其支撐了阿里雲頂層的所有服務，包括大文娛、優酷土豆、天貓、淘寶以及高德、餓了么等本地服務以及螞蟻金融等場景，這些場景都在集團內部經過了多年的打磨，也在阿里雲上有了一定的技術輸出。在本次分享中將為大家介紹阿里巴巴資料庫團隊的技術積累和經驗。

OLAP——OLTP

首先簡單介紹一下幾個資料庫領域的基本概念。OLTP，也叫聯機事務處理(Online Transaction Processing)，表示事務性非常高的系統，一般都是高可用的在線系統，以小的事務以及小的查詢為主，評估其系統的時候，一般看其每秒執行的Transaction以及Execute SQL的數量。

隨著數據量的不斷增長，在1993年，學術界的E.F.Codd提出了OLAP概念，其認為OLTP已不能滿足終端用戶對資料庫查詢分析的需要，SQL對大型資料庫進行的簡單查詢也不能滿足終端用戶分析的要求。用戶的決策分析需要對關係資料庫進行大量計算才能得到結果，而查詢的結果並不能滿足決策者提出的需求。因此，E.F.Codd提出了多維資料庫和多維分析的概念，即OLAP。OLAP也叫聯機分析處理(Online Analytical Processing)系統，就是我們說的數據倉庫。在這樣的系統中，語句的執行量不是考核標準，因為一條語句的執行時間可能會非常長，讀取的數據也非常多。因此，OLAP能夠更好地幫助商業分析師和銷售人員來實現商業成長。

資料庫發展——架構

資料庫最初的發展階段就是單機資料庫，而在分析資料庫的大規模並行處理 (MPP) 體系結構中，有兩種主要方法： "Shared Nothing" 和 "Shared Everything"。在Shared Nothing中，每台伺服器獨立運行，並控制自己的內存和磁碟資源。數據在伺服器之間進行分區， 並且工作負載是分散式的，以便每台計算機都在自己的數據上運行，而無需與網格中的其他計算機共享硬體資源。在Shared Everything環境中，所有伺服器都訪問相同的共享存儲，並且每個工作負載都可以訪問該存儲，以及網格中所有伺服器的計算資源。

雖然Shared Everything和Shared Nothing有各種各樣的優點，但是也都各有不足之處。Shared Nothing的缺點是需要在節點之間複製共享數據，並在節點之間保持數據均勻分區，以實現一致的高性能。新的數據分片技術可以在沒有用戶干預的情況下自動重新分區數據，從而減輕了維護開銷。目前這方面的技術在學術界已經產出了大量的論文，而在商業上也有了一些應用，其降低了用戶整體的運維成本。由於對共享存儲的爭用，可能導致Shared Everything性能降低，而高性能分散式存儲緩解了這一點。總之，每種架構都會存在自身的一些問題，但是隨著時間的推移，這些問題也都在慢慢改善。

為需要滿足不斷變化的應用程序需求，在大多數情況下通過Scale Up (垂直縮放) 和/或Scale Out (水平縮放)來解決的。圍繞雲可伸縮性進行了許多研究和架構開發，這些研究和開發解決了雲如何工作的許多方面，並為新興的"雲原生"應用程序構建了架構。

Scale Up通過向現有系統添加更多資源以達到所需的性能狀態來完成擴展。例如，資料庫需要為了滿足SLA。可以將更多的計算、內存、存儲或網路添加到該系統中，以將性能保持在所需的水平。在雲中執行此操作後，應用程序通常會移動到功能更強大的實例，甚至可能遷移到其他主機並停用它所在的伺服器。當然，這個過程對客戶來說應該是透明的。Scale Out通過添加額外的節點。橫向擴展使服務提供商可以輕鬆地提供"按需付費"的基礎架構和服務。

資料庫發展——核心技術組件

智能化資料庫是資料庫各大廠商以及學術界的近年來關注焦點，主要包含內核智能化和運維管控智能化兩大方面。Oracle在2018年3月正式推出Oracle Autonomous Database。2018年1月Microsoft Azure SQL Database默認對其雲上全部資料庫開啟自動優化服務(Automatic Tuning)。目前工業界傳統資料庫廠商Oracle，以及幾大雲廠商Amazon， Azure都在資料庫智能化方向開始大力投入，並不斷地推出資料庫智能化產品或者功能。

如下圖所示的就是阿里巴巴資料庫的核心技術組件，最底層的是PaaS平台，PaaS平台提供了一些通用服務，包括彈性調度、資源管理、運維管控、計量計費、全鏈路監控、供應鏈關係等。下圖中左右兩邊，在PaaS平台之上提供了數據產品和智能優化，數據產品包括了數據管理工具、ETL工具、數據備份以及數據傳輸等;而智能優化則包括了智能調參、負載預測、診斷調優以及測試標準等。下圖的中間部分展現的是資料庫內核本身的相關功能，包括了軟硬體一體資料庫、資料庫內核以及多模態資料庫三個部分。

隨著新硬體的不斷出現，需要藉助新硬體來助力資料庫的發展，包括了硬體加速、新型SSD以及NVRAM等。舉例而言，前不久阿里雲資料庫首個跨入IOPS百萬時代的雲盤——ESSD，其單盤IOPS高達100萬，比上一代SSD雲盤最高測試數據快40倍，結合25GE網路和RDMA技術，ESSD擁有媲美本地SSD盤的性能，同時兼具雲盤的99.9999999%可靠性設計，並且支持自動快照、數據加密等高級存儲服務。正是通過這些軟硬體一體化技術幫助我們設計資料庫並獲得更好的性能。

對於資料庫內核而言，阿里的資料庫團隊也做了大量的工作，包括並行分析、分散式事務、複雜查詢、近似計算、彈性伸縮、冷熱分離、高可用、新型索引、計算存儲分離、存儲引擎以及內存資料庫等。對於內存資料庫而言，業界的主要代表有SAP HANA以及被Tableau收購的Hyper。內存資料庫解決的一個核心問題是在去掉了I/O 瓶頸以後如何更好的實現HTAP (Hybird Transaction and Analytical Processing)。但是內存資料庫的發展也受限於單節點物理內存的大小，以及如何確保Durability等問題。AWS的內存增強型實例已經可以支持到12T的內存，但任何內存資料庫還是要有Durable Storage Media來確保數據的不丟失。

資料庫發展——更高的應用訴求

隨著資料庫技術的發展，用戶也有更高的應用訴求。用戶的訪問量逐漸增多;數據也在不斷增長，目前雲上實時數倉裡面存儲了超過100PB的數據，大型單庫查詢達到了上萬QPS，單節點寫入吞吐達到了1400萬TPS，無論是從數據規模還是吞吐量都能看出，數據呈現爆炸式增長;同時，目前接入金融、新零售、政府等十多個行業，而各個行業具有自己對於實時數倉的不同需求，因此提出了更大的挑戰;比較通用性的挑戰包括更加實時性的要求，更多的維度以及越來越多的吞吐量，同時數據來源也越來越多，出現了各種異構的數據源，數據格式也各不相同。

資料庫發展——技術挑戰

以上的資料庫訴求轉化為了8個方面的技術挑戰。

1)行列混合存儲;OLTP適合於行存，OLAP適合於列存，而對於如今的實時數倉而言，需要同時提供高吞吐量和高性能，因此需要行列混存的存儲結構，同時需要HTAP這種混合負載的支持。

2)混合資源調度;實時數倉不單只適合於複雜查詢，也需要滿足短查詢能力，還有ETL，因此需要更好地協調內存、CPU、網路和磁碟等資源的調度，更好地提升網路帶寬並降低延遲。

3)智能引擎;也就是比較熱門的如何利用機器學習等自動化方式來幫助系統實現更好的優化。

4)增強分散式的查詢引擎能力。

5)多模;DB-Engines在2019年3月，正式將多模定義為資料庫基本熟悉，代表多模已經成為資料庫產品標配屬性。同時在最近2-3年里，在開源領域發布的資料庫產品均主打多模能力，例如：Apple的FoundationDB，初創資料庫公司YugaByteDB等。在多模能力下，可以為用戶提供多樣性的數據建模靈活度，同時還具備一致性的用戶操作體驗，極大的降低了用戶開發成本，提高工程效率。在雲計算領域，最具代表性的多模資料庫產品是Azure CosmosDB，其提供了兼容MongoDB協議的「文檔模型」，兼容Gremlin的「圖模型」，兼容Cassandra CQL語言的「款表模型」;同時，AWS 也將DynamoDB重新定義為多模資料庫，而不在是傳統KV NoSQL。

6)更好地利用硬體實現加速。端到端加速才能發揮強計算力硬體的全部效能，隨著NVIDIA收購Mellanox，新型高速集群(resource pooling)和完備的SDK將有望落地，屆時所有海量數據能夠在高速計算資源池完成全部複雜計算任務，數據可(解)讀化和可視化已經在數據分析領域成為數據分析標配，特別是大規模可視化能夠充分發揮GPU的大規模高速渲染能力。

7)資料庫的彈性伸縮Scale Up和Scale Out。

8)雲原生;CNCF給出了雲原生應用的三大特徵：容器化封裝，以容器為基礎，提高整體開發水平，形成代碼和組件重用，簡化雲原生應用程序的維護。在容器中運行應用程序和進程，並作為應用程序部署的獨立單元，實現高水平資源隔離。動態管理，通過集中式的編排調度系統來動態的管理和調度。面向微服務：明確服務間的依賴，互相解耦。

AnalyticDB整體架構

阿里雲AnalyticDB採用分層解耦架構，同時將分析計算、數據寫入、索引構建等分離為不同節點，同時各種類型節點採用多活運行模式實現高可用，數據存儲在盤古分散式文件系統上，實現高可靠和高性能讀寫I/O，在整體架構上實現了彈性擴展和高可用。

AnalyticDB的整體架構可以分為三層：

前端接入層

多活的前端節點負責接收SQL請求，並解析生成執行計劃，對於 INSERT語句，將數據發送給 Buffer Node寫入緩存節點，對於查詢語句，將查詢任務分發給計算節點 Computing Node，完成數據分析，並匯總結果返回給客戶端。AnalyticDB 的SQL解析器採用阿里自研的高性能SQL Parser 「fastsql「，全面兼容MySQL的語法和函數，同時兼容MySQL的通信協議，支持JDBC客戶端接入。SQL優化採用基於規則和代價的優化模式，支持分區減枝，CTE歸併等SQL改寫規則，同時基於統計信息，實現最優JOIN ORDER等分散式查詢路徑的優化。

彈性計算層

計算節點(Computing Node)：計算節點接收 FN 下發的執行計劃，並行完成數據的分析處理任務。CN計算節點會從盤古讀取數據，並將熱數據緩存到本地SSD磁碟。計算節點內包括AnalyticDB的曦和分散式計算引擎和玄武存儲引擎。曦和計算引擎支持各種SQL 運算元操作，支持分散式並行執行框架。玄武存儲引擎實現了自研的行列混合存儲格式及多種索引技術，支持將絕大部分計算條件基於索引完成，從而提供極致的分析性能。

採用此讀寫分離架構，可隔離寫入和分析計算負載。無論是計算節點還是寫入節點，都可以根據負載和場景進行靈活配置和動態擴縮容，滿足業務敏捷發展的需求和各種負載下的動態穩定性。

因為對於資料庫而言，並不能只關注於整體架構，也需要關注一些小細節，這裡為大家列舉幾個典型優化點的例子。

優化點1：執行調度

數據查詢有複雜查詢也有短查詢，同時也有ETL這樣的大規模數據處理。那麼如何保證短查詢能夠盡量保證滿足用戶並且儘快返回，同時複雜查詢能夠正常運行完畢，不會因為短查詢佔用而導致「飢餓「狀態。在資料庫內核層面，AnalyticDB參考了Liunx的內核調度機制，資料庫內核會記錄每一個Query 的總執行耗時，Query總時間耗時又是通過每一個Task耗時來進行加權統計的，最終在Query層面形成了一顆紅黑樹。每次總是挑選最左側節點的Driver進行調度(被Block的Driver不在這顆樹上)，每次取出或者加入(被喚醒以及重新入隊)都會重新更新這棵樹，而在Driver被喚醒加入樹的時候也會進行參數調整來處理極端情況，以此保證飢餓不會發生。

上圖中左側是在資料庫內核層面利用線程實現更好地調度，但是資料庫線程對應到物理機的內核上其實是不同的，因為大部分時候線程數會遠高於資料庫內核數。那麼，在資料庫裡面，線程任務下發之後，內核層還是會有相對應的爭搶。AnalyticDB對於資料庫內核進行了一定的調整，通過引入內核層面的控制可以有效解決快查詢低延遲的問題，且無需對運算元的實現進行任何的改造。AnalyticDB讓高優先順序的線程來執行快查詢的運算元，低優先順序的線程來執行慢查詢的運算元，因此通過高優先順序線程搶佔低優先順序線程的機制，快查詢運算元自然會搶佔慢查詢的運算元。這樣一來就能夠使得短查詢和長查詢能夠分配到不同的優先順序上進行執行。

同樣的在實際應用中，很難要求用戶來辨別快慢查詢，這是因為用戶的業務本身可能就沒有快慢業務之分。雖然優化器能夠提供代價模型的估算，但是不一定很準確。因此，在這之上也可以根據查詢過程中運算元的執行時間、調度次數等信息進行統計，當運算元的計算量達到給定的慢查詢的閾值後，系統會把運算元從高優先順序的線程轉移到低優先順序的線程中。

優化點2：內存管理

說完了CPU，再來看看內存。對於不同的查詢而言，也會有不同的內存使用量，這一點在使用過程中也需要考慮到。

對於AnalyticDB的內存管理模型而言，引入了內存池。申請分配內存會產生很多大小不定的內存塊，當頻繁使用時會造成大量的內存碎片並進而降低性能。而內存池則是在真正使用內存之前，先申請分配一定數量的、大小相等的內存塊留作備用。當有新的內存需求時，就從內存池中分出一部分內存塊，若內存塊不夠再繼續申請新的內存。這樣做的一個顯著優點是盡量避免了內存碎片，使得內存分配效率得到提升。這種內存池的設計目前在業界也是比較通用的方法。AnalyticDB在內存分配上就使用了內存池架構，此外還在此基礎上對於快慢查詢做了內存管理，能夠保證用戶的快查詢能夠獲得儘可能多的資源，同時慢查詢能夠保證具有一定的內存分配。此外，使用內存池之後使得數據落盤變得更加方便了，不需要原來繁瑣的序列化和反序列工作。

優化點3：自研優化器

AnalyticDB採用了自研的優化器，本身除了實現了RBO基本功能之外，也實現了一些優化工具，包括計劃診斷、計劃管理以及為用戶提供使用建議等。此外，優化器使得計算和存儲能夠更加緊密地結合在一起，針對於存儲性能和存儲功能對於計劃實現進一步改進。

優化點4：GPU引擎

當SQL從前端節點發送到計算節點，經過解析和邏輯計劃生成以後，Task manager會根據計算的複雜程度選擇由CPU引擎來處理還是由GPU引擎來處理，目前，AnalyticDB也正在逐步完善CPU框架，正在完善CPU和GPU的代價模型的建立，所以現在的判斷規則相對簡單。當選擇GPU引擎之後，邏輯執行計劃會在GPU引擎裡面生成PTX代碼並進行計算。

對於高並發顯存管理而言，現在很多基於GPU的資料庫其實是單查詢佔用了GPU所有的顯存，而顯存卻是GPU上非常珍貴的資源，考慮到高並發場景以及數據分片，因此AnalyticDB提供了一套顯存管理策略。此外，對於CPU-GPU堆外內存傳輸以及SSD到顯存的直傳也都是性能上的優化點。

下圖的數據來自阿里雲的一個客戶，通過引入GPU之後能夠看到使得查詢性能有了3到10倍的提升，同時資源的消耗降低到原本的30%左右。眾所周知，隨著摩爾定律的失效，CPU的發展越來越緩慢，依靠CPU的計算性能去解決上述問題越來越難。相反，GPU的發展卻非常迅猛，從計算核心數(P100多達3840個計算核心)、memory帶寬到浮點計算能力，不僅相對CPU有很大優勢，而且發展比CPU快。在人工智慧領域，GPU是當之無愧的明星，其計算能力得到了充分的驗證，也為我們提供了更多的可能性。

優化點5：自動化運維

智能化資料庫內核和智能化資料庫管控運維平台一定是下一代資料庫系統核心競爭力的主力戰場之一。隨著資料庫系統設計向精細化和複雜化演進，用戶數據的不斷增長和用戶工作負載的多樣化變化，傳統的依賴於基本統計學原理和簡單成本模型的資料庫內核優化技術已經不能高效的適應於這些高維度的調優挑戰。同時，隨著上層業務邏輯和應用的複雜化以及應用規模的成倍增長，資料庫實例數以及系統參數不斷增長，資料庫系統的運維管控和監控越來越需要智能化和自動化。

機器學習技術的迅猛發展為解決這兩類問題提供了有力的武器，結合DBA的領域知識和經驗，以及資料庫系統的運行數據，通過進行有監督或無監督的學習和建模，機器學習/人工智慧技術可以有效地實現智能化的資料庫內核以及智能化的自治資料庫運維平台。具體來說，在查詢優化，系統參數調優，以及智能化系統運維等方向上，人工智慧/機器學習技術和資料庫系統都有很強的結合點。

優化點6：新硬體

下一代資料庫設計的核心技術挑戰中就包括了存儲計算分離。對於新硬體而言，資料庫系統可以利用新的存儲媒介(NVM)和網路訪問(RDMA)來實現分層存儲和共享存儲，利用異構硬體資源進行各種類型的計算加速(GPU， FPGA)。

資料庫系統的研發一直是以系統硬體資源的特點為基礎而出發去設計的，例如傳統的查詢優化器以優化IO為指標。那麼，隨著硬體資源性能特點的不斷演進，資料庫系統的設計和優化也要與時俱進。具體到存儲技術來說， NVM提供了類DRAM的存儲性能同時又能夠確保數據的持久化存儲(類SSD)，在DRAM和SSD之間又加入了一層存儲媒介。資料庫系統的數據冷熱分離和分層存儲會成為大趨勢。類似LSM (Log Structured Merge) tree的存儲結構會更大的發揮它的優勢。

業界認可

在Forrester最新的雲化數據倉庫分析報告和同年Gartner發布的分析型數據管理平台報告中，阿里巴巴屬於榜上為數不多的國內廠商。這體現了阿里巴巴多年來在打造DT商業過程中的大量數據分析技術積累。阿里巴巴的整套數據分析平台AnalyticDB作為分散式分析型資料庫，更是承載了將數據探索實時化，在線化的關鍵任務。

標準測試——TPC-DS

阿里巴巴2019年在TPC-DS上發布了AnalyticDB的測試結果，目前在所有發布的廠商里位於第一名。TPC-DS屬於相當困難的測試，其包括了多種查詢，對於優化器以及查詢性能具有較高要求，並且綜合考慮了數據調入、單並發以及多並發等多方面能力，並且要求數據的高可靠性等。而AnalyticDB通過整個TPC-DS測試，證明了自身性能、穩定性以及可用性，通過結果可以看出，無論是從性價比還是查詢性能上來看，AnalyticDB都要比其他廠商更好。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！