阿裏雲數據庫專家 姚奕瑋：AnalyticDB MySQL離在線一體化技術揭秘

阿裏雲雲棲號14:33阿裏雲計算有限公司

本篇內容將通過三個部分來介紹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上。

原文鏈接：http://click.aliyun.com/m/1000307716/

本文為阿裏雲原創內容，未經允許不得轉載。