簡介：本篇內容為2021雲棲大會-雲原生資料倉儲AnalyticDB技術與實踐峰會分論壇中，阿里雲資料庫資深技術專家 姚奕瑋關於“AnalyticDB MySQL離線上一體化技術揭祕”的分享。
更多前沿分享，點選雲棲大會視訊回放連結即可獲取。
本篇內容將通過三個部分來介紹AnalyticDB MySQL離線上一體化技術。
一、傳統大資料架構面臨的問題和挑戰
二、雲原生資料倉儲的架構與彈性
三、雲原生資料倉儲診斷和運維
一、傳統大資料架構面臨的問題和挑戰
傳統大資料架構面臨的挑戰和問題主要有：第一，資料散亂、不一致，沒有一套統一的系統對這些資料進行分析。第二，分析不實時，一般會在夜間12點後對資料進行ETL清洗和轉換，資料直到第二天的早上才能被查詢到，資料時效性差。第三，系統複雜，為了解決資料時效性差的問題，一般的做法是在批處理上又引入了流式計算的引擎，形成著名的lambda架構，讓整套系統變得越來越複雜。第四，高學習成本。專業的研發人員是非常少的，導致他們的工資非常高，所以要維護這一套系統的成本也非常高。
二、雲原生資料倉儲的架構與彈性
為了解決以上問題，我們構建這套離線上一體的架構。我們的願景是：讓使用者會用資料庫就會用大資料。第一，是我們是高度相容MySQL，我們對MySQL的相容超過了99%。AnalyticDB MySQL是一個雲原生的架構，並且是儲存計算分離的，儲存計算可以分別擴縮容。我們用一套儲存系統支援了實時寫入以及多維的分析，並且通過智慧索引來支援任意維度的分析。除此之外，我們具備例如審計、自建賬號等完備的企業級的能力以及整套的備份還原能力。你如果誤刪了資料，AnalyticDB可以把資料閃回到你想要的時間點上。最後，我們的融合的計算引擎在同一套架構裡面同時支援了離線和線上、結構化和非結構化資料的查詢。
雲原生資料倉儲AnalyticDB的整個架構分為三層，最上面的是接入層，它負責生成一個執行計劃，並且我們的優化器會優化這個執行計劃、產生最終最優的物理計劃、切分計劃並且下發到計算層進行執行。整個資料的儲存，我們是分為兩級分割槽。一級分割槽，把資料打散在各個分片上面，保證了整個系統的水平擴充套件能力。第二部分提供了使用者自定義的二級分割槽。你可以按照時間來分割槽，比如按照天或者小時來進行分割槽。我們的計算引擎也會自動根據這些分割槽來做分割槽裁剪。整個儲存引擎支援強一致的實時增刪改，你可以高併發的寫入這些資料，並且資料寫入後實時可見。與此同時，我們的計算引擎還支援混合負載。
如果使用者需要一個離線上一體化的系統的話，需要哪些功能？第一個，你需要有支援多維分析以及ETL的能力。同時，必須支援資料的明細查詢和檢索。最後，你還要支援實時的高吞吐的查詢和寫入。這三個需求的交集就是AnalyticDB想要做到的部分。我們通過支援混合負載的融合計算引擎來做到高效能的查詢；我們通過行列混存以及深度優化的寫入方式來達到高併發以及高吞吐的寫入；然後我們通過智慧索引來做到明細的查詢以及資料內文字的檢索。
接下來看一看我們具體是怎麼做的。首先是寫入部分，離線上一體化的寫入部分有兩個需求。第一，高併發的資料流式地寫入。第二，對於已經有的存量資料，能夠高吞吐的把它匯入到AnalyticDB裡邊。左邊的部分，它是高併發的，整個流程當中，我們實現了資料的編碼和傳輸的各種優化，使得資料在整個過程中的流轉是零拷貝的，並且通過shard級並行和shard內部的表級並行做到了高併發。通過這套架構我們實現了千萬級每秒的資料寫入。右邊的部分是高吞吐寫入的架構。我們通過源頭向量化讀資料來源、計算引擎向量化直接寫入到儲存來做到高吞吐的寫入。
這部分講的是AnalyticDB提供的高價效比。如果使用者想把資料全部存在AnalyticDB上面的話，肯定會有冷存資料和熱存資料。比如說使用者想存三年的資料，但是有可能你只對最近一個星期的資料有熱存的要求。因為最近一個星期的資料需要經常查，剩下的資料，使用者希望低成本的把它存在AnalyticDB上，那就會放在冷存上面。所以我們提供了三種型別的表，一種是全熱的表，資料全部存在熱存。一種是全冷的表，資料全部存在冷存。還有一種是冷熱混合，也就是部分資料可以存在熱存裡，剩下的資料存在冷存裡。
接下來，看一下我們明細查詢。明細查詢利用了AnalyticDB的智慧索引能力。我們對於不同的資料型別有不同的索引。我們通過CBO來估算索引篩選率的高低，來決定是否使用索引。AnalyticDB根據不同的過濾條件使用不同的索引，最後漸進地多路歸併返回查詢結果的行號。我們內部的資料通過行列混存的方式進行儲存，並且通過meta裡面儲存的粗糙集來進一步過濾資料。我們還用了字典編碼來壓縮字串型別的資料。
我們在一套計算系統裡實現了離線和線上的融合。對於線上的查詢場景，使用者希望它的查詢能夠儘量的快。我們可以做到幾十毫秒甚至幾毫秒的分析型的查詢結果返回。我們通過調起所有的stage，並且運算元流式地、不落盤地處理資料來達到極短的延時。右邊的是離線的場景，延時並不是第一優先順序。使用者希望離線場景查詢能夠在固定的時間內穩定地跑完。
ETL型別查詢有可能會跑個幾天，這時候我們採取另一種batch的執行方式，整個過程非常穩定。資料在stage間的shuffle都會落盤。我們對Coordinator和Executor節點的當機都做了failover的支援，同時我們通過自適應的分批排程來實現子計劃的規模化排程。在整個計算的過程當中，我們通過Codegen減少虛擬函式的開銷、減少資料物化到記憶體，從而進一步優化我們的查詢。
Adaptive Execution解決的問題是,優化器估的再準，總是有誤差的。有可能最終生成的計劃和我想要生成的最優的計劃是不一樣的。那我們就需要在計劃執行的過程當中去自適應地調整這個計劃。我們實現了基於資料中間結果的自適應分割槽和基於資料結果的自適應計劃，起到了runtime矯正計劃的作用。
說完了計算和儲存，再說一下優化器。我們實現了整套智慧的優化。優化器分為兩個部分，第一個部分是底層統計資訊的採集部分。我們會根據查詢條件，自動在某些列上採集統計資訊。第二，我們會在規定的時間內通過Cascades的框架搜尋出最優的執行計劃，我們用一套優化器支援了整套離線上的查詢。並且我們的優化器，不僅對接了AnalyticDB內部的資料來源，還支援了外部的例如儲存在OSS、HDFS上的資料來源。做到了湖倉一體的查詢優化。
除了上面提及的一些效能的優化之外，我們還做了很多其他的效能優化：比如源頭向量化讀取；向量化演算法優化；自動物化檢視的改寫；基於代價的最大執行子樹複用等等。
AnalyticDB是支援多維的彈性的，計算支援從1個節點到5000節點，ETL+線上分析按需動態擴充套件。儲存的彈性分為兩個維度：儲存的容量支援從GB到100PB；儲存節點的QPS支援從1到百萬級。
來看一下我們為什麼要做彈性的功能。這是我們AnalyticDB在去年的某一週的所有的查詢。我們對它進行了分析。我們發現只有萬分之五的查詢等待超過了1秒。但是通過另一個維度從例項級別來看，反而有大約有10%的查詢超過1秒或者5秒的等待。這說明這萬分之五的查詢分散在不同的例項上面。說明業務有很多場景，它的查詢量，在非常短的時間內會暫時超過它的預估或者期望值，造成查詢排隊。這時候彈性就能很好的解決這個問題。
AnalyticDB提供了三種彈效能力，第一種是分時彈性。比如你知道下午4點到8點會有一個大促活動。那4點之前，我們會把這些計算節點幫使用者給彈出來。第二個是租戶隔離的能力，假如兩個部門有不同的查詢在同時跑，A部門的查詢並不會影響B部門的查詢。第三個是按需彈性。這個主要為了處理不可預期的流量，我們可以按需地彈出使用者所想要的節點來保證高優先順序業務的SLA。
我們的分時和按需彈性是怎麼做的呢？我們自己維護了一個資源池，然後在池子上寫了一套資源管理器。當使用者有彈性需要時，我們會從這個池子裡面取出節點，加到使用者的AnalyticDB裡。當他用完時，我們會自動把這個節點歸還回資源池裡。整個過程是非常快的，我們可以在分鐘級別完成這個操作。
AnalyticDB提供了資源組隔離的能力。不同的資源組的資源在物理上是隔離的。比如A部門的測試查詢並不會影響B部門的營銷查詢。
三、雲原生資料倉儲診斷和運維
一個優秀的資料倉儲，不僅僅核心要做的好，我們還要給使用者智慧診斷的能力。能夠讓使用者知道自己的系統的問題出在哪裡。所以我們做了一整套的智慧診斷系統。這套智慧診斷系統有很多技術元件，功能元件，這些都深度結合到我們的核心裡。當你有新的查詢來的時候，我們會根據聚類演算法來檢測是否有異常出現。如果有異常的話，我們會對接智慧告警系統，通過釘釘、電話或者郵件給你傳送訊息。
我們的智慧優化提供了自動分析的能力；提供了資料倉儲建模建議，根據系統的實際執行情況，我們會給出具體的建議來修改資料分佈或者分割槽，讓系統更加平滑地執行；同時，我們提供了智慧巡檢告警的能力。
從AnalyticDB離線上一體化架構對於使用者提供的價值來說，第一，我們提供了平臺的統一：使用者無需自建一套複雜架構來做離線上一體化；第二，相比於自建的系統，我們在效能上有了3到10倍的提升。並且我們整套架構是實時化的。最後，我們具備良好的相容性和生態，方便使用者自建叢集遷移到AnalyticDB上。
版權宣告：本文內容由阿里雲實名註冊使用者自發貢獻，版權歸原作者所有，阿里雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿里雲開發者社群使用者服務協議》和《阿里雲開發者社群智慧財產權保護指引》。如果您發現本社群中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社群將立刻刪除涉嫌侵權內容。