ClickHouse作為目前業(yè)內(nèi)主流的列式存儲數(shù)據(jù)庫(DBMS)之一，擁有著同類型DBMS難以企及的查詢速度。作為該領(lǐng)域中的后起之秀，ClickHouse已憑借其性能優(yōu)勢引領(lǐng)了業(yè)內(nèi)新一輪分析型數(shù)據(jù)庫的熱潮。但隨著企業(yè)業(yè)務(wù)數(shù)據(jù)量的不斷擴大，在復(fù)雜query場景下，ClickHouse容易存在查詢異常問題，影響業(yè)務(wù)正常推進。

字節(jié)跳動作為國內(nèi)最大規(guī)模的ClickHouse使用者，在對ClickHouse的應(yīng)用與優(yōu)化過程中積累了大量技術(shù)經(jīng)驗。在近日的【T·Talk】系列技術(shù)分享活動的第11期中，我們特別邀請到了字節(jié)跳動數(shù)據(jù)平臺資深研發(fā)工程師董一峰老師為廣大聽眾解析ClickHouse的復(fù)雜查詢問題，董一峰老師也在直播過程中首次公開分享了字節(jié)跳動解決ClickHouse復(fù)雜查詢問題的優(yōu)化思路與技術(shù)細(xì)節(jié)。【T·Talk】將本次的核心內(nèi)容進行了整理，希望能給大家?guī)硪恍﹩l(fā)：

?

項目背景 

ClickHouse的執(zhí)行模式與Druid、ES等大數(shù)據(jù)引擎類似，其基本的查詢模式可分為兩個階段。第一階段，Coordinator在收到查詢后，將請求發(fā)送給對應(yīng)的Worker節(jié)點。第二階段，Worker節(jié)點完成計算，Coordinator在收到各Worker節(jié)點的數(shù)據(jù)后進行匯聚和處理，并將處理后的結(jié)果返回。

兩階段的執(zhí)行模式能夠較為高效地支持目前許多常見的業(yè)務(wù)場景，例如各類大寬表單的查詢，這也是ClickHouse最擅長的場景。ClickHouse的優(yōu)點是簡單、高效，通常來說，簡單就意味著高效。但隨著企業(yè)業(yè)務(wù)的持續(xù)發(fā)展，愈加復(fù)雜的業(yè)務(wù)場景對ClickHouse提出了以下三類挑戰(zhàn)。

第一類，當(dāng)一階段返回的數(shù)據(jù)較多，且二階段計算較為復(fù)雜時，Coordinator會承受較大壓力，容易成為Query的瓶頸。例如一些重計算的Agg算子，如Count Distinct，若采用哈希表的方式進行去重，第二階段需在Coordinator單機上去合并各個Worker的哈希表。這個計算量會很重且無法并行。

第二類，由于目前ClickHouse模式并不支持Shuffle，因此對于Join而言，右表必須為全量數(shù)據(jù)。無論是普通Join還是Global Join，當(dāng)右表的數(shù)據(jù)量較大時，若將數(shù)據(jù)都放到內(nèi)存中，會比較容易OOM。若將數(shù)據(jù)spill到磁盤，雖然可以解決內(nèi)存問題，但由于有磁盤 IO 和數(shù)據(jù)序列化、反序列化的代價，因此查詢的性能會受到影響。特別是當(dāng)Join采用Hash Join時，如果右表是一張大表，構(gòu)建也會比較慢。針對構(gòu)建問題，近期社區(qū)也進行了一些右表并行構(gòu)建的優(yōu)化，數(shù)據(jù)按照J(rèn)oin key進行Split來并行地構(gòu)建多個Hash Table，但額外的代價是左右表都需要增加一次Split操作。

第三類，則是關(guān)于復(fù)雜查詢（如多表 Join、嵌套多個子查詢、window function 等），ClickHouse對這類需求場景的支持并不是特別友好，由于ClickHouse并不能通過Shuffle來分散數(shù)據(jù)增加執(zhí)行并行度，并且其生成的Pipeline在一些case下并不能充分并行。因此在某些場景下，難以發(fā)揮集群的全部資源。

隨著企業(yè)業(yè)務(wù)復(fù)雜度的不斷提升，復(fù)雜查詢，特別是有多輪的分布式Join，且有很多agg的計算的需求會越來越強烈。在這種情況下，業(yè)務(wù)并不希望所有的Query都按照ClickHouse擅長的模式進行，即通過上游數(shù)據(jù) ETL 來產(chǎn)生大寬表。這樣做對ETL的成本較大，并且可能會有一些數(shù)據(jù)冗余。

企業(yè)的集群資源是有限的，但整體的數(shù)據(jù)量會持續(xù)增長，因此在這種情況下，我們希望能夠充分地去利用機器的資源，來應(yīng)對這種越來越復(fù)雜的業(yè)務(wù)場景和SQL。所以我們的目標(biāo)是基于ClickHouse能夠高效支持復(fù)雜查詢。

?

技術(shù)方案 

對于ClickHouse復(fù)雜查詢的實現(xiàn)，我們采用了分Stage的執(zhí)行方式，來替換掉目前ClickHouse的兩階段執(zhí)行方式。類似于其他的分布式數(shù)據(jù)庫引擎，例如Presto等，會將一個復(fù)雜的Query按數(shù)據(jù)交換情況切分成多個 Stage，各Stage之間則通過Exchange完成數(shù)據(jù)交換。Stage之間的數(shù)據(jù)交換主要有以下三種形式。

• 按照單個或者多個key進行Shuffle
• 將單個或者多個節(jié)點的數(shù)據(jù)匯聚到一個節(jié)點上，稱為Gather
• 將同一份數(shù)據(jù)復(fù)制到多個節(jié)點上，稱為Broadcast或廣播

對于單個Stage執(zhí)行，繼續(xù)復(fù)用ClickHouse目前底層的執(zhí)行方式。開發(fā)上按照不同功能切分不同模塊。各個模塊預(yù)定接口，減少彼此的依賴與耦合。即使模塊發(fā)生變動或內(nèi)部邏輯調(diào)整，也不會影響其他模塊。其次，對模塊采用插件架構(gòu)，允許模塊按照靈活配置支持不同的策略。這樣便能夠根據(jù)不同業(yè)務(wù)場景實現(xiàn)不同的策略。

首先，當(dāng)Coordinator接受復(fù)雜的查詢以后，它會在當(dāng)前的語法樹的基礎(chǔ)上，根據(jù)節(jié)點類型和數(shù)據(jù)分布情況，插入Exchange節(jié)點，并生成一個分布式Plan。其次，Coordinator節(jié)點會根據(jù)ExchangeNode類型切分Plan，并生成每個Stage執(zhí)行計劃片段。

接著，Coordinator節(jié)點會調(diào)用SegmentScheduler調(diào)度器，將各Stage的PlanSegment發(fā)送給Worker節(jié)點。當(dāng)Worker接收到PlanSegment后，InterpreterPlanSegment會完成數(shù)據(jù)的讀取和執(zhí)行，通過ExchangeManager完成數(shù)據(jù)的交互。最后，Coordinator從最后一輪Stage所對應(yīng)的ExchangeManager中去讀取數(shù)據(jù)，并返回給Client。

查詢片段調(diào)度器SegmentScheduler負(fù)責(zé)調(diào)度查詢不同的PlanSegment，根據(jù)上下游依賴關(guān)系和數(shù)據(jù)分布，以及Stage并行度和worker分布和狀態(tài)信息，按照一定的調(diào)度策略，將PlanSemgent發(fā)給不同的 Worker 節(jié)點。

目前而言，我們在進行計劃下發(fā)和調(diào)度時，主要實現(xiàn)了兩種策略。

第一種是依賴調(diào)度，根據(jù)Stage依賴關(guān)系定義拓?fù)浣Y(jié)構(gòu)，產(chǎn)生DAG圖，并根據(jù)DAG圖調(diào)度Stage。依賴調(diào)度要等到依賴Stage啟動以后，才會調(diào)度對應(yīng)的Stage。例如兩表Join，會先調(diào)度左右表讀取Stage，之后再調(diào)度Join這個Stage，因為Join的Stage依賴于左右表的Stage。

第二種是AllAtOnce策略，先計算每個Stage的相關(guān)信息，后一次性調(diào)度所有Stage。

相比而言，這兩種策略是在容錯、資源使用和延時上去做取舍。第一種策略依賴調(diào)度，可以實現(xiàn)更好的容錯。由于ClickHouse數(shù)據(jù)可以有多個副本，讀數(shù)據(jù)時，如部分節(jié)點連接失敗，可以嘗試它的副本節(jié)點。對后續(xù)依賴的節(jié)點的Stage來說，并不需要感知到前面 Stage 的執(zhí)行情況。非Source Stage，本身沒有對數(shù)據(jù)的依賴，所以容錯能力會更強，只要保證Stage并行度的節(jié)點存活即可。甚至極端情況下，如需保證Query正常執(zhí)行，也可以降低Stage的并行度。但調(diào)度存在依賴關(guān)系，并不能完全并行，會增加調(diào)度的時長。Stage較多的情況下，調(diào)度延時可能會占據(jù)SQL整體不小的比例。針對上述問題的可做如下優(yōu)化：對于一些沒有依賴關(guān)系的，盡可能支持并行。例如同一個Stage的不同節(jié)點，可以并行。沒有依賴關(guān)系的Stage，也可以并行。

AllAtOnce策略，通過并行可以極大降低調(diào)度延時。為防止出現(xiàn)大量網(wǎng)絡(luò)IO線程，可以通過異步化手段控制線程數(shù)目。AllAtOnce策略的缺點是容錯性沒有依賴調(diào)度好，每一個Stage的Worker在調(diào)度前就已經(jīng)確定了，調(diào)度過程中有一個Worker出現(xiàn)連接異常，則整個Query都會失敗。另一類情況，Stage在上游數(shù)據(jù)還沒有ready，就被調(diào)度起來了，則需要較長時間等數(shù)據(jù)。例如Final的agg Stage，要等Partial agg完成以后才能夠拿到對應(yīng)的數(shù)據(jù)。雖然我們也對此進行了一些優(yōu)化，并不會長時間空跑，浪費CPU資源。但是其實也消耗了一部分資源，例如需要去創(chuàng)建這些執(zhí)行的線程。

ClickHouse的查詢節(jié)點執(zhí)行主要是以SQL形式在節(jié)點間互相交互。在切分Stage后，我們需要支持能夠執(zhí)行一個單獨的PlanSegment的執(zhí)行計劃。因此，InterpreterPlanSegment主要的作用就是接受一個序列化后的PlanSegment，能夠在Worker節(jié)點上去運行整個PlanSegment的邏輯。此外，我們也進行了功能和性能上的增強，例如支持一個Stage處理多個Join，這樣便可以減少Stage的數(shù)目和一些不必要的傳輸，用一個Stage就可以完成整個Join的過程。InterpreterPlanSegment的執(zhí)行會上報對應(yīng)的狀態(tài)信息，如出現(xiàn)執(zhí)行異常，會將異常信息報告給查詢片段調(diào)度器，調(diào)度器會取消Query其他的Stage的Worker執(zhí)行。

ExchangeManager是PlanSegment數(shù)據(jù)交換的媒介，能平衡數(shù)據(jù)上下游處理的能力。整體而言，我們的設(shè)計采用Push與隊列的方式，當(dāng)上游的數(shù)據(jù)ready時，主動推送給下游，并在這個基礎(chǔ)上支持了反壓的能力。

在整個流程中，上下游都會通過隊列來優(yōu)化發(fā)送和讀取，上游與下游會有一個自己的隊列。當(dāng)隊列飽和的時候，會通過類似反壓的機制來控制上游這個執(zhí)行速度，若上游計算快，下游處理能力比較慢，出現(xiàn)下游處理不過來的情況，則會通過反壓的方式來控制上游執(zhí)行的速度。

由于采用push和隊列，因此要考慮一個相對比較特殊的場景，在某些case的情況下，下游的Stage并不需要讀取全部的上游的數(shù)據(jù)。例如Limit100，下游只需讀取100條數(shù)據(jù)，而上游可能會產(chǎn)生非常大規(guī)模的數(shù)據(jù)。因此在這種情況下，當(dāng)下游的Stage讀取到足夠的數(shù)據(jù)后，它需要能夠主動取消上游Stage的執(zhí)行，并且清空隊列。

ExchangeManager考慮的優(yōu)化點較多，例如細(xì)粒度的內(nèi)存控制，能夠按照實例、Query、Segment等多個層次進行內(nèi)存控制，避免OOM。更長期的考慮是在一些對延遲要求不高、數(shù)據(jù)量大的場景。第一，通過將數(shù)據(jù) Spill 到磁盤，降低內(nèi)存的使用。

第二，為了提升傳輸效率，小數(shù)據(jù)要做Merge，大數(shù)據(jù)要做Split。同時，在網(wǎng)絡(luò)傳輸和處理某些場景的時候，需要做一種有序性的保證。例如在Sort的場景，Partial Sort和Merge Sort的網(wǎng)絡(luò)傳輸過程必須要保證是有序的，傳輸數(shù)據(jù)不能出現(xiàn)亂序的情況，否則進行Merge Sort時數(shù)據(jù)就會出問題，并影響最終結(jié)果。

第三，連接的復(fù)用和網(wǎng)絡(luò)的優(yōu)化，包括上下游在同一個節(jié)點，盡可能走內(nèi)存交換，而不走網(wǎng)絡(luò)。這樣可以減少網(wǎng)絡(luò)開銷以及數(shù)據(jù)的序列化和反序列化的代價。此外，ClickHouse在計算上做了非常充足的優(yōu)化，因此其在某些場景中，內(nèi)存帶寬會成為瓶頸，在ExchangeManager的一些場景中，可以用一些零拷貝和其他優(yōu)化，盡量減少內(nèi)存的拷貝。

第四，異常處理和監(jiān)控。相比于單機，分布式情況下異常情況會更加復(fù)雜，且更加難以感知。通過重試能夠避免一些節(jié)點短時性的高負(fù)載或者異常對查詢的影響。做好監(jiān)控，在出問題的時候，能快速感知，并進行排查，也能夠針對性地去做優(yōu)化。

優(yōu)化與診斷 

首先是Join的多種實現(xiàn)和優(yōu)化。根據(jù)數(shù)據(jù)的規(guī)模和分布，可以根據(jù)不同的場景去選擇合適的Join的實現(xiàn)方式：

• Shuffle Join，是目前使用方式最多，也是最常見的。
• Broadcast Join，大表Join小表場景，將右表廣播到左表的所有Worker節(jié)點上面，這樣可以避免左表大表的數(shù)據(jù)傳輸。
• Colocate Join，如果左右表都已按照J(rèn)oin key分布，并且它們是相通的分布的話，其實不需要去做數(shù)據(jù)的exchange，可以將數(shù)據(jù)的傳輸減到最小。

網(wǎng)絡(luò)連接的優(yōu)化，核心本質(zhì)是減少連接的建立和使用，特別是在數(shù)據(jù)需要Shuffle時，下一輪Stage中的每一個節(jié)點都要從上游的Stage中的每個節(jié)點去拉取數(shù)據(jù)。若集群整體的節(jié)點數(shù)較多，且存在很多較復(fù)雜的Query，就會建立非常多的連接。

目前在字節(jié)內(nèi)部，ClickHouse集群的規(guī)模非常大，在當(dāng)前 ClickHouse 二階段執(zhí)行的高并發(fā)情況下，單機最大可能會建立幾萬個連接。因此必須要進行網(wǎng)絡(luò)連接的優(yōu)化，特別是支持連接的復(fù)用，每個連接上可以跑多個Stage查詢。通過盡可能去復(fù)用連接，在不同的節(jié)點之間，能夠建立固定數(shù)目的連接，不同的Query、Stage都會復(fù)用這些連接，連接數(shù)并不會隨著Query和Stage的規(guī)模的增長而增長。

網(wǎng)絡(luò)傳輸優(yōu)化，在數(shù)據(jù)中心內(nèi)，遠(yuǎn)程的直接的內(nèi)存訪問，通常指RDMA，是一種能夠超過遠(yuǎn)程主機操作系統(tǒng)的內(nèi)核，去訪問內(nèi)存里的數(shù)據(jù)的技術(shù)。由于這種技術(shù)不需要經(jīng)過操作系統(tǒng)，所以不僅節(jié)省了大量的CPU資源，同樣也提升了系統(tǒng)吞吐量，降低了系統(tǒng)的網(wǎng)絡(luò)通信延遲，尤其適合大規(guī)模并行的計算機集群。由于 ClickHouse 在計算層面做了很多優(yōu)化，而網(wǎng)絡(luò)帶寬相比于內(nèi)存帶寬要小不少，在一些數(shù)據(jù)量傳輸特別大的場景，網(wǎng)絡(luò)傳輸會成為一定的瓶頸。為了提升網(wǎng)絡(luò)傳輸?shù)男屎吞嵘龜?shù)據(jù) exchange 的吞吐，一方面可以引入壓縮來降低傳輸數(shù)據(jù)量，另一方面可以引入 RDMA 來減少一定的開銷。經(jīng)過測試，在一些數(shù)據(jù)傳輸量大的場景，有不小的收益。

利用Runtime Filter的優(yōu)化在不少數(shù)據(jù)庫也有使用。Join的算子通常是OLAP引擎里最耗時的算子，優(yōu)化Join算子有兩種思路。一種思路是可以提升Join算子的性能。比如對于 HashJoin，可以優(yōu)化 HashTable 實現(xiàn)，也可以實現(xiàn)更好的哈希算法，包括做一些更好的并行的方式。

另一種思路是，如果本身算子耗時比較重，可以減少參與算子計算的數(shù)據(jù)。Runtime Filter是在一些場景下特別是事實表Join多張維度表的星型模型場景有比較好的效果。在此類場景下，通常事實表的規(guī)模會非常大，而大部分的過濾條件都是在維度表上面。

Runtime Filter的作用，是通過在Join的Probe端，提前過濾掉并不會命中Join條件的輸入數(shù)據(jù)，從而大幅減少Join中的數(shù)據(jù)傳輸和計算。通過這種方式，能夠減少整體的執(zhí)行時間。因此我們在復(fù)雜查詢上也支持了Runtime Filter，目前主要支持Min Max和Bloom Filter。

如果 runtime filter 的列（join column）構(gòu)建了索引（主鍵、skip index…），是需要重新生成 pipeline 的。因為命中索引后，可能會減少數(shù)據(jù)的讀取，pipeline 并行度和對應(yīng)數(shù)據(jù)的處理 range 都可能發(fā)生變化。如果 runtime filter 的列跟索引無關(guān)，可以在計劃生成的時候預(yù)先帶上過濾條件，一開始為空，只是占位，runtime filter 下發(fā)的時候把占位信息改成真正的過濾條件即可。這樣即使 runtime filter 下發(fā)超時了，查詢片段已經(jīng)開始執(zhí)行，只要查詢片段沒有執(zhí)行完，之后的數(shù)據(jù)仍然可以進行過濾。

但需要注意的是，Runtime Filter是一種特殊場景下的優(yōu)化，針對場景是右表數(shù)據(jù)量不大，并且構(gòu)建的Runtime Filter對左表有比較好的過濾效果。若右表數(shù)據(jù)量較大，構(gòu)建的Runtime Filter的時間比較久，或?qū)ψ蟊淼臄?shù)據(jù)過濾沒有效果。Runtime Filter反而會增加查詢的耗時和計算的開銷。因此要根據(jù)數(shù)據(jù)的特征和規(guī)模來決定是否開啟優(yōu)化。

性能診斷和分析對復(fù)雜查詢很關(guān)鍵，由于引入了復(fù)雜查詢的多Stage模型，SQL執(zhí)行的模式會變得復(fù)雜。對此的優(yōu)化首先是盡可能完善各類Metrics，包括Query執(zhí)行時間、不同Stage執(zhí)行時間、起始時間、結(jié)束時間、處理的IO數(shù)據(jù)量、算子處理的數(shù)據(jù)、執(zhí)行情況，以及各類的算子Metrics和一些Profile Events（例如Runtime Filter會有構(gòu)建時間、過濾數(shù)據(jù)量等Metrics）。

其次，我們記錄了反壓信息與上下游的隊列長度，以此推斷Stage的執(zhí)行情況和瓶頸。

通?？梢杂腥缦屡袛啵?/span>

• 輸入和輸出隊列數(shù)目同為低或同為高分別表明當(dāng)前 stage 處理正?；蛱幱诒幌掠畏磯海藭r可以通過反壓信息來進一步判斷
• 當(dāng)輸入和輸出隊列數(shù)目不一樣，這可能是出于反壓傳導(dǎo)的中間狀態(tài)或者該 stage 就是反壓的根源
• 如果一個 stage 的輸出隊列數(shù)目很多，且經(jīng)常被反壓，通常是被下游 stage 所影響，所以可以排除它本身是反壓根源的可能性，更多關(guān)注它的下游
• 如果一個 stage 的輸出隊列數(shù)目很少，但其輸入隊列的數(shù)目很高，則表明它有可能是反壓的根源。優(yōu)化目標(biāo)是提升這個 stage 的處理能力

總的來說，SQL的場景包羅萬象，非常復(fù)雜的場景有時還是需要對引擎有一定了解的同學(xué)去診斷和分析，給出優(yōu)化建議。字節(jié)目前也在不斷完善這些經(jīng)驗，希望能夠通過不斷完善Metrics和分析的路徑，持續(xù)減輕Oncall的負(fù)擔(dān)，在某些場景下能夠更加準(zhǔn)確地給出優(yōu)化建議。

?

效果與展望 

根據(jù)上述所提，目前執(zhí)行模型存在三個缺點，我們進行了復(fù)雜查詢的優(yōu)化，因此需要驗證這種新的模式是否能夠解決發(fā)現(xiàn)的問題，測試場景如下：

• 第二階段計算較復(fù)雜，且第一階段數(shù)據(jù)較多
• Hash Join右表是大表
• 多表Join，模擬復(fù)雜Query
• 以SSB 1T數(shù)據(jù)作為數(shù)據(jù)集，環(huán)境則是構(gòu)建了8個節(jié)點的集群

Case1——二階段計算復(fù)雜。我們看到有一個比較重的計算算子UniqExact，就是count distinct的計算方式，通過Hash表做去重。count distinct默認(rèn)采用這種算法，當(dāng)我們使用復(fù)雜查詢后，Query的執(zhí)行時間從8.5秒減少到2.198秒。第二階段 agg uniqExact 算子的合并原本由coordinator單點合并，現(xiàn)在通過按照group by key shuffle后可以由多個節(jié)點并行完成。因此通過shuffle減輕了coordinator的 merge agg 壓力。

Case2——右表為大表。由于 ClickHouse 對多表的優(yōu)化做的還不是很到位。這里采用子查詢來下推過濾的條件。在這個case中，Lineorder是一張大表，采用復(fù)雜查詢的模式以后，Query執(zhí)行時間從17秒優(yōu)化到了1.7秒。由于Lineorder是一張大表，通過Shuffle可以將數(shù)據(jù)按照J(rèn)oin key Shuffle到各Worker節(jié)點上，這樣就減少了右表構(gòu)建的壓力。

Case3——多表Join。開啟復(fù)雜查詢后，Query的執(zhí)行時間從8.58秒優(yōu)化到4.464秒，所有的右表都可以同時開始數(shù)據(jù)的處理和構(gòu)建。為了和現(xiàn)有模式做對比，復(fù)雜查詢這里并沒有開啟 runtime filter，開啟 runtime filter 后效果會更好。

事實上，優(yōu)化器對復(fù)雜查詢的性能提升也非常大，通過一些RBO的規(guī)則，例如常見的謂詞下推、相關(guān)子查詢的處理等，可以極大提升SQL的執(zhí)行效率。在復(fù)雜查詢的模式下，由于有優(yōu)化器的存在，用戶甚至不需要寫得非常復(fù)雜，優(yōu)化器自動去完成這些下推和RBO規(guī)則優(yōu)化。

此外，選擇用哪一種Join的實現(xiàn)，也會對Join的性能影響較大。若能夠滿足Join Key分布，使用Colocate Join可以減少左右表Shuffle的傳輸代價。在多表Join的情況下，Join的順序和Join的實現(xiàn)方式對執(zhí)行的時長影響，會比兩表Join更大。借助這種數(shù)據(jù)的統(tǒng)計信息，通過一些CBO的優(yōu)化，可以得到一個比較好的執(zhí)行模式。

有了優(yōu)化器，業(yè)務(wù)同學(xué)可以按照業(yè)務(wù)邏輯來寫任何的 SQL，引擎自動計算出相對最優(yōu)的 SQL 計劃并執(zhí)行，加速查詢的執(zhí)行。

總結(jié)一下，ClickHouse目前的執(zhí)行模式在很多單表的場景下表現(xiàn)非常優(yōu)異，我們主要針對復(fù)雜場景做優(yōu)化，通過實現(xiàn)多Stage的模式，實現(xiàn)了Stage之間的數(shù)據(jù)的傳輸，從工程實踐上做了較多嘗試和優(yōu)化，去提升執(zhí)行和網(wǎng)絡(luò)傳輸?shù)男阅?。并希望通過完善Metrics和智能診斷來降低SQL分析和調(diào)優(yōu)的門檻。目前已經(jīng)實現(xiàn)了第一步，未來字節(jié)仍有很多努力的方向。

首先，是要繼續(xù)去提升執(zhí)行和Exchange的性能。這里不談?wù)撘鎴?zhí)行通用的優(yōu)化，比如更好的索引或者算子的優(yōu)化，主要是跟復(fù)雜查詢模式有關(guān)。舉一個例子，比如 Stage 復(fù)用，在 SQL 出現(xiàn)子查詢結(jié)果被反復(fù)使用的場景，比如一些多表 join 和 CTE 場景可能有幫助。通過 Stage 復(fù)用可以減少相同數(shù)據(jù)的多次讀取。Stage 復(fù)用我們之前就已經(jīng)支持，但是用的場景比較少，未來準(zhǔn)備更靈活和通用。

其次，Metrics和智能診斷加強。SQL的靈活度很高，因此一些復(fù)雜查詢?nèi)绻麤]有Metrics其實幾乎很難去做診斷和調(diào)優(yōu)。以上都是字節(jié)跳動數(shù)據(jù)平臺在未來會長期的持續(xù)去發(fā)力的方向。

?

嘉賓介紹

董一峰，字節(jié)跳動數(shù)據(jù)平臺資深研發(fā)工程師。負(fù)責(zé)字節(jié)跳動企業(yè)級實驗平臺團隊，致力于打造業(yè)界最先進好用的實驗平臺，把A/B測試變成驅(qū)動業(yè)務(wù)增長的新基建。從0到1參與搭建了字節(jié)內(nèi)實驗中臺Libra，服務(wù)于抖音、Tiktok、今日頭條等500多個業(yè)務(wù)線；對外發(fā)布火山引擎A/B測試(aka DataTester)、BytePlus Optimize等產(chǎn)品。