本文根據(jù)許鵬老師在〖DAMS 2017中國數(shù)據(jù)資產(chǎn)管理峰會〗現(xiàn)場演講內(nèi)容整理而成。(點擊底部“閱讀原文”獲取許鵬演講完整PPT) 講師介紹 許鵬,攜程機票大數(shù)據(jù)基礎(chǔ)平臺Leader,負(fù)責(zé)平臺的構(gòu)建和運維。深度掌握各種大數(shù)據(jù)開源產(chǎn)品,如Spark、Presto及Elasticsearch。著有《Apache Spark源碼剖析》一書。 主題簡介:
現(xiàn)如今大數(shù)據(jù)一塊有很多的開源項目,因此首先搭建平臺的難點其實在于如何選擇一個合適的技術(shù)來做整個平臺的架構(gòu),第二,因為有業(yè)務(wù)數(shù)據(jù),用了平臺之后的話,如何用平臺把數(shù)據(jù)分析出來讓用戶有很好的交互性的體驗。第三個層面就是理工科喜歡建模,而在這整個過程當(dāng)中,我們會形成一種非數(shù)據(jù)建模,而主要是我們?nèi)绾畏植煌瑢用娴娜藛T搭配,進(jìn)而做成這樣一個大數(shù)據(jù)團隊。 一、數(shù)據(jù)平臺技術(shù)選型 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
其實在做一套大數(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ù)據(jù)團隊能力建設(shè) 這部分講的是我們團隊的建設(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)行考量。 |
|