摘要：如今，對于線上分析技術而言，正在從“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篇。
點選這裡下載下傳本場演講PPT相關閱讀
DTCC 2020 | 阿裡雲李飛飛：雲原生分布式資料庫與資料倉庫系統點亮資料上雲之路
https://developer.aliyun.com/article/781040【内含幹貨PPT下載下傳】DTCC 2020 | 阿裡雲葉正盛：資料庫2025
https://developer.aliyun.com/article/780725【内含幹貨PPT下載下傳】DTCC 2020 | 阿裡雲趙殿奎：PolarDB的Oracle平滑遷移之路
https://developer.aliyun.com/article/780749【内含幹貨PPT下載下傳】DTCC 2020 | 阿裡雲朱潔：NoSQL最新技術發展趨勢
https://developer.aliyun.com/article/780746【内含幹貨PPT下載下傳】DTCC 2020 | 阿裡雲王濤：阿裡巴巴電商資料庫上雲實踐
https://developer.aliyun.com/article/781001【内含幹貨PPT下載下傳】DTCC 2020 | 阿裡雲張鑫：阿裡雲雲原生異地多活解決方案
https://developer.aliyun.com/article/781031DTCC 2020 | 阿裡雲梁高中：DAS之基于Workload的全局自動優化實踐
https://developer.aliyun.com/article/781036【内含幹貨PPT下載下傳】DTCC 2020 | 阿裡雲程實：雲原生時代的資料庫管理
https://developer.aliyun.com/article/780992