日本熟妇hd丰满老熟妇,中文字幕一区二区三区在线不卡 ,亚洲成片在线观看,免费女同在线一区二区

汽車行業:智能輔助駕駛業務遭遇大表瓶頸,小鵬汽車如何破局?

客戶推薦語錄

PolarDB PostgreSQL版的存儲具備彈性擴容的能力,最大可支持100 TB存儲空間。它的大表優化和彈性跨機并行查詢(ePQ),成功解決了社區PostgreSQL針對大表的查詢和并發更新慢的問題。在小鵬汽車的智能輔助駕駛業務上,實現了每日TB級大數據表的7000 萬行更新和大數據表秒級分析查詢。

——小鵬汽車 SRE 負責人

客戶介紹

image.jpeg

關于小鵬汽車

小鵬汽車是中國領先的智能電動汽車公司,致力于為對技術充滿熱情的消費者設計、開發、制造和營銷智能電動汽車。公司的核心使命是通過科技驅動智能電動汽車的變革,引領未來的出行方式。為了提升客戶的駕駛體驗,小鵬汽車投入了大量資源自主研發全棧式智能輔助駕駛技術、車載智能操作系統,以及涵蓋動力總成和電子電氣架構的車輛核心系統。

業務場景

智能輔助駕駛是小鵬汽車的重點技術方向,每天有海量的圖片、視頻數據采集上傳。有海量的數據存儲在對象存儲中,同時還需要在關系數據庫中針對每個文件生成一條“目錄”,以便批量地查找和管理文件,記錄文件的位置、屬性、指標等。這就導致了這個“目錄”要覆蓋到全量的數據文件,即數據庫的超大單表,并且隨著指標的變化要經常進行表的全量數據更新。

客戶痛點

小鵬汽車原先使用的數據庫是社區PostgreSQL,隨著智能輔助駕駛業務的快速增長,系統面臨數據處理的三重挑戰:

大表查詢慢

面對海量數據,單機并行處理能力已經達到極限,無法應對 TB 級大表的查詢,小鵬汽車的智能輔助駕駛分析業務承受前所未有的壓力。小鵬汽車數據中心最龐大的數據表體量已攀升至7 TB,而超過TB級別的數據表數量更是多達四張。當大表的分析查詢時間達到數十分鐘甚至數小時時,這一數據處理瓶頸已成為制約智能輔助駕駛業務的關鍵難題,迫切需要一種新的技術解決方案來破解。

大表頻繁更新

在小鵬汽車的標注業務中,面臨著一個日益嚴峻的問題:TB級大數據表每天的更新量高達7000萬行。這一龐大的數據流量引發了一系列的問題,尤其是在 TB 級大表更新過程中,過多的文件校驗作業導致了文件系統的 IOPS 達到極限,進而導致了系統性能的急劇下降。最終,這種過載使得單行數據更新耗時達到分鐘級,進而觸發數據庫雪崩,對公司的業務運營構成了直接的威脅。

存儲空間快速增長

數據庫總容量飆升至30 TB 并且以每月2 TB的驚人速度持續增長。社區版的PostgreSQL數據庫面臨著一個嚴峻挑戰:它無法實現自動化的擴容。這樣迅猛增加的存儲需求正急劇逼近系統的極限,成為了一個亟待解決的難題。

產品方案

隨著數據量越來越大,社區版PostgreSQL遇到性能瓶頸,數據處理鏈路產生堆積,尤其是數據批量更新更是成為卡點,影響智能輔助駕駛研發效率。針對現狀和PostgreSQL生態兼容性考慮推薦客戶測試PolarDB PostgreSQL版,在兼容現有業務代碼的同時,解決單機數據庫的性能瓶頸,提高研發效率:

image.png

ePQ加速TB級大表分析查詢

ePQ是Elastic Parallel Query(彈性并行查詢)的縮寫。PolarDB PostgreSQL版通過ePQ優化器,生成能夠被多個計算節點并行執行的執行計劃。ePQ的執行引擎將在多個計算節點上協調執行該計劃,同時利用多個節點的CPU、內存、I/O帶寬來掃描和計算數據。PolarDB PostgreSQL版ePQ 的架構示意圖如下所示:

image.png

基于此架構,PolarDB PostgreSQL版的ePQ相較于社區PostgreSQL有如下優勢:

  • 優異的分析查詢性能:1TB TPC-H測試平均提升23倍性能,性能可隨并行度、節點數線性提升。

  • 業務完全透明:無須修改任何業務代碼,僅需在控制臺打開 polar_enable_px開關即可使用ePQ。

  • 一體化存儲:TP/AP 共享一套存儲數據,減少存儲成本。TP高壓力寫入下,AP引擎提供毫秒級數據新鮮度。

大表優化解決大表頻繁更新問題

image.png

客戶業務問題

在小鵬汽車的場景下,單表的大小達到TB級別,最大可達到7 TB。業務側采用短連接 + 高并發(> 400)更新的方式來訪問TB級大表。在這種情況下,大表的文件訪問操作(例如 open/lseek)會將整個數據庫的IOPS打滿,IO時延飆升,觸發數據庫雪崩。

原因分析

在社區PostgreSQL中,每張表的文件都是以Segment為單位來進行存儲,每個Segment大小為1GB。在如下三個場景需要使用open/lseek文件訪問操作來獲取文件大?。?/p>

  1. 刷臟操作:在臟頁寫入情況下,需要定位每一個臟頁需要寫入的具體位置。這個時候,需要打開寫入頁面前所有的segment文件,通過lseek獲取所有 segment文件大小并求和,最終,check臟頁寫入位置正確。

  2. DML引發的表擴展:在Insert/Update過程中,如果找不到空閑頁面,會進行表擴展。表擴展的時候需要獲取當前表的大小用來定位表擴展后的位置,獲取當前表大小需要逐個open/lseek segment文件。

  3. 優化器進行代價估計:優化器在對普通表進行代價估計時,需要獲取表大小用來判斷采用seqscan還是indexscan。獲取當前表大小需要逐個open/lseek segment文件。

小鵬汽車智能輔助駕駛場景下, 7TB的大表意味著7000個Segment文件,每次對大表進行刷臟或者表擴展的時候,單次文件寫入操作會被放大成7000 個 Segment 文件長度校驗。同時業務側還是采用短連接 + 高并發的方式訪問大表,意味著文件句柄無法緩存,只能采用文件操作(open/lseek)來訪問 Segment 文件長度,最終大表的海量文件訪問將整個數據庫的IOPS打滿,IO時延飆升,觸發數據庫雪崩。

解決辦法

PolarDB PostgreSQL版用如下三個方法解決了大表寫入問題:

  1. 二分查找獲取表大?。涸谖募U展或者優化器代價估計。社區PostgreSQL獲取表文件大小,需要逐個獲取每個 segment 大小,復雜度為 O(N);PolarDB PostgreSQL版優化過后,按 2 的倍數依次打開 segment 文件(例如 0、1、2、4、16、32....),直至文件不存在,鎖定文件大小區間,例如 [64,128)。然后在 [64,128)二分查找 segment N 存在并且 N+1 不存在,最終文件的大小鎖定為 (N-1)*segment_size + 第 N 個 segment 大小segment_size 為 1GB)。經過優化后,表文件大小獲取的復雜度由 O(N) 降低至 O(logN)。

  2. 減少冗余文件校驗:社區PostgreSQL在刷臟寫入一個頁面的時候,需要逐個打開之前所有 Segment 文件計算頁面寫入位置信息,檢查頁面寫入位置信息正確。PolarDB PostgreSQL版優化過后,在保證數據正確性的基礎上,減少冗余的文件校驗,僅獲取 SegN-1SegN兩個文件大小。

  3. 表大小緩存(Relation Size Cache):PolarDB PostgreSQL版設計的表大小緩存,會在優化器進行代價估計的時候優先采用緩存,而不是通過IO獲取文件大小。

存算分離實現彈性擴容

image.png

客戶業務問題

小鵬汽車的PolarDB PostgreSQL版實例數據量達到 30 TB,并且以平均每月2 TB的速度在增長?;?ECS 自建的PostgreSQL數據庫已無法應對數據增長的需要。

解決辦法

PolarDB PostgreSQL版基于存儲計算分離的架構,PolarStore 存儲集群可獨立擴展,支持彈性擴容,存儲按量進行計費,最大支持 100 TB 存儲,PolarStore存儲集群的讀寫帶寬穩定在 1.6 GB/s 以上。大容量 + 高帶寬確保PolarDB PostgreSQL版的 IO 和存儲空間不成為瓶頸。

客戶價值

大表分析查詢速度提升3.6倍

以數據統計業務為例,大表(這里簡稱為 xxx)的表大小為7.6 TB,通過如下語句查詢:

select count(1) as cnt from xxx where create_time>='2024-03-19 01:00:00' and create_time<'2024-03-19 02:00:00';

未使用 ePQ 查詢,采用原生單機并行查詢,并行度為 6,執行時間為 66 秒。

image.png

采用 ePQ 2個 RO 節點,24 并發查詢,執行時間可降低至 18 秒。

image.png

采用 ePQ 跨機并行查詢相較于單機并行查詢速度可提升 3.6 倍,能達到查詢性能隨并行度線性提升。再增加只讀節點,查詢速度仍可繼續提升。

數據等待事件降低至幾乎為0

下圖展示了文件系統 seek 和 open iops 的變化,紅線左側是優化前的表現,紅線右側是優化后的表現。

  • 優化前:整體的 open/seek iops 達到 30000 ~ 40000。

  • 優化后:整體的 open/seek iops 達到 5000 左右,減少 80% 的 iops 數量。

image.png

如下圖所示,圖中的每一項表示數據庫在運行過程中的等待事件總量。由原來平均 600+ 的 FileOpen/FileSeek 等待事件,優化到后面幾乎沒有 FileOpen/FileSeek 等待事件(<1)。

優化前:

image.png

優化后:

image.png

存算分離實現彈性擴容

下圖展示了小鵬客戶的總數據量和 7 天內數據增長量??倲祿窟_到37 TB 級別,數據增長量峰值達到每7天 1.5 TB,平均以每月2 TB的速度增長。但PolarDB PostgreSQL版的存儲空間不會成為瓶頸。

image.png

下圖展示了小鵬汽車智能輔助駕駛業務在業務高峰期的 IO 讀寫帶寬,穩定在 1.6 GB/s 以上。PolarDB PostgreSQL版的高讀寫帶寬確保智能輔助駕駛業務在高峰期正常運行。

image.png

總結

PolarDB PostgreSQL版的自動彈性擴容、大表優化和彈性跨機并行查詢已經成為小鵬汽車智能輔助駕駛業務應對 TB 級別大表標注、分析查詢的"利器"。同時,PolarDB PostgreSQL版針對大表的高性能解決方案也可以更好地滿足類似汽車領域內智能輔助駕駛業務的數據庫訪問需求:

  1. 支持 TB 級別大表的秒級分析查詢;

  2. 支持 TB 級別大表每日 7 千萬的頻繁標注更新;

  3. 提供 100 TB 的存儲空間、存儲彈性自動擴容、按量付費方式;

  4. 所有大表優化對業務完全透明,無需業務修改,省去開發和運維負擔。