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

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

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

From“Big Data”to“Fast Data”

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

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

市場分析

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

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

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

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

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

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

技術(shù)發(fā)展——OLAP技術(shù)演進(jìn)

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

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

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

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

典型的“Fast Data”架構(gòu)

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

“Fast Data”關(guān)鍵技術(shù)

結(jié)合典型的Fast Data架構(gòu)來介紹涉及到的關(guān)鍵技術(shù)：

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

計(jì)算存儲(chǔ)分離

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

冷熱混合存儲(chǔ)

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

行列混存+多維索引

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

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

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

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

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

彈性模式-分時(shí)彈性

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

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

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

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

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

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

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

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

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

最佳實(shí)踐

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

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

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

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

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

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

總結(jié)

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

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