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

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

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

京東數(shù)據(jù)分析的場景非常多，零售集團(tuán)主營業(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ù)會更新，比如交易狀態(tài)和金額的變化，組織架構(gòu)的變化會導(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ù)字段會經(jīng)常變化。

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

在大數(shù)據(jù)架構(gòu)中，OLAP的上游是Spark/Flink等計(jì)算引擎，下游對接報(bào)表、分析系統(tǒng)或策略系統(tǒng)。通過實(shí)施OLAP組件，可以加快需求響應(yīng)速度，簡化計(jì)算過程降低IDC成本。京東大數(shù)據(jù)發(fā)展較早，大數(shù)據(jù)體系也比較成熟，陸續(xù)引入了很多OLAP組件，主流OLAP技術(shù)都正式使用過，目前形成了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)置存儲邏輯，提供友好SQL查詢接口；ElasticSearch本身基于Lucence改進(jìn)，用到搜索引擎的索引技術(shù)，一般用于半結(jié)構(gòu)化的數(shù)據(jù)如日志或文本分析。

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

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

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

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

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

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

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

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

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

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

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

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

離線推薦HDD磁盤。在離線場景中，需要存儲數(shù)年的數(shù)據(jù)，存儲空間占用大，一般采用普通機(jī)械磁盤，數(shù)據(jù)在外部排序順序?qū)懭?，磁盤寫入速度和IO都能滿足要求。使用HDD磁盤時(shí)，需要堅(jiān)持小批次大批量的原則，盡量降低小文件對系統(tǒng)的負(fù)擔(dān)，采用大容量的磁盤，一個(gè)好處就是可以做一些物化視圖，來提升查詢性能，以空間換時(shí)間。而實(shí)時(shí)場景，我們一般選擇SSD或NVME，隨機(jī)寫入能性能好，可以低延時(shí)高頻寫入小文件，能獲得更低的數(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臺和64核的5臺，后者在某些場景下計(jì)算性能更優(yōu)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. ClickHouse把數(shù)據(jù)同步和DDL操作放在ZK中，產(chǎn)生兩個(gè)問題，第一個(gè)問題是ZNode會隨著節(jié)點(diǎn)和數(shù)據(jù)規(guī)模擴(kuò)大，ZNode達(dá)到一定數(shù)量會引發(fā)訪問ZK超時(shí)，第二個(gè)問題是沒有保證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，這樣就會涉及到數(shù)據(jù)在分片間移動，如何在線平滑的移動數(shù)據(jù)，是一個(gè)難解決的問題。

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

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

統(tǒng)一元數(shù)據(jù)管理：為了解決上面的問題，我們目前正在研究基于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的過程中，特別是大促的經(jīng)歷，讓我們積累了大量的運(yùn)維和故障處置腳本，我們正在把這些腳本進(jìn)行產(chǎn)品化，讓用戶自助式使用OLAP，如資源申請，創(chuàng)建用戶和庫，自助式的監(jiān)控報(bào)警，異常處理和性能診斷，對管理員側(cè)，做到集群部署和管控，以及故障自動診斷和治愈。

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

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

推薦閱讀：
世界的真實(shí)格局分析，地球人類社會底層運(yùn)行原理
企業(yè)IT技術(shù)架構(gòu)規(guī)劃方案
論數(shù)字化轉(zhuǎn)型——轉(zhuǎn)什么，如何轉(zhuǎn)？
企業(yè)10大管理流程圖，數(shù)字化轉(zhuǎn)型從業(yè)者必備！
【中臺實(shí)踐】華為大數(shù)據(jù)中臺架構(gòu)分享.pdf
華為的數(shù)字化轉(zhuǎn)型方法論
華為如何實(shí)施數(shù)字化轉(zhuǎn)型（附PPT）
超詳細(xì)280頁Docker實(shí)戰(zhàn)文檔！開放下載
華為大數(shù)據(jù)解決方案（PPT）