簡介：如今，對于在線分析技術而言，正在從“Big Data”時代向著“Fast Data”時代邁進，所面對的技術和市場環(huán)境發(fā)生了巨大變化，與此同時也需要面對全新的挑戰(zhàn)。在第十一屆中國數(shù)據(jù)庫技術大會（DTCC2020）上，阿里云數(shù)據(jù)庫高級技術專家吉劍南為大家?guī)砹嗽诰€分析進入Fast Data時代的個關鍵技術解讀。

摘要：如今，對于在線分析技術而言，正在從“Big Data”時代向著“Fast Data”時代邁進，所面對的技術和市場環(huán)境發(fā)生了巨大變化，與此同時也需要面對全新的挑戰(zhàn)。在第十一屆中國數(shù)據(jù)庫技術大會（DTCC2020）上，阿里云數(shù)據(jù)庫高級技術專家吉劍南為大家?guī)砹嗽诰€分析進入Fast Data時代的個關鍵技術解讀。

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

From“Big Data”to“Fast Data”

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

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

市場分析

市場趨勢：數(shù)據(jù)規(guī)模爆炸性增長

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

市場趨勢：數(shù)據(jù)在加速上云

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

市場趨勢：數(shù)據(jù)業(yè)務實時化占比大幅提高

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

技術發(fā)展——OLAP技術演進

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

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

主要的挑戰(zhàn)包括四個方面：

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

典型的“Fast Data”架構

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

“Fast Data”關鍵技術

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

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

計算存儲分離

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

冷熱混合存儲

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

行列混存+多維索引

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

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

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

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

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

彈性模式-分時彈性

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

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

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

高效的向量化執(zhí)行引擎

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

自適應查詢優(yōu)化器

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

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

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

最佳實踐

AnalyticDB：快數(shù)據(jù)時代下的PB級實時數(shù)據(jù)倉庫

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

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

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

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

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

總結

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

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