Uber大型實時數(shù)據(jù)智能平臺建設
為什么是 Gairos?
Gairos 概述

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

單個司機的狀態(tài)轉(zhuǎ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 的客戶端可以是一項服務、一個儀表盤、一個數(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% 的要求?你想用多少分片來處理寫 / 讀流量?
客戶端
Apache Kafka
Gairos-Ingestion(加工層)
Elasticsearch(Gairos 存儲層)
RT-Gairos(查詢層)
查詢分析器
優(yōu)化引擎
索引基準服務

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 客戶端將請求發(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)化。
界定索引范圍。
清除未使用的數(shù)據(jù)。
分片和查詢路由

Write QPS:此因素要求分片應該能夠處理高峰期的流量。
Read QPS:此因素要求分片應該能夠處理峰值查詢。
Filters:查詢中使用的前 x 個頻繁過濾器。頂部過濾器可以被認為是可能的分片關鍵候選者。過濾器必須具有足夠多的不同值。
SLA:無論是分析用例還是實時用例。
Shard Size:我們建議將分片大小控制在 60 GB 以內(nèi)。


每個分片的峰值 Write QPS <= 3000 QPS
每個分片的數(shù)據(jù)大小 <= 60 GB



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

supply_status。


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

data source、granularity、by、filter、aggregations、bucketBy、sort、limit、having等。在定義簽名時,只使用以下字段:datasource、granularity、by、filter、aggregations、bucketBy、sort、limit。查詢簽名由這些字段生成,并對每個字段進行排序。rider_sessions(樣本數(shù)據(jù)集)的一些基準測試結(jié)果:

rider_sessions的查詢都很麻煩,所以我們將在其他數(shù)據(jù)源上進行更多的測試,以驗證我們得到的結(jié)果。supply_status的緩存統(tǒng)計如圖 22 所示。可以看出,supply_status的命中率在 80% 以上。命中率 QPS 在 50 左右,而設置 QPS 在 10 左右。
supply_status的緩存命中率很高,命中 QPS 在 50 左右,而設置 QPS 在 10 左右demand_jobs如圖 23 所示。命中率為 80%。
demand_jobs的緩存命中率在 80% 左右,命中有一些峰值
supply_geodriver的緩存命中率在 30% 左右
合并索引

處理繁重的查詢
分割查詢:分割查詢將多個索引查詢成多個小查詢,可以限制任意時刻查詢的分片數(shù)量。
速率限制:識別重度查詢模式并限制重度查詢的速率,可以提高集群的性能。
緩存或創(chuàng)建滾動表:對于一些命中率較高的查詢,可以考慮使用緩存或滾動表來提高性能。
遷移到 Hive/Presto:對于批量使用的情況,有些可能會遷移到 Hive/Presto。
索引模板優(yōu)化
是否使用?
是否用于過濾?
是否用于聚合?
是否需要模糊搜索?

分片優(yōu)化
界定索引范圍

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

