簡介：如今，對于在線分析技術而言，正在從“Big Data”時代向著“Fast Data”時代邁進，所面對的技術和市場環境發生了巨大變化，與此同時也需要面對全新的挑戰。在第十一屆中國數據庫技術大會（DTCC2020）上，阿里云數據庫高級技術專家吉劍南為大家帶來了在線分析進入Fast Data時代的個關鍵技術解讀。

摘要：如今，對于在線分析技術而言，正在從“Big Data”時代向著“Fast Data”時代邁進，所面對的技術和市場環境發生了巨大變化，與此同時也需要面對全新的挑戰。在第十一屆中國數據庫技術大會（DTCC2020）上，阿里云數據庫高級技術專家吉劍南為大家帶來了在線分析進入Fast Data時代的個關鍵技術解讀。

本文內容根據演講錄音以及PPT整理而成。

From“Big Data”to“Fast Data”

經過近幾年的發展，在線分析所面臨的技術挑戰正在發生變化，甚至可以認為進入了下一個時代。前幾年大家都有一個耳熟能詳的名詞，那就是“Big Data”。與此同時，在硅谷出現了很多在大數據領域很火的公司，如cloudera、hortonworks、MapR等，他們都是圍繞Hadoop生態提供數據分析軟件或者服務。如今，cloudera和hortonworks合并，并且市值一度暴跌40%；另外的一家則被收購，并且面臨著轉型的風險。與其形成形成鮮明對比的是，今年也出現了一家火出了技術圈的公司，它也可能是這些年唯一一個讓股票分析師和數據庫從業者同時產生巨大興趣的上市公司，那就是Snowflake。Snowflake、AWS的Redshift和阿里云的ADB這些產品開始將數據分析帶入到“Fast+Online”的時代。

圍繞“Fast+Online”這兩個關鍵詞，在線分析開始有了不同于大數據時代常規的一些關鍵詞，比如實時分析、實時數據、實時計算、云原生、彈性、在線工作負載等，這些就是過去幾年的變化。

市場分析

市場趨勢：數據規模爆炸性增長

接下來為大家介紹一些機構結合調研對于未來市場的判斷。以下的數據來自于今年早些時候IDC和Gartner的一些調研數據。IDC預測2020年全球數據規模會達到40ZB左右，并且預測在2025年，數據規模將會相較于現在再增長430%，也就是每年都會有三位數的比例增長。結合現有存量數據來看，這樣的增長速度還是非常恐怖的。

市場趨勢：數據在加速上云

在數據存儲上云的趨勢來看，到2025年，數據存儲的云上規模將達到49%，也就是將近一半的數據都將存儲在云上。而數據的規模則會在更早的2023年，將近四分之三的數據庫會部署在云上。

市場趨勢：數據業務實時化占比大幅提高

不僅在數據規模層面，業務對分析新增實時數據的占比，將達到30%。使用實時數據的分析結果進行商業決策、報表制作等的新業務，也將在2022年提高到50%。

技術發展——OLAP技術演進

在阿里巴巴內部，最早的數據分析需求運行在Oracle RAC上。隨著成本降低的訴求，以及分析型和事務型解耦，在2009年開始使用GreenPlum，而2009年前后基本上是淘寶發展最快速的階段，數據分析的需求和體量不斷增大，GreenPlum由于規模的問題，很快到達了瓶頸。2011年出現了兩個技術方向，即以HBase為主的Hadoop生態和Kylin等，以及使用MySQL分庫分表，通過數據庫Sharding做數據分析。但是這兩種方向都不太適合大數據的發展方向。在之后的2012年，阿里自研分布式數據庫AnalyticDB正式服務集團，在此后的8年里，AnalyticDB以高性能、低成本、毫秒級響應高并發多維分析查詢的優勢，在集團內部維護了超過5萬個節點，服務了上千個業務，幾乎覆蓋了阿里巴巴經濟體幾乎所有BU。到2019年，AnalyticDB-3.0以云原生、高并發、低延時，高達100PB在線數據分析體量成為阿里云上核心的分析型數據庫產品。簡單回顧阿里巴巴內部在線分析的發展歷程，從商業單機到商業分布式，從商業走向開源，再從開源到自研。

AnalyticDB作為一個面向Fast Data時代的一個在線數據分析標桿型產品，在做自研的過程中也面臨著很多技術挑戰。

主要的挑戰包括四個方面：

• 首先是高吞吐的實時寫入，這是實時數倉的一個核心前置條件。數據只有能夠快速的進入分析系統，實時才具備可行性。因此，可以認為高吞吐的實時寫入是Fast Data的基礎。
• 其次是在離線混合工作負載。企業數字化分析是多元化的，涵蓋了實時的BI決策，實時報表、數據ETL、數據清洗以及AI分析。傳統數倉方案是通過組合多套數據庫與大數據產品，利用各自不同的優勢來解決不通的分析場景，而帶來的問題就是整個數據冗余，同時需要維護多個異構系統管理的代價。
• 第三是冷數據低成本、熱數據高性能的一體化存儲。在解決了一套系統同時支持在離線分析后，那么帶來的核心問題是：如何既能夠支持在線分析高性能，同時又可以支持冷數據的低成本存儲。因此，動態的數據管理機制和靈活的緩存策略也將是一個很大的挑戰。
• 最后是彈性可擴展。數倉中分析類查詢對資源的靈活需求，由于業務變化而不斷變化的數據體量，都對彈性這一云原生的核心特征提出了訴求。

典型的“Fast Data”架構

結合以上的挑戰介紹典型的“Fast Data”架構。上圖左側是一個經典的數據庫核心模塊，FrontNode節點負責提供協議能力。同時，對于數據庫和大數據一體化的系統，最廣泛使用的MySQL和Spark API兼容是標準配置。再下面一層則是優化器，分析類查詢的一個顯著特征就是查詢的復雜性遠高于事務類查詢，同時由于參與查詢的數據規模很大，執行計劃的好壞對于查詢性能的影響往往是巨大的。因此一個成熟、穩定且高效的優化器是在線分析的核心，應該具備多樣化的優化方式。再往下是計算引擎，良好的彈性和隔離能力是計算引擎需要具備的核心特征，在此之上，支持在離線混合復雜的離線計算模型再加上高效的計算引擎，最終構成了大規模進行數據分析的基礎。最下面這層是存儲層，存儲服務化是存儲與計算分離的前提，在存儲服務化的基礎之上設計一些高效的行列格式，再加上靈活的索引機制，通過高性能的本地ESSD和低成本的遠端OSS，基于靈活的緩存機制，同時滿足客戶對于熱數據的實時查詢和冷數據的低成本維護訴求。

“Fast Data”關鍵技術

結合典型的Fast Data架構來介紹涉及到的關鍵技術：

• 首先是計算存儲分離技術。通過解耦計算和存儲，業務方可以自由選擇資源配比，并按需擴縮容。
• 其次是彈性的資源組，針對有階段性波峰波谷的負載特征，業務側可以靈活調整資源配額，以不同的時間維度制定不同的資源組擴縮容計劃，并且基于對查詢負載資源需求的估計，按需進行資源組的選擇。
• 第三是自適應優化，數據的實時性和體量巨大的歷史數據會讓傳統依賴統計信息的優化手段失效，自適應優化在傳統優化方式的基礎之上會動態的根據執行信息中反饋的數據特征調整執行計劃，使得整個執行計劃達到高效狀態。
• 第四是冷熱分層和開放存儲。一方面存儲成本決定了數據規模和集群規模，將數據的維護成本降低在可控的范圍內，業務才有機會通過數據分析尋找數據價值。另一方面對業界開源生態格式的兼容，讓系統具備了一定的開放能力，不同的系統間可以通過開源的格式進行交互，降低業務ETL的復雜性。

計算存儲分離

接下來將從更細節的角度來拆解每一項關鍵技術。首先是存儲計算分離，存儲層向上提供統一的數據接口服務，計算層可以獨立彈性擴展，資源組在相互隔離的基礎上，同時具備按照時段編排擴縮容計劃和預留基礎資源的功能。通過計算與存儲的解耦，用戶可以較為靈活地單獨對計算資源、存儲容量進行單獨擴縮容，更加合理控制總成本。同時，針對計算資源的擴縮，不再需要數據的搬遷，具備更極致的彈性體驗。數據冷熱分層作為計算存儲分離后，控制成本的核心技術，接下來將進一步展開介紹。

冷熱混合存儲

數據冷熱分層存儲并沒有簡單地通過緩存機制來實現，而是將冷熱這個概念下放到了表級別，同時在表級別也支持冷熱混合的方式。比如將數據表分為3類，即用戶信息表、操作日志表、訂單表，他們分別具備的特征是：用戶信息在業務端是非常頻繁使用的表，將其存儲策略定義為hot；操作日志，較少用來做查詢，更側重于低成本的歸檔，定義為cold，存儲在遠端的OSS；訂單表側重于3天內數據會被頻繁查詢、3天前的主要進行數據歸檔，將其存儲策略定義為mixed。與此同時，定義hot_partition_count為3。數據在最初寫入時會作為熱數據存放在SSD中。通過異步的合并機制，將其按分區的維度重新組織，當新的分區創建出來后，會有異步的線程根據hot_partition_count中定義的數量，將過期的數據遷移到遠端存儲OSS上，那么遠端的數據查詢將直接通過SSD的cache獲取。通過這樣的機制，實現了冷熱分層、冷熱策略的的輕松定義，冷熱分區的自動遷移，以及冷熱數據的一體化訪問接口。

行列混存+多維索引

既然提供了一體化的存儲接口，必然會涉及到多種查詢場景，如數據庫IDE工具中常見的查詢一張表所有的明細數據，同時作為面向分析場景的數據庫系統，列存在進行數據壓縮，高效訪問又有著非常大的優勢，行列混存則可以兼顧兩種訴求，典型的行列混存的格式如圖所示。

將列的值以32768作為一個block，然后將不同列的block拼接為一個RowGroup。并將block級別的元數據信息存儲到文件頭，用于做快速過濾。除了列的元數據信息外，索引也是數據庫系統中常見的加速手段，采取了多維索引的方式對組合查詢條件進行過濾檢索。針對于不同的數據類型，使用不同的索引格式，對于任何條件的組合查詢，能夠通過索引歸并快速拿到目標數據集，然后目標數據集進一步走到計算層進行進一步計算，從而達到大幅度篩選候選集的目的。

彈性模式-資源組（池）多租戶

在定義計算的彈性時，首先將計算的節點劃分成資源組，一個集群可能擁有多個資源組，每個資源組具有不同的資源，資源之間是物理隔離的。并且資源組可以綁定用戶，通過這種機制可以實現各個資源組之間的資源實現物理隔離，這樣業務方就可以為不同的業務部門設定不同的用戶，這樣不同業務方之間的工作負載就不會相互影響，各個業務方可以自行制定自己的查詢隊列、響應時間以及并發數等，實現不同資源組之間的隔離。上圖中的計算層劃分了三個資源組，分別是用于在線分析的默認資源組，用于進行離線ETL，batch查詢的彈性資源組，以及支持Spark任務的算法、迭代資源組。這三個資源組共享同一份數據，支持不同的工作負載。

業務申請一定的計算資源，然后將節點分配給不同的資源組。不同資源組的節點調整可以毫秒級完成分配，同時資源組可以綁定到固定的用戶，這樣業務側通過給不同的部門分配不同的用戶，就可以將整個集群按資源隔離出給多個部門使用。資源組內獨占當前的物理資源，保證資源組間不會相互影響，同時資源組可以單獨的配置同時的并發上線和查詢隊列以及監控，滿足不同部門間對查詢SLA的不同要求。并且通過這種方式實現了一份數據在多種場景下，包括離線計算、在線計算、再加上Spark運算等場景的整體支持。

彈性模式-分時彈性

資源組設定完成以后，就可以為不同的資源組指定不同的彈性計劃。可以按照小時、天以及周制定分時計劃。同時也支持按照多時段的分段彈性。如上圖中例子所示，業務負載的高峰期在上午8點半到11點半，那么業務側就可以指定一個小時級別的彈性計劃，8點半擴容到256個節點，在11點半縮回64個節點。通過這樣的機制，業務側無需為一天剩余的21個小時而花費256個節點的維護費用。同時，存儲的IO也是同步擴縮容的，不會產生額外的費用或者造成瓶頸。

在離線一體化——同時支持低延遲與高吞吐

典型的并行計算執行流程如上圖中灰色部分所。對于在線分析而言，執行模型需要盡量降低數據在算子間傳輸的開銷，這種場景比較合適的是使用并行Pipeline模型，數據在上游算子產生后，直接Push到下游算子所在的運行節點，無需落盤，直接進行計算，保證查詢的高效性。對于離線分析來說，參與計算的數據規模往往較大，運行的查詢往往非常復雜，如果使用Pipeline模型，可能會由于數據量過大導致內存溢出，同時復雜的查詢往往會由于部分運行節點長尾或者硬件原因，需要局部重試，這時Stage By Stage模型則是最合適的。在這種模式下，資源不需要在一開始就分配完成，一個Stage執行完成，所產生的中間數據會落到磁盤中，下一個Stage再起來之后從磁盤中讀取即可。因此支持在離線一體化的引擎，需要在一套執行引擎中同時兼顧兩種場景，也就是MPP+BSP的混合執行模型。

高效的向量化執行引擎

執行引擎所所需要解決的事情和執行模型不太一樣，其所需要解決的是算子之間傳輸的開銷問題，也就是所謂的數據交互的代價，其主要包括了兩個方面，分別是減少虛函數的調用和減小流程指令的開銷。首先，向量化引擎利用了現代CPU流水線的機制，可以提升指令的并發集。其次，利用SIMD提升了數據并發，充分挖掘它的算力。當整個系統的并發提升完成之后，內存訪問就會更內聚，同時也提升了操作系統Cache命中率。向量化引擎的一個特點是按照列或者一組數據來進行的，而數據庫本身是以行的方式輸出的，那么什么時候將執行中的列轉化成行也是一個比較大的挑戰。在阿里巴巴內部，借助優化器解決了這樣的問題，即什么時間段對哪些數據進行列行轉化。

自適應查詢優化器

自適應查詢優化器架構如圖所示。圖中白色部分可以認為是一個傳統的基于規則的優化器，包括語法檢查、語義解析、查詢改寫和轉換、生成物理計劃；圖中綠色部分是引入了代價模型后，基于統計信息和代價估算，選擇系統認為最優的執行計劃，也是就CBO。其中包含物理計劃的轉換、統計信息推導、還有代價預估。CBO有一個核心要處理的問題，就是由于代價預估不準帶來的計劃回退，需要由深綠色的計劃管理模塊和全鏈路的hint來解決。最右邊的藍色部分是基于歷史的運行信息面向用戶或者DBA的一些建議，如統計信息、索引等。圖中的左側橙色部分就是自適應的一些優化目標，其中包括對執行計劃的優化、工作負載的優化、系統資源的優化等。

接下來展開介紹自適應優化這部分。如圖所示，按照自適應優化按照的生效場合，可以分為運行中和事后基于歷史的兩大類。圖中藍色部分是運行中的一些優化方式，首先是對計劃的調整，比如對物理算子的選擇，最常見的是HashJoin、SortMergeJoin或者IndexJoin。另外在分布式執行計劃中最重要的就是如何進行數據分布，通過對小數據量的進行廣播，避免Join的另外一邊進行數據Reshuffle。還有就是不同任務計算節點的并發數，對小數據量進行分布式計算會帶來額外的資源開銷，針對數據傾斜的分片需要進行重新的Reshuffle。另外一個運行中優化的重要手段就是算子本身具備的自適應，在分布式計劃中一個非常常見的優化手段就是Partial Aggregation，但并不是所有的聚合操作都在局部有一定的收斂性，自適應的局部聚合算子在處理了部分數據后，發現本身沒有收斂性，可以快速放棄做局部聚合。此外，還有一個運行中的優化手段，就是DynamicFilterPushDown了，這個目前在很多計算引擎都具備，就不做過多展開。

除了運行時優化之外，另外一個優化方向就是基于歷史的自學習，主要是對于業務工作負載的分析。對于業務工作負載中的重復性查詢，可能每天都需要運行，并且基本不變，對于這種重復性負載而言可以進行一些計劃的重優化，可以根據系統對于執行后的信息匯總對于執行計劃進行調整。還可以構建分布式的CostModel，由于事前的CostModel可能并不準確，因此可以基于歷史查詢數據來進行校正。此外，也可以對重復的工作負載做進一步的優化，并向用戶提供智能化的診斷手段，最終使得優化器更加聰明，進一步實現自適應、自學習的優化器。

最佳實踐

AnalyticDB：快數據時代下的PB級實時數據倉庫

阿里云AnalyticDB是面向PB級數據規模的數據倉庫，能夠提供毫秒、亞秒級別的查詢體驗，其采用MPP+DAG融合的分布式執行引擎，基于存儲與計算分離的架構，能夠支持千億級別的多表關聯分析，并且全面兼容MySQL和PG的生態，自身具有良好的生態。同時，AnalyticDB在云原生上具備快速的彈性能力，依托于阿里云底層的機制，存儲可以從GB彈到PB，并且可以按需支持最高2000臺級別的彈性能力，并具備備份、恢復、審計等完備的企業級特性。

以ADB的MySQL形態為例進行簡單介紹數據從數據源進入ADB到最終產生價值的整體流程。數據最初可能分布在TB型數據庫，也可能來自于Hadoop等集群產生的日志。而通過阿里云DTS等數據同步工具，或者Flink這種流計算引擎或者Kettle這種專門用于數據同步的工具，將數據寫入到ADB MySQL中，通過數據管理工具對數據進行管理，最終的效果能夠支持多樣化的BI，比如Tableau、QlikView、帆軟，也包括阿里的自研BI工具QuickBI等。

AnalyticDB是阿里云完全自研的系統，因此具備完全的知識產權。AnalyticDB目前獲得TPC官方認可的TPC-DS性能世界第一。其次，AnalyticDB獲得了中國信息通信研究院的官方認證，是參與評測的最大規模的集群。此外，還擁有國內專利46篇以及國際頂會論文9篇。

原文鏈接：https://developer.aliyun.com/article/780747?

版權聲明：本文內容由阿里云實名注冊用戶自發貢獻，版權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任。具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》。如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻刪除涉嫌侵權內容。

總結

以上是生活随笔為你收集整理的DTCC 2020 | 阿里云吉剑南：在线分析进入Fast Data时代的关键技术解读的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。