《攜程機(jī)票大數(shù)據(jù)架構(gòu)最佳實(shí)踐》要點(diǎn)：
本文介紹了攜程機(jī)票大數(shù)據(jù)架構(gòu)最佳實(shí)踐，希望對您有用。如果有疑問，可以聯(lián)系我們。

本文根據(jù)許鵬老師在〖DAMS 2017中國數(shù)據(jù)資產(chǎn)管理峰會〗現(xiàn)場演講內(nèi)容整理而成.

講師介紹

許鵬,攜程機(jī)票大數(shù)據(jù)基礎(chǔ)平臺Leader,負(fù)責(zé)平臺的構(gòu)建和運(yùn)維.深度掌握各種大數(shù)據(jù)開源產(chǎn)品,如Spark、Presto及Elasticsearch.著有《Apache Spark源碼剖析》一書.

主題簡介：

1. 數(shù)據(jù)平臺技術(shù)選型
2. 用戶交互實(shí)踐
3. 大數(shù)據(jù)團(tuán)隊(duì)能力建設(shè)

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

一、數(shù)據(jù)平臺技術(shù)選型

1、整體框架

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

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

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

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

作為搜索引擎,社區(qū)這一塊,大家耳熟能詳?shù)膽?yīng)該是Elasticsearch,Elasticsearch的社區(qū)非常活躍,而且它的推廣速度,應(yīng)用型上面易都很好.但是Elasticsearch的難點(diǎn)在于如何對它進(jìn)行好的維護(hù),后面我會講到它可能存在的維護(hù)痛點(diǎn).那么,Elasticsearch有非常強(qiáng)大的搜索能力,響應(yīng)時(shí)間也是非常快的,但是它的用戶接口,有自己的一套基于Lucene的搜索語法,當(dāng)然Lucene的這一套語法本身是非常極客的,很簡潔,但是一般的人不愿意去學(xué)這個(gè)東西,因?yàn)閷τ诜治鰩焷碇v去學(xué),就意味著以前的武功,幾十年功夫白費(fèi)了.

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

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

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

2、ETL PipeLine — Gobblin

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

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

3、分析引擎 – Presto

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

Spark的特點(diǎn)就是它名頭絕對的夠響,但是會發(fā)覺Spark具體的使用過程當(dāng)中有些問題?資源共享是一個(gè)問題,如果說你光用Spark,肯定Concurrent Query出現(xiàn)問題的,要前置一個(gè)東西,比如Livy或者什么東西來解決掉你的資源共享問題.而且Spark的雄心很大,幾乎想把所有東西都吃下去,所有東西都吃,就很難,因?yàn)槟阋婕昂芏嗟念I(lǐng)域.

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

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

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

分析引擎比較——Presto與MapReduce

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

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

MapReduce會重啟,如果成功了還好,重啟很多次崩掉是不是三觀盡毀?通過這種特點(diǎn)也表明Presto適用的場景,適用于交互式查詢,如果是批量的,你晚上要做那種定期報(bào)表的話,把整個(gè)交給Presto是不負(fù)責(zé)任的表現(xiàn),因?yàn)橛写罅康臅r(shí)間,應(yīng)該給Hive比較好.

4、近實(shí)時(shí)搜索 – Elasticsearch

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

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

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

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

下面講ES的調(diào)優(yōu)和運(yùn)維,從兩個(gè)層面出發(fā).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二、數(shù)據(jù)團(tuán)隊(duì)能力建設(shè)

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

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

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

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

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

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

Q&A

Q1：請問攜程這邊Cluster集群的規(guī)模?并發(fā)度大概什么情況?因?yàn)橹v的是一天大概八千個(gè),規(guī)模和并發(fā)度是怎樣的呢?

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

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

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

因?yàn)槲覀冇袑ｉT的數(shù)據(jù)分析師團(tuán)隊(duì),我對他們寫出的SQL佩服得五體投地,他們寫出來的有一千多,我們有同事在,但是那個(gè)不能貼出來看.也不是說很傻瓜的SQL,是很強(qiáng)勁的.

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

(接上問)

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

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

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

(接上問)

Q4：你們目前的版本是?

A4：0.169.

Q5：是京東的嗎?

A5：不是京東的,是Facebook的.

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

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

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

A7：這個(gè)問題本身是比較大路的問題,你肯定能夠想到的比較簡單或者通用的方式.

Q8：團(tuán)隊(duì)的規(guī)模多大?

A8：這個(gè)在精不在量,我們的規(guī)模在十來個(gè)人.

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

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

Q10：這個(gè)沒破?

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

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

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

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

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

文章來自微信公眾號：DBAplus社群

 

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/2190.html