優步分享基於Apache Kafka的Presto使用經驗
Presto和 Apache Kafka 在 Uber 的大資料堆疊中發揮著關鍵作用。
Presto 是查詢聯合的事實標準,已用於互動式查詢、近實時資料分析和大規模資料分析。
Kafka 是支援許多用例的資料流的骨幹,例如釋出/訂閱、流處理等。
透過Presto on Kafka,可以編寫一個簡單的 SQL 查詢SELECT * FROM kafka.cluster.order WHERE uuid = '0e43a4-5213-11ec'並且可以在幾秒鐘內返回結果。
越來越多的使用者正在採用 Presto on Kafka 進行臨時探索。每天有 6,000 個查詢,我們還從 Presto 使用者那裡得到了很好的反饋,他們說 Presto on Kafka 使他們的資料分析變得更加容易。
為什麼要使用Presto?
運營團隊正在調查為什麼有幾條訊息沒有被關鍵服務處理,這將對最終客戶產生直接影響。
然後運維團隊收集了報告問題的幾個UUID,並要求檢查它們是否存在於服務的輸入/輸出 Kafka 流中:
“Is the order with UUID X missing in the Kafka topic T.”
這樣的問題通常透過大資料中的實時分析來解決。在該領域可用的各種技術中,我們專注於 2 類開源解決方案,即:流處理和實時 OLAP 資料儲存。
Apache Flink、Apache Storm 或ksql等流處理引擎連續處理流並輸出處理後的流或增量維護可更新檢視。這種流處理不適合上述問題,因為使用者希望對過去的事件執行點實現查詢或執行分析查詢。
另一方面,Apache Pinot、Apache Druid 和Clickhouse 等實時OLAP資料儲存則更適合。這些OLAP儲存配備了先進的索引技術,因此它們能夠對Kafka資料流進行索引,以提供低延遲的查詢。
事實上,Uber幾年前就採用了Apache Pinot,如今Pinot是Uber資料平臺內部的一項關鍵技術,為多個關鍵任務的實時分析應用提供動力。
然而,實時OLAP需要一個非同尋常的onboarding過程,以建立一個從Kafka流中攝取的表,並調整該表以獲得最佳效能。
這個問題促使Kafka和Presto團隊共同探索一個輕量級的解決方案,並考慮到以下因素。
- 它重用了現有的Presto部署,這是一項成熟的技術,已經在Uber經過了多年的實戰檢驗。
- 它不需要onboarding,Kafka主題可以被發現,並且在建立後可以立即被查詢。
- Presto以其強大的跨資料來源的查詢聯合能力而聞名,因此它允許Kafka和其他資料來源(如Hive/MySQL/Redis)之間的關聯,以獲得跨資料平臺的洞察力。
然而,這種Presto方法也有其侷限性。例如,它的效能不如實時OLAP儲存,因為Kafka聯結器沒有建立索引,因此必須在一個偏移範圍內掃描Kafka流。此外,為了滿足Uber的可擴充套件性要求,在聯結器上還有其他挑戰需要解決,我們將在下一節詳細說明。
Presto面臨挑戰?
Presto已經有一個支援透過 Presto 查詢 Kafka的Kafka 聯結器。但是,該解決方案並不完全適合我們在 Uber 擁有的大規模 Kafka 架構。有幾個挑戰:
- Kafka 主題和叢集發現:在我們提供 Kafka 即服務的 Uber,使用者可以隨時透過自助服務門戶將新主題加入 Kafka。因此,我們需要 Kafka 主題發現是動態的。但是,當前 Presto Kafka 聯結器中的 Kafka 主題和叢集發現是靜態的,每次我們加入新主題時都需要重新啟動聯結器。
- 資料模式發現:與 Kafka 主題和叢集發現類似,我們將模式登錄檔作為服務提供並支援使用者自助登入。因此,我們需要 Presto-Kafka 聯結器能夠按需檢索最新的模式。
- 查詢限制:限制每個查詢可以從 Kafka 消費的資料數量對我們來說很重要。Uber 有許多大型 Kafka 主題,其位元組速率可以高達 500 M/s。 眾所周知,Presto-Kafka 查詢與其他替代方案相比相對較慢,從 Kafka 拉取大量資料的查詢將需要很長時間才能完成。這不利於使用者體驗,也不利於 Kafka 叢集的健康。
- 配額控制:作為分散式查詢引擎,Presto 可以以非常高的吞吐量同時消費來自 Kafka 的訊息,這可能導致 Kafka 叢集的潛在叢集降級。限制最大 Presto 消耗吞吐量對於 Kafka 叢集的穩定性至關重要。
優步的改進
Uber 的資料生態系統為使用者提供了一種編寫 SQL 查詢並將其提交到 Presto 叢集執行的方式。每個 Presto 叢集都有一個 coordinator 節點,負責解析 SQL 語句,規劃查詢,排程任務,讓 worker 節點執行。Presto 中的 Kafka 聯結器允許將 Kafka 主題用作表,其中主題中的每條訊息在 Presto 中表示為一行。在收到查詢時,協調器確定查詢是否具有適當的過濾器。驗證完成後,Kafka 聯結器從 Kafka 叢集管理服務獲取叢集和主題資訊。然後它從模式服務中獲取模式。然後 Presto 工作人員與 Kafka 叢集並行對話以獲取所需的 Kafka 訊息。我們還在 Kafka 叢集上為 Presto 使用者設定了代理配額。
詳細點選標題
相關文章
- 經驗分享:Apache Kafka的缺點與陷阱 - Emil KoutanovApacheKafka
- 分享彼此的優化經驗優化
- 基於 SAP BTP 平臺的 AI 專案經驗分享AI
- Apache基於MySQL的身份驗證(轉)ApacheMySql
- 分享一些 Kafka 消費資料的小經驗Kafka
- Apache Hudi和Presto的前世今生ApacheREST
- KMQ:基於Apache Kafka的可靠性訊息佇列MQApacheKafka佇列
- StreamNative將Kafka整合到基於Apache Pulsar的雲中KafkaApache
- Polymer使用經驗分享
- Drivetribe採取CQRS和Apache Flink的經驗分享Apache
- 使用Kafka Streams構建事件源系統的經驗Kafka事件
- 優步是如何使用Apache Flink和Kafka實現實時Exactly-Once廣告事件處理?ApacheKafka事件
- apache kafka技術分享系列(目錄索引)ApacheKafka索引
- (課程)基於Spark的機器學習經驗Spark機器學習
- 經驗分享 ----------
- 經驗分享
- [轉帖]基礎篇:JVM調優原理相關的知識和經驗分享JVM
- Apache Kafka的4個混沌工程實驗 | IDCFApacheKafka
- OB導數工具使用經驗分享
- 經驗分享:RabbitMQ與Kafka等訊息系統的使用者討論 - ycombinatorMQKafka
- 2.4 一種基於kafka增量資料校驗的方案Kafka
- 基於MySQL的分散式資料庫TDSQL十年鍛造經驗分享MySql分散式資料庫
- 關於URL優化的一些經驗優化
- Halodoc使用 Apache Hudi 構建 Lakehouse的關鍵經驗Apache
- Presto記憶體調優及原理(基礎篇)REST記憶體
- 分享一些我自己的docker使用經驗Docker
- iOS 經驗分享iOS
- Apache Kafka不適用於Event Sourcing!ApacheKafka
- 6條經過驗證的創業經驗分享創業
- 產品經理的面試經驗分享面試
- 關於啟用 HTTPS 的一些經驗分享HTTP
- 安卓應用效能除錯和優化經驗分享安卓除錯優化
- MySQL 企業常用架構與調優經驗分享MySql架構
- 個推基於 Apache Pulsar 的優先順序佇列方案Apache佇列
- Xray使用的一些經驗分享(xray+burp的使用)
- 基於THINKPHP3.2.3開發的IT行業資訊、經驗分享的個人部落格網站PHP行業網站
- Android開發之ListView使用經驗分享AndroidView
- 分享抖音交流經驗