<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          Uber大型實時數(shù)據(jù)智能平臺建設

          共 12313字,需瀏覽 25分鐘

           ·

          2021-03-01 00:11


          在 Uber,實時數(shù)據(jù)(乘車請求數(shù)、可用司機數(shù)、天氣、游戲等)可以讓運營團隊作出明智的決定,例如動態(tài)定價、最大調(diào)度預計到達時間計算以及對我們服務的供求情況進行預測,從而改善 Uber 平臺上的用戶體驗。盡管通過確定中長期趨勢,批量數(shù)據(jù)可以提供強大的洞察力,但 Uber 服務可以將流式數(shù)據(jù)與實時處理結(jié)合起來,以每分鐘一次的方式創(chuàng)建可操作的洞察力。


          Gairos 是 Uber 的實時數(shù)據(jù)處理、存儲和查詢平臺,旨在推動大規(guī)模、高效率的數(shù)據(jù)探索。通過數(shù)據(jù)智能,團隊可以更好地理解 Uber 市場并提高其效率。應用實例包括動態(tài)定價、最大調(diào)度預計到達時間計算和供求預測。

          為保證 Gairos 可以繼續(xù)優(yōu)化它在不斷擴大的用例組合中的性能,我們重新構(gòu)建了該平臺,以實現(xiàn)更好的擴展性、穩(wěn)定性和可持續(xù)性。在這兩種最優(yōu)策略中,影響最大的是數(shù)據(jù)驅(qū)動分片、查詢路由和智能緩存。

          該平臺采用數(shù)據(jù)驅(qū)動的分片和查詢路由技術,可支持 4 倍于以往解決方案的并發(fā)查詢。有些關鍵的集群甚至已經(jīng)從每月一次宕機,穩(wěn)定為每月零宕機。自從 2018 年 12 月發(fā)布以來,該平臺通過智能緩存技術,其規(guī)模已超過10倍,緩存命中率超過80%。

          為什么是 Gairos?

          在 Uber 生態(tài)系統(tǒng)中,每個團隊都有自己的數(shù)據(jù)管道和用于自己用例的查詢服務,他們必須對此保持關注(監(jiān)督監(jiān)控、預警、維護解決方案的流處理框架等),而不是專注于系統(tǒng)優(yōu)化。Gairos 的出現(xiàn)為實時數(shù)據(jù)處理、存儲、查詢建立了統(tǒng)一的平臺,讓團隊可以將更多精力放在系統(tǒng)優(yōu)化上。與實時數(shù)據(jù)系統(tǒng)的通用任務相比,用戶可以專注于定制系統(tǒng)的業(yè)務邏輯。Gairos 的作用如下:
          1. 允許用戶在高級別上查詢數(shù)據(jù),而不用擔心數(shù)據(jù)層的所有低級別細節(jié),如潛在的異構(gòu)數(shù)據(jù)源、查詢優(yōu)化、數(shù)據(jù)處理邏輯和索引方案。
          2. 允許 Gairos 團隊在不影響消費者(通過特定領域中的數(shù)據(jù)抽象層)的情況下實驗和發(fā)展數(shù)據(jù)層。
          3. 在處理高吞吐量、低延遲調(diào)用或基于離線批處理/建模的調(diào)用時,它會根據(jù)用例進行優(yōu)化。

          Gairos 概述

          如圖 1 所示,Gairos 從不同的 Apache Kafka 主題中獲取數(shù)據(jù),然后將數(shù)據(jù)寫到不同的 Elasticsearch 集群。

          圖 1:Gairos 的簡化架構(gòu)展示了該平臺中的主要組件

          在這些 Elasticsearch 集群中, Gairos 查詢服務是查詢數(shù)據(jù)的網(wǎng)關。Gairos 客戶端將查詢發(fā)送到 Gairos 查詢服務,實時獲取數(shù)據(jù)。為了滿足 Apache Hive 和 Presto 長期分析的需要,數(shù)據(jù)還被持久存儲在 HDFS 中。

          在 Gairos 中有幾個系統(tǒng):Apache Kafka、Gairos 攝取管道、 Elasticsearch 集群,Gairos 查詢服務等。這些系統(tǒng)中的任何一個出了問題,客戶都會受到影響。Gairos 的數(shù)據(jù)管道數(shù)量隨著 Uber 市場業(yè)務規(guī)模的增長而增長。需要向 Gairos 添加越來越多的數(shù)據(jù)源來支持新的業(yè)務用例。

          Uber 用例

          通過使用 Gairos,我們得到了很多見解——在 Uber 收集用例,包括:
          1. 動態(tài)定價:動態(tài)定價服務是讀取需求和供應數(shù)據(jù)后,根據(jù)六邊形計算出特定地點和時間的動態(tài)倍數(shù)。
          2. 利用實時的供需數(shù)據(jù)生成司機動態(tài)定價和碳排放建議。

          從用戶打開 Uber 應用開始,我們把每個行程的基本數(shù)據(jù)稱為會話。這一行為引發(fā)了一系列的數(shù)據(jù)事件,從司機實際接受乘車到行程結(jié)束??紤]到系統(tǒng)的復雜性和規(guī)模,這些數(shù)據(jù)會分布在許多不同的事件流中。

          舉例來說,當司機打開 Uber 應用時,它會觸發(fā)司機的事件流。這個應用程序?qū)@示該地區(qū)提供的行程(uberPOOL、uberX、UberBLACK 等)和每一條行程的價格,這是由我們的動態(tài)定價系統(tǒng)產(chǎn)生的,并且每一條行程價格將作為單獨的事件出現(xiàn)在印象事件流中。司機接受了行程后,這一請求就被送到我們的調(diào)度系統(tǒng),它把乘客和司機配對,并把他們的車輛分配到該行程。在司機搭乘乘客時,應用程序會向調(diào)度系統(tǒng)發(fā)送一個“接車完成”事件,該事件將有效地啟動行程。當司機到達目的地,它將發(fā)送一個 “行程結(jié)束”事件,并在應用程序中表明乘客已下車。

          一個典型的行程生命周期可以跨越六個不同的事件流,這些事件是由乘客應用、司機應用和 Uber 的后臺調(diào)度服務器生成的。這些不同的事件流將串聯(lián)到一個 Uber 行程中。

          要讓我們的服務能夠根據(jù)數(shù)據(jù)洞察力迅速行動,實時地處理這些不同的數(shù)據(jù)流并進行查詢,這是一個挑戰(zhàn)。

          司機的狀態(tài)轉(zhuǎn)換

          下圖(圖 2)顯示在用戶定義的時間窗內(nèi)舊金山司機的狀態(tài)轉(zhuǎn)換匯總。這是單個查詢在一秒鐘內(nèi)返回的結(jié)果。

          圖 2:調(diào)度查詢服務從 Gairos 獲取并顯示舊金山司機的狀態(tài)轉(zhuǎn)換數(shù)據(jù)

          單個司機的狀態(tài)轉(zhuǎn)換

          下圖(圖 3)顯示了舊金山的單個司機應用在用戶定義的時間窗口中的所有狀態(tài)轉(zhuǎn)換。這個查詢與前面的查詢相同,只是多了一個過濾器來匹配給定的司機應用 UUID。

          圖 3:調(diào)度服務為給定司機獲取司機程序狀態(tài)數(shù)據(jù)并顯示

          按地理位置劃分的司機使用情況

          下圖(圖 4)顯示了按地理位置劃分的司機使用情況。

          圖 4:按地理位置劃分的司機使用情況

          最后,讓我們通過 Gairos 的數(shù)據(jù)來了解一下動態(tài)定價的原理。

          有時,許多人要求乘車,以致路上沒有足夠的車運送他們。舉例來說,壞天氣,高峰時間和特殊情況,都能讓異常多的人在同一時間想乘坐 Uber。當需求很大時,可以提高票價,以幫助確保需要搭車的人也能搭到車,這就是所謂的動態(tài)定價。

          要計算由H3(Uber的六角分層空間指數(shù))定義的六邊形的動態(tài)倍數(shù),需要從 Gairos 查詢請求數(shù)量(需求)和可用的司機數(shù)量(供給)來獲得最新數(shù)據(jù)。將這些數(shù)據(jù)輸入定價模型,定價模型將生成該位置的動態(tài)倍數(shù)。圖 5 顯示了奧克蘭體育場周圍不同的六邊形區(qū)域的動態(tài)倍數(shù),當時正在進行比賽。

          圖 5:當有賽事時,奧克蘭體育場不同六邊形的動態(tài)倍數(shù)

          可擴展性 / 可靠性方面的挑戰(zhàn)

          在 Gairos 的最初實現(xiàn)中,我們遇到了一些技術挑戰(zhàn)和無法預料的問題。

          由于使用 Gairos 的用例增加,實時數(shù)據(jù)流也隨之增加。為了方便起見, Gairos 提供了 1500+ TB 的可查詢數(shù)據(jù)總量,并提供了 30 個以上的生產(chǎn)線??偣灿?4.5 萬億條記錄,集群有 20 多個。在 Gairos 每秒發(fā)生的事件超過一百萬次。越來越重要的是,要讓系統(tǒng)更加穩(wěn)定、可擴展和可持續(xù),以便為越來越多的用例提供動力。

          接下來,我們將重點介紹在開始擴展 Gairos 之后出現(xiàn)的一些技術挑戰(zhàn):
          • 多種用例共享同一個集群將導致集群的不穩(wěn)定性。某個用例中的某些顯著變化可能會影響該集群中其他所有用例。舉例來說,如果一個用例的輸入數(shù)據(jù)量翻倍,就會影響到其它用例的數(shù)據(jù)可用性。

          • 攝取管線的滯后性是一個對所有實時流水線的普遍挑戰(zhàn)。SLA(service level agreement,服務水平協(xié)議)通常是非常緊湊的,從幾秒鐘到幾分鐘不等。若管道中的任何一個組件變慢,就會造成延遲和 SLA 錯誤。

          • 查詢性能因某些客戶端的流量峰值而降低。因為是多租戶系統(tǒng),突如其來的流量高峰可能會影響同一個集群中運行的某些查詢。

          • 有些數(shù)據(jù)源已經(jīng)不再使用。在將用例加載 Gairos 之后,就無法自動地檢查這些用例的使用情況了。不使用數(shù)據(jù)時,最好為其他用例騰出資源。

          • 有些繁瑣的查詢會導致整個 Elasticsearch 集群變慢。

          • Elasticsearch 集群主節(jié)點宕機。這可能有多種原因:網(wǎng)絡不穩(wěn)定,元數(shù)據(jù)太大無法管理,等等。

          • 有些節(jié)點有很高的 CPU 負載。這類節(jié)點有熱點問題,換句話說,它們處理的分片或讀寫流量超出了合理的資源處理能力(CPU / 內(nèi)存 / 網(wǎng)絡)。

          • 有些節(jié)點會崩潰??赡苁怯捎诖疟P故障或其他硬件故障。

          • 一些分片丟失。當一次處理多個節(jié)點時,分片僅對這些節(jié)點可用。在分片中我們可能會丟失數(shù)據(jù)。

          • 待命工程師經(jīng)常被派去維修這些管道和系統(tǒng),費用很高。

          但我們第一次迭代 Gairos 的主要問題是,Gairos 的數(shù)據(jù)是如何使用的,而不會返回到 Gairos 以指導系統(tǒng)的優(yōu)化和持續(xù)改進。Gairos 沒有主動檢查數(shù)據(jù)是否按規(guī)定使用,是否能夠根據(jù)變化進行調(diào)整 (流量模式、查詢模式等等)。對于 Gairos 自優(yōu)化項目,我們閉環(huán)(圖 6),讓用戶查詢驅(qū)動優(yōu)化,使 Gairos 更穩(wěn)定、更可擴展、更可持續(xù)。

          圖 6:新的架構(gòu)用紅色箭頭指示的新數(shù)據(jù)流為 Gairos 閉環(huán)

          要讓 Gairos 平臺更穩(wěn)定,更可擴展,更低的維護成本,就必須讓系統(tǒng)更高效、更智能。

          圖 7:高層架構(gòu)展示了平臺中的數(shù)據(jù)流。紅色箭頭代表新的數(shù)據(jù)流,淺綠色組件代表兩個新的優(yōu)化:Giaros 查詢分析器和優(yōu)化引擎

          經(jīng)修訂的高層結(jié)構(gòu)如上圖 7 所示。該系統(tǒng)的主要組成部分如下:
          • 客戶端:Gairos 的客戶端可以是一項服務、一個儀表盤、一個數(shù)據(jù)分析師等。

          • Apache Kafka:我們使用 Apache Kafka 作為消息隊列系統(tǒng)來處理服務中的事件、RT-Gairos 查詢以及 Gairos 平臺的指標和事件。

          • Gairos-Ingestion:Gairos-Ingestion 組件接收來自不同數(shù)據(jù)源的數(shù)據(jù)并向 Gairos 發(fā)布事件。

          • Elasticsearch 集群:這些集群從 Gairos-Ingestion 管道中存儲輸出數(shù)據(jù)。

          • RT-Gairos(Real-time-Gairos):RT-Gairos 是 Gairos 查詢服務。它作為所有 Elasticsearch 集群的網(wǎng)關。

          • 查詢分析器:Gairos 查詢分析器分析從 RT-Gairos 收集的查詢,并為我們的優(yōu)化引擎提供一些見解。

          • 優(yōu)化引擎:Gairos 優(yōu)化引擎根據(jù)查詢結(jié)果和系統(tǒng)統(tǒng)計數(shù)據(jù)優(yōu)化 Gairos 的攝取管道、 Elasticsearch 集群 / 索引設置以及 RT-Gairos。舉例來說,一個攝取管道需要使用多少容器,才能達到 SLA 99% 的要求?你想用多少分片來處理寫 / 讀流量?

          下面,我們詳細介紹一下這些組件在整個 Gairos 生態(tài)系統(tǒng)中各自負責的內(nèi)容。

          客戶端

          客戶端可以是服務,也可以是數(shù)據(jù)分析師等非服務用戶。

          服務客戶端包括所有依賴 Gairos 為用戶提供服務的實時服務,包括我們的動態(tài)定價和行程預測服務。這些服務會將一些事件發(fā)送到 Apache Kafka,供下游服務和管道處理。在為請求提供服務時,它們可以從 Gairos 中查詢一些數(shù)據(jù),然后作出決策。例如,預測服務可能需要查詢來改進預測,以預測高流量事件中司機伙伴的需求和供應,或者我們的動態(tài)定價服務可能會利用 Gairos 根據(jù)需求、供應和一些預測輸入來確定動態(tài)倍數(shù)。

          Apache Kafka

          Apache Kafka 是一種分布式流媒體平臺,允許客戶端發(fā)布 / 訂閱事件流。全部實時服務都可以向其發(fā)送重要事件,以供下游服務 / 管道使用。RT-Gairos 還使用它來收集運行在 Gairos 中的所有查詢。

          Gairos-Ingestion(加工層)

          Gairos-ingestion 是一種攝取框架,用于處理來自不同數(shù)據(jù)源的數(shù)據(jù),并將其發(fā)布到 Gairos。有些數(shù)據(jù)源使用 Apache Spark 流。

          Elasticsearch(Gairos 存儲層)

          Gairos 存儲層 Elasticsearch 對 Gairos-Ingestion 使用的 30 多個不同數(shù)據(jù)源的數(shù)據(jù)進行索引,并為 Gairos 客戶的查詢做了準備。

          RT-Gairos(查詢層)

          RT-Gairos 作為 Gairos 的網(wǎng)關。在到達 Gairos 存儲層之前,所有的查詢都會經(jīng)過它。實時 Gairos 會強制執(zhí)行訪問控制、提供路由,并緩存一些查詢結(jié)果。RT-Gairos 會收集所有到 Gairos 的查詢,并推送到 Apache Kafka 主題。

          查詢分析器

          查詢分析器對從 RT-Gairos 收集到的查詢進行分析,并生成用于 Gairos 優(yōu)化引擎輸入的見解。首先,利用簡單的技術(過濾指標、聚合、時間范圍、分片數(shù)、索引數(shù))來生成查詢模式。

          優(yōu)化引擎

          Gairos 優(yōu)化引擎根據(jù)系統(tǒng)統(tǒng)計數(shù)據(jù)和從 Query Analyzer 獲得的查詢信息,推薦使用其生命周期知識庫進行一些優(yōu)化。這會更新 Gairos 的設置:Ingestion-path、RT-Gairos 和 Elasticsearch。

          有些設置更改可能需要進行基準測試,以了解在應用給定的更改之前 KPI 是否會得到改進。舉例來說,對于一個數(shù)據(jù)源,最佳的分片數(shù)量是多少?這就是索引基準測試服務的作用。

          索引基準服務

          要優(yōu)化 Gairos 的設置,我們需要使用一個基準測試工具來比較基于已定義 KPI 的不同設置(讀 / 寫吞吐量、延遲、內(nèi)存使用等等)。

          如圖 8 所示,我們概述了 Gairos 基準測試服務的不同組成部分。

          圖 8:索引基準服務將進行測試并保存測試結(jié)果

          這些組件包括:
          • Elasticsearch Production Clusters:Elasticsearch 生產(chǎn)集群包含用于負載測試的將復制到暫存的生產(chǎn)數(shù)據(jù)。生產(chǎn)索引可用作基準測試基準。

          • Elasticsearch Staging Clusters:這些集群被用來存儲測試數(shù)據(jù),也就是隨機生成的數(shù)據(jù),或者用來做實驗的生產(chǎn)數(shù)據(jù)。

          • Benchmarking Service:基準測試服務接受索引的不同設置,并針對不同設置的索引進行基準測試。測試完成后,測試結(jié)果可供其他服務使用。

          • Load Test Tool:給定大量的讀 / 寫請求,這個工具可以模擬不同數(shù)量的讀 / 寫 QPS(每秒查詢)并記錄 KPI。讀取將從生產(chǎn)中的 RT-Gairos 收集查詢。寫入將從生產(chǎn)中使用的相關 Apache Kafka 主題或直接發(fā)布主題進行模擬。


          Gairos 基準測試服務將接受 Gairos 優(yōu)化引擎的請求,并進行基準測試?;鶞蕼y試服務將復制單個索引,而不是從生產(chǎn)到暫存的整個歷史記錄,從而提高性能并減少資源使用。如果各個索引的性能都有提高,那么這個數(shù)據(jù)源的總體性能也會提高,因為它可以獨立執(zhí)行針對不同索引的查詢。在評估測試結(jié)果之后,優(yōu)化引擎可以決定是否更改生產(chǎn)環(huán)境中的索引設置。

          如圖 7 所示,整個系統(tǒng)涉及不少步驟。這些步驟包括:
          • Gairos 客戶端將請求發(fā)送到 RT-Gairos 以獲取數(shù)據(jù)。

          • Gairos-ingestion 攝取來自 Apache Kafka 主題的數(shù)據(jù)并將其發(fā)布到 Elasticsearch 集群。

          • Gairos 索引數(shù)據(jù),并為查詢做好準備。

          • RT-Gairos 將查詢轉(zhuǎn)換為 Elasticsearch 查詢,并從 Elasticsearch 集群中獲取數(shù)據(jù)。

          • RT-Gairos 將數(shù)據(jù)發(fā)送回客戶端。

          • RT-Gairos 向 Apache Kafka 主題發(fā)送查詢信息。

          • Sample Elasticsearch 集群數(shù)據(jù)定期 向 Apache Kafka 主題發(fā)送信息。

          • Query Analyzer 從查詢 Apache Kafka 主題中提取查詢信息進行分析。

          • Optimization Engine 從 Apache Kafka 主題中提取 Gairos 平臺統(tǒng)計數(shù)據(jù)進行分析。

          • Optimization Engine 從 Query analyery 分析器中提取 Gairos 查詢見解,以查看是否需要執(zhí)行任何操作。

          • Optimization Engine 將優(yōu)化計劃推送到 Gairos 平臺的不同組件。

          優(yōu)化策略

          我們應用了一些優(yōu)化策略,其他組織也可以用來優(yōu)化他們的實時智能平臺。
          • 分片和查詢路由。

          • 基于查詢模式和簽名的緩存。

          • 合并索引。

          • 處理繁重的查詢。

          • 索引模板優(yōu)化。

          • 分片優(yōu)化。

          • 界定索引范圍。

          • 清除未使用的數(shù)據(jù)。

          我們將逐一詳細闡述。

          分片和查詢路由

          分片就是通過一些鍵對數(shù)據(jù)進行分區(qū),這樣就可以將鍵相同的數(shù)據(jù)放入一個分片中。當寫入 Elasticsearch 索引時,必須提供鍵才能將文檔放到正確的分片中。在查詢數(shù)據(jù)時,如果在查詢中指定了鍵,則可以向特定的分片發(fā)送查詢,而不是向所有分片發(fā)送查詢。這樣減少查詢所需的節(jié)點數(shù)量,可以提高延遲,提高彈性(如果單個節(jié)點宕機,但查詢不需要,也沒關系)。

          假設我們想給舊金山的所有司機發(fā)送一個促銷優(yōu)惠,我們需要司機列表。在下圖 9 中,我們查詢的是舊金山的所有司機。在頂部的數(shù)據(jù)沒有按照城市進行分片,查詢必須在所有四個分片中進行,以檢查是否有司機可用。在底部的數(shù)據(jù)是按照城市進行分片的。查詢只需從包含舊金山的司機的分片中檢索數(shù)據(jù)即可??梢钥吹?,進行查詢的次數(shù)從 4 次減少到 1 次。


          圖 9:舊金山中的司機查詢需要查詢所有分片而不需要進行分片,而它只查詢一個帶分片的分片

          分片的一個常見問題是熱點問題(某些分片需要處理比其他分片高得多的寫入 / 查詢流量)。例如,如果我們按城市 ID 來分發(fā)聚合的匿名司機伙伴數(shù)據(jù),有些城市(包括舊金山)的規(guī)模遠比小城市大,從而導致了特定分片或節(jié)點負擔過重。為了幫助分配決策和負載分配,要使分片的大小和效用大致相等,這一點非常重要。

          在進行分片時需要考慮的因素如下:
          • Write QPS:此因素要求分片應該能夠處理高峰期的流量。

          • Read QPS:此因素要求分片應該能夠處理峰值查詢。

          • Filters:查詢中使用的前 x 個頻繁過濾器。頂部過濾器可以被認為是可能的分片關鍵候選者。過濾器必須具有足夠多的不同值。

          • SLA:無論是分析用例還是實時用例。

          • Shard Size:我們建議將分片大小控制在 60 GB 以內(nèi)。

          根據(jù) Write/Read QPS 和分片大小計算分片的數(shù)量。下面是尋找分片鍵的過程(圖 10)。一旦確定了分片鍵,我們就使用歷史數(shù)據(jù)來檢查分片分布是否在 Gairos 給定的閾值內(nèi)。


          下圖 11 所示是一個簡化的分片示例。對于本例,假設每個節(jié)點可以處理 3000 個 Write QPS,并且最多可以存儲 60 GB 數(shù)據(jù)。僅考慮數(shù)據(jù)大小和峰值 Write QPS。


          圖 11:基于給定的約束條件,將四個具有不同數(shù)據(jù)量(即我們平臺上的用戶量較大)和不同 QPS 的城市劃分為四個分片。

          分片必須滿足以下約束:
          • 每個分片的峰值 Write QPS <= 3000 QPS

          • 每個分片的數(shù)據(jù)大小 <= 60 GB

          這樣做的目的是將數(shù)據(jù)盡可能均勻地分布在這些分片上。

          根據(jù)每個城市的數(shù)據(jù)大小,我們可以估算出分片的數(shù)量:

          Shard # based on data size(30GB + 50GB + 80GB + 20GB)/60GB = 3

          根據(jù)峰值 QPS,我們可以得到另一個估計的分片數(shù)量:

          Shard # based on peak QPS(2k + 3k + 5k + 1k)/3k = 4

          求出這兩個估計值的最大值:

          **Shard #**max(3, 4) = 4

          這四座城市將被放在四個分片中。舊金山和南達科他州可以放在同一個分片里。洛杉磯可以放在一個分片里。紐約可以分成兩個分片。這樣數(shù)據(jù)就會更均勻地分布在不同的分片中,同時每個節(jié)點都可以容納數(shù)據(jù)并處理峰值 QPS。

          如果要查詢舊金山的司機,可以直接轉(zhuǎn)到 1 號分片。而查詢紐約的司機,則需要同時指向 3 號和 4 號分片。

          為了緩解傾斜的分片和熱點問題,我們?yōu)?Gairos 開發(fā)了一種定制分片算法,下表 12 是默認分片(之前)和我們的分片算法(之后)的最大 / 最小文檔數(shù)。

          表 12:我們的分片算法生成的分片在文檔數(shù)量上差異較小,文檔在分片上分布更均勻

          可以看出,文檔在這些分片中的分布得更均勻。在 Gairos 的默認分片算法中,每個分片的最大和最小文檔數(shù)比是 2.76;而我們的定制分片算法是 1.3。

          為了檢查它們可以支持的延遲和并發(fā)用戶,我們做了一些基準測試。需求數(shù)據(jù)源的結(jié)果如下。

          圖 13 顯示了不同數(shù)量客戶端下的延遲。可見,有分片的數(shù)據(jù)延遲比沒有分片的低。客戶端數(shù)量越多,差異就越大。

          圖 13:對于需求數(shù)據(jù)來說,使用分片的延遲要低得多,并且隨著客戶端數(shù)量的增加,這種差異將會越來越大,這在本用例中已經(jīng)有描述

          在不同數(shù)量的客戶端中,圖 14 顯示了它能夠支持的并發(fā)用戶數(shù),可以看到,有分片的 QPS 的最高數(shù)量大約是沒有分片的 4 倍左右。

          圖 14:有分片的 QPS 是沒有分片的 QPS 的 4 倍

          下面我們分享一下第二個數(shù)據(jù)源supply_geodriver的一些優(yōu)化結(jié)果。相對于需求數(shù)據(jù)源(存儲乘客請求),文檔數(shù)量更多,數(shù)據(jù)大小更大。

          圖 15:使用分片的延遲較高,并且差異隨著客戶數(shù)量的增加而增加

          如圖 15 所示,使用分片后,平均延遲較差。就其能夠支持的并發(fā)用戶數(shù)量而言,延遲是未使用分片時間的 4 倍,見下圖 16。

          圖 16:有分片的 QPS 是沒有分片的 QPS 的 4 倍

          第三個數(shù)據(jù)源是supply_status。

          圖 17:當客戶端數(shù)量較少時,使用分片的延遲較高,當客戶端數(shù)量超過 200 時,延遲就會降低

          圖 18:有分片的 QPS 是沒有分片的 QPS 的 4 倍

          圖 17 表明,當客戶端數(shù)量較少時,使用分片的平均延遲較高。當客戶端數(shù)量超過 200 的情況下,平均延遲會降低。從圖 18 中 可以看出,使用分片時,它可以支持的并發(fā)用戶最多,大約是沒有分片時的 4 倍。

          綜上所述,延遲對于某些大型數(shù)據(jù)源來說可能更糟糕,而且它能夠支持的并發(fā)用戶數(shù)量總是 4 倍于不分片的數(shù)量。要想在某些大型數(shù)據(jù)源中獲得延遲和可擴展性,我們可以為每一個分區(qū)調(diào)整分區(qū)大小。

          圖 19:動態(tài)定價集群的 CPU 負載呈現(xiàn)出每日模式,并在一天中隨著時間的推移而增加。峰值 CPU 負載從 60 降低到 10,每個節(jié)點的負載在一天中略有變化

          作為分片策略的副產(chǎn)品,我們能夠穩(wěn)定定價集群,如圖 19 所示。由于所有索引都是日索引,所以我們的定價集群中的節(jié)點的 CPU 負載都呈現(xiàn)每日模式。在一天的時間里,我們可以看到 CPU 負載隨著時間的推移而增加。將分片策略應用到定價集群中的所有數(shù)據(jù)源上,CPU 負載穩(wěn)定。

          基于查詢模式和簽名的緩存

          最簡單的緩存方法是緩存所有查詢結(jié)果。但由于我們的數(shù)據(jù)非常大,這些結(jié)果的總大小會比原始數(shù)據(jù)大。

          此外,有些查詢的執(zhí)行頻率不高,其緩存命中率也比較低。為了讓緩存更節(jié)省資源,我們又引入了兩個概念:查詢簽名和查詢模式。我們先通過一個 Gairos 查詢的例子,來了解 Gairos 查詢是什么樣子的。


          Gairos 查詢是一個 JSON 對象,它可能包含下列字段:data source、granularity、byfilter、aggregationsbucketBy、sort、limithaving等。在定義簽名時,只使用以下字段:datasource、granularity、by、filter、aggregations、bucketBy、sort、limit。查詢簽名由這些字段生成,并對每個字段進行排序。

          查詢模式的定義與字段集相同。惟一的區(qū)別是查詢模式只考慮所使用的列,而忽略了過濾器中的操作符和值。對于 Gairos 查詢,可以使用查詢模式和簽名進行更有效的分析。

          根據(jù)查詢模式,我們可以定義 RT-Gairos 的緩存規(guī)則,以便 RT-Gairos 能夠?qū)ΤS玫牟樵兘Y(jié)果進行緩存。舉例來說,客戶端以固定的時間間隔(1 分鐘、5 分鐘、1 小時等)來拉取最近兩周的數(shù)據(jù)。若能按天緩存數(shù)據(jù),則索引命中率將大大提高,緩存可用于改進搜索性能??梢詫Ψ秶丿B的重復查詢以及基于查詢模式的時間粒度應用相似的策略。為提高緩存命中率,需要對查詢進行分片,在此過程中,如果查詢是可分片的,每一個查詢都會根據(jù)查詢的時間范圍分片成多個小查詢。有些聚合不能從單一子查詢結(jié)果中獲取聚合結(jié)果。這些查詢將存儲在 Elasticsearch 集群而非緩存中。

          下面我們重點介紹一下緩存rider_sessions(樣本數(shù)據(jù)集)的一些基準測試結(jié)果:

          圖 20:使用緩存的延遲要低得多,而且隨著客戶端數(shù)量的增加,差異也會顯著增加。

          圖 21:有緩存的 QPS 是沒有緩存的 QPS 的 10 倍

          如圖 20 所示,當我們將緩存應用于這些查詢時,平均延遲會大大降低。從圖 21 可以看出,它能 夠支持的并發(fā)用戶數(shù)量非常大。因為大部分針對rider_sessions的查詢都很麻煩,所以我們將在其他數(shù)據(jù)源上進行更多的測試,以驗證我們得到的結(jié)果。

          supply_status的緩存統(tǒng)計如圖 22 所示。可以看出,supply_status的命中率在 80% 以上。命中率 QPS 在 50 左右,而設置 QPS 在 10 左右。

          圖 22:supply_status的緩存命中率很高,命中 QPS 在 50 左右,而設置 QPS 在 10 左右

          另一個數(shù)據(jù)源demand_jobs如圖 23 所示。命中率為 80%。

          圖 23:demand_jobs的緩存命中率在 80% 左右,命中有一些峰值

          圖 24:supply_geodriver的緩存命中率在 30% 左右

          圖 25:對于需求,根本沒有緩存命中

          最后,從圖 25 可以看出,需求的緩存命中率為 0??梢?,對于不同的數(shù)據(jù)源,使用緩存的效果有很大差異。為了提高緩存命中率,我們計劃做更多的調(diào)整。

          合并索引

          Elasticsearch 是使用倒置索引來使搜索速度更快。當刪除一個文檔時,該文檔將被標記為已刪除,它仍然存在于倒置索引中。已刪除文檔將從搜索結(jié)果中排除。若刪除的文檔數(shù)量較多,則索引大小較大。

          刪除這些文件還會影響搜索性能。例如,在圖 26 中,司機 D1、D2、D3 都更新了多次??梢钥吹?,有 8 個文檔,而司機只有 3 個。在合并索引之后,將清除這些刪除的文檔,并且使索引的大小減小。

          圖 25:對于需求,根本沒有緩存命中

          另一個提高索引性能的重要因素是索引中段的數(shù)量。我們會做一些基準測試,以決定應該使用什么時候才能合并索引。該基準將使用的關鍵指標是索引大?。ù鎯λ饕拇鎯臻g有多大)和搜索延遲(查詢數(shù)據(jù)所需的時間)。收集到的來自實時系統(tǒng)的查詢將用于搜索性能基準測試。

          在確定了每個數(shù)據(jù)源的合并索引標準之后,優(yōu)化引擎可以執(zhí)行一些索引優(yōu)化任務。集群將限制合并索引任務的數(shù)量,以便重新索引對于集群性能沒有太大影響。為了防止性能的顯著下降,任何時候最多只能運行一個合并索引任務。若發(fā)現(xiàn)有任何明顯的影響,所有強制合并的任務將被中止。

          處理繁重的查詢

          某些重度查詢可能會影響整個集群的性能。

          為了使集群更加穩(wěn)定,可采取下列策略:
          • 分割查詢:分割查詢將多個索引查詢成多個小查詢,可以限制任意時刻查詢的分片數(shù)量。

          • 速率限制:識別重度查詢模式并限制重度查詢的速率,可以提高集群的性能。

          • 緩存或創(chuàng)建滾動表:對于一些命中率較高的查詢,可以考慮使用緩存或滾動表來提高性能。

          • 遷移到 Hive/Presto:對于批量使用的情況,有些可能會遷移到 Hive/Presto。

          索引模板優(yōu)化

          從運行的查詢中,可以得到每個數(shù)據(jù)源中每個字段的以下信息,這樣我們就可以為每個字段確定索引設置。

          1. 是否使用?

          2. 是否用于過濾?

          3. 是否用于聚合?

          4. 是否需要模糊搜索?


          每個數(shù)據(jù)源都必須回答以下問題:用戶是否需要拉取原始數(shù)據(jù)。基于這些輸入,可以為每個數(shù)據(jù)源獲得最佳索引設置??梢詫?yōu)化引擎更新為數(shù)據(jù)源存儲的模板,以便我們能夠獲得更好的磁盤空間或搜索性能。某些設置(例如禁用源文件)是不向后兼容的,在執(zhí)行之前需要經(jīng)過一些批準。注意,禁用源文件會導致無法進行更新和重新編制索引。不應該在業(yè)務邏輯需要更新文檔時禁用源代碼。

          因為數(shù)據(jù)是自動持久化的,并且很容易重放,所以發(fā)布的 Apache Kafka 主題在源被禁用前會轉(zhuǎn)變?yōu)闊峁艿乐黝},這樣就可以通過重放 Apache Kafka 持久主題中的事件來遷移數(shù)據(jù)。

          圖 27 顯示了確定每個字段設置的詳細工作流程。

          圖 27:根據(jù)使用情況,確認各字段的設置

          分片優(yōu)化

          每一個數(shù)據(jù)源復制一個到暫存集群的索引,然后使用索引工具將復制的索引重新索引到不同數(shù)量的分片。對于已復制和已重新索引的數(shù)據(jù),基準測試將收集性能數(shù)據(jù)。所用查詢將來自用戶以前收集的查詢。在為每個數(shù)據(jù)源確定了最佳分片后,查詢優(yōu)化可以在新索引中設置新分片編號。

          界定索引范圍

          據(jù)觀察,許多非常小的索引是在一些集群中生成的。這類索引有大量的分片。這在集群中引起了分片分配問題。一些節(jié)點可能有許多未使用的分片,而一些節(jié)點可能有許多繁忙分片,這會導致節(jié)點之間的負載不平衡和資源利用率低。

          由于時間戳出界,通常會出現(xiàn)這些小的索引。在寫入 Elasticsearch 集群時,根據(jù)每個數(shù)據(jù)源的數(shù)據(jù)保留和數(shù)據(jù)預測對數(shù)據(jù)進行過濾,從而避免創(chuàng)建這些接近空的索引,減少分片的數(shù)量。這里有一個群集示例。下面的圖 28 顯示在我們的一個集群中,經(jīng)過清理這些小索引之后,分片數(shù)量從 4 萬左右下降到 2 萬。

          圖 28:清理完這些小索引后,分片數(shù)量從 4 萬左右下降到 2 萬

          清除未使用的數(shù)據(jù)

          所收集的查詢可以確定最近 X 天內(nèi)是否使用了數(shù)據(jù)源?;诖诵畔?,Gairos 優(yōu)化引擎可以執(zhí)行各種數(shù)據(jù)清理任務,比如觸發(fā)通知,刪除數(shù)據(jù)存儲中數(shù)據(jù)源的索引等。

          未來工作

          這些優(yōu)化策略已經(jīng)被應用于一些主要的數(shù)據(jù)源中。我們正計劃將優(yōu)化范圍擴展到所有數(shù)據(jù)源,尤其是那些用于分片和緩存的數(shù)據(jù)源。

          整個過程不是自動化的。一旦我們從對這些數(shù)據(jù)源的優(yōu)化中積累了足夠的領域知識,并應用了這些優(yōu)化,我們就會投入更多的精力來實現(xiàn)整個過程的自動化。

          一些機器學習/深度學習方法也可用于查詢分析器,我們將在未來的迭代中對此進行探索。

          作者 | Uber官方博客譯者
          來源 | https://www.infoq.cn/article/xPQ4MqwKGEbNrrMAZlsY



          物聯(lián)網(wǎng)時代的答案 - Apache IoTDB

          我們在學習Flink的時候,到底在學習什么?

          一線互聯(lián)網(wǎng)公司面試進階全攻略



          歡迎點贊+收藏+轉(zhuǎn)發(fā)朋友圈素質(zhì)三連


          文章不錯?點個【在看】吧
          瀏覽 44
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  精品6区 精品第一 | 午夜福利天天射天天操 | 亚洲国产成人在线播放 | 蜜臀久久99精品久久久久久酒店 | 日韩手机在线视频 |