Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實(shí)的應(yīng)用案例！
[導(dǎo)讀]本文來(lái)源： https://www.cnblogs.com/rickie/p/11648622.html 國(guó)內(nèi)現(xiàn)在有大量的公司都在使用 Elasticsearch，包括攜程、滴滴、今日頭條、餓了么、360安全、小米、vivo等諸多知名公司。 除了搜索之外，結(jié)合Kibana、Logstash、Beats，Elastic Stack還被廣泛運(yùn)用
ich_media_content " id="js_content">
國(guó)內(nèi)現(xiàn)在有大量的公司都在使用 Elasticsearch，包括攜程、滴滴、今日頭條、餓了么、360安全、小米、vivo等諸多知名公司。
除了搜索之外，結(jié)合Kibana、Logstash、Beats，Elastic Stack還被廣泛運(yùn)用在大數(shù)據(jù)近實(shí)時(shí)分析領(lǐng)域，包括日志分析、指標(biāo)監(jiān)控、信息安全等多個(gè)領(lǐng)域。
它可以幫助你探索海量結(jié)構(gòu)化、非結(jié)構(gòu)化數(shù)據(jù)，按需創(chuàng)建可視化報(bào)表，對(duì)監(jiān)控?cái)?shù)據(jù)設(shè)置報(bào)警閾值，甚至通過(guò)使用機(jī)器學(xué)習(xí)技術(shù)，自動(dòng)識(shí)別異常狀況。
京東到家訂單中心系統(tǒng)業(yè)務(wù)中，無(wú)論是外部商家的訂單生產(chǎn)，或是內(nèi)部上下游系統(tǒng)的依賴，訂單查詢的調(diào)用量都非常大，造成了訂單數(shù)據(jù)讀多寫少的情況。
京東到家的訂單數(shù)據(jù)存儲(chǔ)在MySQL中，但顯然只通過(guò)DB來(lái)支撐大量的查詢是不可取的，同時(shí)對(duì)于一些復(fù)雜的查詢，Mysql支持得不夠友好，所以訂單中心系統(tǒng)使用了Elasticsearch來(lái)承載訂單查詢的主要壓力。
Elasticsearch 做為一款功能強(qiáng)大的分布式搜索引擎，支持近實(shí)時(shí)的存儲(chǔ)、搜索數(shù)據(jù)，在京東到家訂單系統(tǒng)中發(fā)揮著巨大作用，目前訂單中心ES集群存儲(chǔ)數(shù)據(jù)量達(dá)到10億個(gè)文檔，日均查詢量達(dá)到5億。
隨著京東到家近幾年業(yè)務(wù)的快速發(fā)展，訂單中心ES架設(shè)方案也不斷演進(jìn)，發(fā)展至今ES集群架設(shè)是一套實(shí)時(shí)互備方案，很好的保障了ES集群讀寫的穩(wěn)定性。
如上圖，訂單中心ES集群架設(shè)示意圖。整個(gè)架設(shè)方式通過(guò)VIP來(lái)負(fù)載均衡外部請(qǐng)求，第一層gateway節(jié)點(diǎn)實(shí)質(zhì)為ES中client node，相當(dāng)于一個(gè)智能負(fù)載均衡器，充當(dāng)著分發(fā)請(qǐng)求的角色。
第二層為data node，負(fù)責(zé)存儲(chǔ)數(shù)據(jù)以及執(zhí)行數(shù)據(jù)的相關(guān)操作。整個(gè)集群有一套主分片，二套副分片（一主二副），從網(wǎng)關(guān)節(jié)點(diǎn)轉(zhuǎn)發(fā)過(guò)來(lái)的請(qǐng)求，會(huì)在打到數(shù)據(jù)節(jié)點(diǎn)之前通過(guò)輪詢的方式進(jìn)行均衡。集群增加一套副本并擴(kuò)容機(jī)器的方式，增加了集群吞吐量，從而提升了整個(gè)集群查詢性能。
當(dāng)然分片數(shù)量和分片副本數(shù)量并不是越多越好，在此階段中，對(duì)選擇適當(dāng)?shù)姆制瑪?shù)量做了近一步探索。
分片數(shù)可以理解為Mysql中的分庫(kù)分表，而當(dāng)前訂單中心ES查詢主要分為兩類：?jiǎn)蜪D查詢以及分頁(yè)查詢。
分片數(shù)越大，集群橫向擴(kuò)容規(guī)模也更大，根據(jù)分片路由的單ID查詢吞吐量也能大大提升，但對(duì)于聚合的分頁(yè)查詢性能則將降低。分片數(shù)越小，集群橫向擴(kuò)容規(guī)模更小，單ID的查詢性能也將下降，但對(duì)于分頁(yè)查詢，性能將會(huì)得到提升。
所以如何均衡分片數(shù)量和現(xiàn)有查詢業(yè)務(wù)，我們做了很多次調(diào)整壓測(cè)，最終選擇了集群性能較好的分片數(shù)。
由于大部分ES查詢的流量都來(lái)源于近幾天的訂單，且訂單中心數(shù)據(jù)庫(kù)數(shù)據(jù)已有一套歸檔機(jī)制，將指定天數(shù)之前已經(jīng)關(guān)閉的訂單轉(zhuǎn)移到歷史訂單庫(kù)。
選擇對(duì)分片后的數(shù)據(jù)庫(kù)建立實(shí)時(shí)索引，把查詢收口到一個(gè)獨(dú)立的 Web Service，在保證性能的前提下，提升業(yè)務(wù)應(yīng)用查詢時(shí)的便捷性。
最終我們選擇了 Elasticsearch，看中的是它的輕量級(jí)、易用和對(duì)分布式更好的支持，整個(gè)安裝包也只有幾十兆。
http://developer.51cto.com/art/201807/579354.htm
這個(gè)是比較通用的數(shù)據(jù)的流程，一般會(huì)通過(guò)Kafka分離產(chǎn)生數(shù)據(jù)的應(yīng)用程序和后面的平臺(tái)，通過(guò)ETL落到不同的地方，按照優(yōu)先級(jí)和冷熱程度采取不同的存儲(chǔ)方式。
一般來(lái)說(shuō)，冷數(shù)據(jù)存放到HDFS，如果溫?cái)?shù)據(jù)、或者熱數(shù)據(jù)會(huì)采用Database以及Cache。一旦數(shù)據(jù)落地，我們會(huì)做兩方面的應(yīng)用
第一個(gè)方面的應(yīng)用是傳統(tǒng)BI，比如會(huì)產(chǎn)生各種各樣的報(bào)表，報(bào)表的受眾是更高的決策層和管理層，他們看了之后，會(huì)有相應(yīng)的業(yè)務(wù)調(diào)整和更高層面的規(guī)劃或轉(zhuǎn)變。
這個(gè)使用路徑比較傳統(tǒng)的，在數(shù)據(jù)倉(cāng)庫(kù)時(shí)代就已經(jīng)存在了。現(xiàn)在有一種新興的場(chǎng)景就是利用大數(shù)據(jù)進(jìn)行快速?zèng)Q策，數(shù)據(jù)不是喂給人的，數(shù)據(jù)分析結(jié)果由程序來(lái)消費(fèi)，其實(shí)是再次的反饋到數(shù)據(jù)源頭即應(yīng)用程序中，讓他們基于快速分析后的結(jié)果，調(diào)整已有策略，這樣就形成了一個(gè)數(shù)據(jù)使用的循環(huán)。
這樣我們從它的輸入到輸出會(huì)形成一種閉環(huán)，而且這個(gè)閉環(huán)全部是機(jī)器參與的，這也是為什么去研究這種大規(guī)模的，或者快速?zèng)Q策的原因所在。
如果數(shù)據(jù)最終還會(huì)給人本身來(lái)看的話，就沒(méi)有必要更新那么快，因?yàn)橐幻腌娝⑿乱淮位蛘?0秒鐘刷新一次對(duì)人是沒(méi)有意義的，因?yàn)槲覀兡X子不可能一直轉(zhuǎn)那么快，基于數(shù)據(jù)一直的做調(diào)整也是不現(xiàn)實(shí)的，但是對(duì)機(jī)器來(lái)講，就完全沒(méi)有問(wèn)題。
http://www.sohu.com/a/199672012_411876
目前，我們最大的日志單集群有120個(gè)data node，運(yùn)行于70臺(tái)物理服務(wù)器上。數(shù)據(jù)規(guī)模如下:
https://www.jianshu.com/p/6470754b8248
15年去哪兒網(wǎng)酒店日均訂單量達(dá)到30w+，隨著多平臺(tái)訂單的聚合日均訂單能達(dá)到100w左右。
原來(lái)采用的熱表分庫(kù)方式，即將最近6個(gè)月的訂單的放置在一張表中，將歷史訂單放在在history表中。history表存儲(chǔ)全量的數(shù)據(jù)，當(dāng)用戶查詢的下單時(shí)間跨度超過(guò)6個(gè)月即查詢歷史訂單表，此分表方式熱表的數(shù)據(jù)量為4000w左右，當(dāng)時(shí)能解決的問(wèn)題。但是顯然不能滿足攜程藝龍訂單接入的需求。
如果繼續(xù)按照熱表方式，數(shù)據(jù)量將超過(guò)1億條。全量數(shù)據(jù)表保存2年的可能就超過(guò)4億的數(shù)據(jù)量。所以尋找有效途徑解決此問(wèn)題迫在眉睫。
由于對(duì)這預(yù)計(jì)4億的數(shù)據(jù)量還需按照預(yù)定日期、入住日期、離店日期、訂單號(hào)、聯(lián)系人姓名、電話、酒店名稱、訂單狀態(tài)……等多個(gè)條件查詢。所以簡(jiǎn)單按照某一個(gè)維度進(jìn)行分表操作沒(méi)有意義。
Elasticsearch分布式搜索儲(chǔ)存集群的引入，就是為了解決訂單數(shù)據(jù)的存儲(chǔ)與搜索的問(wèn)題。
對(duì)訂單模型進(jìn)行抽象和分類，將常用搜索字段和基礎(chǔ)屬性字段剝離。DB做分庫(kù)分表，存儲(chǔ)訂單詳情；Elasticsearch存儲(chǔ)搜素字段。
訂單復(fù)雜查詢直接走Elasticsearch，基于OrderNo的簡(jiǎn)單查詢走DB，如下圖所示。
系統(tǒng)伸縮性：Elasticsearch 中索引設(shè)置了8個(gè)分片，目前ES單個(gè)索引的文檔達(dá)到1.4億，合計(jì)達(dá)到2億條數(shù)據(jù)占磁盤大小64G，集群機(jī)器磁盤容量240G。
https://elasticsearch.cn/article/6197
全面介紹 Elastic Stack 在58集團(tuán)信息安全部的落地，升級(jí)，優(yōu)化以及應(yīng)用。
包括如下幾個(gè)方面：接入背景，存儲(chǔ)選型，性能挑戰(zhàn)，master node以及data node優(yōu)化，安全實(shí)踐，高吞吐量以及低延遲搜索優(yōu)化；kibana 的落地，本地化使其更方便產(chǎn)品、運(yùn)營(yíng)使用。
https://elasticsearch.cn/slides/124
滴滴 2016 年初開(kāi)始構(gòu)建 Elasticsearch 平臺(tái)，如今已經(jīng)發(fā)展到超過(guò) 3500+ Elasticsearch 實(shí)例，超過(guò) 5PB 的數(shù)據(jù)存儲(chǔ)，峰值寫入 tps 超過(guò)了 2000w/s 的超大規(guī)模。
Elasticsearch 在滴滴有著非常豐富的使用場(chǎng)景，例如線上核心的打車地圖搜索，客服、運(yùn)營(yíng)的多維度查詢，滴滴日志服務(wù)等近千個(gè)平臺(tái)用戶。
先看看滴滴 Elasticsearch 單集群的架構(gòu)：滴滴在單集群架構(gòu)的時(shí)候，寫入和查詢就已經(jīng)通過(guò) Sink 服務(wù)和 Gateway 服務(wù)管控起來(lái)。
滴滴幾乎所有寫入 Elasticsearch 的數(shù)據(jù)都是經(jīng)由 kafka 消費(fèi)入到 Elasticsearch。
kafka
的數(shù)
據(jù)包括業(yè)務(wù) log 數(shù)據(jù)、mysql binlog 數(shù)據(jù)和業(yè)務(wù)
自主上報(bào)的數(shù)據(jù)，Sink 服務(wù)將這些數(shù)據(jù)實(shí)時(shí)消費(fèi)入到 Elasticsearch。
最初設(shè)計(jì) Sink 服務(wù)是想對(duì)寫入 Elasticsearch 集群進(jìn)行管控，保護(hù) Elasticsearch 集群，防止海量的數(shù)據(jù)寫入拖垮 Elasticsearch，之后我們也一直沿用了 Sink 服務(wù)，并將該服務(wù)從 Elasticsearch 平臺(tái)分離出去，成立滴滴 Sink 數(shù)據(jù)投遞平臺(tái)，可以從 kafka 或者 MQ 實(shí)時(shí)同步數(shù)據(jù)到 Elasticsearch、HDFS、Ceph 等多個(gè)存儲(chǔ)服務(wù)。
有了多集群架構(gòu)后，Elasticsearch 平臺(tái)可以消費(fèi)一份 MQ 數(shù)據(jù)寫入多個(gè) Elasticsearch 集群，做到集群級(jí)別的容災(zāi)，還能通過(guò) MQ 回溯數(shù)據(jù)進(jìn)行故障恢復(fù)。
所有業(yè)務(wù)的查詢都是經(jīng)過(guò) Gateway 服務(wù)，Gateway 服務(wù)實(shí)現(xiàn)了 Elasticsearch 的 http restful 和 tcp 協(xié)議，業(yè)務(wù)方可以通過(guò) Elasticsearch 各語(yǔ)言版本的 sdk 直接訪問(wèn) Gateway 服務(wù)
Gateway 服務(wù)還實(shí)現(xiàn)了 SQL 接口，業(yè)務(wù)方可以直接使用 SQL 訪問(wèn) Elasticsearch 平臺(tái)。
Gateway 服務(wù)最初提供了應(yīng)用權(quán)限的管控，訪問(wèn)記錄，限流、降級(jí)等基本能力，后面隨著平臺(tái)演進(jìn)，Gateway 服務(wù)還提供了索引存儲(chǔ)分離、DSL 級(jí)別的限流、多集群災(zāi)備等能力。
https://mp.weixin.qq.com/s/K44-L0rclaIM40hma55pPQ
搜索引擎中，主要考慮到Elasticsearch支持結(jié)構(gòu)化數(shù)據(jù)查詢以及支持實(shí)時(shí)頻繁更新特性，傳統(tǒng)訂單查詢報(bào)表的痛點(diǎn)，以及Elasticsearch能夠幫助解決的問(wèn)題。
整個(gè)業(yè)務(wù)線使用服務(wù)化方式，Elasticsearch集群和數(shù)據(jù)庫(kù)分庫(kù)，作為數(shù)據(jù)源被訂單服務(wù)系統(tǒng)封裝為對(duì)外統(tǒng)一接口；各前、后臺(tái)應(yīng)用和報(bào)表中心，使用服務(wù)化的方式獲取訂單數(shù)據(jù)。
https://my.oschina.net/u/2485991/blog/533163
本文來(lái)源：
https://www.cnblogs.com/rickie/p/11648622.html
一、京東到家訂單中心 Elasticsearch 演進(jìn)歷程
架構(gòu)的快速迭代源于業(yè)務(wù)的快速發(fā)展，正是由于近幾年到家業(yè)務(wù)的高速發(fā)展，訂單中心的架構(gòu)也不斷優(yōu)化升級(jí)。
架構(gòu)方案沒(méi)有最好的，只有最合適的。相信再過(guò)幾年，訂單中心的架構(gòu)又將是另一個(gè)面貌，但吞吐量更大，性能更好，穩(wěn)定性更強(qiáng)，將是訂單中心系統(tǒng)永遠(yuǎn)的追求。
二、攜程Elasticsearch應(yīng)用案例
1. 攜程酒店訂單Elasticsearch實(shí)戰(zhàn)
2. 攜程機(jī)票ElasticSearch集群運(yùn)維馴服記
3. 攜程：大規(guī)模 Elasticsearch 集群管理心得
-
單日索引數(shù)據(jù)條數(shù)600億，新增索引文件25TB (含一個(gè)復(fù)制片則為50TB) -
業(yè)務(wù)高峰期峰值索引速率維持在百萬(wàn)條/秒 -
歷史數(shù)據(jù)保留時(shí)長(zhǎng)根據(jù)業(yè)務(wù)需求制定，從10天 - 90天不等 -
集群共3441個(gè)索引、17000個(gè)分片、數(shù)據(jù)總量約9300億, 磁盤總消耗1PB
三、去哪兒：訂單中心基于elasticsearch 的解決方案
四、Elasticsearch 在58集團(tuán)信息安全部的應(yīng)用
五、滴滴Elasticsearch多集群架構(gòu)實(shí)踐
1. Sink服務(wù)
2. Gateway 服務(wù)
六、Elasticsearch實(shí)用化訂單搜索方案
訂單搜索系統(tǒng)架構(gòu)
特別推薦一個(gè)分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒(méi)關(guān)注的小伙伴，可以長(zhǎng)按關(guān)注一下：
長(zhǎng)按訂閱更多精彩▼
如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝
免責(zé)聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺(tái)僅提供信息存儲(chǔ)服務(wù)。文章僅代表作者個(gè)人觀點(diǎn)，不代表本平臺(tái)立場(chǎng)，如有問(wèn)題，請(qǐng)聯(lián)系我們，謝謝！
下載文檔
