（點擊底部“閱讀原文”獲取許鵬演講完整PPT）

講師介紹

主題簡介：

現(xiàn)如今大數(shù)據(jù)一塊有很多的開源項目，因此首先搭建平臺的難點其實在于如何選擇一個合適的技術(shù)來做整個平臺的架構(gòu)，第二，因為有業(yè)務(wù)數(shù)據(jù)，用了平臺之后的話，如何用平臺把數(shù)據(jù)分析出來讓用戶有很好的交互性的體驗。第三個層面就是理工科喜歡建模，而在這整個過程當(dāng)中，我們會形成一種非數(shù)據(jù)建模，而主要是我們?nèi)绾畏植煌瑢用娴娜藛T搭配，進(jìn)而做成這樣一個大數(shù)據(jù)團隊。

1、整體框架

這個框架應(yīng)該是一種大路貨，或者更認(rèn)為是一種比較常見的架構(gòu)。前面也就是從數(shù)據(jù)源到消息隊列到數(shù)據(jù)的清理、數(shù)據(jù)呈現(xiàn)等這些大家容易想到的東西，而在這樣一個大帽子下面，所不一樣的東西是具體選用什么樣的組件來填這個空，在不同的場景下，每個人的選擇是不大相同的。

像消息隊列這一層，我們選用了Kafka，這是目前大家普遍用到的，因為它有高吞吐量，采用Push和Pull結(jié)合的方式，消費端主動拉取數(shù)據(jù)。ETL這塊，目前大家都希望采用一種可以自定義的方式，一般來說比較流行的是用LinkedIn提供的Camus來做從Kafka到HDFS的數(shù)據(jù)同步。這應(yīng)該是一種較為流行的架構(gòu)。那么放到HDFS上面的數(shù)據(jù)，基本上是為了批處理做準(zhǔn)備的，那么在批處理分析的時候，我們選擇一個什么樣的分析引擎，可能就是一個值得爭議的焦點，也就是說，也許在這個分析引擎的下面，有Hive，有Spark，有Presto，有Impala，還有其它的東西。 在這些引擎當(dāng)中的選擇或者實踐，需要結(jié)合具體使用場景。

下面講講為什么會選擇Presto而不是其它。假設(shè)在座的各位有Presto使用經(jīng)驗的話，會發(fā)覺Presto它是一個CLI的用戶界面，并沒有好的一種Web UI，對一般用戶來說，CLI的使用會有難度，不管這是感覺上的還是實際上的，所以需要有個好的Web UI來增加易用性。

當(dāng)前在GitHub上面能找到的Presto webui的就是Airbnb提供的AirPal，但根據(jù)我們的使用經(jīng)驗，不怎么友好，特別在UTC的時間設(shè)置上，同時它的社區(qū)維護(hù)已停滯在兩年前，這一塊我們做了適配，然后用Presto的StatementClient做了Web UI。前端采用的是jquery的easyui, 像剛才講的批處理這一條線，就是用在了批處理這一塊上。下面這一條線就是說有些數(shù)據(jù)可能是希望立馬存儲，立即被搜索到，或者做簡要的分析。

作為搜索引擎，社區(qū)這一塊，大家耳熟能詳?shù)膽?yīng)該是Elasticsearch，Elasticsearch的社區(qū)非常活躍，而且它的推廣速度，應(yīng)用型上面易都很好。但是Elasticsearch的難點在于如何對它進(jìn)行好的維護(hù)，后面我會講到它可能存在的維護(hù)痛點。那么，Elasticsearch有非常強大的搜索能力，響應(yīng)時間也是非?？斓模撬挠脩艚涌?，有自己的一套基于Lucene的搜索語法，當(dāng)然Lucene的這一套語法本身是非常極客的，很簡潔，但是一般的人不愿意去學(xué)這個東西，因為對于分析師來講去學(xué)，就意味著以前的武功，幾十年功夫白費了。

于是我們就采用了一個插件Elastisearch-SQL，這樣就可以采用SQL語句對Elasticsearch進(jìn)行點查詢或者范圍查詢。而且在Elasticsearch的演進(jìn)路徑當(dāng)中，也會支持SQL，按照之前看到的ES roadmap, 應(yīng)該在17年最遲不超過18年發(fā)布6.×，重要的特性之一是對SQL的支持，大家可以看到如果不支持SQL，就等于是自廢武功，或者拒客戶于千里之外。 

Web UI是人機交互的部分，我們會進(jìn)行Ad-hoc查詢，但在整個部門當(dāng)中有不少程序希望調(diào)用查詢，也就是應(yīng)用的接口，采用SOA的架構(gòu)，我們自己開發(fā)實現(xiàn)了 BigQuery API，可以通過這種調(diào)Restful 接口方式，進(jìn)行取數(shù)或者分析。那么我們會自動判別到底是到ES這一側(cè)還是到Presto進(jìn)行取數(shù)。

在很多公司的使用當(dāng)中，數(shù)據(jù)分析這一塊是需要報表的，就是要有很好的Dashboard。

2、ETL PipeLine -- Gobblin

這個是ETL相對比較細(xì)節(jié)的一些東西?？焖龠^一下這個圖。在ETL的時間當(dāng)中，比如說為什么不直接用像Spark或者流的方式，最常見的問題就是小文件的問題，到時候需要清理合并小文件，這很麻煩。如果采用Zeus去調(diào)度，然后設(shè)定一定數(shù)目的Partition，就有一個Map Task對應(yīng)，盡可能的寫滿一個Block，以64M或者128M為主。在存儲的時候我們除了考慮它的大小之外，存儲格式的選擇也應(yīng)該是必須考量的范圍。

從我們當(dāng)前的選擇來看，建議使用ORC這樣的文件格式，采用這個文件格式是由于它已經(jīng)內(nèi)嵌了一定級別的索引，盡管索引不是非常細(xì)粒度，但是在某些層面是能夠急速地提高檢索，跳過不符合條件的數(shù)據(jù)塊，避免不必要的數(shù)據(jù)傳輸。目前相對比較有希望的，或者大力推廣的一個格式就是華為公司在推的CarbonData，它含有的索引粒度，索引信息比ORC更加細(xì)致。他們目前也出了1.×的版本，是相對來講較為成熟一個版本。

3、分析引擎 - Presto

這里講的是Presto的內(nèi)部機理。為什么不用Hive和Spark？Hive相當(dāng)于是俄國的武器，特點就是傻大黑粗，絕對的穩(wěn)定，穩(wěn)定到什么程度？穩(wěn)定到就是它是最慢的一個，有一個笑話就是我的成績一直很穩(wěn)定，因為老考倒數(shù)第一，沒人可以比過，所以一直很穩(wěn)定，而正數(shù)第一不見得很穩(wěn)定，Hive就是這個特點，絕對可以出來結(jié)果，但是會讓你覺得人生沒有指望。

Spark的特點就是它名頭絕對的夠響，但是會發(fā)覺Spark具體的使用過程當(dāng)中有些問題？資源共享是一個問題，如果說你光用Spark，肯定Concurrent Query出現(xiàn)問題的，要前置一個東西，比如Livy或者什么東西來解決掉你的資源共享問題。而且Spark的雄心很大，幾乎想把所有東西都吃下去，所有東西都吃，就很難，因為你要涉及很多的領(lǐng)域。

Presto只專注于數(shù)據(jù)的分析，只關(guān)注SQL查詢層面，只做一件事，這個充分體現(xiàn)了Unix的哲學(xué)，遵循只干一件活，不同的活通過Pipeline的方式串起來。而且Presto是基于流水線的，只要有一個塊當(dāng)中結(jié)果出來了，然后比如說我們最典型的就是后面加一個后置的條件，然后limit 10或者Limit 1，你會發(fā)覺很快出來結(jié)果，用Spark會發(fā)現(xiàn)它Where條件的搜索會經(jīng)歷多個Stage，必須到前面的Stage都完成了才可以跑下一個Stage， 那個Limit 1的結(jié)果要到后面才過濾。

從Presto后面給出的這些數(shù)據(jù)可以看到，這種層面上的一個提升?；贠RC的文件存儲，它的提升應(yīng)該是5倍或者10倍，10倍到20倍的提升。它的架構(gòu)簡單來說是有一個Client，然后這個Client提交SQL語句過來，前面有一個Planner和Scheduler，會把相應(yīng)的SQL的東西分層，分成不同的Stage，每一個Stage有多個Task，這些真正的Task是運行在不同的Workers上面，利用這些Workers去數(shù)據(jù)源讀取數(shù)據(jù)。

也就是說Presto是專注于在數(shù)據(jù)分析這側(cè)，具體數(shù)據(jù)的存儲在外面，這個當(dāng)中肯定要去解決哪些東西是值得去拉取的，有哪些東西可以直接推到數(shù)據(jù)源側(cè)去搞定，不需要傻乎乎地把很多東西拉上來。

分析引擎比較——Presto與MapReduce

大家可以看到我剛才提到一個基于Stage的方式，一個基于Pipeline的方式，Pipeline的方式就是整個過程中，處理沒有停頓，整個是交叉的，它不會等上一個Stage完成后再進(jìn)行下一個Stage，Spark的特點就是等到一個Stage結(jié)束了，數(shù)據(jù)吐到Disk中，下一個Stage再去拉數(shù)據(jù)，然后再進(jìn)行下一個。Pipeline就是說我有一個Task處理完，直接將數(shù)據(jù)吐到下一個Task，直到Aggregator節(jié)點。

那么在這個過程當(dāng)中，你也會看到Presto的一個最大特點就在于所有的計算就在內(nèi)存當(dāng)中，你會想到人的大腦，機器的內(nèi)存都是有限的，會崩掉了，崩掉就崩掉了，早死早超生，大不了再跑一趟，這就是Presto的一個基本原則。

MapReduce會重啟，如果成功了還好，重啟很多次崩掉是不是三觀盡毀？通過這種特點也表明Presto適用的場景，適用于交互式查詢，如果是批量的，你晚上要做那種定期報表的話，把整個交給Presto是不負(fù)責(zé)任的表現(xiàn)，因為有大量的時間，應(yīng)該給Hive比較好。

3、近實時搜索 – Elasticsearch

下面講講ES層面的東西，也就是近實時的搜索引擎，它所有的東西都是基于Lucene上面進(jìn)行一個包裹，對JSON支持的非常好。同時Elasticsearch支持橫向、水平擴展，高可用，易于管理，社區(qū)很活躍，背后有專門的商業(yè)公司。它的競品就是Solr，Solr的Cloud，SolrCloud安裝較為復(fù)雜，引入了獨立的第三方東西，對ZooKeeper集群有極大的依賴，這樣使得Solr Cloud的管理變得復(fù)雜。

SolrCloud的發(fā)展也很活躍，現(xiàn)在是到了6.×，后續(xù)就是到7.×，而且SolrCloud的6.×當(dāng)中引入了對SQL的支持，ES和SolrCloud是同門師兄弟，通過同門師兄弟的相互競爭可以看到發(fā)展的趨勢——SQL一定是會支持的。

如果大家做搜索這一塊東西的話，上面這張圖其實是很常見的，它肯定會在某一個節(jié)點上面有相應(yīng)的一個主分區(qū)，有一個Primary partition，而在另外一個節(jié)點上面它有一個Replicas，而且Replica可能不只一個，如果這些沒有，這張圖就沒有太多好講的。問題是該分幾個Replica，在每臺機器上分幾個不同的partition，如果在從事維護(hù)工作的話，上述問題是值得去分析和考究的。

ES調(diào)優(yōu)和運維

下面講ES的調(diào)優(yōu)和運維，從兩個層面出發(fā)。

第一個層面就是OS， 講到Linux， 調(diào)優(yōu)過程中自然會考慮到它的文件句柄數(shù)，然后它的Memory，它的I/O的調(diào)度，I/O的調(diào)度線如果在座各位對內(nèi)核比較感興趣的話，你會發(fā)現(xiàn)基本使用CFQ，因為在生產(chǎn)環(huán)節(jié)上大多會采用Redhat或者CentOS來部署，不會部署到像自己玩的Archlinux或者Gentoo上面，不可能這樣做的。還有就是它的Virtual memory Dirty Ratio，這個東西是會極大地影響響應(yīng)時間，或者說有時你會發(fā)覺I/O操作，而且CPU一直比較高，因為有文件緩存，緩存足夠多的話就一直往磁盤去寫，所以我們的辦法就是把原來設(shè)置比較高的vm.dirty_ratio，由默認(rèn)20%調(diào)小到10%。意思就是說緩存內(nèi)容一旦超過系統(tǒng)內(nèi)存的10%其它活不要干了，專心致志吐這個緩存內(nèi)容。 Vm.dirty_background_ratio是說如果達(dá)到這個閥值，就開始將文件緩存內(nèi)容寫入到磁盤。OS層面的調(diào)優(yōu)和數(shù)據(jù)庫的系統(tǒng)調(diào)優(yōu)有相似性。

另一個層面的調(diào)優(yōu)是ES本身，首先就是說我在一個Cluster上，Shard的數(shù)目要均勻分布。

我這里放了一張截圖，這個截圖大家可以看到所有的節(jié)點上面，Shard數(shù)目上來講是非常均勻的。有相應(yīng)的參數(shù)調(diào)整可以達(dá)到這樣的效果。第二個就是會有一個Replica的過程，比如新加一臺機器或者說我是減少一臺機器，要做相應(yīng)的維護(hù)，機器的集群會做動態(tài)的擴容和縮減。那么這時如果都來做Shard的轉(zhuǎn)移，整個集群的寫入和查詢會受很大影響，所以做一定的均衡，兩者之間要有一定的Balance。這些講的都是集群級別，下面講索引級別的優(yōu)化。

索引級別的優(yōu)化就是我要對Shard的數(shù)目，到底是這個Index是分十個Shard存還是5個來存，refresh的頻率，Refresh就是說這個數(shù)據(jù)寫入多久之后可以被搜索到。Refresh時間拉得越長，數(shù)據(jù)吞吐量越大，但是可以被搜索到的時間越滯后。 還有Merge的過程，因為分片，為了減少對文件句柄使用， 所以需要進(jìn)行Merge。有人講就是因為ES支持Schemaless了，所以不需要fixed的Schema。但在實際的使用過程中發(fā)覺，如果不做一定限制的話，每個人都認(rèn)為是自由的，就會出現(xiàn)一個Field的急速膨脹，在某個索引下面成千上萬的字段， 這樣一來索引的寫入速度就下來了。

下圖是我們自己寫的Dashboard，說到ES，可能在座的也有不少在用，如果說你們升級到5.×后發(fā)現(xiàn)一點，1.×比較好的插件Marvel，5.×里面就沒有，提供的就是X-pack，X-pack是要收錢的，那么它同時提供了一個所謂的basic版本，F(xiàn)ree的東西大家都知道，便宜無好貨，就是說它的功能是對比了1.×的版本，很多信息都是沒有的。

我們的話就是自力更生，因為你所有的內(nèi)容都是可以通過Rest API讀取到，只不過是需要在前端可視化一下。那么這張圖就是我們做的工作，可以很方便地看到當(dāng)前節(jié)點的寫入量、查詢量，當(dāng)前節(jié)點的索引，Shard數(shù)目還有當(dāng)前集群的狀態(tài)，如果一旦狀態(tài)變?yōu)閞ed，可以郵件通知，在頁面上還可以進(jìn)一步點下去了解每一個節(jié)點和索引的詳細(xì)信息。

稍微總結(jié)一下，一般來說在調(diào)優(yōu)上考量的不外乎四個維度：一個CPU的維度，一個Memory的角度，還有就是Disk的I/O角度，另外一個是網(wǎng)絡(luò)。 比如從原來的百M網(wǎng)卡升級到千M網(wǎng)卡，從千M到萬M，查詢的響應(yīng)速度會有很大提升。

這是前面提到我們統(tǒng)一的一個SQL查詢的接口，大家可以看到這挺簡陋的，很傻很天真的樣子，我就是上面輸入一個SQL，下面很快就出來一個結(jié)果。但就是因為采用了這種方式，因為后面是它采用了Presto這個引擎，在部門內(nèi)部，我們有不少同事都在使用這個進(jìn)行數(shù)據(jù)查詢，目前的日常使用量應(yīng)該是在近8K的樣子，因為最近還升級了一下網(wǎng)卡，升級到萬M網(wǎng)卡，使得速度更加快。多余的時間喝喝咖啡抽抽煙生活多美好，比等在那里焦慮有意思多了。

4、數(shù)據(jù)可視化——Zeppelin

在做數(shù)據(jù)可視化這一塊時，可以借鑒競爭對手或者競品，看看別人在做什么，如果說大家去看Hue， Hue的話，其實就是上面輸入查詢語句之后，后續(xù)就把結(jié)果很好地顯示出來。我們目前所考慮的就是說如何做到Data visualize的，目前嘗試用Zeppelin，這個可以通過JDBC接口對接Presto，把數(shù)據(jù)查詢出來，通過簡單的拖拽，直接把報表以圖形化的方式展現(xiàn)出來。

補充一下，Zeppelin這個如果要對接Spark，如果只是一個Spark集群，直接對接這個Spark集群，資源利用率是非常非常低的，但是你在前置一個Livy Server的話，通過Livy來進(jìn)行資源調(diào)度，資源共享會比較好。目前有兩個這一方面的競品，一個Livy，另外一個就是Oyala它提供的Spark Job ServerS，干的活其實都是一樣。Zeppelin是對Livy Server做了整合。

5、數(shù)據(jù)微服務(wù) – Rest查詢接口

微服務(wù)這一塊，我們提供了一個BigQuery API，這樣的好處是有一個統(tǒng)一的查詢?nèi)肟冢薪y(tǒng)一的權(quán)限管理。因為查詢時不是所有人都應(yīng)該看到所有的數(shù)據(jù)，這很容易出問題，可能有比較實實在在的數(shù)據(jù)，它不像一般的日志數(shù)據(jù)，特別像機票或者我們這邊的酒店，它的數(shù)據(jù)有不少的一些敏感信息，這需要做相應(yīng)的權(quán)限管理。這個入口統(tǒng)一之后，做權(quán)限管理就比較方便了，出問題的話只要查相應(yīng)的日志就OK了。而且使用的是統(tǒng)一的查詢語言，都用的是大家比較熟知的這種SQL語句，不是說用了一個新的東西就要學(xué)習(xí)一套新的知識，這樣子的話原有知識不容易得到傳承，這是大家都應(yīng)盡量去避免的。

6、任務(wù)調(diào)度器 – Job Scheduler

• Zeus-https://github.com/ctripcorp/dataworks-zeus

其實在做一套大數(shù)據(jù)的平臺時，少不了任務(wù)調(diào)度這一塊。任務(wù)調(diào)度這一塊我們使用的是Zeus系統(tǒng)，攜程在這一塊開源出來，由我們公司Ops的團隊專門來負(fù)責(zé)開發(fā)和維護(hù)個平臺。但是你想，通過這個平臺遞交的任務(wù)包括，ETL和定時任務(wù)，可以實現(xiàn)將數(shù)據(jù)從Kafka放入到HDFS或者是把SQL Server和MySQL DB里面的數(shù)據(jù)同步到HDFS。調(diào)度這一塊目前市面上的競品還有AirFlow和其它。

這部分講的是我們團隊的建設(shè)。目前我把它分成五個不同的角度，第一個是引擎的開發(fā)，這一塊是相對較難的，它對后臺的技術(shù)要求比較高。

第二是交互界面設(shè)計，整個東西做出來，如果只是做了引擎，或者對引擎做了，但是沒有實際的人用，老板肯定也會叫滾蛋的，肯定要一環(huán)套一環(huán)，形成有效的傳動，不是單點，只講發(fā)動機沒有任何意義的，要講整車。所以有引擎，引擎的要求也比較高，會有一個交互界面的設(shè)計，就是我如何用這些引擎的東西。

把這些東西都弄上后，可以轉(zhuǎn)起來了，整個可以轉(zhuǎn)起來之后，我們還有個運維，其實大家可以逐步發(fā)現(xiàn)一個趨勢，就是無論大數(shù)據(jù)也好，云平臺也好，對運維的要求都是比較高的，一個好的運維不僅要掌握一個基礎(chǔ)的OS層面的東西，對后臺也得有一個較好的概念或者好的研究。無論是從后臺服務(wù)開發(fā)轉(zhuǎn)到運維還是從運維轉(zhuǎn)后臺服務(wù)器開發(fā)，兩者都需要去交叉學(xué)習(xí)。

那么，一個平臺規(guī)劃相對來說就是一個架構(gòu)師或相對更高層一點人員的工作范疇，視野可以更高一點，這樣的角色肩負(fù)了架構(gòu)和產(chǎn)品經(jīng)理這兩個概念的東西，因為像這種東西最主要是內(nèi)部使用，比較難以獨立出來。

語言這一塊就是見仁見智，我只是把我們現(xiàn)在采用到的，使用到的東西列了一下，有上述這么多。

大體我們的實踐的就是這些。我們所有的部分應(yīng)該就在這一張圖里，這張圖的內(nèi)容看起來比較平淡，但是如果需要把這張圖弄好，確實花了不少時間。

Q1：請問攜程這邊Cluster集群的規(guī)模？并發(fā)度大概什么情況？因為講的是一天大概八千個，規(guī)模和并發(fā)度是怎樣的呢？

A1：目前我們的集群規(guī)模不是特別大，在十臺左右，但是我們的硬件配置是128G的內(nèi)存，萬兆網(wǎng)卡，CPU是16核32超線程的。并發(fā)的話就是在高峰期我們會有十幾或二十個并發(fā)的查詢。

Q2：后面你說是50%的查詢在500，這是什么樣的查詢？

A2：這里的查詢，我們就是要看它查詢的數(shù)據(jù)、目標(biāo)數(shù)據(jù)值，你不可能對所有的數(shù)據(jù)全值做查詢。如果說你本身就存了10T的數(shù)據(jù)或者更多的數(shù)據(jù)，想要一個東西讓它能夠很短的時間都不現(xiàn)實的，不管什么目標(biāo)都是盡量減少數(shù)據(jù)的拉取。沒有把SQL貼出來，可能你看到SQL就知道我們怎么存儲數(shù)據(jù)的。

因為我們有專門的數(shù)據(jù)分析師團隊，我對他們寫出的SQL佩服得五體投地，他們寫出來的有一千多，我們有同事在，但是那個不能貼出來看。也不是說很傻瓜的SQL，是很強勁的。

有兩種層面，第一個就是我們做了一個從Presto讀取Elasticsearch上的數(shù)據(jù)，但我們認(rèn)為還是沒有優(yōu)化到最好。Elasticsearch-SQL就是說只做了SQL的轉(zhuǎn)譯，所有真實的計算和分析都在ES上面，這個Elasticsearch-sql是比較流行的一個插件，如果你玩Presto的話, 要找一個讀取Elasticsearch的connector。 那么能找到的就是我們在開發(fā)的，已經(jīng)放在Github上。

（接上問）

Q3：你們還貢獻(xiàn)了Presto對Carbondata讀取的實現(xiàn)，但我們測下來是在拉少量的時候比ORC性能差不多，如果是大量的數(shù)據(jù)的話carbondata是比ORC差很多。

A3：所以說你看我這張圖，整個的過程沒有。我只能在技術(shù)保持熱情，投入多大資源不是我能決定的。

引擎本身上面，我們可能做的并不是一個性能的優(yōu)化，我們做的就是跟我們內(nèi)部的數(shù)據(jù)的對接Carbondata, 可能在性能的提升上面并沒有做很多實際的，到目前為止并沒有很多資源投入，但由于實現(xiàn)了Presto來讀取ESs和Carbondata，我們對presto整個的執(zhí)行鏈路比較清楚。

（接上問）

Q4：你們目前的版本是？

A4：0.169。

Q5：是京東的嗎？

A5：不是京東的，是Facebook的。

Q6：貴公司每天數(shù)據(jù)處理的量還有數(shù)據(jù)團隊的規(guī)模是多大？大體的范圍是怎樣的？

A6：要看從哪個層面，如果從業(yè)務(wù)去，還是日志數(shù)據(jù)？日志數(shù)據(jù)我們有一個記錄是每天日增800億。就是一張表。

Q7：如何處理日志數(shù)據(jù)和銷售數(shù)據(jù)之間的關(guān)系？

A7：這個問題本身是比較大路的問題，你肯定能夠想到的比較簡單或者通用的方式。

Q8：團隊的規(guī)模多大？

A8：這個在精不在量，我們的規(guī)模在十來個人。   

Q9：我想問一下你們Presto連接的ES服務(wù)，加載大量的數(shù)據(jù)比如百萬級別的這種有沒有什么問題？

A9：加載百萬級別的記錄，因為要進(jìn)行大量I/O操作，會對ES造成比較大的干擾，這也是為什么我們自己后來沒有就是去推Presto ES Connector的原因。舉個最簡單的例子，做個Count操作，也許需要把數(shù)據(jù)從ES側(cè)拉到Presto后再來計算，才能得到這個結(jié)果。然而這個東西其實完全可以下推到ES上，直接得到結(jié)果返回的。

Q10：這個沒破？

A10：對于OR和AND條件查詢，我們做了下推，聚合側(cè)的下推沒有做。

Q11：你用Spark讀取ES也是百萬級的？

A11：需要從里面去讀取，這個很多都是繞不開的，包括用Spark，如果用Elasticsearch-Haoop，就是ES提供的Hadoop組件，會發(fā)現(xiàn)也是要用RDD去讀取ES，把數(shù)據(jù)從ES抽取出來。但是在ES里面，并沒有一個很好的這種所謂的Columnar的Storage，也就是說沒有列存儲，這時候是非常低效的。如果加上一些過濾條件，從ES當(dāng)中把你所需要的字段抽出來，然后再進(jìn)行包裝，再通過網(wǎng)絡(luò)傳輸，再到達(dá)不管Spark還是Presto，這是很低效的。

Q12：寫入大量數(shù)據(jù)到ES？

A12：寫入大量數(shù)據(jù)到ES，ES這個還是能夠很好處理的，那個時候牽扯到調(diào)優(yōu)，要考慮到這些因素。從Refresh的時長，replica的數(shù)目，merge的緩存大小多個方面進(jìn)行考量。