OLAP 實(shí)踐 | 京東 OLAP 億級(jí)查詢高可用實(shí)踐

OLAP（On-Line Analytical Processing）是聯(lián)機(jī)分析處理，它主要用于支持企業(yè)決策和經(jīng)營(yíng)管理，是許多報(bào)表、商業(yè)智能和分析系統(tǒng)的底層支撐組件，支持從海量數(shù)據(jù)中快速獲取數(shù)據(jù)指標(biāo)。

京東OLAP的發(fā)展歷經(jīng)Druid、Kylin、Doris和ClickHouse，廣泛服務(wù)于京東各個(gè)子集團(tuán)和各類場(chǎng)景中，經(jīng)歷了數(shù)次大促的考驗(yàn)無(wú)事故，本文會(huì)重點(diǎn)以ClickHouse為主，介紹京東OLAP高可用實(shí)踐情況，如業(yè)務(wù)場(chǎng)景和選型的考量，運(yùn)維部署方案，高可用架構(gòu)以及在使用過(guò)程中遇到的問(wèn)題和未來(lái)改進(jìn)計(jì)劃。

京東數(shù)據(jù)分析的場(chǎng)景非常多，零售集團(tuán)主營(yíng)業(yè)務(wù)是在線電商業(yè)務(wù)，既有電商交易數(shù)據(jù)又有用戶流量數(shù)據(jù)，同時(shí)也有物流、健康、京喜等線下業(yè)務(wù)線。

1）交易數(shù)據(jù)的難點(diǎn)，就是業(yè)務(wù)復(fù)雜，需要關(guān)聯(lián)多張表，SQL中邏輯多；另外就是數(shù)據(jù)會(huì)更新，比如交易狀態(tài)和金額的變化，組織架構(gòu)的變化會(huì)導(dǎo)致數(shù)據(jù)需要更新或刪除重新導(dǎo)入。

2）流量數(shù)據(jù)有幾個(gè)特點(diǎn)，一是只追加不修改；二是量大，因?yàn)榘脩舻狞c(diǎn)擊和瀏覽等各類行為數(shù)據(jù)，以及由此衍生的各種指標(biāo)，比如UV計(jì)算；三是數(shù)據(jù)字段會(huì)經(jīng)常變化。

3）實(shí)時(shí)大屏是618大促時(shí)常見(jiàn)一種數(shù)據(jù)展現(xiàn)形式，這種場(chǎng)景都是實(shí)時(shí)數(shù)據(jù)，一塊大屏展現(xiàn)數(shù)據(jù)指標(biāo)比較多并發(fā)大，涉及訂單數(shù)據(jù)還需要更新，比如北京消費(fèi)卷就有各種狀態(tài)，可用性要求也非常高。實(shí)時(shí)寫(xiě)入、數(shù)據(jù)更新、高并發(fā)以及海量數(shù)據(jù)，這些條件綜合在一起，對(duì)OLAP來(lái)說(shuō)是一個(gè)不小的挑戰(zhàn)。

在大數(shù)據(jù)架構(gòu)中，OLAP的上游是Spark/Flink等計(jì)算引擎，下游對(duì)接報(bào)表、分析系統(tǒng)或策略系統(tǒng)。通過(guò)實(shí)施OLAP組件，可以加快需求響應(yīng)速度，簡(jiǎn)化計(jì)算過(guò)程降低IDC成本。京東大數(shù)據(jù)發(fā)展較早，大數(shù)據(jù)體系也比較成熟，陸續(xù)引入了很多OLAP組件，主流OLAP技術(shù)都正式使用過(guò)，目前形成了ClickHouse為主Doris為輔的實(shí)施策略。

Druid是實(shí)時(shí)預(yù)聚合的技術(shù)，用于計(jì)算廣告領(lǐng)域比較多，面向廣告主或內(nèi)部產(chǎn)研的廣告數(shù)據(jù)指標(biāo)的計(jì)算；Kylin的技術(shù)特點(diǎn)是預(yù)聚合，Cube計(jì)算方式能夠加快計(jì)算速度，內(nèi)置存儲(chǔ)邏輯，提供友好SQL查詢接口；ElasticSearch本身基于Lucence改進(jìn)，用到搜索引擎的索引技術(shù)，一般用于半結(jié)構(gòu)化的數(shù)據(jù)如日志或文本分析。

如上圖，選擇合適的OLAP組件，需從海量、時(shí)效性、靈活性和適應(yīng)性這幾個(gè)層面來(lái)考慮。

ClickHouse和Doris是分析型數(shù)據(jù)庫(kù)，能夠很好的滿足以上四點(diǎn)，也非常好適應(yīng)絕大部分場(chǎng)景，因而成為京東內(nèi)部主流的OLAP引擎，他們能組成一個(gè)互補(bǔ)的搭配，因?yàn)镃lickHouse性能強(qiáng)悍，擴(kuò)展性好，但使用門(mén)檻和運(yùn)維成本較高，在大數(shù)據(jù)量和極限場(chǎng)景下使用；Doris使用簡(jiǎn)單，運(yùn)維也簡(jiǎn)單，適用于中小數(shù)據(jù)量業(yè)務(wù)場(chǎng)景。

京東業(yè)務(wù)線多，數(shù)據(jù)需求旺盛，我們建立起一套小集群多租戶的模式，部署多個(gè)百臺(tái)左右的集群服務(wù)于大量業(yè)務(wù)；同時(shí)針對(duì)不同場(chǎng)景的特點(diǎn)定制化部署方案，比如存儲(chǔ)量大、并發(fā)大或有大查詢等不同情況。一個(gè)合理的集群規(guī)劃是實(shí)施OLAP成功的關(guān)鍵，如果剛開(kāi)始方案不合適，亦或沒(méi)考慮到運(yùn)維和運(yùn)營(yíng)成本，后面的麻煩事會(huì)接踵而來(lái)，所以我們花一些篇幅來(lái)說(shuō)明這個(gè)問(wèn)題。

如何配置集群和業(yè)務(wù)有多種方式，一個(gè)方案是部署一個(gè)超大的OLAP集群把所有業(yè)務(wù)放在一起，另一個(gè)方案是每個(gè)業(yè)務(wù)都獨(dú)立部署一套集群。前者業(yè)務(wù)響應(yīng)速度快，資源利用率高，但業(yè)務(wù)間互相影響，大集群運(yùn)維難度大；后者完全隔離，但資源無(wú)法調(diào)配，數(shù)量龐大的集群運(yùn)維投入大。因此，我們選擇了分場(chǎng)景隔離和多租戶的模式，能一定程度上兼顧業(yè)務(wù)高可用、資源利用率和運(yùn)維的方便性。

總體來(lái)說(shuō)，就是回答是否實(shí)時(shí)、是否大查詢、是否高并發(fā)等問(wèn)題，如果回答“是”，則需要考慮獨(dú)立一個(gè)集群來(lái)。

多租戶來(lái)服務(wù)眾多業(yè)務(wù)，因?yàn)榧瘓F(tuán)內(nèi)業(yè)務(wù)線眾多，為了保證服務(wù)質(zhì)量，及時(shí)響應(yīng)需求，提升資源利用率，我們提供了共享集群多租戶的運(yùn)營(yíng)方案，在一個(gè)集群中讓數(shù)十個(gè)業(yè)務(wù)一起使用，每個(gè)業(yè)務(wù)分別建立一到多個(gè)賬號(hào)，多個(gè)賬號(hào)可以是不同的團(tuán)隊(duì)、產(chǎn)品或模塊使用，為了避免資源搶占和互相影響，多賬號(hào)通過(guò)配額來(lái)限制，也可以控制不同賬號(hào)權(quán)限比如讀、寫(xiě)和DDL權(quán)限，進(jìn)行分級(jí)管理。我們?cè)贑H中主要通過(guò)查詢量（并發(fā)數(shù)+Query次數(shù)）、查詢大?。▋?nèi)存限制+超時(shí)時(shí)間）來(lái)控制，我們統(tǒng)稱為用戶配額。

1）查詢量（并發(fā)數(shù)和Query次數(shù)）：并發(fā)數(shù)指同時(shí)執(zhí)行的Query數(shù)量，設(shè)置為CPU核數(shù)的1-3倍，具體到每個(gè)賬號(hào)，可以根據(jù)在線人數(shù)峰值來(lái)預(yù)估。Query次數(shù)，在CH的Quota設(shè)置中，計(jì)數(shù)窗口是可以自定義的，為了避免峰值波動(dòng)以及能快速生效，我們定義的是10秒的時(shí)間窗口，10秒內(nèi)的Query數(shù)量不能超過(guò)某個(gè)限制，同時(shí)我們修改了內(nèi)核對(duì)讀和寫(xiě)的Query分別統(tǒng)計(jì)。

2）查詢大小（內(nèi)存限制和超時(shí)時(shí)間）：為了避免執(zhí)行時(shí)間過(guò)長(zhǎng)的查詢對(duì)集群的影響，限制查詢內(nèi)存大小和超時(shí)時(shí)間，單個(gè)查詢內(nèi)存限制為節(jié)點(diǎn)內(nèi)存的1/4-1/2，達(dá)到超時(shí)時(shí)間的查詢將會(huì)被終止。如果出現(xiàn)超過(guò)內(nèi)存或時(shí)間的情況，需要降低查詢范圍以及Group By的數(shù)據(jù)量，另外看是否需要優(yōu)化存儲(chǔ)和SQL來(lái)提升單個(gè)查詢的性能。

通過(guò)多租戶和配額的機(jī)制，可以快速響應(yīng)業(yè)務(wù)側(cè)新申請(qǐng)賬號(hào)或配額變更的需求，同時(shí)也對(duì)不符合最佳實(shí)踐的使用進(jìn)行約束，比如慢查詢或穿透緩存的查詢。同時(shí)這個(gè)方案對(duì)獨(dú)占集群也是有效的，因?yàn)椴煌~號(hào)對(duì)應(yīng)的模塊之間也需要分別來(lái)控制。多租戶方案的另一個(gè)好處在出現(xiàn)問(wèn)題時(shí)，我們可以根據(jù)賬號(hào)來(lái)縮小排查范圍，快速定位問(wèn)題。

通過(guò)上云讓業(yè)務(wù)自主化使用，另一個(gè)支持業(yè)務(wù)方案是上云，通過(guò)K8S來(lái)部署集群，容器化的優(yōu)勢(shì)是標(biāo)準(zhǔn)化和資源隔離，我們通過(guò)標(biāo)準(zhǔn)化的資源搭配供用戶去選擇。我們自研了OLAP管控面，用戶可以通過(guò)管控面申請(qǐng)資源，配置監(jiān)控和報(bào)警以及查看查詢情況。管理員也可以進(jìn)行日常運(yùn)維操作，集群部署、上下線、配額調(diào)整等，當(dāng)集群故障時(shí)也可通過(guò)預(yù)設(shè)方案進(jìn)行自愈。

OLAP中既有存儲(chǔ)又有計(jì)算，是計(jì)算和存儲(chǔ)都密集型，資源選型和搭配合理性尤為重要。

資源類型配比要合理。不同場(chǎng)景資源類型的需求是不一樣的。按照我們的經(jīng)驗(yàn)，計(jì)算量大的業(yè)務(wù)，選擇CPU核數(shù)多主頻高的，比如分組和去重的計(jì)算；數(shù)據(jù)保留時(shí)間長(zhǎng)的業(yè)務(wù)，磁盤(pán)空間則需要大；如果使用字典，數(shù)據(jù)需要加載到內(nèi)存，則需要考慮大一點(diǎn)內(nèi)存。一般來(lái)說(shuō)CPU32核內(nèi)存64-128G磁盤(pán)2-10T。

離線推薦HDD磁盤(pán)。在離線場(chǎng)景中，需要存儲(chǔ)數(shù)年的數(shù)據(jù)，存儲(chǔ)空間占用大，一般采用普通機(jī)械磁盤(pán)，數(shù)據(jù)在外部排序順序?qū)懭?，磁盤(pán)寫(xiě)入速度和IO都能滿足要求。使用HDD磁盤(pán)時(shí)，需要堅(jiān)持小批次大批量的原則，盡量降低小文件對(duì)系統(tǒng)的負(fù)擔(dān)，采用大容量的磁盤(pán)，一個(gè)好處就是可以做一些物化視圖，來(lái)提升查詢性能，以空間換時(shí)間。而實(shí)時(shí)場(chǎng)景，我們一般選擇SSD或NVME，隨機(jī)寫(xiě)入能性能好，可以低延時(shí)高頻寫(xiě)入小文件，能獲得更低的數(shù)據(jù)延時(shí)，更低的IO繁忙率。

優(yōu)先選擇單機(jī)性能高。分組或去重計(jì)算，需要把全部或部分?jǐn)?shù)據(jù)匯聚到少量實(shí)例中，然后在匯聚實(shí)例中計(jì)算，依賴單節(jié)點(diǎn)的計(jì)算性能，集群相同核數(shù)的情況下優(yōu)先選擇CPU核數(shù)多和主頻高的，比如32核的10臺(tái)和64核的5臺(tái)，后者在某些場(chǎng)景下計(jì)算性能更優(yōu)。

分片和副本數(shù)量，需要根據(jù)數(shù)據(jù)規(guī)模和并發(fā)量來(lái)確定。

如何確定分片數(shù)，計(jì)算單副本未壓縮的數(shù)據(jù)量，然后除以單節(jié)點(diǎn)磁盤(pán)容量，除以壓縮率，就是分片數(shù)。另一個(gè)計(jì)算方式是，一個(gè)分片一天寫(xiě)入條數(shù)為5億條，一是兼顧了寫(xiě)入速度二是考慮到每個(gè)分區(qū)下的分片數(shù)據(jù)量不能過(guò)大。

如何確定副本數(shù)，通?？梢园磫胃北?00QPS來(lái)計(jì)算（和查詢復(fù)雜度密切相關(guān)以實(shí)際壓測(cè)為準(zhǔn)），假如有500QPS，則需要5個(gè)副本來(lái)做負(fù)載均衡；另一個(gè)考慮是，數(shù)據(jù)的可靠性，所以我們一般推薦2副本以上，避免機(jī)器故障導(dǎo)致數(shù)據(jù)丟失。

流行的CH部署方是單實(shí)例的，比如5分片2副本，需要10臺(tái)服務(wù)器，每臺(tái)服務(wù)器部署一個(gè)節(jié)點(diǎn)，如果查詢并發(fā)少，CPU和內(nèi)存會(huì)有浪費(fèi)。因此，我們采用多實(shí)例多副本的部署模式，如下圖4臺(tái)服務(wù)器，我們部署了4分片和2副本。

1）支持多實(shí)例：我們支持一臺(tái)物理機(jī)部署1-N個(gè)實(shí)例，每個(gè)實(shí)例對(duì)應(yīng)不同的網(wǎng)絡(luò)端口和磁盤(pán)目錄，單實(shí)例是多實(shí)例的一種特例。

2）支持多副本：通過(guò)配置不同的副本在不同的機(jī)器上，保證了數(shù)據(jù)可靠性，如上圖，S指分片R指副本，相同分片的不同副本間互為主備。同時(shí)多副本也能充分利用多塊磁盤(pán)減輕IO壓力。

從過(guò)往的使用經(jīng)驗(yàn)來(lái)看，OLAP具有一定的高可用性，但是依然有一些情況會(huì)引發(fā)集群不穩(wěn)定，如數(shù)據(jù)或查詢不均衡、硬件故障等，我們一直在架構(gòu)側(cè)努力去彌補(bǔ)這些薄弱環(huán)節(jié)。

硬件故障是無(wú)法避免的，因此如何做到在硬件故障時(shí)使用上無(wú)感知是我們努力的方向。我們部署CH集群是三層結(jié)構(gòu)：域名 + CHProxy + CH節(jié)點(diǎn)，域名轉(zhuǎn)發(fā)請(qǐng)求到CHProxy，再由CHProxy根據(jù)集群節(jié)點(diǎn)狀態(tài)來(lái)轉(zhuǎn)發(fā)。CHProxy的引入是為了讓Query均勻分布在每個(gè)節(jié)點(diǎn)上，自動(dòng)感知集群節(jié)點(diǎn)的狀態(tài)變化，我們對(duì)CHProxy做了一定的改進(jìn)。當(dāng)集群節(jié)點(diǎn)故障時(shí)，分為查詢、寫(xiě)入和DDL操作來(lái)考慮如何規(guī)避其影響。

查詢時(shí)，CHProxy會(huì)轉(zhuǎn)發(fā)到健康節(jié)點(diǎn)，接收查詢的節(jié)點(diǎn)對(duì)副本有Load_balancing策略，執(zhí)行查詢計(jì)劃時(shí)會(huì)把子查詢發(fā)給健康副本，故障節(jié)點(diǎn)不會(huì)收到查詢請(qǐng)求。

寫(xiě)入時(shí)，情況稍微復(fù)雜，如通過(guò)域名來(lái)寫(xiě)分布式表或隨機(jī)寫(xiě)本地表和查詢的機(jī)制類似。如果指定分片寫(xiě)入本地表，可以在QUERY中指定分片序號(hào)，CHProxy會(huì)轉(zhuǎn)發(fā)寫(xiě)入到指定分片的某個(gè)副本上，同樣會(huì)跳過(guò)故障副本節(jié)點(diǎn)。

DDL操作，DDL指元數(shù)據(jù)的修改，在ZooKeeper中有一個(gè)DDL隊(duì)列，如果故障節(jié)點(diǎn)短時(shí)間內(nèi)修復(fù)后又上線了，會(huì)繼續(xù)執(zhí)行隊(duì)列中的DDL操作。如果長(zhǎng)時(shí)間未能修復(fù)，再次上線時(shí)，會(huì)導(dǎo)致該節(jié)點(diǎn)和其他節(jié)點(diǎn)的元數(shù)據(jù)不一致，因此需要手工去修復(fù)。我們開(kāi)發(fā)了元數(shù)據(jù)一致性檢查工具，去檢測(cè)節(jié)點(diǎn)元數(shù)據(jù)、ZooKeeper元數(shù)據(jù)、數(shù)據(jù)之間的一致性。

假如CHProxy故障了，域名服務(wù)有探測(cè)機(jī)制，如果請(qǐng)求超時(shí)或失敗不再轉(zhuǎn)發(fā)請(qǐng)求到故障的CHProxy節(jié)點(diǎn)。

而Doris在這方面要強(qiáng)很多，因?yàn)樗幸粋€(gè)完善的元數(shù)據(jù)管理功能，校驗(yàn)并修復(fù)元數(shù)據(jù)的一致性，有副本的校驗(yàn)和均衡機(jī)制，自動(dòng)修復(fù)副本故障，所以，節(jié)點(diǎn)故障后下線以及修復(fù)后上線，業(yè)務(wù)側(cè)幾乎感知不到。

如果是集群?jiǎn)喂?jié)點(diǎn)故障，可以快速下線該節(jié)點(diǎn)，對(duì)業(yè)務(wù)影響較??；如果集群大面積故障，比如機(jī)房機(jī)架故障，或需要對(duì)集群進(jìn)行停機(jī)維護(hù)，對(duì)于特別重要的報(bào)表，我們有主備雙流的機(jī)房，能夠快速切換到備用集群中。

雙機(jī)房之間的數(shù)據(jù)同步，目前是通過(guò)外部雙寫(xiě)雙集群的方式來(lái)處理，寫(xiě)入程序需要檢查雙寫(xiě)的一致性。這種方式會(huì)增加外部寫(xiě)入的復(fù)雜度，同時(shí)帶來(lái)不必要的資源消耗，有較大的優(yōu)化空間。

我們有一套較為完備的故障發(fā)現(xiàn)和處理機(jī)制，比如定期的硬件檢測(cè)、監(jiān)控和報(bào)警系統(tǒng)和定期的冒煙測(cè)試。冒煙測(cè)試指對(duì)集群進(jìn)行最常見(jiàn)的常規(guī)操作，比如建表、寫(xiě)入數(shù)據(jù)和刪除表等操作，是集群健康度的最后一道防線。

在發(fā)現(xiàn)硬件故障時(shí)，能及時(shí)下線故障節(jié)點(diǎn)，待問(wèn)題修復(fù)之后再重新上線，或者用備用機(jī)替換故障機(jī)；在程序崩潰時(shí)，能夠自動(dòng)拉起等，這些操作都在我們管控面中進(jìn)行，可以做到分鐘級(jí)處理。而針對(duì)這些故障，每次大促前都會(huì)進(jìn)行演練以提升操作熟練度。在上層應(yīng)用中，也有響應(yīng)的緩存、限流和分流功能。

我們?cè)贑lickHouse的日常使用中，積累了較多的經(jīng)驗(yàn)也遇到不少問(wèn)題，部分問(wèn)題通過(guò)某些手段進(jìn)行了規(guī)避和優(yōu)化，如上文的集群規(guī)劃和高可用架構(gòu)，但是依然存在一些從架構(gòu)層面比較難以解決的問(wèn)題。

ClickHouse并發(fā)能力，因?yàn)镃H是MPP架構(gòu)，分布式表的查詢會(huì)分發(fā)到所有節(jié)點(diǎn)去執(zhí)行，每個(gè)分片的節(jié)點(diǎn)都會(huì)參與計(jì)算，并發(fā)能力和單機(jī)是一樣的，增加副本可以提升并發(fā)能力。另一方法是提升單個(gè)查詢的查詢性能，比如通過(guò)改寫(xiě)SQL、物化視圖或者字典表的使用降低查詢時(shí)間。在查詢時(shí)間優(yōu)化到幾十毫秒以內(nèi)，增加副本數(shù)可以讓QPS達(dá)到數(shù)千甚至上萬(wàn)。

ClickHouse Join優(yōu)化，CH的Optimizer不夠自動(dòng)化，很多SQL需要顯式的指定執(zhí)行順序和優(yōu)化參數(shù)。我們之前做過(guò)ClickHouse的TPC-DS的測(cè)試，大部分多表Join的SQL都需要改寫(xiě)，比如把Join改為子查詢，改為本地表Join，設(shè)置distributed_group_by_no_merge去做分布式GroupBy等，改寫(xiě)之后的性能比較好，但大表和大表的Join在右表數(shù)據(jù)量達(dá)到千萬(wàn)級(jí)別之后，性能會(huì)急劇下降。

分布式的一系列問(wèn)題。這個(gè)問(wèn)題比較復(fù)雜，簡(jiǎn)單來(lái)說(shuō)，CH中強(qiáng)依賴于ZK，而ZK的性能瓶頸和不可擴(kuò)展性決定了CH的使用局限，另外一方面ClickHouse中的元數(shù)據(jù)管理很松散，缺乏統(tǒng)一的完整的解決方案。

1. ClickHouse把數(shù)據(jù)同步和DDL操作放在ZK中，產(chǎn)生兩個(gè)問(wèn)題，第一個(gè)問(wèn)題是ZNode會(huì)隨著節(jié)點(diǎn)和數(shù)據(jù)規(guī)模擴(kuò)大，ZNode達(dá)到一定數(shù)量會(huì)引發(fā)訪問(wèn)ZK超時(shí)，第二個(gè)問(wèn)題是沒(méi)有保證ZK和CH之間元數(shù)據(jù)的一致性，經(jīng)常出現(xiàn)ZK的元數(shù)據(jù)、節(jié)點(diǎn)的元數(shù)據(jù)、節(jié)點(diǎn)的本地?cái)?shù)據(jù)之間不一致。

2. 不方便擴(kuò)縮容，增加和減少副本是可以的，但是擴(kuò)分片需要數(shù)據(jù)均衡，比如下圖S1和S2兩個(gè)分片，增加S3這個(gè)分片，需要把S1和S2的數(shù)據(jù)分發(fā)一部分到S3，這樣就會(huì)涉及到數(shù)據(jù)在分片間移動(dòng)，如何在線平滑的移動(dòng)數(shù)據(jù)，是一個(gè)難解決的問(wèn)題。

3. 導(dǎo)入事務(wù)和冪等性， ClickHouse可以支持100萬(wàn)內(nèi)數(shù)據(jù)導(dǎo)入的原子性，這批數(shù)據(jù)要么都成功，要么都失敗，但沒(méi)有保證數(shù)據(jù)一致性和持久化，比如數(shù)據(jù)寫(xiě)入到某個(gè)副本中，寫(xiě)入后副本數(shù)據(jù)還沒(méi)同步到其他副本，此時(shí)節(jié)點(diǎn)故障了，數(shù)據(jù)就丟失了。當(dāng)開(kāi)啟了Spark的推測(cè)執(zhí)行，或?qū)?shù)程序故障重啟等問(wèn)題時(shí)，會(huì)導(dǎo)入重復(fù)數(shù)據(jù)。也就是說(shuō)CH的導(dǎo)數(shù)并未實(shí)現(xiàn)Exactly-once的語(yǔ)義。

京東的OLAP的實(shí)踐規(guī)劃，大致上按照提升高可用性，降低使用門(mén)檻，提升需求響應(yīng)速度等方面展開(kāi)。

統(tǒng)一元數(shù)據(jù)管理：為了解決上面的問(wèn)題，我們目前正在研究基于Raft的ZooKeeper替代方案，一方面是提升吞吐量和容量，另一方面是需要和ClickHouse結(jié)合更加緊密，保存更多元數(shù)據(jù)類型以增強(qiáng)CH的分布式能力，比如節(jié)點(diǎn)狀態(tài)，元數(shù)據(jù)管理，副本、分區(qū)和文件信息，并在此基礎(chǔ)上形成彈性擴(kuò)縮容的能力，集群遷移和備份恢復(fù)能力，以及跨數(shù)據(jù)中心數(shù)據(jù)復(fù)制能力。

管控面產(chǎn)品化：在使用CH和Doris的過(guò)程中，特別是大促的經(jīng)歷，讓我們積累了大量的運(yùn)維和故障處置腳本，我們正在把這些腳本進(jìn)行產(chǎn)品化，讓用戶自助式使用OLAP，如資源申請(qǐng)，創(chuàng)建用戶和庫(kù)，自助式的監(jiān)控報(bào)警，異常處理和性能診斷，對(duì)管理員側(cè)，做到集群部署和管控，以及故障自動(dòng)診斷和治愈。

云原生的OLAP：在容器化部署的同時(shí)，進(jìn)一步實(shí)現(xiàn)云原生，利用HDFS和對(duì)象存儲(chǔ)的優(yōu)勢(shì)，把存儲(chǔ)層放到外部，避免數(shù)據(jù)的重復(fù)存儲(chǔ)，節(jié)省導(dǎo)入時(shí)間，計(jì)算節(jié)點(diǎn)可以彈性擴(kuò)縮容。存儲(chǔ)分離出來(lái)之后，存儲(chǔ)如何擴(kuò)縮容，以及計(jì)算節(jié)點(diǎn)和存儲(chǔ)分片之間如何映射，都是新的問(wèn)題，這塊需要繼續(xù)研究。

其他方面如查詢優(yōu)化、分布式緩存、易用性提升等也都在規(guī)劃之中。京東數(shù)據(jù)中心的OLAP團(tuán)隊(duì)，已有幾千臺(tái)服務(wù)器，覆蓋交易、流量、算法等場(chǎng)景，同時(shí)我們也積極參與和回饋社區(qū)。

歡迎有志之士加入，對(duì)文中有任何疑問(wèn)也可以聯(lián)系：[email protected]