當前位置:首頁 > 公眾號精選 > 架構師社區(qū)
[導讀]本文來源: https://www.cnblogs.com/rickie/p/11648622.html 國內(nèi)現(xiàn)在有大量的公司都在使用 Elasticsearch,包括攜程、滴滴、今日頭條、餓了么、360安全、小米、vivo等諸多知名公司。 除了搜索之外,結合Kibana、Logstash、Beats,Elastic Stack還被廣泛運用

ich_media_content " id="js_content">

Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!

本文來源:

https://www.cnblogs.com/rickie/p/11648622.html




國內(nèi)現(xiàn)在有大量的公司都在使用 Elasticsearch,包括攜程、滴滴、今日頭條、餓了么、360安全、小米、vivo等諸多知名公司。
除了搜索之外,結合Kibana、Logstash、Beats,Elastic Stack還被廣泛運用在大數(shù)據(jù)近實時分析領域,包括日志分析、指標監(jiān)控、信息安全等多個領域。
它可以幫助你探索海量結構化、非結構化數(shù)據(jù),按需創(chuàng)建可視化報表,對監(jiān)控數(shù)據(jù)設置報警閾值,甚至通過使用機器學習技術,自動識別異常狀況。

一、京東到家訂單中心 Elasticsearch 演進歷程

京東到家訂單中心系統(tǒng)業(yè)務中,無論是外部商家的訂單生產(chǎn),或是內(nèi)部上下游系統(tǒng)的依賴,訂單查詢的調(diào)用量都非常大,造成了訂單數(shù)據(jù)讀多寫少的情況。
京東到家的訂單數(shù)據(jù)存儲在MySQL中,但顯然只通過DB來支撐大量的查詢是不可取的,同時對于一些復雜的查詢,Mysql支持得不夠友好,所以訂單中心系統(tǒng)使用了Elasticsearch來承載訂單查詢的主要壓力。
Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!
Elasticsearch 做為一款功能強大的分布式搜索引擎,支持近實時的存儲、搜索數(shù)據(jù),在京東到家訂單系統(tǒng)中發(fā)揮著巨大作用,目前訂單中心ES集群存儲數(shù)據(jù)量達到10億個文檔,日均查詢量達到5億。
隨著京東到家近幾年業(yè)務的快速發(fā)展,訂單中心ES架設方案也不斷演進,發(fā)展至今ES集群架設是一套實時互備方案,很好的保障了ES集群讀寫的穩(wěn)定性。
Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!
如上圖,訂單中心ES集群架設示意圖。整個架設方式通過VIP來負載均衡外部請求,第一層gateway節(jié)點實質(zhì)為ES中client node,相當于一個智能負載均衡器,充當著分發(fā)請求的角色。
第二層為data node,負責存儲數(shù)據(jù)以及執(zhí)行數(shù)據(jù)的相關操作。整個集群有一套主分片,二套副分片(一主二副),從網(wǎng)關節(jié)點轉(zhuǎn)發(fā)過來的請求,會在打到數(shù)據(jù)節(jié)點之前通過輪詢的方式進行均衡。集群增加一套副本并擴容機器的方式,增加了集群吞吐量,從而提升了整個集群查詢性能。
當然分片數(shù)量和分片副本數(shù)量并不是越多越好,在此階段中,對選擇適當?shù)姆制瑪?shù)量做了近一步探索。
分片數(shù)可以理解為Mysql中的分庫分表,而當前訂單中心ES查詢主要分為兩類:單ID查詢以及分頁查詢。
分片數(shù)越大,集群橫向擴容規(guī)模也更大,根據(jù)分片路由的單ID查詢吞吐量也能大大提升,但對于聚合的分頁查詢性能則將降低。分片數(shù)越小,集群橫向擴容規(guī)模更小,單ID的查詢性能也將下降,但對于分頁查詢,性能將會得到提升。
所以如何均衡分片數(shù)量和現(xiàn)有查詢業(yè)務,我們做了很多次調(diào)整壓測,最終選擇了集群性能較好的分片數(shù)。
由于大部分ES查詢的流量都來源于近幾天的訂單,且訂單中心數(shù)據(jù)庫數(shù)據(jù)已有一套歸檔機制,將指定天數(shù)之前已經(jīng)關閉的訂單轉(zhuǎn)移到歷史訂單庫。

架構的快速迭代源于業(yè)務的快速發(fā)展,正是由于近幾年到家業(yè)務的高速發(fā)展,訂單中心的架構也不斷優(yōu)化升級。

架構方案沒有最好的,只有最合適的。相信再過幾年,訂單中心的架構又將是另一個面貌,但吞吐量更大,性能更好,穩(wěn)定性更強,將是訂單中心系統(tǒng)永遠的追求。

二、攜程Elasticsearch應用案例

1. 攜程酒店訂單Elasticsearch實戰(zhàn)

選擇對分片后的數(shù)據(jù)庫建立實時索引,把查詢收口到一個獨立的 Web Service,在保證性能的前提下,提升業(yè)務應用查詢時的便捷性。
最終我們選擇了 Elasticsearch,看中的是它的輕量級、易用和對分布式更好的支持,整個安裝包也只有幾十兆。
http://developer.51cto.com/art/201807/579354.htm

2. 攜程機票ElasticSearch集群運維馴服記

Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!
這個是比較通用的數(shù)據(jù)的流程,一般會通過Kafka分離產(chǎn)生數(shù)據(jù)的應用程序和后面的平臺,通過ETL落到不同的地方,按照優(yōu)先級和冷熱程度采取不同的存儲方式。
一般來說,冷數(shù)據(jù)存放到HDFS,如果溫數(shù)據(jù)、或者熱數(shù)據(jù)會采用Database以及Cache。一旦數(shù)據(jù)落地,我們會做兩方面的應用
第一個方面的應用是傳統(tǒng)BI,比如會產(chǎn)生各種各樣的報表,報表的受眾是更高的決策層和管理層,他們看了之后,會有相應的業(yè)務調(diào)整和更高層面的規(guī)劃或轉(zhuǎn)變。
這個使用路徑比較傳統(tǒng)的,在數(shù)據(jù)倉庫時代就已經(jīng)存在了?,F(xiàn)在有一種新興的場景就是利用大數(shù)據(jù)進行快速決策,數(shù)據(jù)不是喂給人的,數(shù)據(jù)分析結果由程序來消費,其實是再次的反饋到數(shù)據(jù)源頭即應用程序中,讓他們基于快速分析后的結果,調(diào)整已有策略,這樣就形成了一個數(shù)據(jù)使用的循環(huán)。
這樣我們從它的輸入到輸出會形成一種閉環(huán),而且這個閉環(huán)全部是機器參與的,這也是為什么去研究這種大規(guī)模的,或者快速決策的原因所在。
如果數(shù)據(jù)最終還會給人本身來看的話,就沒有必要更新那么快,因為一秒鐘刷新一次或者10秒鐘刷新一次對人是沒有意義的,因為我們腦子不可能一直轉(zhuǎn)那么快,基于數(shù)據(jù)一直的做調(diào)整也是不現(xiàn)實的,但是對機器來講,就完全沒有問題。
http://www.sohu.com/a/199672012_411876

3. 攜程:大規(guī)模 Elasticsearch 集群管理心得

目前,我們最大的日志單集群有120個data node,運行于70臺物理服務器上。數(shù)據(jù)規(guī)模如下:
  • 單日索引數(shù)據(jù)條數(shù)600億,新增索引文件25TB (含一個復制片則為50TB)
  • 業(yè)務高峰期峰值索引速率維持在百萬條/秒
  • 歷史數(shù)據(jù)保留時長根據(jù)業(yè)務需求制定,從10天 - 90天不等
  • 集群共3441個索引、17000個分片、數(shù)據(jù)總量約9300億, 磁盤總消耗1PB
https://www.jianshu.com/p/6470754b8248

三、去哪兒:訂單中心基于elasticsearch 的解決方案

15年去哪兒網(wǎng)酒店日均訂單量達到30w+,隨著多平臺訂單的聚合日均訂單能達到100w左右。
原來采用的熱表分庫方式,即將最近6個月的訂單的放置在一張表中,將歷史訂單放在在history表中。history表存儲全量的數(shù)據(jù),當用戶查詢的下單時間跨度超過6個月即查詢歷史訂單表,此分表方式熱表的數(shù)據(jù)量為4000w左右,當時能解決的問題。但是顯然不能滿足攜程藝龍訂單接入的需求。
如果繼續(xù)按照熱表方式,數(shù)據(jù)量將超過1億條。全量數(shù)據(jù)表保存2年的可能就超過4億的數(shù)據(jù)量。所以尋找有效途徑解決此問題迫在眉睫。
由于對這預計4億的數(shù)據(jù)量還需按照預定日期、入住日期、離店日期、訂單號、聯(lián)系人姓名、電話、酒店名稱、訂單狀態(tài)……等多個條件查詢。所以簡單按照某一個維度進行分表操作沒有意義。
Elasticsearch分布式搜索儲存集群的引入,就是為了解決訂單數(shù)據(jù)的存儲與搜索的問題。
對訂單模型進行抽象和分類,將常用搜索字段和基礎屬性字段剝離。DB做分庫分表,存儲訂單詳情;Elasticsearch存儲搜素字段。
訂單復雜查詢直接走Elasticsearch,基于OrderNo的簡單查詢走DB,如下圖所示。
Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!
系統(tǒng)伸縮性:Elasticsearch 中索引設置了8個分片,目前ES單個索引的文檔達到1.4億,合計達到2億條數(shù)據(jù)占磁盤大小64G,集群機器磁盤容量240G。
https://elasticsearch.cn/article/6197

四、Elasticsearch 在58集團信息安全部的應用

全面介紹 Elastic Stack 在58集團信息安全部的落地,升級,優(yōu)化以及應用。
包括如下幾個方面:接入背景,存儲選型,性能挑戰(zhàn),master node以及data node優(yōu)化,安全實踐,高吞吐量以及低延遲搜索優(yōu)化;kibana 的落地,本地化使其更方便產(chǎn)品、運營使用。
Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!
https://elasticsearch.cn/slides/124

五、滴滴Elasticsearch多集群架構實踐

滴滴 2016 年初開始構建 Elasticsearch 平臺,如今已經(jīng)發(fā)展到超過 3500+ Elasticsearch 實例,超過 5PB 的數(shù)據(jù)存儲,峰值寫入 tps 超過了 2000w/s 的超大規(guī)模。
Elasticsearch 在滴滴有著非常豐富的使用場景,例如線上核心的打車地圖搜索,客服、運營的多維度查詢,滴滴日志服務等近千個平臺用戶。
先看看滴滴 Elasticsearch 單集群的架構:滴滴在單集群架構的時候,寫入和查詢就已經(jīng)通過 Sink 服務和 Gateway 服務管控起來。
Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!

1. Sink服務

滴滴幾乎所有寫入 Elasticsearch 的數(shù)據(jù)都是經(jīng)由 kafka 消費入到 Elasticsearch。 kafka 的數(shù) 據(jù)包括業(yè)務 log 數(shù)據(jù)、mysql binlog 數(shù)據(jù)和業(yè)務 自主上報的數(shù)據(jù),Sink 服務將這些數(shù)據(jù)實時消費入到 Elasticsearch。
最初設計 Sink 服務是想對寫入 Elasticsearch 集群進行管控,保護 Elasticsearch 集群,防止海量的數(shù)據(jù)寫入拖垮 Elasticsearch,之后我們也一直沿用了 Sink 服務,并將該服務從 Elasticsearch 平臺分離出去,成立滴滴 Sink 數(shù)據(jù)投遞平臺,可以從 kafka 或者 MQ 實時同步數(shù)據(jù)到 Elasticsearch、HDFS、Ceph 等多個存儲服務。
有了多集群架構后,Elasticsearch 平臺可以消費一份 MQ 數(shù)據(jù)寫入多個 Elasticsearch 集群,做到集群級別的容災,還能通過 MQ 回溯數(shù)據(jù)進行故障恢復。

2. Gateway 服務

所有業(yè)務的查詢都是經(jīng)過 Gateway 服務,Gateway 服務實現(xiàn)了 Elasticsearch 的 http restful 和 tcp 協(xié)議,業(yè)務方可以通過 Elasticsearch 各語言版本的 sdk 直接訪問 Gateway 服務
Gateway 服務還實現(xiàn)了 SQL 接口,業(yè)務方可以直接使用 SQL 訪問 Elasticsearch 平臺。
Gateway 服務最初提供了應用權限的管控,訪問記錄,限流、降級等基本能力,后面隨著平臺演進,Gateway 服務還提供了索引存儲分離、DSL 級別的限流、多集群災備等能力。
https://mp.weixin.qq.com/s/K44-L0rclaIM40hma55pPQ

六、Elasticsearch實用化訂單搜索方案

搜索引擎中,主要考慮到Elasticsearch支持結構化數(shù)據(jù)查詢以及支持實時頻繁更新特性,傳統(tǒng)訂單查詢報表的痛點,以及Elasticsearch能夠幫助解決的問題。
Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!

訂單搜索系統(tǒng)架構

整個業(yè)務線使用服務化方式,Elasticsearch集群和數(shù)據(jù)庫分庫,作為數(shù)據(jù)源被訂單服務系統(tǒng)封裝為對外統(tǒng)一接口;各前、后臺應用和報表中心,使用服務化的方式獲取訂單數(shù)據(jù)。
Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!

https://my.oschina.net/u/2485991/blog/533163

特別推薦一個分享架構+算法的優(yōu)質(zhì)內(nèi)容,還沒關注的小伙伴,可以長按關注一下:

Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!

Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!

Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!

長按訂閱更多精彩▼

Elasticsearch 在各大互聯(lián)網(wǎng)公司大量真實的應用案例!

如有收獲,點個在看,誠摯感謝

免責聲明:本文內(nèi)容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!

本站聲明: 本文章由作者或相關機構授權發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內(nèi)容真實性等。需要轉(zhuǎn)載請聯(lián)系該專欄作者,如若文章內(nèi)容侵犯您的權益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或?qū)⒋呱龈蟮莫毥谦F公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉(zhuǎn)型技術解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關鍵字: 汽車 人工智能 智能驅(qū)動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務中斷的風險,如企業(yè)系統(tǒng)復雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務連續(xù)性,提升韌性,成...

關鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質(zhì)量流程IT總裁陶景文發(fā)表了演講。

關鍵字: 華為 12nm EDA 半導體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權最終是由生態(tài)的繁榮決定的。

關鍵字: 華為 12nm 手機 衛(wèi)星通信

要點: 有效應對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質(zhì)增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務引領增長 以科技創(chuàng)新為引領,提升企業(yè)核心競爭力 堅持高質(zhì)量發(fā)展策略,塑強核心競爭優(yōu)勢...

關鍵字: 通信 BSP 電信運營商 數(shù)字經(jīng)濟

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術學會聯(lián)合牽頭組建的NVI技術創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術創(chuàng)新聯(lián)...

關鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(集團)股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關鍵字: BSP 信息技術
關閉
關閉